Forum: HF, Funk und Felder Fehlerkorrektur für kleine Paketgrößen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Georg S. (georgschmied)


Lesenswert?

Hi,

ich arbeite mich gerade in die Thematik der Vorwärtsfehlerkorrektur ein. 
Anwendung ist eine Echtzeitkommunikation in 2 Varianten:

1. die Übertragung von sehr kurzen Paketen zu je 4 bis 16 Bits (netto 
Datenlänge) und
2. für eine kontinuierliche Übertragung.

Es gibt sehr viele Methoden wie RS, BCH, LDPC, Polar und Turbo Codes 
etc. In der Literatur finde ich kaum Untersuchungen, welche für sehr 
kleine Paketlängen oder die kontinuierliche Übertragung am besten 
geeignet wären. Ich suche die optimale Methode mit minimaler Komplexität 
und gleichzeitig maximaler Anzahl der korrigierbaren Bits bei minimaler 
Redundanz.

Für Tipps wäre ich sehr dankbar.

Gruß
Georg

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Georg S. schrieb:
> Ich suche die optimale Methode mit minimaler Komplexität
> und gleichzeitig maximaler Anzahl der korrigierbaren Bits bei minimaler
> Redundanz.

Achnee. Wer haette das gedacht?

Wie sonst auch oft, gibts natuerlich auch hier nicht die eierlegende 
Wollmilchsau. Das ist wie eine Decke, die zu kurz ist, es haengen also 
immer Fuesse, Arme oder Brustkorb raus. Oder wie ein Tiefpassfilter, das 
hat entweder gutes Sperrverhalten, dann aber Ripple im Durchlass und 
eine fuerchterliche Gruppenlaufzeit. Oder halt schoene 
Impulseigenschaften, aber kack-Selektion. Oder halt riesen-Aufriss...

Ich wuerde da moeglichst wenig Raeder neu erfinden, sondern je nach Art 
deiner Echtzeitkommunikation irgendeinen bestehenden Standard hernehmen.

zB. wird bei DVB-S Viterbi und RS verwendet, bei DVB-S2 LDPC und BCH. 
Warum? Weil halt bei der Spezifizierung von DVB-S LDPC noch zu komplex 
zum decodieren war; sprich die dafuer noetige HW waere noch zu teuer 
gewesen - also wurd's halt Viterbi, obwohl LDPC wohl n Tick "besser" 
ist.
Bei Mobilfunk / WLAN wirds auch irgendwas geben, aber was? Davon hab ich 
keine Ahnung.

Ich denk mal, es haengt viel mehr davon ab, wie genau dein Kanal bzw. 
dessen Fehler beschaffen ist/sind, wie die Rate ist, ob's Buendelfehler 
gibt, wenn ja wie lange, etc...

Wenn du das dann doch alles selber basteln willst, dann wuerd ich 
empfehlen, erstmal mit 'nem Hammingcode anzufangen. Da ist die Korrektur 
noch recht simpel gestrickt.

Gruss
WK

von Rainer W. (rawi)


Lesenswert?

Georg S. schrieb:
> Ich suche die optimale Methode mit minimaler Komplexität
> und gleichzeitig maximaler Anzahl der korrigierbaren Bits bei minimaler
> Redundanz.

Sonst hast du keine Wünsche. Du musst zwei Arten von Störungen 
unterscheiden: Rauschen, dass zum Kippen einzelner Bits führen kann und 
Burst-Störungen, die den Übertragungskanal vorübergehend für kurze Zeit 
unbrauchbar machen.
Gegen welche Art von Störungen willst du deine Übertragung absichern und 
wie lange dauern ggf. Burst-Störungen?
Die Anforderungen nach Echtzeit lässt sich nur erfüllen, wenn "Echtzeit" 
langsam gegenüber der Dauer von Burst-Störungen ist.
Bei Bitkippern musst du den Unterschied zwischen der Anzahl 
detektierbarer Störungen und der Anzahl korrigierbarer Störungen 
unterscheiden.

"maximaler Anzahl der korrigierbaren Bits" würde bedeute, dass du 
Stärungen in allen Bits korrigieren können möchtest. Für "minimale 
Redundanz" gibt es da wenig Spielraum. Es gibt immer eine 
Restwahrscheinlichkeit für unentdeckte Fehler.

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

Rainer W. schrieb:
> Georg S. schrieb:
>> Ich suche die optimale Methode mit minimaler Komplexität
>> und gleichzeitig maximaler Anzahl der korrigierbaren Bits bei minimaler
>> Redundanz.
>
> Du musst zwei Arten von Störungen
> unterscheiden: Rauschen, dass zum Kippen einzelner Bits führen kann und
> Burst-Störungen, die den Übertragungskanal vorübergehend für kurze Zeit
> unbrauchbar machen.
> Gegen welche Art von Störungen willst du deine Übertragung absichern und
> wie lange dauern ggf. Burst-Störungen?

