Checksumme bestimmen (wahrscheinlich CRC8)

[Fabian H. (hdr)]

Hallo,
ich habe eine Übertragung zwischen zwei Controllern, die nicht in meiner 
Hand liegt. Nun würde ich gerne selber Telegramme einschleusen. Das 
Problem ist, dass ich hierfür die Checksumme berechnen muss.

Das Telegram besteht aus STX Nutzdaten Checksumme ETX.

Hier sind mal 3 Beispiele:

02 02 01 01 D5 03
02 02 01 00 8B 03 

02 12 01 00 C1 03 

02 18 03 00 00 00 CA 03

Kann man anhand dieser Beispiele bereits das Polynom oder das Verfahren 
bestimmen? Gibt es evtl. ein Tool, welches ich mit dem Beispiel füttere 
und welches dann alle Polynome o.ä. per Brute-Force durchgeht?

Vielen Dank!

[Dennis (Gast)]

Fabian H. schrieb:
> Gibt es evtl. ein Tool, welches ich mit dem Beispiel füttere
> und welches dann alle Polynome o.ä. per Brute-Force durchgeht?

Schreibt man als Programmierer in wenigen Minuten in C, also erwartest 
du hoffentlich nicht daß das einer für dich tut?

[Fabian H. (hdr)]

Hast Recht... Habe ich jetzt auch gemacht. Aber das Problem ist, dass 
ich für den oberen Fall 0xC7 bekomme. Für den zweiten Fall keine Lösung 
und für den 3. Fall 0x5B...

Also eine einfache CRC Berechnung scheint es doch nicht zu sein.

[Tiramisu (Gast)]

Fabian H. (hdr)schrieb:
>Hier sind mal 3 Beispiele:

Vier ;-)

Sind die Daten wirklich richtig erhoben?

>
>02 02 01 01 D5 03

Woher soll das "Protokoll" erkenen, welcher der 02er
der Start ist.

>02 02 01 00 8B 03
>
>02 12 01 00 C1 03
>
>02 18 03 00 00 00 CA 03

Hm, welcher 03er zeigt denn nun das Ende an?

Das Uebertragungsprotokoll waere ziemlich vermurkst,
wenn die bisherigen Hypothesen so stimmen.

[R. R. (elec-lisper)]

Zuumindest bei den Seriellen Protokollen mit denen
ich üblicherweise zu tun habe kommt die Checksumme nach ETX.
Dort wird das Paket ohne STX, aber mit ETX über simples XOR
der Bytes mit einer "Checksumme" (BCC) am Ende versehen.
Also:

STX XX XX XX XX ETX BCC

> Woher soll das "Protokoll" erkenen, welcher der 02er der Start ist.

Start kann ja nur das erste STX sein. Danach sucht man ja
üblicherweise nach dem ETX. Hat sein Paket zusammen, zieht
die Checksumme, und vergleicht sie mit der Checksumme
des Paketes.

Wenn die Checksumme wirklich Teil des Paketes ist, dann muss
verhindert werden, dass diese den Wert ETX annimmt.
Entweder über spezielles Escaping oder indem man die Checksumme
hinter das ETX schiebt.

[Fabian H. (hdr)]

Tiramisu schrieb:
> Das Uebertragungsprotokoll waere ziemlich vermurkst,
> wenn die bisherigen Hypothesen so stimmen.

Warum vorhandene 02 / 03 des Frames nicht Escaped werden ist mir auch 
ein Rätsel, aber ist halt so...

Eine komplette Nachricht sieht so aus:

<STX> <Kommando> <Payload-Länge> <Payload> <CRC> <ETX>

Wobei das niederwertigste Bit des Kommandos immer die Datenrichtung 
angibt.

Durch das zeitliche Verhalten (immer ca. 1 Sekunde Pause zwischen den 
Telegrammen) sollten die oben gezeigten Telegramme schon richtig 
dargestellt sein. Durch STX, Länge, CRC und ETX ist die Syncronisation 
wohl relativ sicher. (auch ohne Escape).

Im Anhang ist mal ein längerer Trace. Die beiden Kommunikationspartner 
scheinen im Request / Respone Verfahren zu kommunizieren.

[Fabian H. (hdr)]

