Hallo, ich habe leider die Aufgabe, die serielle Kommunikation mit einem uralten Gerät ohne vernünftige Dokumentation zu programmieren und bin dabei auf folgendes Problem gestoßen: Das Gerät sendet mir immer 4 bytes Daten gefolgt von einem Paritätsbyte. Leider ist nirgends spezifiziert, wie dieses Paritätsbyte berechnet wird. Einzig folgende 4 Beispiele sind gegeben 00110001 01001111 01001111 01001111 00110011 01001110 01000110 01010110 00111000 01011111 01000110 01000101 00110111 01010100 01011111 01010010 00111101 00111010 01100000 00111110 Aus dieser Tabelle kann ich aber leider kein gängiges Verfahren erkennen. Es handelt sich weder um eine XOR-Verknüpfung noch um eine Längsparitätsprüfung. Erkennt vielleicht jemand von euch mit einem scharfen Auge um welches Paritätsverfahren es sich handelt?
Was ist es denn für ein Gerät? Es könnte auch möglich sein, dass das Verfahren ohne weitere Informationen nicht zu erkennen ist. Beispielsweise CRC
Frank J. (Gast) >wird. Einzig folgende 4 Beispiele sind gegeben >00110001 01001111 01001111 01001111 >00110011 01001110 01000110 01010110 >00111000 01011111 01000110 01000101 >00110111 01010100 01011111 01010010 >00111101 00111010 01100000 00111110 >Aus dieser Tabelle kann ich aber leider kein gängiges Verfahren >erkennen. Es handelt sich weder um eine XOR-Verknüpfung noch um eine >Längsparitätsprüfung. Naja, wenn da keine Tipfehler drin sind, ist es meistens gerade Parität, d.h. es gibt eine gerade Anzahl 1er Bits in jeder Spalte. Klappt aber nicht in der 3. und 4. Spalte. Vielleicht eine "Geheimkodierung", welche die 3. und 4. Spalte mit ungerader Parität betreibt? Dann klappt es mit allen Spalten! Sprich, erst normale Parität bilden und dann mit 00110000 nochmal XOR-verknüpfen. Ist informationstechnisch zwar Nonsense, hat aber möglicherweise einen persönlichen Touch?
Frank J. schrieb: > Das Gerät sendet mir immer 4 bytes Daten gefolgt von einem Paritätsbyte. > 00110001 01001111 01001111 01001111 fällt dir was auf?
dummschwaetzer schrieb: > Frank J. schrieb: >> Das Gerät sendet mir immer 4 bytes Daten gefolgt von einem Paritätsbyte. >> 00110001 01001111 01001111 01001111 > fällt dir was auf? Lies die Beispiele nickend, nicht Kopf schüttelnd.
Es handelt sich um eine Waage, welche modifiziert wurde, so dass sie die Messergebnisse seriell versendet. Daher gibt es auch kein Datenblatt oder ähnliches. Eine "Geheimkodierung" halte ich für höchst unwahrscheinlich. Tippfehler habe ich drei- und vierfach gesucht, aber keine gefunden.
Bitwurschtler schrieb: > Lies die Beispiele nickend, nicht Kopf schüttelnd. Abgenickt. eventuell was mit CRC kansst du unter http://zorc.breitbandkatze.de/crc.html rumspielen
Falk B. schrieb: > Vielleicht eine "Geheimkodierung", welche die 3. und 4. Spalte mit > ungerader Parität betreibt? Dann klappt es mit allen Spalten! Die Parität der Spalte 2 im 3. Datensatz ist aber ebenfalls ungerade. @Frank: Hast du noch ein paar mehr Beispiele?
Frank J. schrieb: > Yalu X. schrieb: >> Hast du noch ein paar mehr Beispiele? > > Leider nein, das sind die einzigen. Woher weißt du dann, dass es gültige Daten sind? Und nicht 1 oder 2 taube Nüsse dazwischen... Und: Einer Waage sollte man mehr Werte entlocken können.
Frank J. schrieb: > Es handelt sich um eine Waage, welche modifiziert wurde, so dass sie die > Messergebnisse seriell versendet. Sartorius?
Arduino F. schrieb: > Woher weißt du dann, dass es gültige Daten sind? > Und nicht 1 oder 2 taube Nüsse dazwischen... > > Und: > Einer Waage sollte man mehr Werte entlocken können. Das sind Beispiele aus einer "Dokumentation". Die Waage zum testen hatte ich nicht zur Hand. Aber das Rätsel ist mittlerweile gelöst. Die Bytes sind ASCII Zeichen. Um das Paritätsbyte zu errechen zieht man von jedem Byte 48 (also '0') ab, verknüpft alles mit XOR und addiert 48 wieder auf.
Frank J. schrieb: > Aber das Rätsel ist mittlerweile gelöst. Die Bytes sind ASCII Zeichen. > Um das Paritätsbyte zu errechen zieht man von jedem Byte 48 (also '0') > ab, verknüpft alles mit XOR und addiert 48 wieder auf. Mist, und ich war so kurz davor ... :) Einer meiner ersten Gedanken war, dass die Prüfsumme irgendwie so umgerechnet wird, dass (passend zum Rest) ein druckbares Zeichen herauskommt. Erst probierte ich die Subtraktion von 32, XOR-Verknüpfung der 4 Bytes und anschließende Addition von 32. 32 deswegen, weil das der niedrigste ASCII-Code eines druckbaren Zeichens ist. Das passte aber nicht. Als ich die zweite 32 auf 48 erhöht habe, stimmten immerhin schon 3 der 4 Prüfsummen. Irgendwie habe ich es verpennt, die erste 32 auch noch auf 48 zu erhöhen, was ja nur logisch gewesen wäre :-/
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.