Hallo allerseits, 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! Felix
Es kann auch eine Signatur sein. Sprich mit irgend ein Kryptoverfahren wird eine Signatur errechnet und auf 1 Byte verkürzt.
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?
Dieter S. schrieb: > Das ist vermutlich irgendwas mit Summe der Bytes. Bei den letzten drei > Sequenzen ist die Summe der Bytes über die vollständige Sequenz > identisch, Welche Summe meinst du und was ist da bei den letzten drei identisch? - CRC8 ist es wohl nicht (habe keine passende gefunden) - Summe der Byte-Werte und daraus das High oder Low-Byte ist es auch nicht.
Adam P. schrieb: > Welche Summe meinst du Wenn ich jeweils die 24 Bytes einer Zeile zusammenaddiere, hat das Ergebnis im unteren Byte jeweils eine 0x65 - nur nicht in der ersten Zeile.
Frank M. schrieb: > > Wenn ich jeweils die 24 Bytes einer Zeile zusammenaddiere, hat das > Ergebnis im unteren Byte jeweils eine 0x65 - nur nicht in der ersten > Zeile. Genau, bei der ersten Sequenz ist es 0x45, daher meine Frage ob die Sequenzen auch stimmen.
Frank M. schrieb: > 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).
Felix schrieb: > Ich habe ein serielles Protokoll, das ich per reverse engineering > auswerten möchte. Hast du evtl. noch weitere Infos? - Welches Gerät / Hersteller? - Was kann das Gerät (Funktionsweise)? - ... Evtl. Datensätze die 2 entgegengesetzte Situationen darstellen? (z.B.: Wenn Regler in max. rechts und dann links Stellung ist)
Ist es wirklich so schwierig zu verstehen? 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.
Adam P. schrieb: > aber deine 0x65 sind nirgends im Stream enthalten. Muss es ja nicht. > Ich denke eher das der TO das jeweils letzte Byte im Stream meint. 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.
Frank M. schrieb: > 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.
Frank M. schrieb: > Adam P. schrieb: >> aber deine 0x65 sind nirgends im Stream enthalten. > > Muss es ja nicht. > >> Ich denke eher das der TO das jeweils letzte Byte im Stream meint. > > 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. Also das mit der Summe und XOR ist mir schon bewusst, jedoch wäre ich jetzt davon ausgegangen, dass das letzte Byte diese/bzw. ähnliche Info enthält: Mit Verfahren X durchlaufe ich den Stream und vergleiche das letzte Byte mit meinem Ergebnis.
M. K. schrieb: > 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.
:
Bearbeitet durch User
Felix schrieb: > Ich habe ein serielles Protokoll Wenn du eines der beteiligten Geräte nennst kann dir vlt. jeman helfen.
Hi, danke für Eure Ideen bisher! 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... Danke, Grüße, Felix
:
Bearbeitet durch User
Adam P. schrieb: > Mit Verfahren X durchlaufe ich den Stream und vergleiche das letzte Byte > mit meinem Ergebnis. Prinzipiell ist das dasselbe, wenn Du die Rechenformel umstellst: Bei Deinem Beispiel muss halt die Summe MINUS Crc gleich $MAGIC (hier 0) sein.
Felix schrieb: > Das Protokoll ist vom Mövi Pro Kamera-Schwenkkopf. Hab hier was von einer Freefly API gefunden: https://freeflysystems.com/support/movi-pro-support https://docs.google.com/document/d/1eNkpmxHHc22ooSi0EKxd6F0UNi5H_kI13hzm_rTR8i0/edit# jedoch passt das Protokoll nicht zu deinem, aber vllt. kommst du da an weitere Infos (falls du nicht eh schon dort geschaut hast). Die hätten folgende Prüfsumme im letzten Byte: "QX Packet Checksum" 255 - [SUM(Byte 3 thru Byte 28) Mod 256]
Hallo Adam, danke fürs Checken, ja die API gibt es, aber ich benötige die Komm zwischen dem Kopf und seinem Original-Steuerpult, die ist nicht offengelegt... Grüße, Felix
Felix schrieb: > 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.
Hallo, 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 ;) Danke Felix
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.
:
Bearbeitet durch User
Ohne Gewähr, das hier sieht ähnlich aus, vlt. kann man die Checksummen-Berechnung daraus ableiten: https://www.foxtechfpv.com/product/cameras/EH10/EH10-10x-camera-Camera-Serial-Command-Communication-Protocol.pdf
Passt übrigens, 5. Byte bis vorletztes Byte als 8-Bit Summe zusammenzählen, diese Summe + Checksumme muss FF ergeben.
Harald A. schrieb: > Ohne Gewähr, das hier sieht ähnlich aus, vlt. kann man die > Checksummen-Berechnung daraus ableiten: > https://www.foxtechfpv.com/product/cameras/EH10/EH10-10x-camera-Camera-Serial-Command-Communication-Protocol.pdf TOP, ich habs! :-) Berechnung ist wie Folgt: Header = Byte[0] bis Byte[3] Prüfbyte = Byte[24] Prüfbyte = 255 - (Summe(Byte[4] bis Byte[23]) % 256)
Adam P. schrieb: > > TOP, ich habs! :-) Da waren wir bereits, XOR 0xFF von der Byte-Summe ist das selbe. Und für die erste Zeile des Beispiels passt es doch immer noch nicht, oder?
:
Bearbeitet durch User
Adam P. schrieb: > Berechnung ist wie Folgt: > Header = Byte[0] bis Byte[3] > Prüfbyte = Byte[24] Wenn Du bei 0 anfängst zu zählen, gibt es kein Byte[24] mehr ;-)
Frank M. schrieb: > Wenn Du bei 0 anfängst zu zählen, gibt es kein Byte[24] mehr ;-) Hast natürlich Recht, hab mich verschaut 😉 Excel und so
Dieter S. schrieb: > Und für die erste Zeile des Beispiels passt es doch immer noch nicht, > oder? Alle anderen Zeilen passen, evtl. ein Fehler beim Übertragen in den Foren-Editor?
Hallo, hier nochmal ein paar Datenpakete, leider wird die Summe nicht immer gleich:
1 | B1 82 00 33 87 01 05 BC 05 BB 05 BC 38 83 FF CA 00 00 00 00 00 00 00 B1 |
2 | B1 82 00 33 87 05 05 BC 05 BB 05 BC 38 8F FF CA 00 00 00 00 00 00 00 81 |
3 | B1 82 00 33 87 01 05 BC 05 BB 05 BD 38 8F FF CA 00 00 00 00 00 00 00 84 |
4 | B1 82 00 33 87 05 05 BC 05 BC 05 BC 38 84 FF BA 00 00 00 00 00 00 00 BB |
5 | 91 82 00 33 87 01 05 BC 05 BC 05 BC 38 B6 FF CA 00 00 00 00 00 00 00 7D |
6 | B1 82 00 33 87 05 05 BC 05 BB 05 9D 38 80 FF 8A 00 00 00 00 00 00 00 CF |
7 | B1 82 00 33 87 01 05 BC 05 BB 05 B8 38 8E FF CA 00 00 00 00 00 00 00 86 |
8 | B1 82 00 33 87 05 05 BC 05 9B 05 BC 38 85 FF BA 00 00 00 00 00 00 00 BB |
9 | B1 82 00 33 87 01 05 BC 05 BB 05 BC 38 88 FF CA 00 00 00 00 00 00 00 8C |
10 | B1 82 00 33 87 05 05 BC 05 9C 05 BC 38 85 FF BA 00 00 00 00 00 01 00 BA |
11 | B1 82 00 33 87 01 05 BC 05 BC 05 BC 38 B0 FF BA 00 00 00 00 00 00 00 B3 |
12 | B1 82 00 33 87 05 05 DC 05 BB 05 BC 38 8F FF BA 00 00 00 00 00 00 00 B1 |
13 | B1 82 00 33 87 01 05 BC 05 BB 05 BC 38 89 FF BA 00 00 00 00 00 00 00 BB |
14 | 91 82 00 13 87 05 05 BC 05 BB 05 BC 38 8C FF BA 00 00 00 00 00 00 00 B4 |
15 | B1 82 00 33 87 01 05 9C 05 BB 05 BC 38 81 FF 8A 00 00 00 00 00 00 00 F3 |
16 | 91 82 00 13 87 05 05 BC 05 BB 05 BC 38 88 FF CA 00 00 00 00 00 00 00 88 |
17 | B1 82 00 33 87 01 05 9C 05 BB 05 BD 38 82 FF CA 00 00 00 00 00 00 00 B1 |
Das sind die Pakete vom Controller zum Kopf (mit den Soll-Werten vom Joystick). In die andere Richtung geht es so zu:
1 | B1 82 00 43 72 00 00 00 00 00 00 00 00 00 00 02 02 02 7F FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D |
2 | B1 82 00 17 01 09 7B 00 CC 47 02 C2 00 00 47 B1 03 C6 00 00 00 00 78 00 0B 00 8A B5 |
3 | B1 82 00 43 72 00 00 00 00 00 00 00 00 00 00 02 02 02 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D |
4 | 91 82 00 17 01 09 7B 00 CC 47 02 E2 00 00 47 B1 03 C5 00 00 00 00 77 00 0B 00 8A B7 |
5 | 91 82 00 63 32 00 8B 00 00 00 00 00 00 00 00 02 02 02 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |
6 | 91 82 00 37 01 09 7B 00 CC 67 02 E2 00 00 47 B1 03 C9 00 00 00 00 76 00 0C 00 8A B3 |
7 | B1 82 00 63 72 00 44 00 00 00 00 00 00 00 00 02 02 02 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 |
8 | B1 82 00 37 01 09 7B 00 CC 66 02 C2 00 00 47 B1 03 C7 00 00 00 00 79 00 0B 00 8A B4 |
9 | B1 82 00 43 72 00 0F 00 00 00 00 00 00 00 00 02 02 02 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E |
Grüße, Felix [Mod: Formatierung angepasst]
:
Bearbeitet durch Moderator
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.
Hallo Dieter, 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 | 51 42 00 13 C7 01 05 5C 05 DF 05 DB 00 13 00 00 00 00 00 00 00 00 00 FF |
2 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 13 00 00 00 00 00 00 00 00 00 FB |
3 | 51 42 00 13 C7 01 05 5C 05 E0 05 DB 00 0B 00 00 00 00 00 00 00 00 00 06 |
4 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 0D 00 00 00 00 00 00 00 00 00 01 |
5 | 51 42 00 13 C7 01 05 5C 05 E0 05 DB 00 03 00 00 00 00 00 00 00 00 00 0E |
6 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 02 00 00 00 00 00 00 00 00 00 0C |
7 | 51 42 00 13 C7 01 05 5C 05 DF 05 DB 00 0B 00 00 00 00 00 00 00 00 00 07 |
8 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 0E 00 00 00 00 00 00 00 00 00 00 |
9 | 51 42 00 13 C7 01 05 5C 05 DF 05 DB 00 05 00 00 00 00 00 00 00 00 00 0D |
10 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 10 00 00 00 00 00 00 00 00 00 FE |
11 | 51 42 00 13 C7 01 05 5C 05 DF 05 DB 00 08 00 00 00 00 00 00 00 00 00 0A |
12 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 07 00 00 00 00 00 00 00 00 00 07 |
13 | 51 42 00 13 C7 01 05 5C 05 DF 05 DB 00 02 00 00 00 00 00 00 00 00 00 10 |
14 | 51 42 00 13 C7 05 05 5C 05 E0 05 DB 00 00 00 00 00 00 00 00 00 00 00 0D |
15 | 51 42 00 13 C7 01 05 5C 05 E0 05 DB 00 01 00 00 00 00 00 00 00 00 00 10 |
16 | 51 42 00 13 C7 05 05 5C 05 DF 05 DB 00 00 00 00 00 00 00 00 00 00 00 0E |
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. Danke, Grüße, Felix
...und tatsächlich ist die Checksumme in Byte[23]: 255 - SUMME(Byte[4]:Byte[22])%256 Vielen Dank an alle! Nur das Emfpangsverhalten von dem Arduino wundert mich noch... Grüße, Felix
:
Bearbeitet durch User
Felix schrieb: > > 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.
Felix schrieb: > 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.
Hallo, gibts da einen Workaround? Die Baudrate im Arduino anpassen? Ich nutze die SoftwareSerial Library. Grüsse, Felix
Felix schrieb: > gibts da einen Workaround? 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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.