Springen naar inhoud

bitstream encoding , dc Balanced en forward error correction


  • Log in om te kunnen reageren

#1

FrostByte

    FrostByte


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 30 juni 2005 - 09:37

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]

Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

Rogier

    Rogier


  • >5k berichten
  • 5679 berichten
  • VIP

Geplaatst op 30 juni 2005 - 09:57

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 :oops: 0011 en 1 :shock: 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.

#3

FrostByte

    FrostByte


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 30 juni 2005 - 10:39

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.

#4

Rogier

    Rogier


  • >5k berichten
  • 5679 berichten
  • VIP

Geplaatst op 30 juni 2005 - 10:44

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.

En heel belangrijk ! Hoe meer (correctie/detectie)bits je toevoegt aan je stream hoe vaker biterrors zullen/kunnen optreden.

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?
In theory, there's no difference between theory and practice. In practice, there is.

#5

FrostByte

    FrostByte


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 30 juni 2005 - 10:55

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

#6


  • Gast

Geplaatst op 30 juni 2005 - 22:25

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

#7


  • Gast

Geplaatst op 01 juli 2005 - 11:47

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

#8

Rogier

    Rogier


  • >5k berichten
  • 5679 berichten
  • VIP

Geplaatst op 01 juli 2005 - 13:09

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.

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? :shock:
In theory, there's no difference between theory and practice. In practice, there is.

#9


  • Gast

Geplaatst op 01 juli 2005 - 18:01

Niemand die mijn antwoord goed vindt?

#10

FrostByte

    FrostByte


  • 0 - 25 berichten
  • 13 berichten
  • Gebruiker

Geplaatst op 09 juli 2005 - 13:01

Niemand die mijn antwoord goed vindt?


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) .

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.co...8/HPL-98-46.pdf
Performance of Efficient Balanced Codes : http://www.exp-math....k/pdf/efbal.pdf
Uses of channel codes and Checksums to improve Wireless Communication: http://www.tkn.tu-be...pers/frame1.pdf

#11


  • Gast

Geplaatst op 10 juli 2005 - 19:08

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.





0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures