> ich versteh das nicht so richtig
ich verstehe auch nicht so richtig, was du nicht verstehst.
Ich wiederhole mal das was ich rauslese aus deinen Zeilen:
FFFF ergibt Checksum EB78
A9FFFF ergibt Checksum 3E02
--> und was ist jetzt deine Verständnis-Frage? Hättest du einen anderen
Wert erwartet?
Hallo,
zunächst einmal Danke für die Antworten. Wenn ich die
Umdrehungsgeschwindigkeit auf 9000U/min setze fange ich den folgenden
Befehl mit hTerm ab --> []23280820. also 2328--> HextoDec= 9000.
Ich versteh jetzt allerdings nicht wie die CRC gebildet wird, also 0820.
Bei 8000U/min bekomme ich []1F40A576. Ich schau mir bei der Kalk. der
CRC ja nur die Bytes an und nehme das entsprechende Polynom zur
Berechnung also x16 + x12 + x5 +1.
Reinhard hat Recht, ich hab da so ein Gemisch aus Hex und ASCII
genommen. Warum zeigt es mir dann aber die korrekte Checksum an? Könnte
mir jemand auf die Sprünge helfen?
Grüße
Hallo,
aus deinem Bild ist zu entnehmen, dass deine Geräte ASCII-Zeichen
senden, die Hex-Zahlen darstellen. 2328 = 9000 dez sagt mein
Taschenrechner auch. Für Prüfsummen werden aber die gesendeten Bytes
verrechnet, ohne Rücksicht auf die Bedeutung, d.h. im diesem Fall wird
CRC/Prüfsumme gebildet aus (zumindest) den Bytes (hex) 32,33,32,38. Die
Zahl 9000 dez ist für die Prüfung irrelevant.
Ob das Startbyte B0 einegerechnet wird, ist Vereinbarungssache, kann man
nur probieren (wahrscheinlich ja, wenn verschiedene vorkommen -
irgendwas muss ja sagen: Drehzahl folgt). Das Byte 0D (= CR) ist sicher
der Recordabschluss.
Blieben also 4 Bytes als CRC, die als 4 ASCII-Zeichen 0820 interpretiert
werden - die Prüfsumme kann also in Hex 0820 oder 2008 lauten.
Gruss Reinhard
Hallo Reinhard,
danke für die Antwort!
Hast du mir vielleicht einen Tipp für einen CRC-Calculator?
Wie gesagt, wenn ich die Bytes bei lammertbies.nl- Online calculator in
Hex, also B0 32 33 32 38 eingebe, erhalte ich 0xA7E6...Das passt nicht!
Wie du gesagt hast, spielt die Darstellung, also 2328 --> DectoHex -->
9000 für die Berechnung der CRC keine Rolle. Vielleicht wurden die Bytes
ja so aufgebaut, dass eine einfache Umrechnung von Hex zu Dez möglich
ist, wobei der Befehl in ASCII codiert wurde?! Evtl. wurde eine einfache
Identifikation der einzelnen Parameteränderung im codierten ASCII-String
angestrebt.
>Blieben also 4 Bytes als CRC, die als 4 ASCII-Zeichen 0820 interpretiert>werden - die Prüfsumme kann also in Hex 0820 oder 2008 lauten.
Das verstehe ich nicht ganz. Die Prüfsumme müsste doch in Hex 30 38 32
30 sein, in ASCII 0820.
>werden - die Prüfsumme kann also in Hex 0820 oder 2008 lauten.
Sie müsste doch in ASCII 0820 lauten, oder? Wie kommst du da noch auf
2008?
Komisch ist nur, dass wenn ich ein Gemisch aus Hex also "B0" und ASCII
"2328" mache, ich auf die korrekte CRC "0820" komme.
Sorry, aber ich steh total auf dem Schlauch. Bin für jeden Tipp und
Hinweis dankbar.
Viele Grüße
Anton schrieb:> Sie müsste doch in ASCII 0820 lauten, oder? Wie kommst du da noch auf> 2008?
Schon mal was von Bytereihenfolge gehört?
Was passiert wenn Du die beiden Bytes 0x20 und 0x08 in unterschiedlicher
reihenfolge zusammensetzt?
Genau: Einmal 2008 und einmal 0820.
Welches Byte bei einem 16 Bit Wert (2 Byte) zuerst übertragen wird ist
Vereinbarungssache und hängt vom verwendeten Protokoll ab.
Hallo,
Tatsachen sind:
in deinem ersten Posting hast du abgehört: A9 FF FF 3E 02 , der
Holländer rechnet das gleiche aus.
In deiner Grafik "Received Data" steht: B0 32 33 32 38 30 38 32 30 (0D),
müsste aber heissen B0 32 33 32 38 41 37 45 36 (0D).
Warum das einmal übereinstimmt und einmal nicht, kann ich dir natürlich
nicht erklären - am wahrscheinlichsten ist immer noch, dass du irgendwo
einen Fehler gemacht hast. Die Online-Berechnung erscheint mir
vertrauenswürdig, ausserdem kann die Übereinstimmung im ersten Fall kein
Zufall sein.
Gruss Reinhard
Hallo Anton,
ich denke, ich weiß in etwa wo dein Problem liegt:
Folgendes: Du greifst den Befehl (siehe Posting) □23289820 ab. Das sind
ASCII-Zeichen, die Hex-Zahlen darstellen. Das hat Reinhard ja schon
erklärt. Um nun zu wissen, was tatsächlich über die Leitung geht, musst
du dir die Hex-Bytes ansehen. Das siehst du ja schon via hTerm--> B0 32
33 32 38 30 38 32 30 0D. Die Bytefolge kannst du ja aus der
ASCII-Tabelle entnehmen bzw. siehst du ja auch mit hTerm.
Die ASCII-Zeichen,so scheint mir es, die Hex-Zahlen darstellen (23 28),
werden jetzt zur CRC-Berechnung eingesetzt. das Quadrat scheint auch mit
zur Berechnung eingezogen werden. "□" ist aber keine Hexzahl, also
schauen wir in die ASCII-Tabelle und entnehmen "□" -HexzuDez-> "B0". Du
berechnest jetzt, unter der Tatsache, dass 2328 keine ASCII- sondern
eine Hex-Darstellung ist, die CRC. Bytemässig würde das dann so
aussehen:
B0--> 1011 0000
23--> 0010 0011
28--> 0010 1000
>Vielleicht hast du was aus ASCII und Hex wild zusammengesetzt.
Im Grunde ist es dann eine Vermischung aus ASCII- und Hex-Darstellung.
Eigentlich werden die ASCII-Zeichen als Hex-Darstellung zur
CRC-Berechnung interpretiert.
Gut möglich, dass die Geräte auf der Pseudo-Hex-Darstellung (2328) ihre
Checksum berechnen.Probiere doch mal folgendes aus: Generiere mal
verschiedene Befehle und schau, ob du das Gerät ansteuern kannst.
Probiers mal aus und wenn es klappt, wäre es die einzige Lösung die mir
dazu einfallen würde. Natürlich musst du beim Versenden des Befehls via
hTerm die Checksum in Hex-Bytes umwandeln und anhängen,
also (die 4 Bytes in ASCII-Zeichen)0820 wäre dann 30 38 32 30 +0D
(Carriage return)! Befehl würde also für dein Bsp. wie folgt lauten: B0
32 33 32 38 30 38 32 30 0D
>In deiner Grafik "Received Data" steht: B0 32 33 32 38 30 38 32 30 (0D),>müsste aber heißen B0 32 33 32 38 41 37 45 36 (0D).
Ja, wenn man die Bytefolge der ASCII-Darstellung nimmt. Wenn man aber
die ASCII-Zeichen als Hex-Darstellung interpretiert passt das dann
schon.
Das scheint mir die einzige Erklärung (wenn auch etwas Vogelwild) für
dein Problem zu sein.
Gruß
Hi Karl,
dass passt! Ich kann das Gerät ansteuern. Scheint die Lsg. zu sein, oder
gibt es da noch weitere Ansätze? Ist das ne übliche Codierung? Das mit
dem Online-Calculator ist ja gut und Recht, allerdings versteh ich immer
noch nicht ganz das Prinzip der CRC 16-CCITT(XModem)-Berechnung. Kann
mir da jemand weiterhelfen...Literatur,Links, Tipps,etc.? Gruß und
nochmals Danke für eure Antworten
Hallo,
also ich hab persönlich noch nie so eine Art von CRC-Berechnung erlebt.
Wobei der von Karl beschriebene Ansatz doch Sinn macht. Wie Reinhard
schon beschrieben/erwähnt hat, wird das normalerweise bytemässig
geregelt bzw. berechnet, also dass, was auch wirklich übertragen wird.
Interessant...Gruß Benni
