Hallo an alle, ich bin neu hier im Forum und hoffe für meine Fragen auch das richtige Unterforum gefunden zu haben. Hinsichtlich Fehlererkennenden Codes und Checksummen habe ich ein paar Verständnisfragen. Es geht weniger um die technische Umsetzung. Ausgangssituation: 32bit, 64bit oder 128bit Eingangswortbreite. Nun gibt es ja die unterschiedlichsten Fehlererkennenden Codes und Checksummen um Fehler zu erkennen und ggf. zu korrigieren. Jedoch habe ich ein Problem mit dem Verständnis wie groß (Byte) die Checksummen im Verhältnis zum Eingangswort sind. Nehmen wir den Parity Check. Dann führe ich diese Prozedur über die einzelnen Bits des EIngangswortes durch und hänge dann ein einziges Bit als Parity Bit mit an das Eingangswort mit an bzw. 0x01 oder sehe ich das verkehrt? Als zweites Beispiel zieh ich mal eine einfache XOR Checksumme heran. Wird jetzt hier auch wie beim Parity Check Bit für Bit des Eingangswortes XOR Verknüpft bis zum letzten Bit? Das würde ja heißen es würde auch nur ein Bit angehängt werden, was ja ziemlich sinnlos ist oder wird die XOR Checksumme Byte für Byte durchgeführt und so ein Byte als Checksumme angehängt? Ein letztes Szenario habe ich noch. Was genau bedeutet z.b. bei Fletcher16 und Fletcher32 oder bei CRC16 und CRC32 das 16 und 32? Ist das die Länge der entstehenden Checksumme? Wenn ja, ist diese mit der Breite des Eingangsworte identisch, also das ich bei CRC16 und einem Eingangswort von 32 Bit, die 32Bit in 2*16Bit splitten muss und bei 64Bit dann 4*16Bit? Wie sinnvoll wäre dann bei 32Bit Eingangswort CRC32 anzuwenden? Weniger sinnig, oder? Oder ist die Länge der Checksumme in Byte (z.b. 4 Byte) von CRC16 und CRC32 gleich und die 16 und 32 geben die Eingangswortlänge an, was soviel heißt, dass es auch CRC64 und CRC128 in meinem Fall gibt. Ich hoffe ihr könnt mir helfen. Gruß Franky
Grundsätzlich bleibt dir selbst überlassen in welchem Verhältnis die Nutzdaten zur Checksumme stehen. Wenn es ganz Sicher sein soll, benutzt man ein Echo, um Daten zu verifizieren. Der Parity-Check beispielsweise wird mit jedem Nutzbyte übertragen, aber was nutzt es, wenn gleichzeitig 2 Bits bei der Übertragung verdreht wurden? Genau so schlimm wäre eine 1 Byte Checksumme bei Daten größer als 256 Byte. Es kommt drauf an wie "wichtig" die Daten sind. Je "wichtiger" desto exakter (länger) die Checksumme.
Bei CRC16 und CRC32 ist es die Länge der Prüfsumme in Bit. CRC-Verfahren lassen sich auch auf Bit-Streams beliebiger Länge anwenden. Chris D. schrieb: > Wenn es ganz Sicher sein soll, benutzt man ein Echo, um Daten zu > verifizieren. Echo macht die Übertragung nicht sicher. Die Übertragungsstrecke könnte z.B. immer das Bit 3 eines Bytes invertieren, in beide Richtungen. Parity macht in Verbindung mit byteweisem XOR Sinn. Da wird schon einiges erwischt. Habe ich aber selten gesehen, dass es in Kombination gemacht wird. Guter Einstiegspunkt in der Wikipedia mit weiterführenden Links: http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren
Ich danke euch schon mal für eure Antworten und aufschlussreicheren Informationen. Grundsätzlich möchte ich hier aber keine Grundsatzdiskussion über die Effizienz von Fehlererkennenden Codes anstoßen. Ist der Parity-Check eine Ausnahme, bei dem nach jedem Byte das Prüfbit übertragen wird? Ich war der Meinung, dass ein Prüfbit/byte/checksum immer an das Eingangswort angehängt wird. Soweit ich es verstanden habe, kann ich für mich selber bestimmen mit welchem Verfahren und mit welchen Parametern ich die Daten versende. Gibt es dennoch für jedes Verfahren so etwas wie eine Norm z.b. für 32bit Eingangswörter CRC16 und für 64Bit dann CRC32? Danke nochmal für eure Mühen
Frank L. schrieb: > Soweit ich es verstanden habe, kann ich für mich selber bestimmen mit > welchem Verfahren und mit welchen Parametern ich die Daten versende. Du hast die freie Wahl. Bei der Auswahl ist es wichtig zu wissen, welche Auswirkungen fehlerhafte Daten haben können, wie wahrscheinlich Fehler sind (Fehlerbits pro kBit oder pro Datenpaket usw.), wie sich die Fehler verteilen (Einzelbitfehler, Burst), wie bei Fehlern zu reagieren ist (Daten verwerfen oder ggf. FEC http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur). Bei der seriellen Datenübertragung mit RS-232 wird oft ganz auf Fehlererkennung verzichtet. Meistens geht das auch gut oder die Daten richten keinen wesentlichen Schaden an, wenn mal ein Bit umkippt.
Frank L. schrieb: > Gibt es dennoch für jedes Verfahren so etwas wie eine Norm z.b. für > 32bit Eingangswörter CRC16 und für 64Bit dann CRC32? Die verwendeten Polynome sind schon festgelegt. Und es gibt noch sehr viel mehr Varianten. Wenn Kommunikationsgeräte miteinander arbeiten sollen, dann ist üblicherweise festgelegt, welche Blockgrößen und welcher Fehlerschutz angewendet werden muss. Sonst könnten die Geräte unterschiedlicher Hersteller ja nicht miteinander kommunizieren (zumindest nicht mit dem Fehlerschutz). Welcher Code bzw. welches Verfahren gewählt wird, ist immer ein Kompromiss. Man muss sich klar machen, was hat der Übertragungskanal im worst case für eine Fehlerrate, wie viele Fehler kann ich akzeptieren, weil andere Verfahren greifen (in höheren Schichten) oder muss ich bereits auf der Übertragungsschicht so sicher wie möglich sein. Dann muss ich mich fragen, wie viel Overhead bin ich bereit zu spendieren. Ich muss mich fragen, ob es reicht, Fehler zu erkennen oder will ich Fehler auch korrigieren, usw. Dazu gibt es ein Menge Literatur. Ich hab im Hinterkopf: W.W.Peterson "Error Correcting Codes". In deutsch gibt es ein Buch von Joachim Swoboda, das sich an vielen Stellen auf Peterson stützt.
Frank L. schrieb: > Nehmen wir den Parity Check. Dann führe ich diese Prozedur über die > einzelnen Bits des EIngangswortes durch und hänge dann ein einziges Bit > als Parity Bit mit an das Eingangswort mit an bzw. 0x01 oder sehe ich > das verkehrt? Kann man so machen. Man kann aber auch ganz einfach sagen: Anstelle von 8 Bit übertrage ich 9 und das 9.te Bit ist das Parity Bit. RS232 macht das. > Als zweites Beispiel zieh ich mal eine einfache XOR Checksumme heran. > Wird jetzt hier auch wie beim Parity Check Bit für Bit des > Eingangswortes XOR Verknüpft bis zum letzten Bit? Das würde ja heißen es > würde auch nur ein Bit angehängt werden, was ja ziemlich sinnlos ist > oder wird die XOR Checksumme Byte für Byte durchgeführt und so ein Byte > als Checksumme angehängt? Nein. Es werden einfach alle Bytes ausummiert, äh aufgexodert und das Ergebnis davon an die Daten angehängt und übertragen. > Ein letztes Szenario habe ich noch. Was genau bedeutet z.b. bei > Fletcher16 und Fletcher32 oder bei CRC16 und CRC32 das 16 und 32? Ist > das die Länge der entstehenden Checksumme? Ja. > Wenn ja, ist diese mit der > Breite des Eingangsworte identisch, Nein. Auf dieser Ebene hat man normalerweise nur noch Bytes. Also einen Bytestrom, den man durch die CRC Berechnung durchstopft. Sind alle Bytes durch, dann kommt aus der CRC Berechnung eine Zahl raus (in Form von mehreren Bytes), die dann nach den Daten auch noch übertragen wird.
Ich danke euch für eure hilfreichen Beiträge. Dennoch habe ich noch eine Frage. Hierbei geht es um die Funktion und den Unterschied zweier Verfahren. Sind weniger Fehlererkennende Codes, eher die einfache Vorstufe um Fehler auszuschließen. Wiederholungscode und Redundanzcode (Duplication,Triplication). Bei einem Wiederholungscode wird das Eingangswort ja einfach nur über eine festgelegte Anzahl an Wiederholungen hintereinander neu gesendet. Ist das nicht das gleiche wie ein Redundanzcode? Wenn nicht, wie kann ich mir den funktionalen Unterschied vorstellen softwareseitig. Gruß Franky
Frank L. schrieb: > Fehler auszuschließen. Wiederholungscode und Redundanzcode Der Wiederholungscode enthält (d.h. IST) die gesamte Nachricht. Der Redundanzcode sichert die Nachricht gegen Fehler, enthält aber selbst keine Information. Nachricht Parität Byte 1: 00100010 0 Byte 2: 10000010 0 Byte 3: 00101100 1 Byte 4: 01001100 1 XOR: 11000000 0 <--- XOR-Prüfsumme Hier besteht die Nachricht aus den Bytes 1 bis 4, die Redundanz aus der XOR-Prüfsumme und den Paritätsbits. Die Paritätsbits werden üblicherweise von der Hardware des UART/USART beim Senden erzeugt bzw. beim Empfang geprüft. Die XOR-Prüfsumme wird per Software erzeugt und an die Nachricht angehängt. Mit diesem Verfahren können alle 1-, 2- und 3-Bit-Fehler in einer Nachricht erkannt werden, d.h. es kann gesagt werden, dass die Nachricht entweder fehlerfrei empfangen wurde oder mindestens 4 Bit (von der Nachricht plus der XOR-Prüfsumme plus den Paritätsbits) bei der Übertragung verfälscht wurden.
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.