www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ab wann macht CRC8, 16 oder 32 Sinn?


Autor: hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte ganz gerne eine Übertragung auf der seriellen Schnittstelle 
mit einer Checksumme versehen.

Ab welcher Datenbyte Anzahl macht CRC 16 und CRC 32 Sinn?

Gibt es da eine Orientierung? Bei GPS Datensätze wird ja zum Beispiel 
nur ein normales XOR pro Datenbyte gemacht, das halte ich aber eindeutig 
für anfällig.

Da kann die Checksumme mit 2 Bit Drehern plötzlich wieder stimmen obwohl 
falsche Daten enthalten sind.

:-(

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hardy schrieb:
> Da kann die Checksumme mit 2 Bit Drehern plötzlich wieder stimmen obwohl
> falsche Daten enthalten sind.
Und wie hoch ist die von dir ermittelte Wahrscheinlichkeit das ein zwei 
(vier, sechs, ...) bit Fehler Auftritt?
Und wieviele musst/willst du den erkennen können? Dann schaust du was 
die CRC leistet und hast deine Antwort.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phi * Daumen:
bis 256 Byte: CRC8
bis 64kB: CRC16


Peter

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zwei Bitfehler an exakt derselben Stelle findest du für zu anfällig?

Wie oft trat dieser Fehler bei dir schon auf?

Autor: hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dank an Euch!

Läubi .. schrieb:
> Und wie hoch ist die von dir ermittelte Wahrscheinlichkeit das ein zwei
> (vier, sechs, ...) bit Fehler Auftritt?
> Und wieviele musst/willst du den erkennen können? Dann schaust du was
> die CRC leistet und hast deine Antwort.

Ich habe keine Ahnung wie ich das ermitteln soll... da reicht mein 
Wissen wohl nicht. Ich habe Datenpakete von max. 127 Datenbytes...

Peter Dannegger schrieb:
> Phi * Daumen:
> bis 256 Byte: CRC8

Das klingt doch gut! Das ist im Prinzip das was ich wissen wollte. Alles 
kostet ja Rechenzeit und Speicherplatz und wenn eine CRC 8 reichen 
würde, dann wäre es doch sehr schön.

Bastler schrieb:
> zwei Bitfehler an exakt derselben Stelle findest du für zu anfällig?
> Wie oft trat dieser Fehler bei dir schon auf?

Keine Ahnung, es ist ja nun nicht so das dann am Controller eine Lampe 
leuchtet. Es wird dann eine Fehlfunktion geben und man wundert rum.
Fand die Anfälligkeit am PC beim erstellen von GPS Datensätze
eben erstaunlich schnell. Zwei Werte verändert und dann kam die gleiche
XOR Summe bei heraus obwohl beide Pakete unterschiedliche Daten 
enthielten.

Das möchte ich durch den Einsatz von CRC vermeiden.

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>und dann kam die gleiche XOR Summe bei heraus obwohl beide Pakete 
>unterschiedliche Daten enthielten.

Das ist ja auch möglich und kein Fehler.
Der Empfänger des Protokolls muss natürlich selbst die CRC berechnen und 
mit der gesendeten vergleichen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hardy schrieb:

> eben erstaunlich schnell. Zwei Werte verändert und dann kam die gleiche
> XOR Summe bei heraus obwohl beide Pakete unterschiedliche Daten
> enthielten.

Gut. Du hast sie mutwillig verändert.
Daher auch die Frage: Wie oft hast du das schon in freier Wildbahn 
beobachtet?

Klar kann es auch mal auf einer Seriellen Störungen geben. Allerdings 
sind diese Fehler normalerweise nicht so subtil, dass zufällig mal 
irgendwo ein Bit kippt. Wenn eine Serielle gestört ist, dann ist sie 
richtig gestört. Da erkennst du deinen GPS Datensatz nicht mehr wieder. 
Da stimmt dann nichts mehr. Keine Datensatzkennung, keine oder viele zu 
viele ',' die die Teile des Datensatzes trennen, kein '\n' oder eines an 
einer völlig falschen Stelle, etc. etc.
Sprich: Wenn man nicht einfach blind in einen GPS Datensatz reingreift 
und sich Zeichen rausholt, dann erkennt man sofort, dass dieser 
Datensatz nichts taugt. Auch völlig ohne Checksumme.

Einen sporadischen Einzelbitfehler hab ich in 30 Jahren auf einer 
Seriellen noch nie erlebt. Komplett gestörte Datensätze ... kommt schon 
mal vor.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Phi * Daumen:
>bis 256 Byte: CRC8
>bis 64kB: CRC16

Nein. Es sind

CRC8  schuetzt bis 2^8  bit = 32byte
CRC16 schuetzt bis 2^16 bit = 8kbyte
CRC32 schuetzt bis 2^32bit = 500MByte

Autor: hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Das ist ja auch möglich und kein Fehler.

Das ist natürlich richtig, doch bin ich der festen Annahme das diese 
Änderung 2 verschiedene CRC Summen erzeugt und damit ein anderen Inhalt 
"anzeigt".

Karl heinz Buchegger schrieb:
> Daher auch die Frage: Wie oft hast du das schon in freier Wildbahn
> beobachtet?

Ganz ehrlich? Noch nie... und es ginge noch weiter, ich habe bis jetzt 
wohl auch noch keine Störung auf den Leitungen erlebt. :-(
Nur weil ich nun von den Prüfsummen gehört habe, würde ich es eben gerne 
doch implementieren um den eventuell Störungsfall einfach auszuschließen 
und im Fall des Falles dann einfach nochmal neu zu senden.

Karl heinz Buchegger schrieb:
> Wenn eine Serielle gestört ist, dann ist sie
> richtig gestört. Da erkennst du deinen GPS Datensatz nicht mehr wieder.

Ok, was sagt dann Deine Erfahrung in Bezug mit Wiederholung bei falscher 
CRC? Macht es dann mit dem Retry überhaupt Sinn? Ohh man, wohl doch 
nicht so trivial wie ich erst dachte.

Heia Jetzt-aber schrieb:
> Nein. Es sind
> CRC8  schuetzt bis 2^8  bit = 32byte

Hmm dann müsste ich wohl doch zu CRC 16 greifen... hmm

Danke Euch!

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hardy schrieb:
> doch bin ich der festen Annahme
Bei Checksummen ist es wie in der Kryptographie: durch feste Annahmen 
ist noch kein sicheres Verfahren entstanden...

hardy schrieb:
> Nur weil ich nun von den Prüfsummen gehört habe, würde ich es eben gerne
> doch implementieren um den eventuell Störungsfall einfach auszuschließen
Ein XOR ist halt einfach und deckt viele Fälle ab
> und im Fall des Falles dann einfach nochmal neu zu senden.
Wenn der Störungsfall ungleich einem Störfalls (GAU) ist kann man auch 
oft damit leben das (vorübergehend) falsche Werte angezeigt werden, wenn 
diese nicht sowieso wie schon angesprochen durch eine 
Plausibilitätsprüfung verworfen wurden.
Und das Problem ist doch: Wenn die Leitung so "kaputt" ist das gleich 
mehrere Bits umkippen... wie willst du dann die Nachricht, dass neu 
gesendet werden soll darüberkriegen?

Autor: hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> wie willst du dann die Nachricht, dass neu
> gesendet werden soll darüberkriegen?

Jo ja ähm also das weiß ich nun auch noch nicht.

Es geht darum das ich von einem PC zu einer Schaltung übertragen möchte 
und die auch wieder abfragen. Wenn es Störungen gibt dann darf die 
Steuerung keinen Mist machen.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Es geht darum das ich von einem PC zu einer Schaltung übertragen möchte
>und die auch wieder abfragen. Wenn es Störungen gibt dann darf die
>Steuerung keinen Mist machen.

Dann mach die Verbindung stabil.

MfG Spess

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denk dir ein Protokoll aus!

Es gibt Protokolle wo Zeichen doppelt versendet werden um sicher zu 
gehen.

Beispiel:
- Jedes Byte mit Parität
- Zeichen wiederholen
- CRC


Aber im Ernst, ich arbeite bei einem Sensorhersteller, da dürfen auch 
keine Fehler vorkommen sonst läuft ne Maschine Amok.
RS232 ist mit dem Pegel schon nicht sooo einfach zu stören, ansonsten 
nimm RS485.
Geschirmte Kabel verwenden, keine extreme Baudraten und ne CRC8 drüber.
Da passiert "normalerweise" nichts.

Wenn die physikalische Anbindung schlecht ist nützt das beste Protokoll 
nichts. Denk auch daran.

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, vergessen.

Wenn die Anlage sicher sein soll, dann bau eine Art "Keep-Alive" 
Nachricht ein. Wenn die Anlage eine Zeitlang nichts mehr hört geht diese 
in einen sicheren Zustand.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Gibt es da eine Orientierung? Bei GPS Datensätze wird ja zum Beispiel
>nur ein normales XOR pro Datenbyte gemacht, das halte ich aber eindeutig
>für anfällig.

>Da kann die Checksumme mit 2 Bit Drehern plötzlich wieder stimmen obwohl
>falsche Daten enthalten sind.

Das kommt auf Dein Fehlermodell an. Diese (un-)bewussten
Vertauschungen ("Dreher") kommen i.d.R. bei Menschen vor,
wenn sie etwas niederschreiben muessen, dafuer wurden bestimmte
Pruefsummen entwickelt (z.B. Luhn-Algorithmus).

Bei dem CRC Fehlermodel liegt eine lokale Fehlerannahme zugrunde,
dass ein n-Fehlerbuendel (= n gestoerte Bits) zuschlaegt,
was besonders im Industrieumfeld bei Schaltvorgaengen
(auch bei sonst "ungestoerten" seriellen Leitungen) haeufiger
auftritt ("burst error"). (Auch hier ist das Stichwort RS-485
statt RS-232 schon gefallen.. ;-)

Erstmal:
Wenn das zugrundeliegende Polynom den Grad r hat, wird
jedes Fehlerbuendel der Laenge b <= r sicher (=100%) erkannt.

Da Du auf eine Zeichenvertauschungserkennung "scharf" bist
(SCNR) bist, ist eine CRC-16 zwingend :-)

Sofern diese n gestoerten Bits mit gleicher Wahrscheinlichkeit
auftreten:
b=r+1 Fehlerbursts werden mit 2^(-r+1) nicht erkannt
b>r+1 Fehlerbursts werden mit 2^(-r) nicht erkannt
(-> Jungnickel, Codierungstheorie)

Fuer r=16 also 17er Fehlerbursts zu ~ 1:32000
Fuer r=16 also >17er Bursts zu ~1:65000

Mit ein paar Annahmen zu Deinem Fehlermodell auf Layer1
(jedes Bituebertragung unabhaengiges Ereignis mit z.B.
10^-6 Fehlerwahrscheinlichkeit (also Erfolgsw.=99,9999%),
kommt man bei einem Block von 10000 Bits auf 99,00%
Blockuebertragungserfolg ohne Fehler. Und nun sieht man sich
die Burst-Fehler an und ueberlegt sich bei den verbleibenden
Fehlern, ob das Anforderungsdokument des Systems das
Restfehlermodell impliziert.

Mag man die Rechnerei nicht, gab es schon ein paar
gute Praktikerabschaetzungen in Thread...

VG,
Hans

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein vernuenftiges Protokol macht auch schon was. zB, dass jede Meldung 
des Master vom Slave quitiert werden muss. Wenn man einen vorgegebenen 
Master und einen oder mehrere Slaves hat, so macht das so Sinn. Also 
auch ein Steuercommand bewirkt eine Antwort. Der Slave muss also immer 
in einem sicheren Zustand sein, resp von selbst dahin gelangen.

Autor: hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke Euch allen für die Antworten!
Mit den Informationen sollte ich es doch in den Griff bekommen.

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.