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
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
Gast
#531380
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
Gast
#531385
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
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 ...
@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
Gast
#531391
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
@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
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
Gast
#531395
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
@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
Gast
#531407
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
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.
@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
Gast
#531419
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
@Frank: Klingt sehr gut! Werd's mal umsetzten und berichten ....
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.