Wie ist dieses Infrarot-Signal kodiert?

[Eff v. (eff_v)]

Guten Abend,

ich sitze gerade daran, ein Infrarot-Protokoll zu reversen und hab mir 
hierfür mithilfe einer IR-LED, eines 3,5mm Klinkenkabels und eines 
Mikrofoneingangs einen IR-Receiver gebaut.

Nach einigen Messungen, stellen sich mir nun zwei Fragen, die geklärt 
sein müssten, um das Protokoll zu verstehen.

Als Anhang ein Screenshot meiner Excel-Tabelle.

Die erste Frage:

Um welche Kodierung handelt es sich? Da ich genau 2 verschiedene Längen 
an "Höhen" und "Tiefen" habe, die sich genau im Faktor 2 unterscheiden 
(21 bzw. 42 "Samples"), dachte ich zuerst an einen Manchester-Code, nach 
kurzem Ausprobieren sah es dann aber eher so aus, als handele es sich um 
einen Biphase-Mark-Code (BMC), weil bei ersten, manuellen 
Dekodierungsversuchen die Flanken sonst nicht mehr gepasst hätten. Liege 
ich damit richtig?
Bevor ich dann anfange, da manuell zu zählen, wollte ich eine Meinung 
von Fachmännern einholen. :)

Zweite Frage:
Angenommen, es handele sich um eine BMC-Kodierung, so wäre jedes Bit 
doch in konstanter Zeit kodiert, die Messungen müssten also auch gleich 
lang sein.
Die Frage lautet also: Warum sind die verschiedenen Messungen 
unterschiedlich lang? Woher weiß das Empfangsgerät dann, um welchen Wert 
es sich ab wann handelt, wenn es nicht eine konstante Bitzahl ist?
Kann es ein Grenzpattern geben und wenn ja, wäre das nicht viel zu 
ineffizient, weil alleine das Pattern mehrere Bits verbraucht?


Vielen Dank schon einmal im Voraus,

Eff

Edit: Wann nach dem Startbit sollte man denn das Dekodieren anfangen? 
Direkt, oder? Beginnt die erste Messung also mit 0, 0, 0, 0.... (wenn 0 
= kein Übergang) oder mit 1, 1, 1, 1...?

[Harald W. (wilhelms)]

Eff v. X. schrieb:

> ich sitze gerade daran, ein Infrarot-Protokoll zu reversen

Du kennst www.mikrocontroller.net/articles/IRMP ?
Gruss
Harald

[Eff v. (eff_v)]

Ja, und ich fand ihn auch hilfreich. Es sieht aber so aus, als würde das 
verwendetes Protokoll nicht enthalten sein, was aber auch nicht 
verwundert, da es es sich nicht um eine der hier aufgeführten Firmen 
handelt, bzw. geht es überhaupt nicht um solch eine Fernbedienung für 
Fernseher, Boxen oder Receiver.

Desweiteren versuche ich auch, das ohne µC hinzubekommen und bis hierhin 
sehen die Messwerte ja auch ziemlich gut aus, ich bräuchte nur noch 
etwas Hilfe bei der Interpretation.

Gruß

[flipsi (Gast)]

Hi!
Ein Begrenzungsmuster würde ich für unwahrscheinlich halten. Der lange 
Puls am Anfang scheint ja die Rahmen zu synchronisieren (hier wäre die 
Darstellung eines repetitierenden Musters interessant gewesen). Ob 
Manchester- oder BMC kann ich nicht spontan beantworten. Die 
unterschiedlichen Längen könnten jedoch davon herrühren, daß eine 
Lauflängenkodierung (RLE) verwandt wird. Ev. auch mit Checksumme am 
Ende. Ich würde die Datenfolgen erstmal nach Manchester- und BMC 
dekodieren und mir die Datenfolgen anschauen. Vielleicht kannst Du sie 
ja mal hier posten? Um was handelt es sich bei Deiner 
Übertragungsstrecke? Ist das für ein ferngesteuertes Auto?
Gruß
  flipsi

[Eff v. (eff_v)]

Okay, danke für den Tip mit der Lauflängenkodierung. Ich werde mich 
jetzt wohl also mal hinsetzen und mit BMC und Manchester versuchen, zu 
dekodieren.

Es handelt sich dabei um einen 3-Kanal-RC-Helikopter mit Trim-Rädchen 
und Turbotaste. :)

Ich hab gerade mal noch eine längere Zeitspanne aufgenommen. Es scheint 
so, als wären die Sendezeitpunkte recht unregelmäßig/willkürlich.
Das Bild wurde bei konstantem Vollgas aufgenommen, sonst hab ich nichts 
geändert. Wenn ich andere Richtungen noch mitbewege, ändert sich aber - 
so wie es aussieht - wohl auch Nichts an der Unregelmäßigkeit.

