Forum: FPGA, VHDL & Co. Generelle Frage zu CRCs


von Peter (Gast)


Lesenswert?

Moin moin!

Ich habe mal eine generelle Frage zu CRCs.
Bei CRCs gibt man an wie wahrscheinlich es ist bestimmte Fehler zu 
erkennen, so wird bei CRC16 z.B. unter anderem gesagt das alle 2 bit 
Fehler für Botschaften < 2^16 Bytes erkannt werden, burst fehler bis zu 
16 bits, etc...

Geht man bei dieser Aussage davon aus das der CRC Wert korrekt und 
Fehlerfrei übertragen wird, oder wurde schon berücksichtigt, das der CRC 
nicht korrekt ist.
Die Frage mag blöd klingen, aber ich habe es noch nie irgendwo explizit 
erwähnt gesehen.

Viele Grüße,

Peter

von user (Gast)


Lesenswert?

es wird auch ein fehler in der crc berücksichtigt

von Peter (Gast)


Lesenswert?

Bringt es etwas, Daten mehrfach zu übertragen (auch den CRC) oder ist es 
von der Datenmenge her günstiger, den CRC zu vergrößern, um eine 
definierte Steigerung der Sicherheit zu erlangen?

von Peter (Gast)


Lesenswert?

Hehe, danke. Lange Frage, kurze Antwort, so mag ich es!

von Duke Scarring (Gast)


Lesenswert?

Peter schrieb:
> ist es
> von der Datenmenge her günstiger, den CRC zu vergrößern, um eine
> definierte Steigerung der Sicherheit zu erlangen?

Die Frage ist, was Du willst, wieviel Zeit Du dafür hast, wie sicher die 
Daten wirklich sein müssen, ob es einen Rückkanla gibt, etc. pp.

CRC war eine der ersten Methoden der Fehlererkennung (nach Parity). 
Inzwischen kennt man wesentlich bessere Techniken:

http://de.wikipedia.org/wiki/Hamming-Code
http://de.wikipedia.org/wiki/ARQ-Protokoll
http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur

Verrate uns doch mal, was Du machen willst, dann kann man viel konkreter 
helfen.

Duke

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Peter schrieb:
> Bringt es etwas, Daten mehrfach zu übertragen (auch den CRC)
Was wirst du machen, wenn durch einen dummen Zufall die Daten korrupt 
sind und die passende CRC dazu auch, und zwar blöderweise genau so, dass 
die CRC wieder stimmt?
Dann hilft es auch nichts, wenn du das Paket zweimal überträgst, denn 
dann empfängst du einfach zwei komplett unterschiedliche Pakete, die 
aber beide in sich stimmen (eines mit korrupten Daten und einer 
passenden korrupten Prüfsumme, und eines mit den richtigen Daten und der 
richtigen Prüfsumme). Welchem willst du dann glauben und welches willst 
du dann verwerfen?

> oder ist es von der Datenmenge her günstiger, den CRC zu vergrößern, um
> eine definierte Steigerung der Sicherheit zu erlangen?
Das eher. Aber es wird eben keine 100% Sicherheit geben...

von sim (Gast)


Lesenswert?

Peter schrieb:
> Bringt es etwas, Daten mehrfach zu übertragen (auch den CRC) oder ist es
> von der Datenmenge her günstiger, den CRC zu vergrößern, um eine
> definierte Steigerung der Sicherheit zu erlangen?


Bei einer mehrfachübertragung hast du einen Diversitätsgewinn was 
bedeutet, dass du Fehler eventuell nicht nur erkennen sondern sogar 
beheben kannst indem du das korrupte Telegramm ignorierst. Die erkaufst 
du dir allerdings durch die größere Datenmenge.
Wenn es keinen Rückkanal gibt, also der Empfänger keine Möglichkeit hat 
einen Fehler zu melden, dann ist eine solche Überlegung sinnvoll. Auser 
man kann natürlich ein defektes Packet verschmerzen (wie z.B. beim 
Fernsehr). Dann kann man auch einfach verwerfen und damit leben.
Gibt es einen Rückkanal und damit die Möglichkeit ein Packet erneut 
anzufordern, dann ist dies meist die effizientere Variante.

Gruß
sim

von Duke Scarring (Gast)


Lesenswert?

sim schrieb:
> Gibt es einen Rückkanal und damit die Möglichkeit ein Packet erneut
> anzufordern, dann ist dies meist die effizientere Variante.

Aber eben nur, wenn man die Zeit dazu hat und einen Zwischenspeicher für 
die restlichen Daten.

Daher sollte uns der OP mal verraten, was er vorhat. Sonst ist es nur 
ein stochern im Schneesturm...

Duke

Bitte 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
Noch kein Account? Hier anmelden.