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 ...
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).
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.
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.
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...
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.
(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.
(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.
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.
(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.
(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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
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/
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:> 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
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.
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
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.
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.
