Fout controle / correctie - Kleine verpakkingen

[atferrari]

Ik ben het koppelen van twee micro's via infrarood, een manier alleen, zodat herhaling kan niet worden gevraagd aan de zender.

Ik gebruik de Sony's SIRC protocol.Snelheid is hetzelfde gebruikt voor afstandsbedieningen voor huishoudelijke apparaten.

Wat is ontvangen veranderd moet worden weggegooid of gecorrigeerd (?).

Ik heb het lezen van een partij te beginnen met pariteit check, check, Hamming-code, FEC, SECDEC en meer.

<img src="http://www.edaboard.com/images/smiles/icon_cry.gif" alt="Huilen of zeer triest" border="0" />Mijn zorg: wat moet het evenwicht tussen de kleine omvang van het bericht (een, uiteindelijk twee verpakkingen met commando's) en uiteindelijk robuust maar lange en complexe routines die vertraging (?) Veel van het proces.

Hoewel ik wil dat alle eenvoudige, ook ik wil het roubust genoeg.

Het
is net een robot, maar ik wil het goed draaien.Elke regel van de duim?

Herhaling van de verpakkingen drie of vijf keer voor de meerderheid van stemmen, is het dan een optie?

Veranderen van de volgorde en de hoeveelheid verpakkingen verstuurd kan worden gedaan elk moment, maar mijn probleem is er niet.

Sorry als ik het goed vaag, maar hebben geen ervaring.

Opmerkingen / suggesties anyone?Muchas gracias

Agustín Tomás

 

[Buriedcode]

Hallo weer atferrari,

Een tijdje geleden heb ik geëxperimenteerd met een draadloze digitale audio systeem.Zien als ik nodig had was RF sommige foutcorrectie (het was een manier comms en) en enkele detectie.Ik gebruikte [13,8] Hamming codes, uitgevoerd in pure logica (sequentieel
en niet parallel, de XOR-boom werd massaal).Het kan juist een fout in een 13-bits pakket, en het detecteren van 2.Echter, de beperkingen van het systeem waren latentietijden <1ms, en alles moest gebeuren in pure logica (CPLD).

Het feit dat je een PIC micro te spelen, met al haar geheugen / logische functies betekent dat je gemakkelijk zou kunnen gaan voor een meer gecompliceerde systeem.(vergeleken met een 64 MC cpld, de PIC micro is veel beter)

De 'Hamming codes' zijn niet fantastisch in hun correctie vermogen, maar het feit dat zij hebben foutdetectie en middelen kunt u uw link.Bijvoorbeeld, met de [8,4] Hamming-code, kunt u 1 op de 8 fouten (4 bits check bits) en u kunt detecteren 2 in 8, dat is 1 op 4.Hoewel het verdubbelt de hoeveelheid data die u verstuurt (en verdubbelt het risico van een fout, aangezien u door meer data te sturen)
en dat kan erg nuttig zijn bij het experimenteren met uw link.Gewoon je een test circuit, met het maximale bereik van uw link, en een draad die van Rx naar Tx, zodat de Tx stuurt de gegevens via infrarood, de RX verzamelt, en stuurt ongeacht de ontvangen (samen met eventuele fouten ) terug naar de zender.Dan kon je net XOR de twee bytes te vergelijken.Eigenlijk hebben een teller, die stuurt 0-255, en doen dit 255 keer.
Dus het aantal pakketten die u verzendt, worden (65025).Increment een loket voor elke fout die u ontvangt.Zodra deze klaar is, net zien hoeveel fouten je hebt en het werk van de 'Bitfoutenkans' (GVV is geen' bit error rate ').Dan probeer dit met een ruwe FEC algoritme.De RX beslist zij vóór haar terug naar de Tx, en de Tx weer de vergelijking met wat zij verzonden.Als de fouten toenemen, dan is het FEC algoritme doet meer kwaad dan goed.Maar het zou een aanzienlijke vermindering van de fouten, tenzij je een echte slechte IR link.

Maar goed, dat is hoe ik mijn koppeling getest, en ik heb ongeveer 1 in 1000 bits in fout, ik denk niet dat uw link wordt zo slecht als dat wel.Ik ben ook links de test uitgevoerd voor 2 uur (ongeveer 140 miljoen pakketten verstuurd), maar de fout tegen overflowed.

Citaat:

Wat is ontvangen veranderd moet worden weggegooid of gecorrigeerd (?).