Hallo liebe Gemeinde, ich habe ein Problem, dem ich nicht gewachsen bin: Die Kommunikation eines Sensors mit einem Modul wird über 5 Datenbytes übertragen, das 6.Byte ist eine Prüfsumme/crc oder irgendetwas in der Art. Ausgelesene Beispiele sind in der angehängten Datei. Kann mir irgendjemand helfen, wie ich den Algorithmus dahinter finden kann? Vielen Dank schon mal, Tom
Nenn das nächste mal deine Datei gleich *.txt Dann haben alle weniger Probleme.
> Die Kommunikation eines Sensors
Welches Sensors?
Vielleicht gibt es dazu ja ein Datenblatt.
Das folgende passt auf den Anfang: 1. Byte um 4 Bits nach links rotieren 2. Byte um 3 Bits nach links rotieren 3. Byte um 2 Bits nach links rotieren 4. Byte um 1 Bits nach links rotieren 5. Byte um 0 Bits nach links rotieren Aufsummieren ergibt die Prüfsumme
ja, vielen Dank - eine heiße Spur. Das klappt bei mir bis zur Prüfsumme 255. Ist die Prüfsumme größer, wird es komisch...
Eigentlich nicht. man nimmt immernur das nidrigste Byte der Summe. Das heisst man addiert in ein Byte und vergisst den Overflow. Das ist sowieso das Normale Verhalten.
Aber spätestens hier 0x1F 0x0 0x0 0x87 0x1 0x0 funktioniert es nicht mehr. Ich denke das ist eine Sackgasse, auch wenn der Ansatz nicht dumm ist.
Hm, beim Beispiel dezimal 79,154,0,255,16 habe ich die Prüfsumme 212 gelesen 79 SHL 4=244 154 SHL 3=212 0 SHL 2=0 255 SHL 1=255 16 =16 -------------- Summe 727 lowbyte also 215 wo ist mein Fehler?
Der Ansatz ist von Jürgen total Klasse, die crc trifft häufig, Abweichungen wenn, dann nur minimal. Das ist - glaube ich - der richtige Weg.
Jürgen S. schrieb: > Das folgende passt auf den Anfang: > > 1. Byte um 4 Bits nach links rotieren > 2. Byte um 3 Bits nach links rotieren > 3. Byte um 2 Bits nach links rotieren > 4. Byte um 1 Bits nach links rotieren > 5. Byte um 0 Bits nach links rotieren > > Aufsummieren ergibt die Prüfsumme Hallo Jürgen, wie hast Du diesen Zusammenhang erkannt?
Alex W. schrieb: > > wie hast Du diesen Zusammenhang erkannt? Aus der aufsteigenden Folge am Anfang kann man vermuten, dass das 4. Byte die Wertigkeit 2 hat. Hypothese: Jedes Byte wird mit einem Faktor multipliziert und zur Prüfsumme aufsummiert. An einer aufsteigenden Folge weiter hinten sieht man, dass das zweite Byte die Wertigkeit 8 hat. Damit kriegt man aus den Anfängen der ersten beiden Blöcke die Wertigkeit 1 für das 5. Byte. Hypothese: Die Faktoren sind die Zweierpotenzen 16, 8, 4, 2, 1 Wenn man die erste Zeile anguckt, fehlen ohne Byte 5 noch 0xf1 in der Prüfsumme. Ein scharfer Blick auf das erste Byte gibt die Idee mit dem Rotieren.
Tom Weber schrieb: > Der Ansatz ist von Jürgen total Klasse, die crc trifft häufig, > Abweichungen wenn, dann nur minimal. Bei den meisten Einträgen ist sie falsch. Nur am Anfang des Files ist die Trefferquote relativ hoch. Wenn die Checksumme dir was bringen soll, muß sie auch genau stimmen und nicht nur so ungefähr. Karl Heinz Buchegger schrieb: > Aber spätestens hier > > 0x1F 0x0 0x0 0x87 0x1 0x0 > > funktioniert es nicht mehr. Richtig. Da müßte 1 rauskommen, aber es kommt 0 raus. Seltsam ist, daß es bei den drauffolgenden, sehr ähnliche Werten aber wieder stimmt: 0x1F 0x0 0x0 0x87 0x1 0x0 0x1F 0x0 0x0 0x88 0x1 0x3 0x1F 0x0 0x0 0x89 0x1 0x5 Gegen später stimmt das Ergebnis fast bei keiner Zeile mehr. Außerdem scheint sich die Abweichung nach hinten raus leicht zu vergrößern. Im File sind auch leere Zeilen drin, an Stellen, wo es zu Wechseln zwischen falsch und richtig kommt. Beispiel:
1 | 0x4F 0x5F 0x0 0xFF 0x10 0xFE -> falsch (0xFD) |
2 | |
3 | 0x4F 0x60 0x0 0xFF 0x10 0x6 -> richtig |
4 | 0x4F 0x61 0x0 0xFF 0x10 0xE -> richtig |
5 | |
6 | 0x4F 0x62 0x0 0xFF 0x10 0x13 -> falsch (0x16) |
Es gibt da mehrere Stellen, an denen das so aussieht. Das sind aber immer Stellen, an denen vom 2.Byte das untere Nibble von F auf 0 springt. Aber gegen später im File kommt noch irgendein anderer Offset dazu, so daß es da dann auch nicht mehr paßt. Im Anhang ist mal der komplette Inhalt durchgerechnet. Man sieht da die Originalwerte, dann True oder False, je nachdem, ob das Ergebnis paßt, dann das nach dem Jürgen-Verfahren berechnete Ergebnis, einmal auf 8 Bit beschnitten, einmal komplett, und am Schluß noch die rotierten Einzelwerte.
Ist denn sichergestellt, dass das die Bits den Bytes richtig zugeordnet werden? Vielleicht geht ja zwischen den Bytes ein neuntes Bit verschütt, das würde auch das Rotieren / Schieben erklären, und das Prüfbyte könnte eine einfache Summe der korrekten Daten sein.
Bei Maxim gibt es eine CRC8-Berechnung mit Tabelle. Das ist viel schneller als die Bitschieberei: http://www.maxim-ic.com/appnotes.cfm/appnote_number/27 Schau' mal bei "Example 3. DOW CRC Lookup Function"
zumindest bei den Zeilen mit 4F bin ich mir sicher, da stimmt zu Zuweisung. Komischerweise stimmt das, wenn 2.Byte 0,1,32,33,64,65,96,97 - ansonsten gibt es Verschiebung. Irgendwie ist da was mit dem 2.Byte
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.