Doppelt senden oder CRC

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? :-)

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!

> 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...

Gustel ist wohl nach Diktat verreist oder hat das Interesse verloren.

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.