Hallo, ich möchte eine bidirektionale Datenübertragung zwischen zwei Controllern realisieren. Daten befinden sich in zwei Bytes. Nun ist die Frage was ist statistisch sicherer eine Fehlerhafte Übertragung der Information zu identifizieren. Das Datenpacket nochmal senden, also 2 + 2 Byte... Dann vergleichen! Oder Einen CRC16 dranzuhängen. was ebenfalls 2 + 2 Bytes wären. Danke für eure Antworten.
Wenn deine Übertragungsstrecke ein Byte konsistent und immer gleich verändert, dann kannst du das mit Wiederholung nicht detektieren. Denn auch die Wiederholung wird exakt gleich verändert wie das Original. Einfachstes Beispiel: deine Übertragungsstrecke modifiziert alle Bytes zu 0x00. D.h. der Empfänger sieht 0x00,0x00 und als Widerholung ebenfalls 0x00 und 0x00. Woraus er schliesst, das 0x00,0x00 korrekt ist. Ist es aber nicht. Eine CRC unterscheidet sich aber von den Datenbytes. D.h. selbst wenn der Sender 0x00, 0x00 senden will, ist die CRC dafür nicht 0x00, 0x00. Was der Empfänger wiederrum detektieren kann und daher weiß, dass etwas nicht stimmt. Eine Nachricht zu wiederholen ist ungefähr so sinnvoll wie bei offensichtlichem Nichtverstehen einer Frage, dieselbe Frage in gleichem Wortlaut nochmal in gesteigerter Lautstärke zu wiederholen.
Ich habe mal alle Bits invertiert nachgeschickt und geprüft. Bombensicher und für wenige Bytes einfacher zu berechnen als CRC. Schöne Grüße Michal
Gustel schrieb: > > Das Datenpacket nochmal senden, also 2 + 2 Byte... Dann vergleichen! Das 2.mal sollte man die negierten Daten schicken. > > Oder > > Einen CRC16 dranzuhängen. was ebenfalls 2 + 2 Bytes wären. > Overkill, CRC5 bzw CRC8 reicht. Ein ECC für 16bit braucht übrigens auch nicht mehr.
Die 99€ Frage lautet: Wie genau muss es sein? Eine einfache (8 Bit) Prüfsumme benötigt weder sehr viel Rechenleistung, noch viel Platz (1 Byte). In den meisten Fällen reicht das gute alte Paritätsbit. Damit können viele - natürlich nicht alle - Fehler in JEDEM Byte erkannt werden. Als zusätzliche Sicherheit kann auch eine Plausibilitätsprüfung, auf Softwareebene, erfolgen. Zum Bleistift sind 99°, 102° und 100° plausibel. 150° dazwischen aber nicht. Übrigens: Mit einer CRC ist es ja auch nicht getan. Der Sender muss immer auf eine Bestätigung (min. 1 Byte) warten und es muss auch ein Wiederholungsprotokoll implementiert werden. Bei den im Beispiel aufgeführten Werten, könnte man den Wert 150° durch den Mittelwert des Vorgängers und des Nachfolgers ersetzen. Natürlich ist, genügend Zeit (Rechen- und Übertragungszeit) vorausgesetzt, eine echte Prüfsumme genauer.
Mit CRC Übertragungsfehler erkennen und die Message periodisch senden (siehe CAN).
gehh schrieb: > und die Message periodisch senden (siehe CAN). CAN hat nichts mit "periodisch senden" zu tun. Wird zwar öfters so gemacht, aber bei weitem nicht immer. Häufig wird auch nur bei einer Werte- oder Zustandsänderung eine CAN-Message geschickt. Btw: periodisch senden kann man auch auf jedem anderen Übertragungsweg (RS232, I²C, SPI, RS485 usw...). Das hat nichts mit CAN zu tun...
"Eine Nachricht zu wiederholen ist ungefähr so sinnvoll wie bei offensichtlichem Nichtverstehen einer Frage, dieselbe Frage in gleichem Wortlaut nochmal in gesteigerter Lautstärke zu wiederholen." (Karl-Heinz) Schlechter Vergleich bzw. Ironie, da im realen Leben doch wohl mehr als sinnvoll und hilft fast immer weiter;) CRC ~95% Warscheinlichkeit eines systematischen Fehlers: ??? Wenn man systematische Übertragungsfehler real nahe Null annimmt, iegen die beiden Fehlerwarscheinlichkeiten vieleicht gar nimmer so weit auseinander, oder?
Michal Polanski schrieb: > Ich habe mal alle Bits invertiert nachgeschickt und geprüft. Das wäre eine einfache Variante. Nur, wenn ein Wert davon falsch ist, weiß ich immer noch nicht, welcher der Beiden gesund war. :-)
oszi40 schrieb: > Nur, wenn ein Wert davon falsch ist, > weiß ich immer noch nicht, welcher der Beiden gesund war. :-) Weißt du bei einer CRC, welches von beiden Bytes falsch war? :-)
oszi40 schrieb: > welcher der Beiden gesund war Für solche Zwecke ist das Stichwort "ECC", es fiel weiter oben schon einmal. Bei 16 Prüfbits auf 16 Nutzbits ist da schon eine Menge möglich.
Zwei Aspekte, die nicht erwähnt wurden: 1. Was wird denn mit den Daten gemacht? Werden sie z.B. nur zyklisch alle 100ms auf einem Display ausgegeben, kann man eine Prüfsumme auch weglassen. Werden die Daten weiterverarbeitet … was kann im schlimmsten Fall passieren? 2. Was heisst "bidirektionale Datenübertragung" genau? Im Falle einer SPI Übertragung werden bei einer Störung der Clock ggf. alle Bits im Empfänger versetzt gelesen. Ein reines doppeltes Senden (mit oder ohne Invertierung) deckt den Fehler dann ggf. nicht auf (aber alles schon gesehen….) > Eine CRC unterscheidet sich aber von den Datenbytes. > D.h. selbst wenn der Sender 0x00, 0x00 senden will, > ist die CRC dafür nicht 0x00. Vorsicht! Das gilt nur, wenn der Startwert ungleich 0x00 ist. Sonst wirft eine CRC über 0x00…. als Wert 0x00 aus!
Was noch nicht angesprochen wurde: Neben eine Sicherung über CRC a.Ä. ist es wichtig, dass der Anfang der Nachricht sicher erkannt wird. Eine Pause zwischen 2 Datensätzen ist eine einfache Methode. Bei einer lückenlosen Sendung braucht man ein eindeutiges Startzeichen bzw. Startsequenz. Gruß Dietrich
> Für solche Zwecke ist das Stichwort "ECC"
ECC würde ich IMHO nicht nutzen. ECC ist auf Controllern meist auf
aufwändiger, macht nur Sinn wenn eine Rekonstruktion der Daten wichtig
ist. Bei zyklischen Übertragungen ohne ECC muss man halt auf das nächste
Paket warten.
Ich würde eine CRC nutzen. Ob 8/16/32 Bit würde ich abhängig von der CPU
machen. Meistens nutze ich eine schnelle 8/16 Bit CRC mit Lookup
Tabelle. Startwert irgendetwas != 0.
npn schrieb: > CAN hat nichts mit "periodisch senden" zu tun. Wird zwar öfters so > gemacht, aber bei weitem nicht immer. Richtig. Der Hinweis in Richtung CAN sollte auch nur dem Beispiel dienen, da es dort meiner Meinung nach in Mehrheit so praktiziert wird. > Häufig wird auch nur bei einer > Werte- oder Zustandsänderung eine CAN-Message geschickt. Dann komme ich aber um eine Fehlererkennung plus erneutem Senden bei Übertragungsfehler nicht herum. Sende ich periodisch, kann ich mir dieses Handling sparen. Lediglich die Zeit zwischen den Messages könnte ggf. zu lang sein. Aber das wäre ja Definitionssache. Sende ich bei Übertragungsfehler noch einmal, könnte auch diese Message wieder gestört werden. Da gibt es auch keinen Unterschied zum zyklischen Senden. Auch hier könnte die nächste Message gestört werden. > Btw: periodisch senden kann man auch auf jedem anderen Übertragungsweg > (RS232, I²C, SPI, RS485 usw...). Das hat nichts mit CAN zu tun... Habe ich ja auch nicht gesagt. Oder stand da, dass zyklisches Senden nur bei CAN eingesetzt wird, bzw. überhaupt einsetzbar ist? A -> B ist nicht automatisch B -> A...
Erstmal danke für die zahlreichen Antworten. Also zweimal senden scheint wirklich nicht die erste Wahl sein. Gefallen tut mir persönlich das mit den 2ten mal invertiert vor crc da eben weniger Rechenaufwand... zumindest wenn keine Hardware-CEC vorhanden ist. Wenn Daten verloren gehen bzw. Check nicht passt wirds einfach verworfen und auf nächstes Paket gewartet. Welches Byte bzw. Bit da falsch war oder nicht ist mir dann egal.
Man sollte vielleicht auch eine Sekunde investieren, um sich die Ursachen von Fehlern zu vergewaertigen. Ein CRC ist gut, um sporadische Einzelbit Fehler zu detektieren. Wenn man ein schlechtes Layout, einen schlechten Schaltregler und koppelnde Leitungen hat, die jedes 5.Bit niedermachen, sind die genannten Massnahmen nicht passend.
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.