Ich melde mich dann wieder mit 1en und 0en.

Gruß,
Eff

[Eff v. (eff_v)]

So, ich habe mich jetzt mal drangesetzt und versucht, das zu dekodieren.

Ich hab jetzt 2 verschiedene Varianten des BCM-Decodings verwendet, 
einmal hab ich direkt nach dem Startpuls begonnen und einmal habe ich 
noch einen Takt, also 500µs gewartet und ab da begonnen. (Zu Sehen auch 
in KeinManchester(2).png)

Beim Dekodieren bin ich dann auch (wie bereits angedeutet) wieder darauf 
gestoßen, dass Manchester-Encoding logisch nicht möglich ist. Stimmt 
doch so laut den Bildern, oder? (Markante Stellen sind rot eingekästelt)

Ich geh zur zeit z.B. schon einmal davon aus, dass die ersten 8 Bit die 
Stärke des Gas kodieren.

Welche Werte sollte ich denn erstmal genauer ansehen? Die mit der Grenze 
direkt nach dem Startpuls, oder die, wo die Grenze um 500µs verschoben 
ist?
Kommen denn noch andere Kodierungsverfahren in Frage?

Ich schätze fast, dass die Längenvariation an einer Checksum liegt, für 
eine Lauflängenkodierung finden sich zu viele aufeinanderfolgende 1- 
bzw. 0-Worte, oder?

Habt ihr vielleicht noch weitere Vorschläge?

Gruß,
    Eff

[flipsi (Gast)]

Hi Eff!
Sorry, daß mit der Lauflängenkodierung hat nicht gestimmt. Bei näherer 
Betrachtung fällt aber auf, daß es immer genau 24 fallende und steigende 
Flanken gibt. Die unterschiedliche Länge entsteht, da die Abstände 
variieren. 1 und 0 wird daher vermutlich in diesen Längen kodiert.

Weiterhin viel Erfolg
  flipsi

[Eff v. (eff_v)]

Ja, das sieht ziemlich danach aus.

Ich habe gerade noch einmal eine Reihe von Aufnahmen gemacht, die sich 
nur in dem Wert des Gashebels unterscheiden, was mir - denke ich - 
weiterhelfen wird, wenn ich wieder Zeit finde. :)

Es sieht wohl so aus, als ist der Rythmus, in der die Steuersignale 
gesendet werden, weiter nicht von Belang. Wie genau die 1en und 0en nun 
aussehen, weiß ich zwar noch nicht, aber das wird sich wohl noch zeigen, 
wenn mal mehr Messungen vorliegen.

Mal sehen, was der 4. Teil, der sich auch unterscheidet, sein wird. 
Vielleicht steckt ja wirklich eine Checksum dahinter, aber das schau ich 
mir dann später mal irgendwann genauer an.

Vielen Dank schonmal für die Tipps und Hilfe, flipsi. :)

[flipsi (Gast)]

Hi Eff!
Ich hab nochmal auf Deinen ersten Anhang geschaut und mir ist 
aufgefallen:
Alle Pakete starten mit einem langen Puls (Kopf) und enden mit einem 
kurzen Puls. Dazwischen liegen 45 Zeitabschnitte, wenn man den Abstand 
zwischen je zwei Flanken betrachtet. Wenn man diese 45 Abschnitte als 5 
Byte + Paritätsbit interpretiert, ergibt sich eine Even-Parität für alle 
Bytes der ersten drei Messungen (weiter hab ich es nicht ausprobiert).
Ich habe lang als 1 und kurz als 0 interpretiert; die Trennung ist "." 
zwischen Nibbeln, "-" zwischen Byte und Parität und "," zwischen Bytes;
+0 steht für den letzten Zeitabschnitt, der immer kurz zu sein scheint:

1111.1101-1,0000.1000-1,0001.0001-0,1110.1000-0,0100.0111-0+0
0010.0101-1,0000.1000-1,0001.0001-0,0011.1000-1,0100.0101-1+0
1010.0001-1,0000.1000-1,0001.0001-0,1011.1000-0,0100.0101-1+0

Das Paritätsbit könnte natürlich auch jeweils das erste Bit sein (falls 
die Bytes umgekehrt interpretiert werden).
Eventuell kannst Du mal mehr von Deinen Daten automatisiert auswerten, 
ob das so hinkommen kann. Warum allerdings der Gashebelstand in mehreren 
Bytes kodiert ist, verstehe ich nicht. Hast Du vielleicht doch noch 
andere Einstellungen geändert als nur das Gas? Oder korrigiert die 
Fernsteuerung vielleicht auch andere Parameter nach, wenn man das Gas 
variiert (z.B. die Geschwindigkeit für den Heckrotor), um Übersprechen 
zu mindern (ich hab noch nie mit einem Modellhubschrauber gespielt und 
vermute das daher nur)?

