Het gaat mij om een codering van 8 bits voor het versturen over een RadioLink. Bij een radio link kunnen veel bitfouten optreden, en moet het codewoord dc-balanced zijn.
De theorie hierover is altijd erg wiskundig.
Als ik 8bit codeer volgens een HammingCode krijg ik een codewoord van 12bits lang.
Het 12bits codewoord kan ik weer coderen naar een 16bits DC-balanced codewoord.
16bits is erg makkelijk te versturen met huidige uControllers die ik gebruik.
Maar !, Dit coderings schema lijkt waardeloos te zijn als je naar het decoderen kijkt.
Als er bv 1bitfout optreed dan resulteert dat bij de decodering van het 16bits codewoord naar 12bits hammingwoord direct in Meerdere bitfouten !.
Vraag: Is dit codering schema aan te passen zodat het bruikbaar is, of Kent iemand betere coderingsmethoden die hier beter voor geschikt zijn (ps ik heb heel weinig rekenpower in de uC)
DC Balanced : evenveel 1 als 0 in de datastream/codewoord.
Forward ErrorCorrection (FEC) : Extra redundancy die het mogenlijk maakt 1 of meer bitfounten te corrigeren[/b]
Laatste berichten
-
18:43
Ervaringen met "herontdekkingen" 5
-
17:59
Gezocht: de/een naam voor een getallenrij met een cauchyrij als partieelsommenrij
-
17:39
hall effect in vloeistof gebruiken als stromingssensor 2
-
17:28
Casus uit de praktijk: positief test THC 18
-
23:58
speciale rel. theorie 4
-
17 apr
Vreemde stank in huis 11
-
17 apr
3 vragen over mijn rooskleurige r.berekening H2netGekoppeldeHBrflowbatterij.
-
17 apr
Interpretatie reactie-energie 3
-
17 apr
Logistic equation (Pierre Verhulst,Belgian Mathematician) 5
-
16 apr
vB 9
-
15 apr
Kunnen quantum Zonnecellen 190% quantum efficiënt zijn 1
-
15 apr
Python: sockets sluiten 4
-
14 apr
Een eenvoudige logische redenering waarom tijd niet kan bestaan 'daarbuiten' 6
-
14 apr
Hoe kun je op quantumwijze getallen vinden in een rij die kleiner zijn dan getal k 3
-
13 apr
Rotatie van het heelal 22
-
13 apr
Documentenverdwijnen uit onedrive 1
-
12 apr
Behoud van impulsmoment en energie 5
-
12 apr
INLOG STORING / TIPS 4
-
09 apr
[natuurkunde] systeemgrafen 1
-
05 apr
afbuiging licht rond zware objecten via grondbeginselen relativiteitstheorie 490
Nieuwsberichten
-
04 mar
Een nieuw soort magnetisme: altermagnetisme
-
31 okt
AI kan via stem diabetes vaststellen 11
-
21 okt
Einstein krijgt wéér gelijk 45
-
07 feb
witter dan wit 20
-
19 jun
irrigatie en de aardas
bitstream encoding , dc Balanced en forward error correction
Forumregels
(Middelbare) school-achtige vragen naar het forum "Huiswerk en Practica" a.u.b.
Zie eerst de Huiswerkbijsluiter
(Middelbare) school-achtige vragen naar het forum "Huiswerk en Practica" a.u.b.
Zie eerst de Huiswerkbijsluiter
-
- Berichten: 5.679
Re: bitstream encoding , dc Balanced en forward error correction
Ik zou zeggen: codeer een 0 als 01 en een 1 als 10. Dan moet je voor een 8 bit woord een 16 bit code versturen, die is altijd DC-balanced, en fouten zijn redelijk te detecteren: 00 of 11 zijn namelijk ongeldig, en beide achtereenvolgende bits moeten fout gaan wil je je vergissen.
Nog meer code bits per oorspronkelijk bit gebruiken maakt foutcorrectie mogelijk: als je bijvoorbeeld een 0 verstuurt als 001 en een 1 als 110, moet het wel erg mis gaan wil je een oncorrigeerbare én ondetecteerbare fout krijgen. Dit is natuurlijk niet 100% DC balanced, daarvoor zou je zelfs met 4 bits per bit kunnen werken: bijvoorbeeld 0
0011 en 1 
1100, wat tevens nog hogere zekerheid en errorcorrectie geeft.
Gaat het om theorie of praktijk? Want als het om een praktijkoplossing gaat zou ik het ofwel helemaal niet coderen en met checksums werken (en opnieuw sturen tot het klopt). Of als er zó veel fouten optreden dat je op die manier te vaak opnieuw moet sturen, dan iedere bit encoden als 3 bits + checksum, zodat je bij eventuele fouten eerst nog kan kijken of de triviale correcties de boel wel kloppend krijgen met de checksum, en zo niet, dan pas opnieuw sturen.
Nog meer code bits per oorspronkelijk bit gebruiken maakt foutcorrectie mogelijk: als je bijvoorbeeld een 0 verstuurt als 001 en een 1 als 110, moet het wel erg mis gaan wil je een oncorrigeerbare én ondetecteerbare fout krijgen. Dit is natuurlijk niet 100% DC balanced, daarvoor zou je zelfs met 4 bits per bit kunnen werken: bijvoorbeeld 0
0011 en 1 1100, wat tevens nog hogere zekerheid en errorcorrectie geeft.Gaat het om theorie of praktijk? Want als het om een praktijkoplossing gaat zou ik het ofwel helemaal niet coderen en met checksums werken (en opnieuw sturen tot het klopt). Of als er zó veel fouten optreden dat je op die manier te vaak opnieuw moet sturen, dan iedere bit encoden als 3 bits + checksum, zodat je bij eventuele fouten eerst nog kan kijken of de triviale correcties de boel wel kloppend krijgen met de checksum, en zo niet, dan pas opnieuw sturen.
In theory, there's no difference between theory and practice. In practice, there is.
-
- Berichten: 13
Re: bitstream encoding , dc Balanced en forward error correction
Het is een praktijk probleem, Zoals altijd is het een afweging qua keuze.
- Het is one-way communicatie, Kan geen retransmit aanvragen.
- Bandbreedte is belangrijk Dus zo veel mogenlijk databits versturen per Tijdeenheid.
En heel belangrijk ! Hoe meer (correctie/detectie)bits je toevoegt aan je stream hoe vaker biterrors zullen/kunnen optreden.
- Het is one-way communicatie, Kan geen retransmit aanvragen.
- Bandbreedte is belangrijk Dus zo veel mogenlijk databits versturen per Tijdeenheid.
En heel belangrijk ! Hoe meer (correctie/detectie)bits je toevoegt aan je stream hoe vaker biterrors zullen/kunnen optreden.
-
- Berichten: 5.679
Re: bitstream encoding , dc Balanced en forward error correction
Met one-way heb je dus nooit zekerheid dat je data goed aankomt. Dan moet je inderdaad een afweging maken, tussen de zekerheid en de snelheid waarmee je je data wil verzenden.
Logisch, als iedere bit een kans p heeft om fout te worden verstuurd, neemt de totale kans op een biterror natuurlijk toe naarmate je meer bits verstuurt. Of bedoel je zelfs dat p (de foutkans per bit) groter wordt naarmate je meer bits verstuurt?En heel belangrijk ! Hoe meer (correctie/detectie)bits je toevoegt aan je stream hoe vaker biterrors zullen/kunnen optreden.
In theory, there's no difference between theory and practice. In practice, there is.
-
- Berichten: 13
Re: bitstream encoding , dc Balanced en forward error correction
De data die ik verstuur zijn Blokken van zeg 64 tot 256 Bytes die keuze ligt nog niet vast. In deze blokken zit gelukkig een 8bit CRC.
De error detectie is dus hoog. Maar als er 1 bit omvalt in de transmissie is m´n hele blok naar de knoppen zonder fec.
Helaas weet ik op het moment te weining van de transmissie eigenschappen van het RF kanaal, De keuzes die ik maak moeten daar natuurlijk wel bij passen. Ik moet die nog in een testopstelling meten.
BitErrorRate zal denk ik slechter dan 10^-3 zijn
De error detectie is dus hoog. Maar als er 1 bit omvalt in de transmissie is m´n hele blok naar de knoppen zonder fec.
Helaas weet ik op het moment te weining van de transmissie eigenschappen van het RF kanaal, De keuzes die ik maak moeten daar natuurlijk wel bij passen. Ik moet die nog in een testopstelling meten.
BitErrorRate zal denk ik slechter dan 10^-3 zijn
Re: bitstream encoding , dc Balanced en forward error correction
Zou het niet simpel zijn om gewoon je 8-bits codewoord te coderen met Hamming (= 12 bits) en dan gewoon 4 nullen achteraan toevoegen. En bekijk dan enkel de eerste 12 bits? Simpel en effectief toch?
Greets
Greets
Re: bitstream encoding , dc Balanced en forward error correction
Met 8 bits als data zijn er maar 256 mogelijke resultaten,
dus bereken je ze eerst allemaal met de PC en plaatst die
dan in een tabel van 256 * 16 bits in je µP. Dan moet je
enkel maar via een index twee bytes opzoeken en versturen.
Steve
dus bereken je ze eerst allemaal met de PC en plaatst die
dan in een tabel van 256 * 16 bits in je µP. Dan moet je
enkel maar via een index twee bytes opzoeken en versturen.
Steve
-
- Berichten: 5.679
Re: bitstream encoding , dc Balanced en forward error correction
Ten eerste heb je dan hetzelfde probleem voor de index, want hoe krijg je die met voldoende zekerheid en snelheid verzonden. En ten tweede: hoe groot denk je dat zo'n index is, in vergelijking tot de oorspronkelijke bytes?Steve schreef:Met 8 bits als data zijn er maar 256 mogelijke resultaten,
dus bereken je ze eerst allemaal met de PC en plaatst die
dan in een tabel van 256 * 16 bits in je µP. Dan moet je
enkel maar via een index twee bytes opzoeken en versturen.
In theory, there's no difference between theory and practice. In practice, there is.
Re: bitstream encoding , dc Balanced en forward error correction
Niemand die mijn antwoord goed vindt?
-
- Berichten: 13
Re: bitstream encoding , dc Balanced en forward error correction
Je antwoord is zeker goed, echter effectief proberen we net een trede hoger te zien. Je voegt 4 nullen aan het eind toe die geen echte informatie bevatten wat INeffectief is (in dit geval) .Niemand die mijn antwoord goed vindt?
Wat ik zoek is een Simple techniek (ik gebruik een kleine uController <1Kram <4Krom)
Dit zijn eigenlijk de Documenten waar het antwoord in verborgen zit echter voor mij heel slecht leest (erg wiskundig)
A New Class of (2 p )B(2 p +1)B dc Balanced Line Codes : http://www.hpl.hp.com/techreports/98/HPL-98-46.pdf
Performance of Efficient Balanced Codes : http://www.exp-math.uni-essen.de/~immink/pdf/efbal.pdf
Uses of channel codes and Checksums to improve Wireless Communication: http://www.tkn.tu-berlin.de/publications/p...pers/frame1.pdf
Re: bitstream encoding , dc Balanced en forward error correction
Het beste is om al je data 3 keer te verzenden waarbij er ook nog eens volgorde markeerders geplaatst worden.
Deze volgorde markeerders kunnen ook fouten oplopen zodat deze ook 3 dubbel verzonden moeten worden.
Na een complete sessie kan men de data gelijk trekken en kijken of de datablokjes overeenkomen.
2-2-2 is 2
2-2-9 is 2 want 9 zal wel foutief zijn geweest.
Als de data verzending 3 seconde duurt kan de zender zelfs 1 seconde uit de lucht gaan terwijl de boel nog goed aankomt.
Men moet rekening houden dat de foutcode ook fout kan gaan.
Als een wiskundige zegt dat voor een goede overdracht van 8 bits maar 12 bits nodig is dan vergeet hij dat de code om te controleren ook fout kan gaan.
Dus gebruik 3*8 plus coderingen voor de datavolgorde plus foutcodering voor de datavolgorde.
En voor nog betere overzending gewoon meervoudig zenden.
Deze volgorde markeerders kunnen ook fouten oplopen zodat deze ook 3 dubbel verzonden moeten worden.
Na een complete sessie kan men de data gelijk trekken en kijken of de datablokjes overeenkomen.
2-2-2 is 2
2-2-9 is 2 want 9 zal wel foutief zijn geweest.
Als de data verzending 3 seconde duurt kan de zender zelfs 1 seconde uit de lucht gaan terwijl de boel nog goed aankomt.
Men moet rekening houden dat de foutcode ook fout kan gaan.
Als een wiskundige zegt dat voor een goede overdracht van 8 bits maar 12 bits nodig is dan vergeet hij dat de code om te controleren ook fout kan gaan.
Dus gebruik 3*8 plus coderingen voor de datavolgorde plus foutcodering voor de datavolgorde.
En voor nog betere overzending gewoon meervoudig zenden.
