Hi, wie funktioniert eigentlich die Verification von einem CRC32? Wenn ich auf dieser Seite (http://www.lammertbies.nl/comm/info/crc-calculation.html) z.B. den Hexwert 0x6E65 eingebe erhalte ich als Prüfsumme 0x877FC101 Wenn ich jetzt 0x6E65877FC101 eingebe erhalte ich allerdings nicht 0 als Prüfsumme, so dass ich weiß, dass die CRC Checksumme auch passt. Gruß Lars
Lars schrieb: > Hi, > > wie funktioniert eigentlich die Verification von einem CRC32? Du berechnest die die CRC von den Daten die du hast und vergleichst diese mit der Checksumme der Ursprungsdaten. Wenn diese ungleich sind hast du Fehler in deinen Daten.
Timmo H. schrieb: >> wie funktioniert eigentlich die Verification von einem CRC32? > Du berechnest die die CRC von den Daten die du hast und vergleichst > diese mit der Checksumme der Ursprungsdaten. Wenn diese ungleich sind > hast du Fehler in deinen Daten. d. h. der Empfänger des Datenpakets muss die letzten 4Bytes des Datenstreams für die Berechnung des CRCs weglassen und muss dann auf die gleiche CRC kommen wie die letzten 4 Datenbytes, die er erhalten hat? Ich dachte das Verfahren wäre beim CRC ähnlich wie bei der Checksummenüberprüfung von IP?
hier überprüft der Empfänger allerdings auch über die kompletten Datenstream und erhält im Erfolgsfall 0x00 http://www.mikrocontroller.net/articles/CRC Passiert allerdings auch nicht, wenn man bei dem Online-Calculator 0x6e6500000000 eingibt -> der CRC ist dann 0xD2EE37B4 und die empfangenen Daten 0x6e65D2EE37B4 ergeben dann einen CRC von 0xA1C46CAD
Lars schrieb: > Passiert allerdings auch nicht, wenn man bei dem Online-Calculator > 0x6e6500000000 eingibt -> der CRC ist dann 0xD2EE37B4 und > die empfangenen Daten 0x6e65D2EE37B4 ergeben dann einen CRC von > 0xA1C46CAD Ganz einfach. Der Kalkulator ist kaputt. Nimm den hier, der geht. Und ich hab dir sogar schon das CRC-32 Polynom eingetragen: http://ghsi.de/CRC/index.php?Polynom=100000100110000010001110110110111 XL
Axel Schwenke schrieb: > Ganz einfach. Der Kalkulator ist kaputt. das muss noch mit etwas anderem zusammenhängen. Die Berechnung der CRC32 Prüfsumme stimmt nämlich.
Lars schrieb: > wie funktioniert eigentlich die Verification von einem CRC32? Dafür gibt es zwei Möglichkeiten (das gilt generell für alle CRCs, nicht nur für eine konkrete CRC32) 1) Bildung der Prüfsumme über die empfangenen Daten und Vergleich mit der übermittelten Prüfsumme. 2) Bildung der Prüfsumme über empfangene Daten und empfangene Prüfsumme und Vergleich mit einem sog. "Magic"-Wert. Variante 2 hat meist den Vorteil, geringfügig schneller zu sein bzw. geringere Latenzen zu erzeugen, hat dafür aber den Nachteil, daß der "Magic" natürlich vom ganz konkreten CRC-Verfahren abhängt (Startwert und Polynom), so daß austauschbare Checksum-Verfahren schlecht zu implementieren sind. Wegen dieses Nachteils wird diese Variante i.d.R. nur dann benutzt, wenn das zu wählende Verfahren unveränderlich feststeht und/oder das Nachrichtenende und damit die Position der Checksumme im Datenstrom erst nach Empfang der Checksumme ermittelbar ist. Ein typisches Beispiel dafür wäre USB, da steht das Checksum-Verfahren fest und die Länge der Nachricht kann erst ermittelt werden, nachdem die Checksum bereits empfangen wurde. Deswegen wird jede ernstzunehmende Implementierung hier Variante 2 verwenden.
hab hier einen CRC32 Generator gefunden, der die gleichen Daten erzeugt http://zorc.breitbandkatze.de/crc.html Trotzdem bekomme ich nicht 0 als Wert zurück, wenn ich den CRC überprüfe. Hab die STandardeinstellungen verwendet, wenn man auf CRC32 klickt und %6E%65 eingegeben als DAten
ich glaube das hängt mit CRC32 reflected oder nicht zusammen. Warum gibt es überhaupt eine "reflected CRC Version"? Im IEEE Standard wird diese ebenfalls angewandt.
yo, reflected. Du invertierst Dein Ergebnis 877FC101 zu 78803efe und steckst es bytegedreht rein, also 6e65fe3e8078 bei http://www.lammertbies.nl ergibt 0xffffffff Kann einen an den Rand des Wahnsinns bringen, siehe hier meinen post samt Programm: Beitrag "Yet another CRC32 Code" >>Ganz einfach. Der Kalkulator ist kaputt. Wenn man von einem Thema keinen Schimmer hat, einfach mal auf eine Äußerung verzichten. Cheers Detlef
Detlef _a schrieb: > Kann einen an den Rand des Wahnsinns bringen, siehe hier meinen post > samt Programm: ja hat mich gerade auch einige stunden gekostet. Warum wird überhaupt invertiert und bytegedreht? Hat das eine tiefere bewandtnis?
Ich glaube, das hat was zu tun wie Du die Daten siehst, ob bei deinen Bytes also 6e oder 65 das 'Most significant Byte' ist. Bei meiner Berechnungsroutine muß man das Polynom ja auch 'umdrehen'. Invertieren hat damit zu tun, ob Du im LFSR mit 0x00 oder 0xffffffff startest. Aber Genaueres weiß ich leider auch nicht, würde ich wohl gerne. Funktionieren tut's jedenfalls. Cheers Detlef
:
Bearbeitet durch User
Lars schrieb: > arum wird überhaupt > invertiert und bytegedreht? Hat das eine tiefere bewandtnis? Ja. Die benutzte Arithmetik der CRCs, Shift Register, kann in Hardware auf zwei Arten implementiert werden: http://en.wikipedia.org/wiki/Linear_feedback_shift_register Je nach benutzter Methode, Galois oder Fibonacci, ändert sich dabei die Schieberichtung der LFSRs und somit die Reihenfolge der Taps die man nutzen muß. Jedes Polynom kann dabei in natürlicher oder invertierter Form überführt werden, je nachdem ob man das LFSR als Galois oder Fibonacci ausführt. Je nach Hardware ist dann die jeweilige Implementation, also als Galois oder Fibonacci, einfacher oder schwieriger zu bewerkstelligen. Auf FPGAs benutzt man gerne die Fibonacci Repräsentation, auf PCs häufiger die Galois. Hat man sich für einen Typ der Impelmentierung entschieden so hat man sich auch für den richtigen Startwert des internen CRC Registers entschieden. Jedes LFSRs muß mit 1'en als Startwert arbeiten da der Wert Null als Startwert ungültig ist. Ein LFSR läuft, mit nicht reduzierbaren Polynom, alle Zustände durch, ausser dem Zustand Null.
>>>>>> Jedes LFSRs muß mit 1'en als Startwert arbeiten da der Wert Null als Startwert ungültig ist. Ein LFSR läuft, mit nicht reduzierbaren Polynom, alle Zustände durch, ausser dem Zustand Null. <<<<<< Das hängt von der Art des LFSR ab. Xilinx http://www.xilinx.com/support/documentation/application_notes/xapp210.pdf haben mal mit XNORs zurückgekoppelt, da ist alles 1 der verbotene Zustand. Galois/Fibonacci unterscheiden sich durch die Anordnung der XORs, nicht durch die Schieberichtung. Cheers Detlef
Detlef _a schrieb: > Das hängt von der Art des LFSR ab. Xilinx > http://www.xilinx.com/support/documentation/application_notes/xapp210.pdf > haben mal mit XNORs zurückgekoppelt, da ist alles 1 der verbotene > Zustand. Korrekt. Ändert aber nichts an der Sache das man mit XNOR eine Invertierung der mathm. Formel durchgeführt hat. Die "Basis-Formel" für LFSRs arbeitet mit XOR als mathem. definierte Addition für Galois Felder in GF(2). Es hängt letztendlich auch nicht vom LFSR Typus ab sondern von der gewählten Implementierung, invertiert oder nicht invertierter Betrieb. Das kann man sich so vorstellen das man eine additive Formel durch Vorzeichenwechsel in eine Formel überführen kann die mit Subtraktionen arbeitet statt Additionen. Mathm. bleibt es also bei meiner Aussage, der Zustand 0 im Register ist illegal.
Hagen Re schrieb: > Korrekt. Ändert aber nichts an der Sache das man mit XNOR eine > Invertierung der mathm. Formel durchgeführt hat. durch die Invertierung werden weitere mögliche Fehler bei der Übertragung entdeckt - Nullen die sich am Ende der Daten (einschließlich CRC) eingeschlichen haben bei der Übertragung.
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.