Die Berechnungen erfolgen im übrigen auf einem STM32F103

[Flo (Gast)]

Das dritte Byte ist die Länge

<STX> ?? <Länge> <n x daten> <checksumme> <etx>

[Flo (Gast)]

Das zweite Byte wird wahrscheinlich eine Nachrichtentyp oder Kommando 
Byte sein.

[Fabian H. (hdr)]

Ja. Ich habe den kompletten Frame ja schon um 8:35 Uhr beschrieben:

Fabian H. schrieb:
> Eine komplette Nachricht sieht so aus:
>
> <STX> <Kommando> <Payload-Länge> <Payload> <CRC> <ETX>
>
> Wobei das niederwertigste Bit des Kommandos immer die Datenrichtung
> angibt.

Es geht mir jedoch um die Prüfsummen-Berechnung.

[Flo (Gast)]

Ist offenbar Dallas CRC8...
Fabian, du warst früher mal cleverer.... :-)

Gruß,
Flo

[Fabian H. (hdr)]

Und Du konntest früher mal lesen. :-P

Aber nu prüfe ich erstmal, ob es sich um Dallas CRC8 handelt, denn ich 
habe inzwischen alle Permutationen von Polynomen und Initialwerten 
durchprobiert...

[Flo (Gast)]

Fabian H. schrieb:
> Warum vorhandene 02 / 03 des Frames nicht Escaped werden ist mir auch
> ein Rätsel, aber ist halt so...

Naja, wenn ich die Länge kenne kann ruhig ETX uns STX im Body 
vorkommen...
Ist doch logisch. Das letzte ETX kann man dann noch zur Sicherheit 
abfragen, um evtl. Bitfehler in der Länge zu erkennen.

Gruß,
Flo

[Flo (Gast)]

Fabian H. schrieb:
> Aber nu prüfe ich erstmal, ob es sich um Dallas CRC8 handelt, denn ich
> habe inzwischen alle Permutationen von Polynomen und Initialwerten
> durchprobiert...

Nur CRC8 mit Dallas/Maxim Polynom nicht :-)

[Dennis (Gast)]

Fabian H. schrieb:
> denn ich
> habe inzwischen alle Permutationen von Polynomen und Initialwerten
> durchprobiert...

Prüfe auch mal die Zwischenwerte in deinem Programm ab, ich habe schon 
einige Übertragungen gesehen, bei denen der CRC nicht über das gesamte 
Datenpaket gerechnet wurde sondern nur über einen Teilbereich.

Fabian H. schrieb:
> STM32F103

Dann hat es ja einen eingebauten CRC in HW, siehe Anhang.

Quote:"In the scope of the EN/IEC 60335-1 standard..."

[Fabian H. (hdr)]

Flo schrieb:
> Nur CRC8 mit Dallas/Maxim Polynom nicht :-)

Das scheint es tatsächlich zu sein... :-) ... Nun muss ich erst einmal 
Ursachenforschung betreiben, warum ich nicht selbst darauf gekommen 
bin.... ;-)

Vielen Dank!

[Fabian H. (hdr)]

Vielen Dank, Flo!
Irgendwo hatte sich wohl in meine CRC-Berechnung ein Fehler 
eingeschlichen. (ich denke mal, falsche Bit-Order), aber es lässt sich 
jetzt nicht mehr genau sagen... Egal.

Um diesen Thread ordentlich abzuschließen, hier die Zusammenfassung:

- Die CRC wird über den kompletten Frame ohne STX und ETX berechnet.
- Es wird das Dallas/Maxim Polynom (DOW) verwendet.
- Der folgende Code berechnet die richtige CRC:

    public class Crc
    {
        public static byte Calc(byte[] data)
        {
            byte crc = 0;
            byte inbyte;
            byte mix;

            for (byte i = 0; i < data.Length; i++)
            {
                inbyte = data[i];
                for (byte j = 0; j < 8; j++)
                {
                    mix = (byte)((crc ^ inbyte) & 0x01);
                    crc >>= 1;
                    if (mix != 0)
                        crc ^= 0x8C;
                    inbyte >>= 1;
                }
            }
            return crc;
        }
    }

Vielen Dank auch an alle anderen, die sich ebenfalls beteiligt haben!