Servus zusammen, ich hab da ein Problem mit der CRC-CCITT (XModem) Checksum. 1) Wo kann ich detaillierte Infos über die Bildung dieser Checksum bekommen. Im Internet hab ich bis jetzt nichts brauchbares gefunden. 2) Wenn ich folgenden abgegriffenen Befehl habe ©FFFF3E02 (3E02 ist CRC) und den ASCII-Code in CRC-Calculator (lammertbies.nl) eingebe (Input type ASCII), bekomme ich die Checksum 0xEB78. Wenn ich jetzt aber nun das erweiterte Steuerzeichen © in Hex umwandle, also A9, und dann den Befehl A9FFFF eingebe (Input type Hex), bekomme ich als CRC die 3E02. Also, ich versteh das nicht so richtig...Kann mir jemand auf die Sprünge helfen? Gruß
> 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?
Ich versteh nicht, warum ich das erweiterte Steuerzeichen "©" in Hex A9 umwandeln muss, damit ich die gewünschte CRC 3E02 raus bekomme. Zudem kapier ich nicht ganz, weshalb ich den Input type auf Hex dann umstellen muss, weil ©FFFF ja die ASCII-Darstellung ist.
Anton schrieb: > 2) Wenn ich folgenden abgegriffenen Befehl habe ©FFFF3E02 (3E02 ist > CRC) Hallo, das kann schon nicht richtig sein. Es handelt sich um CRC16, also ist die Prüfsumme 16 bit bzw. 2 Byte, nämlich 3e und 02. Dann müssen die Daten aus 2 Byte FF bestehen, aber eine Hexzahl © gibt es nicht. Vielleicht hast du was aus ASCII und Hex wild zusammengesetzt. Von hier aus kann man deine Leitung schlecht abhören, das musst du schon selber machen und richtig aufschreiben. Gruss Reinhard
Angehängte Dateien:
-
hTerm.jpg
34 KB
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.
Autsch, stimmt!Dank Dir Udo. kannst du mir bei den restlichen Fragen vielleicht auch noch auf die Sprünge helfen? Gruß
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 Reinhard, das ist ja genau das Problem, dass ich die ganze Zeit versuche zu beschreiben. ©FFFF3E02 habe ich abgehört! in Hex wäre es A9 46 46 46 46 33 45 30 32. Wenn ich jetzt anstelle "©" das A9 einsetze (also A9FFFF) erhalte ich die korrekte CRC. Allerdings vermische ich da Hex und ASCII und das geht ja mal gar nicht. Diese Tatsache verwirrt mich ja!
Anton schrieb: > .. ©FFFF3E02 habe ich abgehört! in Hex wäre es A9 46 46 46 46 > 33 45 30 32. NEIN (Verzweiflung) - das ist die Bytefolge mit ASCII-Zeichen geschrieben! Lies nochmal mein letztes Posting: du hast A9 FF FF 3E 02 empfangen, 5 Bytes, nicht 9! (Wo du den abschliessenden CR hingetan hast, ist eine andere Frage). 2 Bytes FF FF sind vermutlich -1 in als 16bit-Wert. Da ist nirgendwo ein ASCII 'F' (hex 46). In ASCII lässt sich das A9 FF .. garnicht darstellen. 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
Das kann definitiv nicht sein! Da müssen die Bytes genommen werden, die auch tatsächlich übertragen werden.
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.