Übertragungsprobleme bei DX6i und Deltang rx31b

[Mattef]

Hallo!

Ich habe seit einiger Zeit ein paar Probleme mit der Inbetriebnahme des Miniaturempfängers rx31b von Deltang (http://www.deltang.co.uk/rx31b.htm) und ich sehe gerade keinen anderen Weg, euch mein Problem zu schildern. Eine intensive Websuche und langes Rätselraten brachten mich nicht weiter. Ich beschreibe mein Problem so ausführlich wie möglich, auch wenn es vielleicht auf lasten der Textlänge geht. Ich hoffe auf einen motivierten Helfer, der sich des ganzen Problems annimmt

Ich verwende die Fernbedienung DX6i von Spektrum. Das Binden von Empfänger und Fernsteuerung funktioniert problemlos, allerdings gibt es Probleme bei der Übertragung.

Den Empfänger rx31 habe ich so konfiguriert, dass er an Pin3 serielle Daten aller sieben Kanäle ausgibt. Diesen seriellen Datenstrom lese ich von einem Mikrokontroller (XMega32) ein, der die weitere Verarbeitung übernimmt und die empfangenen Hex-Werte an meinen Computer schickt.

Laut Hersteller sieht der serielle Datenstrom folgendermaßen aus:

- 16 byte RS-232 serial output at 115200 baud, 8 bit, no parity, 2 stop bits, LSB first.
- Byte 1: Checksum - sum of other 15 bytes cast to 1 byte
- Byte 2: Signal quality - 1st bit (MSB) 1=new data, 0='hold' data/signal not validated; next 2 bits not used; last 5 bits (LSB) = RSSI (31 max, 0=no signal/timeout)
- Bytes 3-16: Payload - 7 channels, 2 bytes per channel - 1st 3 bits notused, next 3 bits = channel number, last 10 bits = servo position
- Frame rate is 22ms

So wie ich das versetehe kommt also alle 22ms ein Datenframe an, wobei die eigentlichen RC-Daten ab dem dritten Paket starten und ein Kanal immer zwei aufeinanderfolgende Paketebelegt. Nach http://www.rcgroups.com/forums/showthread.php?t=1482559 sollte das Format ungefähr wie folgt aussehen:

byte 1 = Checksum
byte 2 = Signal quality
byte 3 = Throttle High Byte
byte 4 = Throttle Low Byte
byte 5 = Ail High Byte
byte 6 = Ail Low Byte
byte 7 = Elev High Byte
byte 8 = Elev Low Byte
byte 9 = Rudder High Byte
byte 10 = Rudder Low Byte
byte 11 = Flaps High Byte
byte 12 = Flaps Low Byte
byte 13 = Gear High Byte
byte 14 = Gear Low Byte
byte 15 = Aux1 High Byte
byte 16 = Aux1 Low Byte

Soweit so gut. Meinen Mikrokontroller habe ich nach den oben gelisteten Vorraussetzungen eingestellt (115200B, 8N2), er empfängtdie Daten, allerdings in einem für mich unverständlichem Format. Originaldaten von meinem Mikrokontroller sehen bei mir so aus (mit allen Knüppeln der Funke in der Nullposition außer Throttle auf Min):

0x00 0x9f 0x7f 0x7f 0x26 0x7f 0x00 0xff 0x0d 0xff 0x00 0x9b 0x10 0x99 0x18 0x00 0x00

Bewege ich die Knüppel, kann ich durch das Ändern der Bytes erkennen, welche Kanäle auf den Bytes liegen. Folgende Zuordnung zeigt, welche Bytes sich ändern, wenn ich die Steuerknüppel bewege:

byte 1 = immer 0x00 (falls dieser Wert tatsächlich die Checksum ist,
sollte er sich immer ändern, wenn ein Knüppel bewegt wird. Ändert sich
aber nicht)
byte 2 = signal quality (Werte nehmen ab, wenn ich mich mit meiner Funke
entferne, oder ich die Funke in die (ausgeschaltete) Mikrowelle lege )
byte 3 = Pitch
byte 4 = Yaw
byte 5 = Gear/F Mode
byte 6 = Throttle (wenn Flugmodell Helikopter), immer 0x7f (wenn Flugmodell Airplaine)
byte 7 = immer 0x00
byte 8 = Pitch
byte 9 = Yaw (ändert sich nicht merklich zwischen 0x0c und 0x0f)
byte 10 = Yaw
byte 11 = Throttle (ändert sich nicht merklich zwischen 0x00 und 0x03)
byte 12 = Throttle
byte 13 = Gear/F Mode
byte 14 = Gear/F Mode
byte 15 = immer 0x00
byte 16 = immer 0x00

Ist euch aufgefallen, dass Roll nicht aufgeführt ist? Seltsam, oder? Bewege ich den Roll-Knüppel, ändert sich kein einziges Byte. Ich muss zugeben, dass ich nicht wirklich Ahnung von meiner Fernsteuerung DX6i habe. So viele Knöpfchen verwirren mich ein bisschen. Lege ich alle möglichen Knöpfe und Hebel an der Fernsteuerung um, ändert sich das Verhalten der Datenpakete allerdings nicht.

In der Bedienungsanleitung steht außerdem, dass beim Binden der DX6i und dem Emfpänger ausgemacht wird, welches Datenformat zwischen den beiden verwendet wird. Also kann es ja eigenlich nicht Schuld einer falschen Einstellung der Fernsteuerung sein.

Zu guter letzt möchte ich noch erwähnen, dass ich mit einem anderen Empfänger und einem Oszilloskop überprüft habe, dass meine Fernsteuerung funktioniert und auf jedem Kanal sendet. Ich vermute also, dass das Problem eher beim rx31 oder dem Mikrokontroller liegt. Dazu habe ich im Anhang das Programm für den Mikrokontroller angehängt. Vielleicht gibt es hier einen schlauen Typen, der den Fehler auf Anhieb entdeckt

Nun die großen Fragen: Woher kommt die Abweichung zum vom Hersteller angegebenen Datenframe? Warum ändern sich die Bytes des Frames nicht, wenn ich den Roll-Knüppel bewege? Wo ist meine Checksumme? Und was haben die vielen Nuller (0x00) im Datenframe zu suchen?

Ich jedenfalls bin ziemlich ratlos.

Achja, noch eine Sache: Die Einstellung der Baudrate des Mikrokontrollers scheint richtig zu sein. Die Kommunikation zum Empfänger läuft in einem weiten Bereich weitestgehend stabil (zwischen 110000B und 130000B). Stellt man eine niedrigere oder höhere Baudrate als 110000B oder 130000B ein, empfängt der Mikrokontroller nur noch Mist, was ich daran erkenne, dass sich mehr als drei Bytes des Datenframes beim Bewegen eines Steuerknüppels ändern. Außerdem funktioniert ja auch die Kommunikation zum Computer mit 19200B, woraus ich schließe, dass der Mikrokontroller richtig eingestellt ist, bzw. mit der korrekten Frequenz läuft.

Ich danke euch vielmals für die Bereitschaft mir zu Helfen!
Viele Grüße
Matthais

[Che Guevara]

Hi,

laut deiner Beschreibung arbeitet das Modul mit RS232 Pegeln, hast du das berücksichtigt? Welchen Baustein verwendest du zur Pegelanpassung? Evtl. liegt ja auch da der / ein Fehler?
Hast du mal den Empfänger direkt an den PC angeschlossen, um einen Fehler durch dem µC auszuschließen? Wenn ja, kommt das selbe bei raus?
Achja, Cross-posting macht man nicht ( http://www.rclineforum.de/forum/boar...deltang-rx31b/ )

Gruß
Chris

[Mattef]

Hey Chris,

gute Idee! Das muss ich nachprüfen ob es tatsächlich an den Pegeln liegt. Allerdings müsste ja dann der Empfänger rx31 seine Pegel auch irgendwie aus den 5V, die ich an ihn anschließe, herstellen. Und einen Pegelwandler auf dem Empfänger sehe ich nicht.

Sorry für das Crossposting. Nachdem ich dort keinen Antwort erhielt und ich im Nachhinein dachte, dass hier vielleicht die bessere Anlaufstelle ist, wollte ich die gleiche Frage auch hier noch stellen.

Grüße!

[PICture]

Hallo!

Angeblich müsstest Du zuerst interaktiv einfache Fragestellung praktisch erlernen._.

[Mattef]

Hallo!

Angeblich müsstest Du zuerst interaktiv einfache Fragestellung praktisch erlernen._.

Danke, sehr hilfreicher Beitrag. Hätte ich lieber schreiben sollen: Mein Empfänger funktioniert nicht, bitte helft mir? Mit so etwas ist niemandem geholfen.
Dann schreib ich doch lieber ausführlich, all das was ich bisher efahren habe und welche Methoden ich schon probiert habe.
was verstehst du an meiner Frage nicht (nicht als Angriff gemeint)?

[PICture]

Bitte und sorry, dass ich kein Schriftsteller bin._.

[Mattef]

Hi,

laut deiner Beschreibung arbeitet das Modul mit RS232 Pegeln, hast du das berücksichtigt? Welchen Baustein verwendest du zur Pegelanpassung? Evtl. liegt ja auch da der / ein Fehler?
Hast du mal den Empfänger direkt an den PC angeschlossen, um einen Fehler durch dem µC auszuschließen? Wenn ja, kommt das selbe bei raus?
Achja, Cross-posting macht man nicht ( http://www.rclineforum.de/forum/boar...deltang-rx31b/ )

Gruß
Chris

So, habs nachgeprüft und von anderer Stelle (Harald Sattler) bestätigen lassen: Der rx31 arbeitet mit TTL-Pegeln und keinen RS232 Pegeln, also 3.3V = 1 und 0V = 0. An unterschiedlichen Pegeln von Empfänger und Mikrokontroller sollte es deshalb nicht liegen (mein XMega arbeitet auch mit 3.3V).

Außerdem habe ich den Empfänger gerade direkt an den Computer angeschlossen (mit einem FTDI dazwischen) und den Datenstrom abgehorcht. Hier taucht tatsächlich ein Byte für die Checksum auf, das Byte für den Roll-Wert fehlt allerdings trotzdem noch.
-> Empfänger kaputt?

Ich forsche weiter, über Lösungsvorschläge freue ich mich aber dennoch

[Che Guevara]

Hi,

dann ist auf jeden Fall die Beschreibung des Herstellers / Händlers falsch, evtl. willst du denen ja ne Mail schreiben, damit sich keiner was kaputt macht...
Wenn Harald auch mit dem Emfpänger arbeitet, könntest du dann ihn nicht mal darum bitten, sich das Teil anzusehen? Soweit ich informiert bin, funktioniert sein snQ doch?!
Ansonsten kann ich dir momentan auch nicht weiterhelfen, evtl. fällt mir ja noch was ein

Gruß
Chris

[Mattef]

Per Mail hab ich Harald auch schon von meinem Problem berichtet, aber er scheint bislang auch ein wenig ratlos zu sein. Sein xNQ funktioniert so viel ich weiß größtenteils, auf jeden Fall arbeitet die Kommunikation von Receiver und Mikrokontroller über UART bei ihm korrekt, obwohl er nichts grundlegendes anderes macht als ich.

Ich war gerade bei einem Freund von mir, der ein gescheites Oszi daheim hat, mit dem ich den Empfänger genau vermessen konnte.
Es gibt ja mehrere Möglichkeiten den rx31 zu Konfigurieren. Zum einen kann man die Kanalwerte direkt über vier Pins ausgeben lassen. Darüber hinaus gibt es die Möglichkeit SUM-PPM oder serielle Daten aller Kanäle an Pin3 auszugeben.
Stelle ich den rx31 so ein, dass er die SUM-PPM Werte erzeugt, kann man am Oszi direkt beobachten, dass sich das Signal jedesmal verändert, wenn man einen Steuerknüppel bewegt. Es ändert sich also insbesondere auch dann, wenn man den ROLL-Knüppel bewegt (der Kanal, der bei den seriellen Daten fehlt).

Die Fernsteuerung funktioniert also, und der rx31 im Prinzip auch. Nur mit dem seriellen Datenstrom stimmt irgendwas nicht.

Zumindest konnte ich jetzt ein paar Möglichkeiten ausschließen...

Danke dir Chris soweit schon mal.

[wkrug]

Gleich mal Vorweg, mit X-MEGA hab ich noch nicht gebastelt, mit den normalen ATMEGA's kenn ich mich schon einigermassen aus.
Ich würde das Empfangssignal noch mal mit nem Oszi anschauen. Sind es wirklich 2 Stopp Bits, passt die Geschwindigkeit und Polarität des Signals?
Wenn das geht und trotzdem beim PC und deinem Controller unterschiedliche Werte ankommen, hast Du eventuell ein Problem in Deiner Auswertesoftware.

Du könntest dein PC Interface ja auch mal als USART Sender verwenden und gucken, ob deine Auswertesoftware alle Bytes erkennt. ( Datei vorbereiten und "Text Senden" ).

Wie erkennst Du den Anfang eines Frames?
Werden tatsächlich alle Bytes erkannt und abgespeichert?
Bei manchen Controllern ist der USART Empfänger doppelt gepuffert. Das bedeutet es kann ein Byte im Übergabepuffer stehen und ein weiteres im Empfangsregister.
Es wird aber nur ein Interrupt generiert. Das müsstest Du dann aber selber überprüfen.

Ich mach mir da immer einen Ringpuffer, der von einer RxD Interruptroutine befüllt wird.
Eine Hauptroutine liest die Werte dann aus.
Wenn Du sicher den Anfang eines Frames detektieren kannst, ist es auch möglich die Werte direkt in eine Tabelle zu schreiben.
Das würde ich dann vorerst mal Byteweise machen.
Ein Buffer Overflow muss auch erkannt werden, da damit ja auch Bytes verloren gehen. = 2 Bytes wurden empfangen, das erste Byte aber gelöscht, da es nicht abgeholt wurde. Trotzdem wird nur ein Interrupt generiert.