Ich habe ein serielles Protokoll, das ich per reverse engineering auswerten möchte. Am Ende jeder der Sequenz ist offensichtlich 1 byte Checksumme, aber komme nicht auf das Berechnungsverfahren.
Online-Rechentools habe ich schon probiert, aber bisher ohne Erfolg,
bzw. habe die Verfahren berechnungsmäßig auch nicht ganz verstanden.
Hier sind vier Sequenzen:
B1 82 00 33 87 01 05 BC 05 BB 05 BC 7A 4B FF CA 00 00 00 00 00 00 00 87
B1 82 00 33 87 05 05 BC 05 BB 05 BC 7A 4D FF FA 00 00 00 00 00 00 00 71
B1 82 00 33 87 01 05 BC 05 BB 05 BC 7A 7C FF CA 00 00 00 00 00 00 00 76
B1 82 00 33 87 05 05 BC 05 BB 05 BC 7A 76 FF FA 00 00 00 00 00 00 00 48
Es wäre nett, wenn mir jemand helfen könnte!
Vielen Dank im Voraus!
Das ist vermutlich irgendwas mit Summe der Bytes. Bei den letzten drei Sequenzen ist die Summe der Bytes über die vollständige Sequenz identisch, bei der ersten Sequenz passt das allerdings nicht.
Die Sequenzen stimmen und da ist kein Fehler bei der ersten Sequenz?
Wenn ich jeweils die 24 Bytes einer Zeile zusammenaddiere, hat das
Ergebnis im unteren Byte jeweils eine 0x65 - nur nicht in der ersten
Zeile.
Ja gut,
aber deine 0x65 sind nirgends im Stream enthalten.
Ich denke eher das der TO das jeweils letzte Byte im Stream meint.
Sprich im letzten wäre es 0x48 und er möchte wohl wissen, wie dieser Wert zustande kommt (falls es wirklich ein Prüfbyte oder sowas ist).
Eine häufig verwendete Prüfsumme ist die Summe der Bytes XOR 0xFF.
Als Beispiel:
1
01 02 03 -> Prüfsumme F9
2
3
04 05 06 -> Prüfsumme F0
Wenn man über die komplette Sequenz die Summe berechnet ist diese konstant, in diesem Fall 0xFF. Man kann auch einen anderen Startwert als 0 für die Summe nehmen, dann kommt was anderes heraus. Oder es wird nur ein Teil der Sequenz für die Summe verwendet. Aber zumindest deutet eine konstante Summe über die komplette Sequenz auf ein derartiges Verfahren hin.
Das meine ich auch: Das letzte Byte ergänzt die Summe derart, dass das
Ergebnis $MAGIC (hier 0x65) lautet. Diese Methode ist ein gängiges
Verfahren.
Eben, so ähnlich macht das ja auch z.B. CRC (ergänzt die Nachricht passend) sodass der Empfänger weiß, dass etwas schief lief, wenn er was anderes als 0 raus bekommt.
Eben, so ähnlich macht das ja auch z.B. CRC (ergänzt die Nachricht
passend) sodass der Empfänger weiß, dass etwas schief lief, wenn er was
anderes als 0 raus bekommt.
Ja OK, so könnte man es auch machen.
edit:
Da spart man sich halt die extra Bytes im Transfer.
Tatsächlich kommen bei weiteren Sequenzen mal 0x65 und mal 0x45 als Summe raus. Leider kein direkt offensichtliches System.
Das Protokoll ist vom Mövi Pro Kamera-Schwenkkopf.
Die Bytes 6-20 habe ich schon gefunden, das sind alles Positionsvorgaben für die einzelnen Achsen, meistens in 16bit.
Komisch ist auch, dass die ersten beiden Bytes, die ich als Kennung vermutete, auch "gelegentlich" (alle paar Tage / Wochen) andere Werte haben. Nur die Position der o.g. Achsen sind immer gleich und die Sequenzlänge (24Bytes). Zur weiteren Kontrolle wollte ich nun noch die Prüfsumme verstehen...
Tatsächlich kommen bei weiteren Sequenzen mal 0x65 und mal 0x45 als
Summe raus. Leider kein direkt offensichtliches System.
Hm, vielleicht sagt die Checksumme nicht nur, dass die Übertragung OK war, sondern auch zu welcher Achse die Daten gehören...kommt mir so grade als Idee.
eher nicht, die Achsinformationen sind alle in jeder Nachricht enthalten. Wie gesagt, Länge der Nachricht und Position der Achsdaten innerhalb der Nachricht verändern sich nicht, das sind derzeit meine Konstanten zur Identifikation der Nachricht. Auswertung der Checksumme am Ende (oder was es ist) würde zur Verifizierung noch gut passen ;)
Stell doch hier mal eine längere Aufzeichnung rein.
Geht die Kommunikation nur in eine Richtung oder wird auch was zum Kamera-Schwenkkopf geschickt (bzw. kommt vom Kopf)? Falls ja wäre das auch interessant weil dort vermutlich die selbe Prüfsummenberechnung verwendet wird.
Wenn ich mir die Daten ansehe würde ich vermuten daß irgendetwas mit der Aufzeichnung nicht stimmt (z.B. die Baudrate nicht exakt passt). Insbesondere beim erste Byte würde ich erwarten daß es fest 0xB1 ist und nicht manchmal 0x91.
Wie zeichnest Du denn die Daten auf? Hast Du schon andere Wege ausprobiert (z.B. einen anderen UART auf USB Adapter, idealerweise mit anderem Chip)?
Wenn das nicht hilft vielleicht auch mal mit einem Logicanalyzer aufzeichnen und schauen ob da diese Unterschiede beim ersten Byte ebenfalls auftreten.
der war leider gut.
Die Aufzeichnung erfolgte in einem Arduino Pro Mini, da das später mal als eigenständige Komponente laufen soll. Zum Debuggen wurden die Daten seriell auf den PC übertragen.
Habe jetzt mal den Arduino weggelassen und direkt seriell in den PC gesendet, dann sieht es so aus:
1
51420013C701055C05DF05DB0013000000000000000000FF
2
51420013C705055C05DF05DB0013000000000000000000FB
3
51420013C701055C05E005DB000B00000000000000000006
4
51420013C705055C05DF05DB000D00000000000000000001
5
51420013C701055C05E005DB00030000000000000000000E
6
51420013C705055C05DF05DB00020000000000000000000C
7
51420013C701055C05DF05DB000B00000000000000000007
8
51420013C705055C05DF05DB000E00000000000000000000
9
51420013C701055C05DF05DB00050000000000000000000D
10
51420013C705055C05DF05DB0010000000000000000000FE
11
51420013C701055C05DF05DB00080000000000000000000A
12
51420013C705055C05DF05DB000700000000000000000007
13
51420013C701055C05DF05DB000200000000000000000010
14
51420013C705055C05E005DB00000000000000000000000D
15
51420013C701055C05E005DB000100000000000000000010
16
51420013C705055C05DF05DB00000000000000000000000E
Damit ergibt sich bei Addition aller Bytes MOD 256 immer A5.
Die Baudrate stimmt auch nicht ganz (Gerät 111,111bps), PC / Arduino-Schnittstelle 115200bps. Komischerweise scheint der PC damit besser zurechtzukommen als der Arduino.
Die Baudrate stimmt auch nicht ganz (Gerät 111,111bps), PC /
Arduino-Schnittstelle 115200bps. Komischerweise scheint der PC damit
besser zurechtzukommen als der Arduino.
Manche Chips in den UART auf USB Konvertern können "krumme" Baudraten sauber verarbeiten.
Das Protokoll macht jetzt deutlich mehr Sinn, 0x13 im Header wird vermutlich die Länge der nachfolgenden Daten sein.
Die Baudrate stimmt auch nicht ganz (Gerät 111,111bps), PC /
Arduino-Schnittstelle 115200bps
Sind 3,6% --> zu viel des Guten.
Und wenn jetzt die Baudrate vom Andruiden noch um 1% in "die andere Richtung" abweicht, dann hast du gegenseitig fast 5% Fehler. Kein Wunder, dass du da Übertragungsfehler hast.
Komischerweise scheint der PC damit besser zurechtzukommen als der
Arduino.
Evtl. macht der PC-Adapter eine 3-fach Abtastung oder sogar ein Resync an den Flanken.
Natürlich. Du könntest die Taktfrequenz von deinem Arduino ändern.
Die Granularität der Baudrateneinstellung kannst du dir im Quellcode der SoftwareSerial Library angucken. Die lässt sich im vorhandenen Code nicht sonderlich fein einstellen - aber probier's.
Mit welcher Nominalfrequenz und mit welcher tatsächlichen Frequenz läuft dein Arduino?