Gegen Burst-Fehler gibt es verschiedenen Strategien wie Scrambling, das 
durch Umsortieren einzelner Bits in einer grösseren Gruppe Einzelfehler 
macht. Bei paketorientierter Übertragung eher nichtpraktikabel. Oder 
eine Art Handshake/Quittierung, bei der das gesamte Paket lediglich mit 
CRC geprüft wird und bei inkorrekthei eine negative Quittung 
zutückgeschickt wird. Dann sendet man das Paket eben nochmal.

Zu beachten ist wahrscheinlich, das hier von Aktionen in verschiedenen 
Schichten des OSI-7 Schichten-Modell gesprochen wird. Vorwärtskorrektur 
ist Schicht-2, während Pakete (und nicht Blöcke ?!) erst in den 
Schichten 3 und 4 vorkommen.

Vielleicht schaut man sich das Ganze mal in der Implementierung als UDP 
an. https://de.wikipedia.org/wiki/User_Datagram_Protocol

: Bearbeitet durch User
von Rainer W. (rawi)


Lesenswert?

Bradward B. schrieb:
> Gegen Burst-Fehler gibt es verschiedenen Strategien wie Scrambling, das
> durch Umsortieren einzelner Bits in einer grösseren Gruppe Einzelfehler
> macht.

Größere Gruppen gibt es aber bei 4..16 Bit nicht. Für Scrambling 
innerhalb der der Gruppe gibt es da wenig Spielraum.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>> Gegen Burst-Fehler gibt es verschiedenen Strategien wie Scrambling, das
>> durch Umsortieren einzelner Bits in einer grösseren Gruppe Einzelfehler
>> macht.
>
> Größere Gruppen gibt es aber bei 4..16 Bit nicht. Für Scrambling
> innerhalb der der Gruppe gibt es da wenig Spielraum.

Stimmt, die Angabe 16 bit (also word, kein Paket/Block) hab ich 
überlesen.

Typisch für scrambling zur Umwandlung Burst zu Single-Fehler ist die CD:

https://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology#Error_Correction

https://aircconline.com/ijcsit/V14N4/14422ijcsit01.pdf

Das wendet man bei Blöcken im Bereich von mehreren Tausend bytes an.

von Georg S. (georgschmied)


Lesenswert?

Danke für eure Antworten - ja ich suche einen Schutz gegen Burstfehler, 
Scrambling/Interleaving ist mir klar, geht hier aufgrund der geringen 
Größe aber nicht so wirklich.

Ich bitte um Antworten zu den Fehlerkorrekturalgorithmen selbst - RS, 
BCH, LDPC, Polar und Turbo Codes etc - was hier der geeignetste wäre.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Georg S. schrieb:
> Ich bitte um Antworten zu den Fehlerkorrekturalgorithmen selbst - RS,
> BCH, LDPC, Polar und Turbo Codes etc - was hier der geeignetste wäre.

Was schmeckt am besten: Pizza, Currywurst oder Vanillepudding?

Nimm den, wo du am leichtesten an eine praxistaugliche Implementierung 
der Fehlerkorrektur kommst, die auch auf deiner Ziel-HW laeuft...

Gruss
WK

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Angehängte Dateien:

Lesenswert?

> In der Literatur finde ich kaum Untersuchungen, welche für sehr
> kleine Paketlängen oder die kontinuierliche Übertragung am besten
> geeignet wären.

> Ich suche die optimale Methode mit minimaler Komplexität
> und gleichzeitig maximaler Anzahl der korrigierbaren Bits bei minimaler
> Redundanz.

Im Anhang eine Doppelseite zu Turbocodes aus isbn:3-519-16143-3 (M. 
Bossert: "Kanalcodierung").

Da wird die Qualität der Codes an anderen als von dir genannten Metriken 
bewertet. Du nennst lediglich die Hammingdistanz, die sich relativ 
leicht abschätzen lässt. Wie in der Nachrichtentechnik üblich wird hir 
das SNR (Signal-Rausch-Verhältniss) und das BER (Bitfehlerrate) 
betrachtet.
Vielleicht formulierst Du deine Anforderungen in die dort benutzten 
Begriffe um.

Zum Polarcode findet sich nichts in diesem m.E. sehr guten Buch zum 
Thema, wohl weil Polarcodes erst 10 Jahre nach Drucklegung (1998) 
vorgeschlagen wurden (2008).

Zum Thememkreis "Optimale Codierung" könnte man eine ganze Doktorarbeit 
verfassen und Du verlangst das Dir das ein Wald-und-Wiesen-Forum vorkaut 
...

: Bearbeitet durch User
von Lu (oszi45)


Lesenswert?

Für gewöhnlich testet man sich an die optimale Größe und Geschwindigkeit 
heran. Bei Voyager hat es jedenfalls funktioniert. Ob man ein Rad immer 
neu erfinden muß? https://www.bernerzeitung.ch/voyager-283506682410

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.