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. :-(
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.
zwei Bitfehler an exakt derselben Stelle findest du für zu anfällig? Wie oft trat dieser Fehler bei dir schon auf?
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.
>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.
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.
>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
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!
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?
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.
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
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.
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.
>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
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.
Ich danke Euch allen für die Antworten! Mit den Informationen sollte ich es doch in den Griff bekommen.
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.