Viele Grüße
  flipsi

[Eff v. (eff_v)]

Ah, da kann ich lange überlegen, warum ich die Abschnitte auch immer in 
9 Bytes eingeteilt habe und eine Logik dahinter suchen, wenn ich von 
Paritätsbits noch nie gehört habe. Eine Art Checksum-Error-Checking hab 
ich aber schon vermutet.

Das mit den Paritätbits stimmt auf jedenfall, das hab ich vorhin bei 
allen Messwerten nachvollziehen können.

Gas          Seitsteuerung    Vorne/Hinten        1 = lang, 0 = kurz                      in Dec (LSB first)
100,00%        Nichts        Nichts        1111.1101-1,0000.1000-1,0001.0001-0,1110.1000-0,0100.0111-0+0    191    16    136    23    226
50,00%        Nichts        Nichts        0010.0101-1,0000.1000-1,0001.0001-0,0011.1000-1,0100.0101-1+0    164    16    136    28    82
10 – 20%      Nichts        Nichts        1010.0001-1,0000.1000-1,0001.0001-0,1011.1000-0,0100.0101-1+0    133    16    136    29    82
100,00%        100% Links      Nichts        1111.1101-1,0111.0000-1,0001.0001-0,1010.1000-1,0100.1011-0+0    191    14    136    21    210
100,00%        100% Rechts      Nichts        1111.1101-1,0111.1000-0,0001.0001-0,1010.0000-0,0100.1111-1+0    191    30    136    5    242
100,00%        Nichts        100% Vorne      1111.1101-1,0000.1000-1,0001.1111-1,1110.0001-0,1100.0111-1+0    191    16    248    135    227
100,00%        Nichts        100% Hinten      1111.1101-1,0000.1000-1,0001.0110-1,1110.1001-1,1000.0111-0+0    191    16    104    151    225
50,00%        Nichts        50% Vorne      1011.0101-1,0000.1000-1,0001.1001-1,1010.1001-0,0000.0101-0+0    173    16    152    149    160
50,00%        Nichts        50% Hinten      0000.1101-1,0000.1000-1,0001.1010-1,0001.1001-1,0000.0101-0+0    176    16    88    152    160
90,00%        50% Links      50% Hinten      1111.1101-1,0000.1000-1,1001.0100-1,0001.1000-0,0000.0111-1+0    191    16    41    24    224
90,00%        50% Rechts      50% Vorne      1111.1101-1,0001.1000-0,1001.0001-1,0000.0000-0,0000.0011.0+0    191    24    137    0    192
10%*        Nichts        Nichts        0010.0001-0,0000.1000-1,0101.0001-1,0111.1000-0,0100.0101-1+0    132    16    138    30    162
10%*        Nichts        Nichts        1100.0001-1,0000.1000-1,0101.0001-1,1011.1000-0,0100.0101-1+0    131    16    138    29    162


Turbotaste änderte 4. Byte, Trimmrad Byte 3, 4 und 5.

Nach einigen Experimenten mit der Turbotaste und dem Trimmrad, bin ich 
zwar wieder etwas verwirrter, aber da brauch ich einfach nur mehr 
Messwerte, bei denen ich auch rel. genau auf die genau Ansteuerung 
achte. Das muss ich aber erst mal nach hinten verschieben, die Prüfungen 
stehen an.

Aber danke für den entscheidenden Tipp! Wenn man dann mal weiß, wie der 
Binary-Blob aufgeteilt ist und man 1en und 0en richtig unterscheiden 
kann, sollte das weitere Auseinandernehmen des Protokolls mit genügend, 
zuverlässigen Messwerten nur noch eine Frage der Zeit sein.

Hast mir super weitergeholfen, flipsi! :)

(Zu deiner Frage:
Der Helikopter besitzt einen Koaxialrotor, der für den Auftrieb und das 
Drehen zuständig ist. Der Heckrotor ist parallel zu dem großen Rotor 
angebracht und sorgt nur für Vor- und Rücktrieb beim Fliegen. (Der 
Turboknopf ist auch nur ein Turbo für den Heckrotor, hat also auch nur 
Auswirkung, wenn man nach vorne/hinten fliegt) Es kann also auch gut 
sein, dass beim Beschleunigen/Gas Geben die beiden Hauptrotoren getrennt 
angesprochen werden. Damit rechnet die Fernbedienung dann auch die 
"Drehzahl" der beiden Hauptrotoren aus, um die gewünschte Drehung zu 
bewerkstelligen oder eben zu verhindern.
Ich werde den Thread vielleicht für interessierte Googler vielleicht 
nochmal ausgraben und updaten, wenn mir die genaue Bedeutung jedes 
einzelnen Bits dann klar sein wird, das kann aufgrund bevorstehender 
Prüfungen allerdings noch ein wenig dauern.)

Gruß,

Eff