www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Übertragungsprotokoll


Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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 ...

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael K. (mmike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank: Klingt sehr gut! Werd's mal umsetzten und berichten ....

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.