Forum: Mikrocontroller und Digitale Elektronik Übertragungsprotokoll


von Michael K. (mmike)


Lesenswert?

Hallo Leute,
in der Arbeit entwickeln wir einen unbemannt fliegenden Hubschrauber und 
haben für die Datentragung eine bidirektionale Funkstrecke 
(Schnittstellen sind RS232 - 19200). Jetzt müssen für den RP (Remotely 
piloted, Fliegen aus der Bodenkontollstation) Flug periodisch Daten mit 
25Hz übertragen werden. Das ist noch nicht das Problem, denn wenn hier 
mal ein Datenpaket hops geht machts nicht viel, denn das nächste kommt 
ja bald nach (zeitlich gesehen). Jetzt sollen aber noch 
Einstellparameter für den Autopiloten übertragen werden, bei denen 
sichergestellt werden muss daß diese auch ankommen. Zudem wäre auch 
wünschenswert zu wissen wann die angekommen sind.
Beispiel:
* Reglerparameter wird auf einer GUI eingestellt
* Der Sync - Button wird gedrückt und wird rot
* Sobald vom Regler die Bestätigung kommt, daß der Wert erfolgreich 
angekommen ist soll der Sync - Button grün werden.

Gibt es hierfür schon fertige Protokolle, die ich verwenden könnte ?

Beste Grüße,
Michael

von Michael K. (mmike)


Lesenswert?

Nachtrag:
Ein periodisches Datenpaket enthält die Steuergrößen für den 
Hubschrauber (rund 25 bytes).
Ein Datenpaket für den Flugregler ist dabei nur nur 10 Bytes groß.
Grüße,
Michael

von Frank (Gast)


Lesenswert?

Hm, würde da nicht ein simples ACOP reichen? Also Daten mit ACK oder NAK 
bestätigen. Wenn die Pakete ne Prüfsumme haben, dann kann der Empfänger 
feststellen ob das Paket OK war und ein ACK zurückschicken, ansonsten 
antwortet er mit NAK und bekommt das Paket nochmal.

bye

Frank

von Stefan (Gast)


Lesenswert?

Willst du Fehlerkorrektur (1) betreiben oder nur z.B. anhand einer 
Prüfsumme (2) oder eines Hashes (3) erkennen ob gültige Daten vorliegen?

Bei deinen kleinen Datenblöcken ist X-Modem (4) vielleicht nicht 
angebracht. Aber vielleicht kannst du was ähnliches für 
"Datenübertragung mit kleinen Blockgrößen" stricken.

Ein Bereich wo solche Protokolle bestimmt verwendet werden ist der RFID 
Bereich, wo mit jedem Byte geknausert wird.

(1) http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren
(2) http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check
(3) http://de.wikipedia.org/wiki/Hash-Funktion
(4) http://de.wikipedia.org/wiki/X-Modem

von Michael K. (mmike)


Lesenswert?

Die eingesetzten Funkmodems kann man eine CRC - Prüfung einschalten, was 
wir auch vorhaben, jedoch kommt am Empfänger kein Datenpaket an, wenn 
die Prüfsumme nicht überein stimmt. Somit weiß der Empfänger nicht ob 
was gekommen ist oder nicht.
Die Prüfsumme könnte man schon auch selbst machen, jedoch müsste dann 
eine Art Message ID mit angehängt werden, damit der Empfänger melden 
kann, welche Message nicht richtig angekommen ist ...

von Michael K. (mmike)


Lesenswert?

@Stefan: Ich hatte auch schon geschaut, bei den ganzen XX-Modem (X, Y, 
Z) Protokollen, aber so richtig getaugt hat mir da keins, da die 
Datenpakete einfach zu groß sind.
Werd mal bei RFID schauen ob es da was gibt .....
Grüße,
Michael

von Frank (Gast)


Lesenswert?

Wenn der Empfänger jedes Paket quittieren muss, dann kann man auf die 
Numerierung verzichten. Das aktuelle Paket muss erst quittiert sein 
bevor das Nächste gesendet wird.

bye

Frank

von Michael K. (mmike)


Lesenswert?

