mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Verständnisfrage CRC (16) -CCITT (XModem)


Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anton (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Schmitt (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autsch, stimmt!Dank Dir Udo. kannst du mir bei den restlichen Fragen 
vielleicht auch noch auf die Sprünge helfen? Gruß

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Cosmo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann definitiv nicht sein! Da müssen die Bytes genommen werden, die 
auch tatsächlich übertragen werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.