Hallo zusammen! Ich verschicke über Funk in Intervallen 4 Bytes an Messdaten. Da Funk alles andere als zuverlässig ist, muss ich sicherstellen, dass ich fehlerhaft übertragene Daten verwerfe. Reflexartig habe ich an CRC32 gedacht, aber nachdem ich ewig nach einer AVR Implementation via LUT gesucht habe (CRC32 auf Bitbasis ist unverschämt lahm) dachte ich mir, warum nicht einfach die Daten doppelt senden? CRC32 hat 4 Bytes, die Daten haben 4 Bytes.... ich spare mir jede Menge Arbeit... Die Frage ist jetzt, ob Daten+CRC32 mehr Fehler abfangen könnte als Daten+Daten. Bin kein Mathematiker. PS: Wenn jemand weiss, wo man eine CRC32 LUT Version für AVR findet, wäre ich auch sehr dankbar. Angeblich kommt man mit einer 1 kB LUT aus.
Für so viele Daten muss es ja nicht gleich CRC sein. Warum addierst du nicht alle vier Bytes und sendest das LSB Byte der Summe als fünftes Byte mit? Wenn es nur um einen einfachen Integritäts-Check geht ...
Bei 4 Bytes empfehle ich eine CRC-8. Fehlererkennung: https://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Erkannte_Fehler Liste von CRC-VArianten: https://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Polynome_und_Typen Weitere Infos in der letzten Spalte rechts (Anmerkungen).
Jan schrieb: > dachte ich mir, warum nicht einfach die Daten doppelt > senden? Wie erkkenst du dann welcher von den beiden Datensaetze luegt?
Daten doppelt schicken kann auch 2x den selben Fehler zur Folge haben.
Schau dir mal util/crc16.h an! (Bestandteil von avrlibc) Man muß ja nicht alles neu erfinden...
Beitrag #6725663 wurde vom Autor gelöscht.
Beitrag #6725664 wurde vom Autor gelöscht.
Ich generiere mir in der Regel CRC code mit hilfe von https://pycrc.org/. Damit kannst Du C code für Deinen gewünschten Algorithmus erzeugen. Du kannst auch die bevorzugte Optimierung angeben (Tabelle oder kleine Code grösse).
Oder den Code 6x senden und die Variante nehmen, die beim Empfänger mindestens 2x gleich ankam.
Stefan ⛄ F. schrieb: > Oder den Code 6x senden und die Variante nehmen, die beim Empfänger > mindestens 2x gleich ankam. Thema verfehlt... Jan schrieb: > sicherstellen, dass ich fehlerhaft übertragene Daten verwerfe. ...denn Fehlerkorrektur ist nicht verlangt. Es gibt viele Anwendungen, in denen es ausreicht, falsche Werte einfach zu verwerfen.
:
Bearbeitet durch User
Ich kenne das auch "von früher", dass man die Daten 4x oder öfter geschickt hat. Man muß sich nur genau überlegen, was passieren soll/muß, wenn da längere Zeit nichts brauchbaren ankommen sollte! Nun gut, dass muß man bei CRC oder anderen Strategien natürlich auch... Gruß Rainer
Wenn vier Byte Nutzlast gesetzt sind, das Telegramm acht Bytes lang werden darf und nur selten Fehler passieren, wäre vielleicht auch ein (63,57)-Hamming-Code eine Alternative? Dann passen noch zusätzliche 25 Bit Nutzlast ins Telegramm, und es könnte ein Fehler korrigiert werden. Hängt davon ab, wie fehleranfällig die Funkstrecke ist: Wenn 50% der Bits verkippt werden oder ganze Telegramme untergehen, müssen andere Mittel ran.
Stefan ⛄ F. schrieb: > Oder den Code 6x senden und die Variante nehmen, die beim Empfänger > mindestens 2x gleich ankam. Was wenn 3 x 2 Bytes jeweils gleich sind? Die Leute, die vor Äonen CRC und Prüfsummen erfunden haben sind nicht so blöd gewesen wie manche hier glauben, bloss weil das schon lange her ist. Georg
Georg schrieb: > Die Leute, die vor Äonen CRC und Prüfsummen erfunden haben sind nicht so > blöd gewesen wie manche hier glauben Ich wundere mich darüber auch ein wenig. Zumal der Aufwand von CRC wirklich überschaubar ist. Es gibt nicht viele Funkübertragungen, auf die man einen AVR ansetzt, die für eine byte- statt bitweise bearbeitete CRC zu schnell sind. Zumal das auch noch fix und fertig in der avrlibc steckt.
:
Bearbeitet durch User
Was für Funk? Bei einigen ist da schon CRC für die Funkstrecke enthalten(z.B Radiocraft 8xx MHz). Benötigst du in deiner Anwendung wo anders CRC (SD-Karte, ...)? Wenn ja, den nehmen.( CRC7, 16) Da ist auch die Lockup-Table nicht ganz so groß.
dummschwaetzer schrieb: > Da ist auch die Lockup-Table nicht ganz so groß. CRC-Verfahren fressen für die Tabelle 0,5kB ROM bei CRC16 und 1kB ROM bei CRC32, wobei damit 8 Bit pro Zyklus verarbeitet werden, statt 1 Bit. Wenn man also nicht mit vorgehaltener Pistole in einen ATtiny4 gezwungen wird...
:
Bearbeitet durch User
Oder halt Controoler mit eingebauter CRC-Hardware nehmen.
Jan schrieb: > Ich verschicke über Funk in Intervallen 4 Bytes an Messdaten. Da Funk > alles andere als zuverlässig ist, muss ich sicherstellen, dass ich > fehlerhaft übertragene Daten verwerfe. OK, einzusehen. > Reflexartig habe ich an CRC32 gedacht Quatsch. Da kannst du besser gleich den Payload nochmal invertiert dranhängen. Wennschon CRC, dann bei vier Bytes Payload natürlich CRC8. Oder einfach XOR.
Die von den 1-Wire Temperatursensoren genutzte CRC8 ist etwas riskant. Da habe ich gelegentlich schon Fehlwerte gehabt.
(prx) A. K. schrieb: > Die von den 1-Wire Temperatursensoren genutzte CRC8 ist etwas riskant. > Da habe ich gelegentlich schon Fehlwerte gehabt. Wieviel Bits sichert die CRC8 bei den Dingern ab? Welches Polynom wird da verwendet?
c-hater schrieb: > Quatsch. Es gibt Übertragungsszenarien, in denen Fehler oft in Bursts auftreten. Dann ist nicht 1 Bit im Eimer, sondern etliche hintereinander. Bei Funk ein nicht unwahrscheinliches Szenario. In solchen Fällen sind Verfahren schwach, deren Stärke in Einzelbitfehlern liegt und bei denen solche Burst allzu leicht als korrekt durchrutschen können. Also bevor man etwas als Quatsch bezeichnet, sollte man schon mehr Gedanken investieren. Mindestens für die Analyse dessen, mit welchem Problem man es überhaupt zu tun hat. Und mit welchem Risiko - als was geschieht, wenn doch mal ein falscher Wert durchrutscht.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Es gibt Übertragungsszenarien, in denen Fehler oft in Bursts auftreten. > Bei Funk ein nicht unwahrscheinliches Szenario. Das entspricht meiner Erkenntnis als ich vor einigen Jahren AM modulierte Funkübertragungen baute.
c-hater schrieb: > Wieviel Bits sichert die CRC8 bei den Dingern ab? Welches Polynom wird > da verwendet? Siehe Maxim/Dallas. Wer erklärtermassen kein Problem damit hat, 8 statt 4 Bytes zu übertragen, der hat genug Luft für mindestens eine CRC16, oder auch eine CRC32 (ja nach Risiko, siehe eben). Programmaufwand und Tempo heutzutage Problemlos. Weshalb also nicht?
(prx) A. K. schrieb: > Es gibt Übertragungsszenarien, in denen Fehler oft in Bursts auftreten. Ohne Zweifel ist das so. > In solchen Fällen sind Verfahren > schwach, deren Stärke in Einzelbitfehlern liegt und bei denen solche > Burst allzu leicht als korrekt durchrutschen können. Die Stärke jeder CRC liegt bei der Detektion von Einzelbitfehlern. Burstfehler werden umso schlechter erkannt, je länger der Burst ist. Das gilt unabhängig von der Breite der CRC. Die ist "nur" entscheidend für das Verhältnis zwischen Payload und Redundanz. Also Abwägungssache. Nur war hier der Sonderfall gewünscht, bei dem die Redundanz 100% erreicht. Und dann wird CRC sinnlos, das war, was ich mit Quatsch meinte und mein Gegenvorschlag war, einfach den invertierten Payload an die Nachricht anzuhängen. So, du Schlaumeier, und nun erkläre mal, wo im Vergleich dammit dann noch der Vorteil der CRC32 herkommt...
Die Datenbytes aufsummieren und die Prüfsumme so gestalten, dass die Gesammtsumme 0 ist. Diese Verfahren wird im Intel Hexprotokoll verwendet. Siehe Berechnung der Prüfsumme: https://de.m.wikipedia.org/wiki/Intel_HEX Die Daten können im Gegensatz im Hexprotokoll binär bleiben.
:
Bearbeitet durch User
Das Kriterium sollte die Hamming-Distanz sein. (Bei Funk sowieso). Daten doppelt schicken hat die schlechteste Hamming Distanz. Gute Literatur dazu hat Philip Koopman. Im Artikel https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf und auf seiner Webseite findet man empfohlene CRC Polynome mit guter HD.
Gerald K. schrieb: > Diese Verfahren wird im Intel Hexprotokoll > verwendet. ... weil vor einem halben Jahrhundert jedes Byte im ROM und jeder einzelne Taktzyklus zählte. Die Qualität der Fehlererkennung ist jedoch sehr bescheiden.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Die Qualität der Fehlererkennung ist jedoch sehr bescheiden Ist schon richtig. Die Sicherheit wurde erhöht weil nur Hexzeichen zulässig waren und mit 7Bit + Paritätsbit gearbeitet wurde. Einsatz waren z.B. Lochstreifen. Besser ist es einen CRC einzusetzen oder doppelt zu senden, wo ich die reduntanten Zeichen im 2er Kompliment übertragen würde.
Kann es sein, dass CRC gerade bei Burst-Fehlern unbrauchbar ist? Der Hamming-Abstand ist selbst bei CRC32 geringer als 32 Bit. Wenn ich also 4 Bytes durch einen Burst zerschiesse, kann der CRC stimmen. Gibt es keine beweisbar sichere Methode, ein paar Bytes zu übertragen und Übertragungsfehler 100%ig sicher zu erkennen? Sowas wie das one time pad ist ja auch beweisbar sicher.
Jan schrieb: > Kann es sein, dass CRC gerade bei Burst-Fehlern unbrauchbar ist? Mein Eindruck ist, dass sich die Entwicklung stärker auf fehlerkorrigierende Codes als auf rein fehlererkennende Codes konzentrierte.
Jan schrieb: > Gibt es keine beweisbar sichere Methode, ein paar Bytes zu übertragen > und Übertragungsfehler 100%ig sicher zu erkennen? Nur wenn der Empfänger die Bytes schon vorher kennt. ;-) Das hat mehr mit Wahrscheinlichkeit als absoluter Sicherheit zu tun. Als wie sicher für dich sicher genug ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Mein Eindruck ist, dass sich die Entwicklung stärker auf > fehlerkorrigierende Codes als auf rein fehlererkennende Codes > konzentrierte. Ist ja auch verstaendlich wenn man keine Retry-Schleuder bauen will.
Mit CRC-Codes kann man nicht nur Fehler erkennen, sondern auchkorrigieren: https://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Erkannte_Fehler Siehe auch CRC-24.
Jan schrieb: > Gibt es keine beweisbar sichere Methode, ein paar Bytes zu übertragen > und Übertragungsfehler 100%ig sicher zu erkennen? Nein. 100% geht einfach niemals nicht. Theoretisch nicht und praktisch natürlich auch nicht. > Sowas wie das one time > pad ist ja auch beweisbar sicher. Nein, wie kommst du denn auf diesen Unsinn? Auch bei OTP sind natürlich Kollisionen möglich. Merke: NICHTS ist beweisbar sicher. Allenfalls ist eine gewissen Wahrscheinlichkeit für den Fall des Auftretens von Kollision beweisbar. Nunja, es gibt immer wieder mal Krypto-Routinen, bei denen mal was "bewiesen" wurde. Bis dann irgendwer bewiesen hat, dass der ursprüngliche "Beweis" schlicht falsch war... ... Im Vergleich zu Krypto-Kram wird bei dem Problem, um das es hier konkret geht, aber mit wesentlich weniger Bits hantiert. Das ist in Bereichen, die man tatsächlich recht problemlos vollständig durchkalkulieren kann (auf einem heutigen PC). Wer also mathematischen Beweisen nicht traut oder sie auch einfach nur nicht versteht, kann hier die Nützlichkeit diverser (relativ) rechenzeitaufwendiger Algorithmen im Vergleich zu trivial scheinenden Lösungen einfach mal selber durchkalkulieren und sich die Ergebnisse anschauen... prx, hörst du mich?
Siggy schrieb: > Mit CRC-Codes kann man nicht nur Fehler erkennen, sondern > auchkorrigieren: Nein, kann man nicht. CRC ist reine Fehlererkennung. Fehlerkorrektur ist FEC. Natürlich kommen dabei auch Algorithmen zum Einsatz, die mit CRC eng verwandt sind, aber es ist nicht dasselbe.
Wenn es darum geht, einfach und gegen burst sicher zu sein, wäre auch eine 4 zu 6 Bit Codierung plus crc8 gut. Also 10x6= 60 Bit, fast 8 Byte. Die 16 Codes hängen dann natürlich davon ab, welche Art von Fehler/bursts man erwartet.
c-hater schrieb: > Siggy schrieb: > >> Mit CRC-Codes kann man nicht nur Fehler erkennen, sondern >> auchkorrigieren: > > Nein, kann man nicht. CRC ist reine Fehlererkennung. Fehlerkorrektur ist > FEC. Natürlich kommen dabei auch Algorithmen zum Einsatz, die mit CRC > eng verwandt sind, aber es ist nicht dasselbe. Du bist ein echter Spinner*1, dumm wie Brotbrösel und hast keinen blassen Schimmer von der Mathematik. Kriech' wieder unter deinen Stein und halt deine Klappe. Allein dein Nick ist schon zum Kotzen.
A. S. schrieb: > Wenn es darum geht, einfach und gegen burst sicher zu sein, wäre auch > eine 4 zu 6 Bit Codierung plus crc8 gut. Also 10x6= 60 Bit, fast 8 Byte. > > Die 16 Codes hängen dann natürlich davon ab, welche Art von > Fehler/bursts man erwartet. Alles huppse. Wenn der ganze Gewinn lächerliche 4 Bit sind. Zumal man bei vielen Funklösungen das nichtmal nutzen könnte, weil die nix unter Bytes können. Also: das geht endgültig in die falsche Richtung.
Ich hat vor sehr langer Zeit ein Programm von einem Intel Entwicklungssystem auf einen CPC464 auf folgende Weise übertragen: - Programm von binär auf Intel Hex umgewandelt - Hexfile mit 2400 Baud 7 Bit + Paritatsbit direkt,ohne Modem, auf MC Kassette aufgezeichnet - Programm für den CPC464 mit MC Kassetteninterface geschrieben, welches die Flankenwechsel in einen Bytestrom umgewandelt hat und diesen in einer Datei speicherte - Hexfile korregiert und wieder in binär umgewandelt Der Hexfile war knapp über 100k groß und enthielt eine Reihe von Übertragungsfehler, die sich dadurch äußerten, dass es keine ASCII-Hexzeichen waren, die Recordprüfsumme und die Paritätsbit falsch waren. Also schrieb ich ein Programm, das die fehlerhaften ASCII-Zeichen so lange durch variierte bis es ein ASCII-Hexzeichen war, das Paritatsbit und die Recordprüfsumme stimmte. Es blieben dann ein paar Fehler übrig wo zwei Zeichen in einem Record falsch waren. Diese korregierte ich manuell mit einem Texteditor. Das Programm war am Ende lauffähig.
Wie kommst Du darauf, daß die CRC eine merkbare CPU-Last bewirkt? Da muß ja Deine Funkstrecke extrem schnell sein (>1MBaud).
Jan schrieb: > [...] warum nicht einfach die Daten doppelt > senden? CRC32 hat 4 Bytes, die Daten haben 4 Bytes.... ich spare mir > jede Menge Arbeit... > > Die Frage ist jetzt, ob Daten+CRC32 mehr Fehler abfangen könnte als > Daten+Daten. Bin kein Mathematiker. > > PS: Wenn jemand weiss, wo man eine CRC32 LUT Version für AVR findet, > wäre ich auch sehr dankbar. Angeblich kommt man mit einer 1 kB LUT aus. Dein vorgeschlagenes Verfahren tituliert unter den Begriff Wiederholungscode. Dieser Codes ist z.B. in https://de.wikipedia.org/wiki/Wiederholungscode recht anschaulich erklärt. Zitat: „Der Wiederholungscode ist der einfachste fehlerkorrigierende Kanalcode. Er wiederholt jedes übertragene Symbol n-mal [...] Ein Wiederholdungcode hat keinen Codegewinn, das heißt, die Fehlerkorrekturfähigkeit des Codes und der Mehraufwand durch n-fache Übertragung löschen sich gerade aus. Der Einsatz von Wiederholdungcodes in praktischen Systemen ohne weitere Maßnahmen ist daher nur begrenzt sinnvoll.“ Ev. sachdienlichere Info findest du z.B. hier: https://de.wikipedia.org/wiki/Fehlerkorrekturverfahren#Fehlererkennende_und_-korrigierende_Codes bietet eine Übersicht über gängige Verfahren. Ohne dein Problem näher untersucht zu haben, könnte ich mir vorstellen, dass der „Reed-Muller-Code“ oder „Reed-Solomon-Code“ interessant sein könnte. Verwendet von der NASA in den Mariner- bzw. Voyager-Missionen, also zu einer Zeit, da technische Systeme noch nicht mit Speicher- und Rechenkapazität gesegnet waren. Entsprechend unaufwendig sind sie Verfahren zu implementieren. Die jeweiligen Links zu den Artikel bieten auch Hilfe bei der Implementierung. just my 2 ct
Peter D. schrieb: > Wie kommst Du darauf, daß die CRC eine merkbare CPU-Last bewirkt? > Da muß ja Deine Funkstrecke extrem schnell sein (>1MBaud). Oder man macht Polling und muss den CRC-Kram deshalb ausserhalb der eigentlichen Übertragungszeit des Payload machen. Scheint mir ein recht typisches Problem für C-only C&P-ler zu sein... Lach'
jo schrieb: > Ohne dein Problem näher untersucht zu haben, könnte ich mir vorstellen, > dass der „Reed-Muller-Code“ oder „Reed-Solomon-Code“ interessant sein > könnte. Das ist FEC. War weder gewünscht noch ist es in dieser Anwendung sonderlich sinnvoll.
c-hater schrieb: > Das ist FEC. War weder gewünscht noch ist es in dieser Anwendung > sonderlich sinnvoll. Sagt wer? FEC ist genau dann sinnvoll, wenn kein Rückkanal existiert.
jo schrieb: > Ein Wiederholdungcode hat keinen Codegewinn, das heißt, die > Fehlerkorrekturfähigkeit des Codes und der Mehraufwand durch n-fache > Übertragung löschen sich gerade aus. Na dann ist die Frage doch beantwortet. Einfach mehrmals übertragen ist damit fehleranfälliger als CRC, wenn wir mal bei der Sichtweise von Wahrscheinlichkeiten bleiben. Ich würde dann wohl einfach auf CRC32 gehen, da ist die Chance wenigstens kleiner als bei CRC16. Was ich aber dazu zwingend brauche ist eine LUT Version. Aber ich habe auch nach 3 Stunden Suchen nichts gefunden. Es gibt jede Menge C-Code dazu, aber ich kenne mich mit C nicht aus und alleine das liest sich für mich schon wie Ciphertext. Viele Beispiele kompilieren nichtmal. Wenn man schon sieht, dass da Klammern fehlen, braucht man sich das gar nicht erst antun. Gibt also viel Müll im Netz. Eine richtig schöne LUT Version für CRC32 für den AVR in Assembler habe ich nicht gefunden. Was mich ein wenig wundert.
Wolfgang schrieb: > FEC ist genau dann sinnvoll, wenn kein Rückkanal existiert. FEC ist nur dann erforderlich, wenn fehlende Werte ein Problem sind. Was bei einer Zustandsinformation beispielsweise kein Problem darstellen muss. Da kann es ausreichen, den letzten als korrekt angenommenen Wert und dessen Alter zu nutzen.
Immer wieder zum Augenrollen sind auch Forenbeiträge nach dem Motto "here is my code! haven't tried it, but should work!!!"
Jan schrieb: > Eine richtig schöne LUT Version für CRC32 für den AVR in Assembler habe > ich nicht gefunden. Was mich ein wenig wundert. Sag doch endlich mal, was Deine Funkstrecke überhaupt kann. Oder willst Du einfach nur der CPU beim Däumchen drehen zusehen.
Gut abgehangen, aber natürlich in C.
:
Bearbeitet durch User
Wie ich schon sagte, ist auch wichtig, was passiert, wenn (innerhalb einer bestimmten Zeit ??) keine gültige Übertragung zustande gekommen ist! Die ersten digitalen Modelleisenbahnsteuerungen haben mit Wiederholung der Daten - ich glaube 1 - 3 Byte - gearbeitet und es hat wohl funktioniert. Heute wird ein Datensatz mit CRC übertragen. Funktioniert wohl auch, denn aus der Eisenbahnwelt in Hamburg z.B. hört man ja kaum von irgendwelchen Unfällen. Und auch wenn im Beispiel der Controller massig Zeit für die Arbeit hat, muß ein Zug doch vor dem Signal anhalten, wenn es auf "Rot" steht. Ich weiß auch nicht, ob da noch weitere Sicherungsmassnahmen in der Software stecken, denn "unendlich" wird kein Zug auf der Anlage herumgurken! Gruß Rainer
Jan schrieb: > Eine richtig schöne LUT Version für CRC32 für den AVR in Assembler habe > ich nicht gefunden. Was mich ein wenig wundert. Vielleicht hilft dir c-hater dabei, daraus ASM zu machen. ;-) Viel Code ist es wirklich nicht.
1 | #define crc32_byte(octet, crc) (crc_32_tab[((crc)^(octet)) & 0xff] ^ ((crc)>>8))
|
(prx) A. K. schrieb: >> Gibt es keine beweisbar sichere Methode, ein paar Bytes zu übertragen >> und Übertragungsfehler 100%ig sicher zu erkennen? > Nur wenn der Empfänger die Bytes schon vorher kennt. ;-) 99_komma_wieviel Prozent sind denn real erreichbar? Sehr robust ist der PCOSAG-Code für die Datenübertragung an Funkrufempfänger. Der wurde etwa Ende 70er oder Anfang 80er von der britischen Postverwaltung erschaffen. Lange ist's her, die CRC konnte ich mal auf Karopapier rechnen und der Kollege hat sie mit vielen 40xx-ICs berechnet. Für die Serienprodukte gab es dann fertige ICs, die sicher noch kein µC waren. Im Frame stecken 20 Bit Nutzdaten und dazu 10 Bit CRC plus ein Parity-Bit, damit kann man ein fehlerhaftes Bit rückrechnen. Ich habe keine Ahnung, wie groß die CRC würde, wenn man 32 Bit Nutzdaten sichern und zumindest ein Bit rückrechenbar haben möchte.
Jan schrieb: > jo schrieb: >> Ein Wiederholdungcode hat keinen Codegewinn, das heißt, die >> Fehlerkorrekturfähigkeit des Codes und der Mehraufwand durch n-fache >> Übertragung löschen sich gerade aus. > > Na dann ist die Frage doch beantwortet. Nicht wirklich, jedenfalls nicht für deinen konkreten Fall. Da ist die optimale Lösung: invertierten Payload als Prüfsumme anhängen. Wobei man vielleicht "invertiert" noch konkretisieren müsste: Gemeint ist hier konkret: 1er Komplement. Also "~" in C, "com" in AVR-Asm. > Ich würde dann wohl einfach auf CRC32 gehen, da ist die Chance > wenigstens kleiner als bei CRC16. Das ja. CRC16 würde halt immerhin zwei Bytes sparen. Also 25% der Nachrichtendauer. Aber die Verwendung von CRC16 würde tatsächlich die Wahrscheinlichkeit für false positives vergleichsweise explodieren lassen. Kein Wunder, wenn man die Redundanz von 100% auf 50% reduziert... > Was ich aber dazu zwingend brauche ist eine LUT Version. Nein, brauchst du nicht. Du brauchst auch keine CRC32. So lange du genauso viele Bits als Redundanz sendest, wie du als Payload hast, ergibt CRC KEINEN Sinn. Macht nur Aufwand für exakt NULL Nutzen.
Jan schrieb: > Ich verschicke über Funk in Intervallen 4 Bytes an Messdaten. Da Funk > alles andere als zuverlässig ist, muss ich sicherstellen, dass ich > fehlerhaft übertragene Daten verwerfe. Wie äußert sich die Unzuverlässigkeit von Funk bei dir. Hast du Burst-Störungen, die ganze Funktelegramme verunstalten oder hast du eher Einzelbitfehler, ggf. auch mal zwei? Einzel- oder Doppelbitfehlern lassen sich bei geeigneter Codierung der Daten (z.B. mit Hamming-Code) durch hinzufügen weniger Bits korrigieren. Für 57 Bit werden 6 Paritätsbits benötigt.
c-hater schrieb: > Nein, brauchst du nicht. Du brauchst auch keine CRC32. So lange du > genauso viele Bits als Redundanz sendest, wie du als Payload hast, > ergibt CRC KEINEN Sinn. Macht nur Aufwand für exakt NULL Nutzen. Wenn man die Burst-Charakteristik weglässt und einfacherweise über den kleinsten Hamming-Abstand geht, ein schon erwähntes Mass für solche Verfahren: Bei obiger CRC-32 ist er in diesem Fall 8 (lt. Koopmann). Das ist schon etwas besser als 2 bei einfacher Wiederholung, ob invertiert oder nicht. Anders ausgedrückt: Die CRC-32 erkennt sicher 7 defekte Bits, die Wiederholung nur eines. Bei Bursts sieht es anders aus.
:
Bearbeitet durch User
Wenn man CRC-32 will, kann man die auch Halbbyte-weise machen. Das ist ein Kompromiß zwischen Bit-weise und Byte-weise - dann kommt man mit 64 Bytes für die LUT aus anstatt 1kB und ist immer noch gut halb so schnell wie mit der Byte-weisen Version.
@Jan Steht Dir eigentlich ein Rückwärtsgang zur Verfügung? Ein Kontrollbyte ist eine Sache - ein: "mach's nochmal Sam" eine andere. Steht nur eine Richtung zur Verfügung, so sollte man das Stichwort Redundanz im Auge behalten. Kann man aber sagen: "Nochmal senden", so sieht das ganze schon viel einfacher aus.
Sebastian S. schrieb: > Kann man aber sagen: "Nochmal senden", so sieht das ganze schon viel > einfacher aus. Inwiefern? Dazu muss man erst einmal wissen, dass die Daten defekt sind.
(prx) A. K. schrieb: > Anders ausgedrückt: Die CRC-32 erkennt sicher 7 defekte Bits, die > Wiederholung nur eines. Bei Bursts sieht es anders aus. Ich denke, das solltest du nochmal durchdenken. Vor allem auch mit der (noch durchaus berechenbaren) Realität abgleichen...
c-hater schrieb: >> Anders ausgedrückt: Die CRC-32 erkennt sicher 7 defekte Bits, die >> Wiederholung nur eines. Bei Bursts sieht es anders aus. > > Ich denke, das solltest du nochmal durchdenken. Vor allem auch mit der > (noch durchaus berechenbaren) Realität abgleichen... Und nicht zu vergessen: In Relation zu deiner ursprünglichen Aussage stellen, dass Bursts eigentlich das Problem wären...
c-hater schrieb: > nochmal durchdenken. Vor allem auch mit der > (noch durchaus berechenbaren) Realität abgleichen... Tu dir keinen Zwang an und berechne. c-hater schrieb: > Und nicht zu vergessen: In Relation zu deiner ursprünglichen Aussage > stellen, dass Bursts eigentlich das Problem wären... Schrieb ich ja auch. Aber Bissel was will ich schon dir überlassen. Sollst doch eine Chance auf eine Lösung haben, die nicht bloss aus dem Bauch kommt. Also her mit Zahlen und Wahrscheinlichkeiten.
:
Bearbeitet durch User
Ist halt die Frage, wieviel Aufwand man in die Programmierung stecken will. Dreimal die Nettodaten in einem Block senden, ermöglicht eine einfache effiziente Erkennung von Einzel-/Mehrfachfehlern und auch Bursts. Mit Mehraufwand wäre der Code der bei RDS verwendet wird, empfehlenswert.
c-hater schrieb: > A. S. schrieb: >> 4 zu 6 Bit Codierung plus crc8 > > Alles huppse. Wenn der ganze Gewinn lächerliche 4 Bit sind. Zumal man > bei vielen Funklösungen das nichtmal nutzen könnte, weil die nix unter > Bytes können. > > Also: das geht endgültig in die falsche Richtung. Wie kommst Du auf 4 Bit? Weil man von den 8 Byte 4 Bit nicht unbedingt braucht? Und Du als Assembler-Programmierer, kannst keine Bits in Bytes wandeln? Die Vorteile hat Gerald K (für sein Verfahren, ist aber ähnlich) gut dargestellt.
Abdul K. schrieb: > Mit Mehraufwand wäre der Code der bei RDS verwendet wird, > empfehlenswert. Wenn ich mir angucke, was die RDA5807M China-Empfänger so liefern, taugt entweder der RDS-Code nichts oder ist schwierig zu decodieren.
Hallo, ich nutze die fertige Lib <util/crc16.h> dafür und folgende Berechnungsfunktion.
1 | uint16_t calc_CRC16 (uint8_t feld[], uint8_t length) |
2 | {
|
3 | uint16_t crc = 0xFFFF; // initial CRC value |
4 | uint8_t b = 0; |
5 | |
6 | while (length--) { |
7 | crc = _crc16_update(crc, feld[b++]); |
8 | }
|
9 | return crc; |
10 | }
|
Es besteht außerdem die Frage wie die Daten übertragen werden. Welche Übertragungsart? Einfach Seriell, Differenziell ala RS485 oder ...
:
Bearbeitet durch User
Manfred schrieb: > Wenn ich mir angucke, was die RDA5807M China-Empfänger so liefern, taugt > entweder der RDS-Code nichts oder ist schwierig zu decodieren. Vielleicht ist der Chip falsch konfiguriert. Die Daten auf meinem Autoradio sind immer plausibel.
Es gibt in Normen zur Funktionalen Sicherheit Vorgaben zur Fehlerrestwahrscheinlichkeit bei Datenübertragungen. Dort wird abhängig vom Übertragungsmedium eine Bitfehlerrate angesetzt. Es gibt einen guten Artikel von Peter Wratil, "Sichere Netzwerke Technik und Anwendung" , Elektronik 2005 (2 Teile), der etwas Grundlagen dazu bietet. Findet man im Netz. Funkverbindungen sind zwar eine andere Nummer, da die Bitfehler durch beliebige äußere Einflüsse auftreten, aber das Verfahren hilft Zusammenhänge zu verstehen. In dem Artikel fehlen aber Betrachtungen zu Burst. Es gibt eine Dissertation von Heinrich–Theodor Hannen, in der Untersuchungen zu Burst und CRC gemacht wurden. Wenn es nichts sicherheitskritisches ist, würde ich die CRC16 oder CRC32 nehmen und das ganze einfach probieren.
(prx) A. K. schrieb: > Wie darf ich mir differenziell per Funk vorstellen? Mit unterdrücktem Träger?
c-hater schrieb: > Quatsch. Da kannst du besser gleich den Payload nochmal invertiert > dranhängen. Wennschon CRC, dann bei vier Bytes Payload natürlich CRC8. > Oder einfach XOR. Für mein Wireless DMX habe ich direkt Byte und invertiertes Byte hintereinander gesendet. Das hat den Vorteil, das bei einer Störung nur eine Payload verworfen werden muss, die anderen aber noch durchkommen (das war bei den DMX Kanälen sehr nützlich). Da wirklich nur ein XOR pro Byte gemacht werden muss, ist das ganze sehr schlank. CRC hat halt den Nachteil, das das ganze Paket Müll ist, wenn CRC nicht stimmt.
Matthias S. schrieb: > Das hat den Vorteil, das bei einer Störung nur eine Payload verworfen > werden muss, die anderen aber noch durchkommen (das war bei den DMX > Kanälen sehr nützlich). Wie erkennt man welcher Teil der Payload ok ist? Oder erhält der reduntante Teil seine eigene Prüfsumme?
Wenn er die Bytes A,~A,B,~B,C,~C,D,~D überträgt, kann er die defekten Paare aussortieren. Fragt sich nur, ob das bei der hier betrachteten Übertragung was bringt, bei regelmässig 4 Bytes. Bleibt immer noch das Problem von 2 Einzelbitfehlern in exakt 8 Bits Abstand, die nicht erkannt werden, während eine CRC16 damit kein Problem hat und eine CRC32 mit mindestens 7 erkennbaren Fehlern auch bei Bursts ähnlich gut ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bleibt immer noch das Problem von 2 Einzelbitfehlern in exakt 8 Bits > Abstand, die nicht erkannt werden Das gabs bei meinem Projekt niemals. Aber ausschliessen kann man es nicht, genauso wie eine zufällig wieder passende CRC.
Wenn man das qualifiziert angehen will, muss man die tatsächliche Fehlercharakteristik des Kanals betrachten. Gerade bei lokalem Funk ist das nicht trivial, weil Aussagen von heute auf Morgen u.U. nicht mehr anwendbar sind. Da kann man eine Woche mit gutem Ergebnis lang messen, und am Tag drauf kommt der Nachbar aus dem Urlaub zurück.
:
Bearbeitet durch User
Matthias S. schrieb: > Das gabs bei meinem Projekt niemals. Aber ausschliessen kann man es > nicht, genauso wie eine zufällig wieder passende CRC. Daher sind Plausibitätschecks auf höherer Ebene sinnvoll. Z.B. passen die zuletzt empfangen Danten zu den vorangegangen Daten. Ein Sprung der Aussentemperatur um 100°C innerhalb einer Sekunde ist nicht plausibel. Gleiches bei Drehzahlen etc.
Man kann bei Funk noch zusehen, andere Plausibilitätsprüfungen einzubauen. Hier ließe sich beispielsweise einfach eine laufende Nummer mit übertragen, die bei jeder Aussendung hochgezählt wird. Die Plausibilitätsprüfung testet dann, ob die empfange Nummer in einem sinnvollen Bereich zur zuvor empfangenen liegt.
Gerald K. schrieb: > Daher sind Plausibitätschecks auf höherer Ebene sinnvoll. Z.B. passen > die zuletzt empfangen Danten zu den vorangegangen Daten. Yep, allein schon weil nicht nur Übertragungsfehler erfolgen können, sondern auch korrekt übertragene Daten defekter Messstellen. 80°C Kesselwasser und -10°C Aussentemperatur lasse ich mir gefallen, aber nicht umgekehrt. Ebenso sollte man bei den DS18x20 85,0°C ausfiltern, denn das kommt raus, wenn der frisch startet. Und man sollte veraltete Daten erkennen und passend reagieren, also wenn eine Weile nichts korrekt reinkommt.
:
Bearbeitet durch User
Matthias S. schrieb: > Das gabs bei meinem Projekt niemals. Gab es nie, oder hast es nie gemerkt? ;-)
Jörg W. schrieb: > Man kann bei Funk noch zusehen, andere Plausibilitätsprüfungen > einzubauen. Hier ließe sich beispielsweise einfach eine laufende Nummer > mit übertragen, die bei jeder Aussendung hochgezählt wird. Die > Plausibilitätsprüfung testet dann, ob die empfange Nummer in einem > sinnvollen Bereich zur zuvor empfangenen liegt. Das scheint mir bei Briefen sinnvoller. Funk bleibt nicht 2 Wochen lang unterwegs liegen. Da reicht es, die Werte beim Empfang mit der aktuellen Timestamp zu versehen und die dort zu berücksichtigen, wo die Werte ausgewertet werden. Wenn darüber kein Protokoll gespeichert wird, ist eine auslesbare Fehlerstatistik sinnvoll. Vielleicht eine Warnung, wenn zu hoch.
:
Bearbeitet durch User
Jörg W. schrieb: > Man kann bei Funk noch zusehen, andere Plausibilitätsprüfungen > einzubauen. Hier ließe sich beispielsweise einfach eine laufende Nummer > mit übertragen, die bei jeder Aussendung hochgezählt wird. Die > Plausibilitätsprüfung testet dann, ob die empfange Nummer in einem > sinnvollen Bereich zur zuvor empfangenen liegt. Man kann zusätzlich die empfangen Daten zurückschicken. Dann weiss der Sender, dass die Daten richtig angekommen sind und kann diese bei feherhafter Übereinstimmung ein weiters mal schicken. Es können die Wiederholungen gezählt werden und in Relation zu laufenden Nummer gesetzt weren. So kann die Übertragungsqualität gemessen werden. Beispiel: Funkmelder in einem Gebiet mit wenig WLANs : 129 (0.517%) of 24929 telegrams lost restarts = 4 Funkmelder in einem Gebiet mit vielen WLANs : 3751 (13.963%) of 26864 telegrams lost restarts = 2 Telegramme werden mit UDP übertragen und solange wiederholt bis gesendete Teldgramme und rückgesendete Telegramme übereinstimmen. Restarts erkennt man wenn mit der fortlaufenden Nummer von vorne zu zählen begonnen wird.
(prx) A. K. schrieb: > Funk bleibt nicht 2 Wochen lang unterwegs liegen. Aber es geht mehr verloren als bei der Deutschen Post. ;-) > Da reicht es, die > Werte beim Empfang mit der aktuellen Timestamp zu versehen und die dort > zu berücksichtigen, wo die Werte ausgewertet werden. Wenn man Timestamps auf der Senderseite hat, kann man diese benutzen. Viele kleinere Controller-basierte Geräte haben aber keine time-of-day clock.
Gerald K. schrieb: > Telegramme werden mit UDP übertragen und solange wiederholt bis > gesendete Teldgramme und rückgesendete Telegramme übereinstimmen. Naja, komplettes zurücksenden ist ziemlich viel Aufwand (zumindest bei größeren Telegrammen). Ein kryptografischer Hash sollte genügen, wenn einem die CRC zu unsicher erscheint.
Jörg W. schrieb: >> Werte beim Empfang mit der aktuellen Timestamp zu versehen und die dort >> zu berücksichtigen, wo die Werte ausgewertet werden. > > Wenn man Timestamps auf der Senderseite hat, kann man diese benutzen. > Viele kleinere Controller-basierte Geräte haben aber keine time-of-day > clock. Worin liegt der Vorteil, senderseitig einen Zähler mitzuschicken, gegenüber Code, der beim Empfänger unmittelbar beim Empfang einen hinzufügt?
(prx) A. K. schrieb: > Worin liegt der Vorteil, senderseitig einen Zähler mitzuschicken, > gegenüber Code, der beim Empfänger unmittelbar beim Empfang einen > hinzufügt? Es wurde ja angedeutet, dass eine CRC-Prüfung allein keine Sicherheit bietet, dass die Pakete nicht verfälscht worden sind. Wenn man nicht ohnehin anderweitige Plausbilitätstests machen kann, lässt sich die Monotonie eines solchen Zählers halt als Plausibilitätstest benutzen. Ein Paket, das sowohl plausibel als auch CRC-positiv ist, ist mit sehr hoher Wahrscheinlichkeit auch korrekt. ;-)
Jörg W. schrieb: > Gerald K. schrieb: > >> Telegramme werden mit UDP übertragen und solange wiederholt bis >> gesendete Teldgramme und rückgesendete Telegramme übereinstimmen. > > Naja, komplettes zurücksenden ist ziemlich viel Aufwand (zumindest bei > größeren Telegrammen). Ein kryptografischer Hash sollte genügen, wenn > einem die CRC zu unsicher erscheint. Da die Telegramme sehr kurz sind, und die "Power" eines MSP430 dahinter steckt habe ich mich für die Rücksendung des Telegramms entschieden. Die fortlaufende Nummer ist am Ende des Telegramms zu sehen:
1 | 2021-05-20 11:11:47 68:c6:3a:ea:86:4f -L-S-. E 29oC 3298mV 2497mV 5638 |
2 | 2021-05-20 11:11:50 68:c6:3a:ea:86:4f -.-S-. E 29oC 3272mV 2497mV 5639 |
3 | Routerausfall (ETH) 2021-05-20 |
4 | 2021-05-22 12:11:59 68:c6:3a:ea:86:4f ELRS.. P 28oC 3409mV 2497mV 0 |
5 | 2021-05-22 12:12:20 68:c6:3a:ea:86:4f -L-.-. E 28oC 3384mV 2497mV 1 |
Matthias S. schrieb: > Aber ausschliessen kann man es nicht, genauso wie eine zufällig wieder > passende CRC. Der Vorteil einer (konkreten) CRC ist deren definierte Eigenschaft: je nach Breite, Polynom und Vorbehandlung kannst Du nachlesen, welche Arten von Fehlern mit welcher Wahrscheinlichkeit unter welchen Bedingungen ausgeschlossen sind. Die Polynome sind meist speziell ausgesucht für gute Performance. Einen großen Vorteil haben sie, wenn die Länge der Daten unbekannt ist oder die Dekodierung in TTL oder Fgpa erfolgen soll (nur ein paar Logikgatter notwendig) Bei Funk mit uC und fester Länge ist CRC suboptimal, da die Vorteile hier nicht Punkten.
Der Sender hat keine RTC. Das ist nur ein einfaches Gerät. Mit RTC hätte man das Problem, dass die Zeit nach dem Einschalten ja erstmal drauf muss. Muss also ohne gehen. Auch bidirektionale Kommunikation ist leider nicht drin. Ja, das ist halt die Frage nach der sichersten Methode. Wie man sieht, gibt es extrem viele Methoden. Es ist halt anscheinend extrem schwierig, die richtige rauszusuchen und anscheinend gibt es keine, die wirklich niemals versagen kann. Wie läuft das denn im Ethernet? Da ist doch auch nur eine CRC32 Prüfsumme. Die wird doch wohl ab und zu mal zufällig auch bei fehlerhaften Daten stimmen? Was passiert dann mit dem Paket? Auch wenn die Chance 1 zu 4 Mrd ist, werden doch pro Sekunde Billionen Pakete weltweit versendet. Wenn da irgendwo ein prinzipieller Fehler wäre, wäre das doch schon längst aufgefallen.
Jan schrieb: > Wie läuft das denn im Ethernet? => https://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf
Jan schrieb: > wäre das doch schon längst aufgefallen. Selbst ein Programm kann mit einem fehlerhaften Bit kann lange laufen bis auffällt.
(prx) A. K. schrieb: > Jan schrieb: >> Wie läuft das denn im Ethernet? > > => https://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf Danke. Man sieht deutlich, es ist Zeit für ein neues Polynom!
Gerald K. schrieb: > Selbst ein Programm kann mit einem fehlerhaften Bit kann lange laufen > bis auffällt. Wobei bei TCP noch eine einfache Checksum oben drauf sitzt.
Ich lade ein Proramm grunsätzlich zweimal herunter und vergleiche die Binärdateien Ein Fehler beim Runterladen einer gezippten Datei würde auffallen, denn sie lässt sich nicht entpacken.
:
Bearbeitet durch User
Viele kritische Quellen erlauben eine Überprüfung per MD5/SHA.
Jan schrieb: > (prx) A. K. schrieb: >> Jan schrieb: >>> Wie läuft das denn im Ethernet? >> >> => https://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf > > Danke. Man sieht deutlich, es ist Zeit für ein neues Polynom! Hmmm... ok Ethernet ist nicht wirklich mit Funk zu vergleichen, wo gerne mal 10% der Bits regelmässig falsch ankommen und 90% packet loss durchaus auch mal der Normalfall sein kann. Im Ethernet würde dann nichts mehr gehen, aber wenn ich per Funk jede Sekunde einen Messwert versende und trotzdem nur alle 10 Sekunden einer heil ankommt, ist das in der Regel völlig ausreichend. 9 von 10 Paketen sind also Müll und müssen auch als solchen erkannt werden. Von 32 Bits sind also zum Beispiel 10 falsch. Das muss erkannt werden. Aber CRC32 erkennt maximal 6 falsche Bits..... also eigentlich dürfte man CRC32 nicht nehmen?
Bei TFTP wird eine Prüfsumme über jeden einzelnen übertragenen Block (512Byte) gebildet. Im IP Stack wird sicher noch eine Gesamtprüfsumme gebildet. Das erhöht die Sicherheit enorm. Schicht 2 hat auch eine Sicherung. https://www.ip-insider.de/was-ist-layer-2-a-651843/
:
Bearbeitet durch User
Jan schrieb: > Aber CRC32 erkennt maximal 6 falsche Bits..... also eigentlich > dürfte man CRC32 nicht nehmen? Die Tabelle in dsn02_koopman_CRC32.pdf zeigt für 32Bit Nutzdaten schafft man mit CRC32 (0x82608EDB) immerhin eine HD=10. Vermutlich muss man es andersherum machen. Wenn regelmäßig x% von 10 Paketen defekt sind muss man das System abschalten. Sonst wird es zwangsläufig nach x Tagen zum Fehler kommen. Unter dem Baukran möchte ich nicht stehen, wenn plötzlich die Last kommt… Alternativ noch mehr Redundanz und Erwartungswerte.
BeBe schrieb: > Die Tabelle in dsn02_koopman_CRC32.pdf zeigt für 32Bit Nutzdaten schafft > man mit CRC32 (0x82608EDB) immerhin eine HD=10. Stimmt, in dieser Tabelle zählt nur die Nutzdatenlänge. Ich hatte oben die Gesamtlänge angenommen.
Moin, Wenn man euch so zuhoert/zuliest - dann muss man ja zum Schluss kommen, dass so Sachen wie WLAN, DVB-S/T/S2/T2 oder gar Mobilfunknetze komplett auf Zauberei beruhen muessen. Anders kann deren Alltagstauglichkeit keinesfalls zustande kommen. SCNR, WK
Jan schrieb: > Auch wenn die Chance 1 zu 4 Mrd ist, werden doch pro Sekunde Billionen > Pakete weltweit versendet. Wenn da irgendwo ein prinzipieller Fehler > wäre, wäre das doch schon längst aufgefallen. Schau Dir Mal die Liste an, was an Fehlern sicher erkannt wird. Du hast auch bei Fehlern eine Verteilung. Wenn jedes tausendste Telegramm ein Bit falsch hat (also kaputt, was viel ist, aber immer erkannt wird), dann ist es schon nur jedes millionste Telegramm mit 2 zufälligen Bits. Und das dann Mal 4 Mrd, das ist dann E16. 100.000 Telegramme pro Sekunde wären dagegen nur E12 im Jahr.
Nagut, da bisher kein wirklich sicheres Verfahren vorgeschlagen wurde, werde ich das Teil einfach so designen, dass durchschlüpfende Fehler keine Katastrophe verursachen. Ich fühle mich einfach nicht wohl dabei, wenn man einfach nach Wahrscheinlichkeiten geht, vorrausgesetzt natürlich, es gibt ein Verfahren, was 100%ig sicher ist, was man aber einfach nicht eingebaut hat, weil man davon nichts wusste.
Jan schrieb: > werde ich das Teil einfach so designen, dass durchschlüpfende Fehler > keine Katastrophe verursachen. Guter Ansatz.
Jan schrieb: > Nagut, da bisher kein wirklich sicheres Verfahren vorgeschlagen wurde, > werde ich das Teil einfach so designen, dass durchschlüpfende Fehler > keine Katastrophe verursachen. Ja guter Ansatz wie mein Vorposter. Du kannst aber trotzdem, das Paket doppelt senden und einfach zusätzlich jedes Byte mit einem Paritybit versehen, dann siehst du, wen ein Paket ein Fehler aufweist welches von den beiden es ist das ist. Ein Paritätsbit ist rechnerisch für den MCU kein Aufwand und kostet auch kaum Rechenzeit ;-) Bei Kritischen Daten (Etwa für die Chemie zufuhr der Impfzellen in Schwimmbädern) Sende ich beispielsweise die Pakete auch doppelt inklusive CRC um zu verhindern das die Badegäste plözlich grüne Haare haben oder andere Zwischenfälle kommen. Dazu verwende ich aber Prozessoren die ein CRC Generatoren Onboard haben ;-)
PaLi schrieb: > Dazu verwende ich aber Prozessoren die ein CRC Generatoren Onboard haben > ;-) Pfff! Am besten noch obendrein direkt AES on-board. Als ob ich die 2 Euro zusätzlich für den xmega A4U ausgebe, statt einen 50 Cent attiny88 zu nehmen. ;) .... Ich bin komisch. Ist ja auch egal. Die Frage war ja nicht, ob CRC in Hardware oder in Software, sondern ob CRC überhaupt. Ganz abgesehen davon bist du bei Hardware-CRC bestimmt auf ein fest vorgegebenes Polynom angewiesen.
PaLi schrieb: > Du kannst aber trotzdem, das Paket doppelt senden und einfach zusätzlich > jedes Byte mit einem Paritybit versehen, dann siehst du, wen ein Paket > ein Fehler aufweist welches von den beiden es ist das ist. Ich finde in diesem Fall auch die Idee, jedem Byte seine "Negation" nachzuschicken, bedenkenswert. Dabei könnte man vielleicht auch noch Übertragungsfehler finden...ist nur ein Gefühl...werde ich aber mal ausprobieren :-) Gruß Rainer
Jan schrieb: > Ganz abgesehen davon bist du bei > Hardware-CRC bestimmt auf ein fest vorgegebenes Polynom angewiesen. nein, natürlich nicht.
Rainer V. schrieb: > Ich finde in diesem Fall auch die Idee, jedem Byte seine "Negation" > nachzuschicken, bedenkenswert. Du must nur die Parität beider Pakete ebenfals mit XOR verknüpfen, Selbst wen beide Packete dan den selben übertragungsfehler häten und Zufällig identisch falsch sind ist sehr unwahrscheinlich das dann auch noch das Paritätsbit beider Pakete ebenfalls noch falsch ankommt den das wird ja durch die XOR Verknüpfung dann zwingend falsch sein auch wenn beide Pakete tatsächlich Gleich falsch angekommen sind. Inklusive des CRC ist die Wahrscheinlichkeit 2x Hintereinander im Lotto ein 6er zu habe grösser als dass das Passiert ;-) @ TO Für dein Vorhaben würde ich denken wäre es ausreichend mit Parität und Checksum vollkommen ausreichend. den Checksum ist für eine MCU ja auch kein Hexenwerk ;-)
Rainer V. schrieb: > Ich finde in diesem Fall auch die Idee, jedem Byte seine "Negation" > nachzuschicken, bedenkenswert. Jenseits irgendwelcher Effekte durch die verwendete Modulation hat das m.E. genau einen signifikanten Vorteil gegenüber normaler Wiederholung: Klemmt das Signal auf dauerhaft 0 oder 1, merkt man es.
:
Bearbeitet durch User
Jan schrieb: > Pfff! Am besten noch obendrein direkt AES on-board. Als ob ich die 2 > Euro zusätzlich für den xmega A4U ausgebe, statt einen 50 Cent attiny88 > zu nehmen. ;) Nein ich verwende MSP432 für hohe rechenleistung und MSP430 für ganz einfache sachen da ist tatsächlich CRC und AES mit drinn und kostet etwa 20 Cent mehr als Ohne ;-)
PaLi schrieb: > Jan schrieb: >> Pfff! Am besten noch obendrein direkt AES on-board. Als ob ich die 2 >> Euro zusätzlich für den xmega A4U ausgebe, statt einen 50 Cent attiny88 >> zu nehmen. ;) > > Nein ich verwende MSP432 für hohe rechenleistung und MSP430 für ganz > einfache sachen da ist tatsächlich CRC und AES mit drinn und kostet etwa > 20 Cent mehr als Ohne ;-) Ja, die xmegas werden von Microchip gerade ausgeblutet. Bei den Preisen nehmen Firmen mit hohen Stückzahlen bei neuen Projekten direkt einen ARM. Schade eigentlich. Die xmegas sind richtig gut.
Jan schrieb: > Ich fühle mich einfach nicht wohl dabei, wenn man einfach nach > Wahrscheinlichkeiten geht So ist das. Es geht immer nur um Wahrscheinlichkeiten, selbst bei elektronischen Signaturen und Verschlüsselungen. Informiere dich mal, wie (un-)zuverlässig die Speicherzellen einer SSD sind und wie wahrscheinlich diese Fehler nicht erkannt werden. Achtung: Das Ergebnis könnte dich noch mehr verunsichern. Wir hatten neulich einen Fall in der Firma, da hat ein Server 2x behauptet, dass ein String nicht mit base64 decodiert werden kann, weil er ein ungültiges Leerzeichen enthält. Das stimmt aber nicht. Wir haben doppelt und dreifache Protokolle, die eindeutig belegen, dass da kein Leerzeichen war. Wir konnten das Problem auch kein drittes mal auslösen. Wir haben die gleiche Nachricht tausende male erneut in die Warteschlange gestellt, und sie wurde jedes mal Problemlos decodiert. Auch hat uns der Absender bestätigt, dass sie kein Leerzeichen gesendet haben. Wie kommt sowas? Weil unsere Computer nur wahrscheinlich richtig funktionieren. Neulich hat Google herausgefunden, dass die meisten solcher Fehler gar nicht bemerkt werden. Aber sie passieren.
Gerald K. schrieb: > Da die Telegramme sehr kurz sind, und die "Power" eines MSP430 dahinter > steckt habe ich mich für die Rücksendung des Telegramms entschieden. Die > fortlaufende Nummer ist am Ende des Telegramms zu sehen: Ich hätte da mal die Frage, welchen MSP430 du nimmst? Ich hatte vor kurzem in einem Projekt den MSP430FR2355 Verwendet. es ging da um ein Projekt wo die Daten extrem Wichtig sind. Da habe ich den Onboard AES CRC und den "Manchester codec (MFM)" ebenfalls schon mit drin. Damit habe ich eine Komplette Mess-Schaltung mit den Onboard AD Wandler und Onboard OpAmp realisiert, ohne einen weiteren Aktiven Chip (excl. Spannungsregler). So habe ich dann mit dem AES die Verschlüsselung und mit dem CRC Controllbyte und mit dem Onboard MPY das Checksum mit minimalster Rechenleistung realisiert. Aufs Netzwerk gehe ich mit dem "Manchester codec (MFM)" dann direkt auf ein RJ45 Stecker mit integriertem Trafo... Funst extrem zuverlässig und ist auch mit sehr wenig PCB Space realisiert. (Denke auch für ten TO Interessant und daher nicht wirklich OT ;-)
PaLi schrieb: > Da habe ich den Onboard AES CRC und den "Manchester codec (MFM)" > ebenfalls schon mit drin. > Damit habe ich eine Komplette Mess-Schaltung mit den Onboard AD Wandler > und Onboard OpAmp realisiert, ohne einen weiteren Aktiven Chip (excl. > Spannungsregler). > So habe ich dann mit dem AES Sorry Tipfehler for lauter AES GRMPF... der hat neine Onboard MPY32 und kein AES
Angehängte Dateien:
-
MFM_Block1.gif
120 KB
Fals es dich Interessiert hhier die Beschaltung des RJ45 Mit weniger Bauteile kaum zu schaffen
Ich habe letztens in LittleFileSystem diese einfache CRC32 gefunden: https://github.com/littlefs-project/littlefs
1 | // Software CRC implementation with small lookup table
|
2 | uint32_t CalculateCRC( uint32_t crc, |
3 | const void *buffer, |
4 | size_t size) |
5 | {
|
6 | // Calculate CRC-32 with polynomial = 0x04c11db7
|
7 | static const uint32_t rtable[16] = { |
8 | 0x00000000, 0x1db71064, 0x3b6e20c8, 0x26d930ac, |
9 | 0x76dc4190, 0x6b6b51f4, 0x4db26158, 0x5005713c, |
10 | 0xedb88320, 0xf00f9344, 0xd6d6a3e8, 0xcb61b38c, |
11 | 0x9b64c2b0, 0x86d3d2d4, 0xa00ae278, 0xbdbdf21c, |
12 | };
|
13 | |
14 | const uint8_t *data = (const uint8_t *) buffer; |
15 | |
16 | for (size_t i = 0; i < size; i++) |
17 | {
|
18 | crc = (crc >> 4) ^ rtable[(crc ^ (data[i] >> 0)) & 0xf]; |
19 | crc = (crc >> 4) ^ rtable[(crc ^ (data[i] >> 4)) & 0xf]; |
20 | }
|
21 | return crc; |
22 | } // CalculateCRC() |
Ist für einfache ARMs, sollte aber auch auf einem AVR gehen?
Auf einem AVR 32-Bit Werte um 4 Bits verschieben zu müssen, könnte zur Folge haben, dass der Code nicht arg viel schneller ist, als die CRC bitweise zu rechnen. Um 8 Bits zu verschieben ist viel fixer.
:
Bearbeitet durch User
Zumindest ist dieser Code die Antwort auf die obige Frage nach Nibble-Verarbeitung relativ kleiner Tabelle.
Bei ARMen das auch kein Thema. Generell wird der Nibble-Code bei allen CPUs mit ausreichend breitem Barrel Shifter gut funktionieren. Nur gehört AVR eben nicht dazu.
Gibt es eigentlich einen verständlichen formalen Weg zur Konvertierung eines Alogrithmus von bitwise sequentiell zu mehr oder weniger länglicher Tabelle?
Abdul K. schrieb: > Der olle 8051 hatte doch den SWAP-Befehl, gibt's den nicht beim modernen > AVR? Doch klar. Wie hilft der bei einem 4-Bit-Shift eines 32-Bit-Wertes?
Abdul K. schrieb: > Der olle 8051 hatte doch den SWAP-Befehl, gibt's den nicht beim modernen > AVR? Gibt es, und wird von GCC bei 16-Bit Shifts auch genutzt, wenn man ihn nicht per -Os daran hindert. Bei 32-Bit aber nicht. Ist trotzdem recht umständlich, denn eigentlich bräuchte man eine Art 12-Bit Swap dafür, statt eines 8-Bit Swap. So in der Art eines Rotate-durch-Carry, der ja 9 Bits rotiert statt 8.
1 | swap r25 |
2 | swap r24 |
3 | andi r24,0x0f |
4 | eor r24,r25 |
5 | andi r25,0x0f |
6 | eor r24,r25 |
Bei x86 gibts solche Befehle übrigens, also welche, mit denen man Shifts
>1 jenseits Wortbreite kaskadieren kann: z.B. SHRD.
:
Bearbeitet durch User
Ich würde das in etwa so lösen:
1 | mov.b &RxTxBuff+4,&MPY_L; Examplevalue String "-71dB" MPY_L RES0 ¯¯¯¯¯¯¯¯¯ |
2 | and.b #0Fh,MPY_L ; and Cut all unused Bits [0000¹¹¹¹] [xxxxxxxxxxxxxxxx] |
3 | mov.w #01h,&OP2 ; And Sstore Times Left by MPYx1 [0000¹¹¹¹] [000000000000¹¹¹¹] |
4 | mov.b &RxTxBuff+3,&MAC_L; get 2nd ASCII digit To MAC_L [xxxx²²²²] [000000000000¹¹¹¹] |
5 | and.b #0Fh,&MAC_L ; and Cut all unused Bits to16Bit [0000²²²²] [000000000000¹¹¹¹] |
6 | mov.w #010h,&OP2 ; And Shift 2 Times Left by MPYx4 [0000²²²²] [00000000²²²²¹¹¹¹] |
7 | mov.b &RxTxBuff+2,&MAC_L; get 2nd ASCII digit To MAC_L [xxxx³³³³] [00000000²²²²¹¹¹¹] |
8 | and.b #0Fh,&MAC_L ; and Cut all unused Bits to16Bit [0000³³³³] [00000000²²²²¹¹¹¹] |
9 | mov.w #100h,&OP2 ; And Shift 2 Times Left by MPYx4 [0000³³³³] [0000³³³³²²²²¹¹¹¹] |
10 | mov.w &RES0,&Aud_CD ; And Write to Aud_CD Aud_CD<-[0000³³³³²²²²¹¹¹¹] |
Allerdings geht das nur mit Multiplikation oder einer MPY wie sie im MSP430 vorhanden ist
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.