Forum: Digitale Signalverarbeitung / DSP / Machine Learning Einfache FEC mit CRC32?


von Rate mal! (Gast)


Lesenswert?

Hi,

wenn bei einem 16 Byte Paket + 4 Byte CRC32 die Prüfsumme nicht stimmt, 
kann man die 160 (20*8) Bit einzeln umkippen und schauen ob dann die 
Prüfsumme stimmt.

Ist dann das immer noch besser als eine CRC16?

von Sascha (Gast)


Lesenswert?

Ja klar ist eine CRC32 besser als eine CRC16. Das ersetzt aber keine 
Fehlerkorrektur. Weil es auch bei einer CRC32 immer wieder gleiche 
Ergebnisse gibt !!!

Siehe Dazu Hamming Distanz von CRCs.

Gruß Sascha

von Hp M. (nachtmix)


Lesenswert?

Rate mal! schrieb:
> und schauen ob dann die
> Prüfsumme stimmt.

Kannst du machen, wenn du weisst, dass du es nur mit einem 1-Bit-Fehler 
zu tun hast, z.B. bei einem Datenbus.
Bei einer seriellen Übertragung (Disks, Funk, Telefonleitungen) treten 
aber gerne Burst-Errors auf, und dagegen muß man schwereres Geschütz 
auffahren.

von Manfred (Gast)


Lesenswert?

Hp M. schrieb:
> Bei einer seriellen Übertragung (Disks, Funk, Telefonleitungen)

Siehe POCSAG, ein Übertragungsverfahren für Funkrufsysteme. Der 
Datensatz hat 32 bit, davon 20 Bit reine Nutzdaten. Für CRC und 
Rückrechnen eines fehlerhaften Bits haben die Herren 10 Bit CRC 
spendiert - bestimmt, weil sie gerne möglichst viel Overhead über den 
schmalen Funkkanal schieben wollten.

Rate mal! schrieb:
> kann man die 160 (20*8) Bit einzeln umkippen
> und schauen ob dann die Prüfsumme stimmt.

Klingt eher nach Brute Force denn Mathematik - wie lange soll der 
Korrekturrechenproozess dauern?

Rückrechnen aus CRC16 oder CRC32 sehe ich garnicht.

von A. F. (chefdesigner)


Lesenswert?

Wir verwenden für einen internen Bus aus Gründen der Datensicherheit 
gegen Fehler und Abhören einen Redundanz-Code mit 
64Bit+32Bit-Verschlüsselung und das Ganze mit einem CRC32 über jeweils 
die letzten 8 Datenworte. Viel weniger geht nicht, da industrielle 
Umgebung und Bus aussen geführt, d.h. anzapbar und störbar.

von Pandur S. (jetztnicht)


Lesenswert?

Aber der witz der CRC ist verstanden ? Eher nicht. Ein 16bit CRC 
schuetzt 2^16bit = 8kByte gegen ein-Bit Fehler. Dh nicht dass der Fehler 
repariert wird, sondern dass er detektiert wird. Ein CRC-32 schuetzt 
also 2^32 bit = 256MByte gegen 1 bit Fehler. Den auf ein paar wenige 
Byte anzuwenden ist Bullshit. Nimm da was anderes, zB einen Hamming, der 
kann sogar noch reparieren.

von Mitdenker (Gast)


Lesenswert?

Wieviele MegaBytes da theoretisch geschützt werden, ist vielleicht nicht 
das Entscheidende, weil man sicher keine Tausende Pakete senden möchte, 
bis man weiß, dass was falsch war. Eigentlich könnte man nach jedem 
Paket eine Schutzinformation senden, macht aber keiner, weil es die 
Datenrate halbieren würde.

von Christian K. (Gast)


Lesenswert?

Schau mal wie groß der Hamming Abstand ist. Das CRC sollte dir die 
Bitposition des fehlerhaften Bits für 1 bit Fehler direkt angeben. Es 
besteht keine Notwendigkeit das mit "brute force" zu testen.

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.