crc/xor/Prüfsumme gescuht

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...

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.

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.

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