@Frank: Die Datenübertragung läuft zudem auch bidirektional! Dem Heli 
werden die Steuerdaten geschickt und gleichzeitig schickt der Heli die 
Telemetriedaten wie Lage, Rate, Position .... etc.
Da dann zwischendrin ein NAK zu senden geht zwar nur weiß der Empfänger 
in der Bodenstation dann nicht wozu dieses NAK gehört ...
Grüße,
Michael

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Was du suchst ist ein ARQ-Protokoll. Da gibt es verschiedene Verfahren, 
das einfachste (was hier schon ungefähr beschrieben wurde) ist 
Stop-and-Wait ARQ.

http://de.wikipedia.org/wiki/ARQ-Protokoll

von Frank (Gast)


Lesenswert?

Doch, das NAK gehört dann zu dem letzten gesandten Paket, Welches noch 
nicht beantwortet wurde. Und da es nun negativ beantwortet wurde muss es 
eben erneut geschickt werden.

bye

Frank

von Michael K. (mmike)


Lesenswert?

@Andreas: Das "Selective Repeat ARQ" gefällt mir gut! Jeder 
Reglerparameter wird mit einer eindeutigen ID verschickt. Der Sender in 
der Bodenstation wartet dann eine bestimmte Zeitdauer ab ob dieses Paket 
dann vom Empfänger im Heli bestätigt wird. Wenn nicht wird erneut 
gesendet.
@Frank: Das Problem was ich hierbei sehe ist das hierbei "mitgezählt" 
werden muss wann welches Paket nicht bestätigt wird (NAK). Wenn wir die 
Funkmodems in dem "Auto-CRC" Modus verwenden ist dieser Modus gar nicht 
möglich. Ansonsten könnte es ja im "Worst - Case" so sein, daß der 
Sender in der Bodenstation einen Parameter losschickt der am Empfänger 
defekt ankommt. Jetzt sendet der Heli ein "NAK" an die Bodenstation, die 
wiederum schon 2 weitere Parameter verschickt hat. Zu welchem Paket 
gehört dann das NAK ?
Grüße,
Michael

von Frank (Gast)


Lesenswert?

Wenn keine Frames gezählt werden darf eben nichts Neues gesendet werden 
bevor quittiert wurde. Ansonsten muss man die Frames eben numerieren und 
anhand der Nummern bearbeiten. Bedeutet aber Einiges an Datenoverhead.

bye

Frank

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Selective Repeat würde ich nicht verwenden, das ist unnötig komplex. Das 
macht nur Sinn wenn großer Durchsatz erzielt werden soll - das dürfte in 
deinem Fall ja nicht der Fall sein. Ich würde Stop-and-Wait nehmen.

Abgesehen davon ist das Wiederholen nur bei den Steuerdaten nötig, nicht 
bei den Telemetriedaten - die kann man ja einfach kontinuierlich 
raussenden, wenn was verloren geht ist eine Wiederholung eines alten 
Paketes sinnlos.

von Michael K. (mmike)


Lesenswert?

@Frank: Stimmt. Nichts neu senden zu dürfen ist leider ein No-GO. Denn 
in der Zeit würden auch keine Steuerdaten zum Heli übertragen werden. 
Außer man fährt "zwei" Kanäle. Die Steuerdaten laufen unabhängig von den 
Reglerparametern. Das würde gehen....
Der Datenoverhead sollte nicht das Problem sein. Wir haben schon 
Telemetriedaten (38 Bytepaket) mit über 50Hz nach unten geschickt, also 
die Bandbreite ist vorhanden. Wenn jetzt die Steuerdaten mit 25Hz (25 
Bytepaket) geschickt werden sollten noch genug Reserven vorhanden sein 
für die Reglerparameter....
Vielen Dank an alle schon mal !
Grüße,
Michael

von Frank (Gast)


Lesenswert?

na dann pack einfach einen 8-bit-Counter mit dazu. Der dürfte 
ausreichen. Frames die länger als 255 weitere Pakete gebraucht haben 
dürften eh zu vergessen sein bzw sollte der Empfänger dann mal mit einem 
gezielten ENQ nachfragen wo das Paket denn bleibt.

bye

Frank

von Michael K. (mmike)


Lesenswert?

@Frank: Klingt sehr gut! Werd's mal umsetzten und berichten ....

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.