Folgendes Szenario: Ich hab hier was ausgetüftelt das gelegentlich mal ein 4kB großes Blob von A nach B transportieren muss. A und B sind per CAN-Bus miteinander verbunden. Ich stelle nun fest daß alle paar hundert Byte (zufällig) ein Byte falsch übertragen wird (oder zumindest nach dem Zusammensetzen der vielen 7-Byte Blöcke falsch ist) und zwar jedesmal an zufälliger anderer Stelle. Frage: * Ist es wahrscheinlich daß alle ~70 Telegramme eins so verfälscht wird daß die CRC dennoch passt und der CAN Controller den Empfang eines gültigen Telegramms meldet? (Bonusfrage: wie wahrscheinlich ist das überhaupt bei gegebener CRC-Länge, kann man das quantifizieren, mir mangelt leider etwas die Mathematik zu der ganzen CRC-Geschichte? * Oder muss ich den Fehler in meinen Code suchen? Jetzt wo ich nochmal drüber nachdenke während ich hier umständlich ein Posting darüber verfasse fällt mir aufgrund des nichtdeterministischen Verhaltens vielleicht ein falscher Umgang mit der Hardware ein oder ein Race mit deren DMA (Messagebuffer nicht gesperrt obwohl ich dachte das täte ich).
Aus vielen hundert gigabytes Messung Erfahrung kann ich sagen, dass das untypisch ist. Ein ordentlich aufgebauter Bus hat praktisch keine Bitfehler. Noch dazu müsste der oder die Fehler den CRC passieren ohne erkannt zu werden.
Jo, praktisch null.Irgendwo hatte ich mal ne Zahl für die Wahrscheinlichkeit unerkannter Fehler. Selbst erkannte Fehler sind schon sehr selten. Irgendwas was läuft da bei dir grundsätzlich schief.
Letzteres halte ich für wahrscheinlicher. CRC-Fehler erkennt der CAN-Controller und setzt dann ggf. ein Error Flag. Das musst du natürlich auswerten. Daher mein Verdacht Software. Zur Mathematik: Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit den falschen Daten eine passende Checksumme ergibt. Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt. Wenn es tatsächlich um nicht bemerkte Bitfehler ginge müsste dein Bus ganz massiv gestört sein. Du müsstest tausendfach Frames wegen Fehlern erneut übertragen. Das wäre dir doch sicher aufgefallen?
Die wirkliche fehlerwahrscheinlichkeit dafür kann ich dir auch nicht ausrechnen... Fakt ist, aus der praxis- wenn es bei dir so oft passiert hast du einen bug in deiner software. Oder reden wir von einer wirklich verseuchten umgebung..?
dunno.. schrieb: > Oder reden wir von einer wirklich verseuchten umgebung..? Selbst wenn - da kommt eher die Übertragung zum Erliegen, dass ständig Fehler unerkannt durchrutschen ist sehr unwahrscheinlich. Ganz abgesehen davon kann man ja auch eine eigene Sicherung der Daten durchführen, unabhängig von der Bus-Software. Georg
Tilo R. schrieb: > Zur Mathematik: > Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit > den falschen Daten eine passende Checksumme ergibt. > Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt. Diese Folgerung halte ich für falsch. Das wäre der Fall, wenn du das komplette Telegramm durch ein zufälliges anderes ersetzen würdest. Überträgst du aber z.B. pro Telegramm 128 Bit und hast einen Bitfehler pro MB, wird die Eigenschaft des CRC, dass einzelne Bitfehler immer erkannt werden, dazu führen dass die Rate viel viel niedriger ist, wahrscheinlich Richtung 2^-50 oder noch weniger.
:
Bearbeitet durch User
Schneide den CAN-Traffic doch mal auf einem separaten Gerät (CAN-Bus-Analyzer) mit und vergleiche die Daten auf dem Bus mit den Solldaten. Dann siehst Du ob das Problem auf der Senderseite oder auf der Empfängerseite ist.
Sven B. schrieb: > Tilo R. schrieb: >> Zur Mathematik: >> Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit >> den falschen Daten eine passende Checksumme ergibt. >> Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt. > > Diese Folgerung halte ich für falsch. Ich habe gute Gründe für die Annahme und würde das gerne diskutieren. Wenn ich falsch liege bleibt mir der Erkenntnisgewinn! > Das wäre der Fall, wenn du das > komplette Telegramm durch ein zufälliges anderes ersetzen würdest. Ich habe keine Annahme gemacht, wie viele Bit des Telegrams falsch sind. Zugegeben, ich habe den Prüfsummenalgorithmus nicht untersucht, ob er sicher alle 1-, 2-, ... n-Bit Fehler erkennt, und wie diese Distanzen verteilt sind. Stattdessen habe ich den Checksummen-Algorithmus als ideal angenommen, d.h. wie eine kryptographische Hashfunktion/Prüfsumme, die alle möglichen Telegrammdaten gleichmäßig auf den Wertebereich der Checksummen abbildet. Die Kollissionswahrscheinlichkeit ist dann die Wahrscheinlichkeit für eine falsch-negative Checksumme, d.h. die Wahrscheinlichkeit, dass ein falscher Frame als richtig erkannt wird, ganz egal, wie viele Bits darin jetzt falsch sind. Klar, mit realistischen Bitfehlerraten ist die Betrachtung der dominanten Einzel- bzw. Wenig-Bitfehler und deren Erkennung zielführender. Im gegebenen Fall halte ich meinen Ansatz für gerechtfertigt, da der TO eine abartig hohe Frame-Fehlerrate haben muss, wenn angeblich netto jeder 70ste Frame unerkannt falsch durchkommt. Die korrespondierende Bitfehlerrate muss dazu so hoch sein, dass ein Telegramm-Einzelbitfehler nicht mehr typisch ist und die Einzelbitfehler-Betrachtung daher keinen Sinn mehr macht. > Überträgst du aber z.B. pro Telegramm 128 Bit und hast einen Bitfehler > pro MB, wird die Eigenschaft des CRC, dass einzelne Bitfehler immer > erkannt werden, dazu führen dass die Rate viel viel niedriger ist, > wahrscheinlich Richtung 2^-50 oder noch weniger. Ja, das klingt realistisch. 1 Bit pro MB ist nicht wirchlich toll, das entspricht ungefähr einer Roh-Bitfehlerrate von 10^-7 Damit ergeben sich überschlägig als Wahrscheinlichkeiten (für Frames mit 100 Bit) folgende Warhscheinlichkeiten 1,0 * 10^-5 für einen 1-Bit-Fehler im Frame 4,9 * 10^-11 für 2 falsche Bits 1,6 * 10^-16 für 3 falsche Bits 3,9 * 10^-22 für 4 falsche Bits 1-Bit-Fehler werden vom CRC sicher erkannt, die fallen also weg. Und bei 2- und 3-bit Fehlern wird sicherlich auch noch ein Großteil erkannt (wie gesagt - über die Verteilung der Distanzen habe ich keine Kenntnis) Eine Netto-Framefehlerrate von 2^-50, entsprechend 10^-15 oder besser halte ich auch für möglich. Hier sind wir also einer Meinung.
Tilo R. schrieb: > Im gegebenen Fall halte ich meinen Ansatz für gerechtfertigt, da der TO > eine abartig hohe Frame-Fehlerrate haben muss, wenn angeblich netto > jeder 70ste Frame unerkannt falsch durchkommt. Die korrespondierende > Bitfehlerrate muss dazu so hoch sein, dass ein Telegramm-Einzelbitfehler > nicht mehr typisch ist und die Einzelbitfehler-Betrachtung daher keinen > Sinn mehr macht. Ok, das ist für mich so ohne Rechnen auch erstmal schlüssig. Man müsste mal nachrechnen, ob das so hinkommt (ob z.B. der Bus effektiv überhaupt noch funktioniert, wenn Mehr-Bit-Fehler die Regel sind), aber klingt nachvollziehbar. Im Endeffekt scheint es mir eher so, als ob die "du prüfst das CRC-Error-Flag nicht"-Erklärung plausibel ist.
:
Bearbeitet durch User
Bernd K. schrieb: > Ich stelle nun fest daß alle paar hundert Byte (zufällig) ein Byte > falsch übertragen wird (oder zumindest nach dem Zusammensetzen der > vielen 7-Byte Blöcke falsch ist) und zwar jedesmal an zufälliger anderer > Stelle. Nur eins? Dann schau Dir auch mal das Fifo Handling in der Software an. Insbesondere wenn das NXP Zeuchs ist, die hatten da sowas ähnliches drin:
1 | RingPuffer[(wr++) % BUFFERSIZE] = wert; |
Man sieht nicht gleich dass da der wr Index zu zeitig (VOR dem Schreiben) hochgezählt werden kann.
Zur Fehlererkennung mit CRC: der genutzte Algorithmus beim CAN-Bus erkennt - bis zu 5 zufällig verteilte Fehler in einer Nachricht - 15 aufeinanderfolgende Fehler (Burst-Fehler) - alle ungeradzahligen Bitfehler-Kombinationen - die Restfehlerwahrscheinlichkeit beträgt <4,7*10^-14 (Quelle Eschermann: CAN-Bus) Wie sieht bei dir die Verdrahtung aus? Ist Masse mit verbunden oder nur CAN-L und CAN-H? Wie viele Teilnehmer umfasst dein Netzwerk? Gibt es Error-Frames?
Hallo, oder andere Betrachtung: der CAN ist mit der CRC-Checksumme für ASIL B Datenübertragung nach ISO 26262 geeignet, d.h. als Einzelfehlerquelle im Automotive-Umfeld mit rund 1 FIT als Fehlerrate angenommen. 1 FIT ist 1 Fehler alle 10^9 Betriebsstunden. Da im Auto der CAN mit bis zu 1 MBit/Sekunde betrieben wird, geht also die Norm davon aus, dass bei einem normalen CAN-Bus maximal 1 Fehler alle 4.5*10^17 Bytes unerkannt durchgeht. Wenn bei Dir in jedem Kilobyte ein Byte verfälscht wird, würde ich stark davon ausgehen, dass es am Code liegt (wenn man den unwahrscheinlichen Fall eines Hardwaredefektes des CAN-Controllers ebenfalls ausschließt)... Schöne Grüße, Martin
Ich wuerde auf EMV tippen. Erbitte Schema, Layout und Foto des Aufbaus. Allenfass auch ein Oszilloskopbild der Signale.
Jim M. schrieb: > Nur eins? Dann schau Dir auch mal das Fifo Handling in der Software an. > Ich möchte auflösen. Es war natürlich meine Software, was auch sonst, > Insbesondere wenn das NXP Zeuchs ist, die hatten da sowas ähnliches > drin: > RingPuffer[(wr++) % BUFFERSIZE] = wert; Hardware ist zwar NXP (ehemals Freescale), Treiber selber gestrickt, aber damit hatte es gar nichts zu tun. Nachdem die Übertragung dieser Blobs vor 2 Monaten schonmal funktioniert hat (mit der alten Hardware, deshalb mein Hardwareverdacht) hab ich diesen Teil lange nicht mehr angefasst und auch bis letzte Woche nicht mehr getestet. Allerdings hat eine nachträgliche Änderung an ganz anderer Stelle in Verbindung mit einem von Anfang an unbemerkt fehlerhaften Dispatcher für eingehende Frames dafür gesorgt daß die leeren Heartbeat-Frames des Masters versehentlich in die selbe fifo gelangt sind wie die Frames mit den Nutzdaten. Das hat keine andere Funktion beeinträchtigt, nur an dieser einen einzigen Stelle an der eigentlich normalerweise keine Frames der Länge 0 jemals hätten hingelangen sollen (die wären damals schon viel weiter vorne rausgefiltert gewesen) wurde weder die id geprüft noch die Datenlänge und es wurde uninitialisierter Speicher blind als Sequenznummer und Datenblock interpretiert.
:
Bearbeitet durch User
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.