[Binaire Sequences] Codes herkennen

[wexel]

Beste Tweakers,

Ik ben bezig met I.R. led die herkend worden door een camera.
De I.R. leds zenden een binaire code uit die de camera dan ontvangt.
Elk I.R ledje heeft zijn eigen identiteit en dus code.

Ik heb onderzoek gedaan naar verschillende binaire sequensces.
Zo kwam ik op bijvoorbeeld de Gold, Kasami en Barker sequence / codes.
De codes hiervan kunnen dan beter uit elkaar gehouden worden wat voor minder fouten / snellere herkenning zorgt.

Nu vraag ik me af hoeveel verschillende codes er binnen een seconde herkend kunnen worden van deze sequences. Hierbij loop ik namelijk bij in de knoop.

De camera heeft 30 FPS.
Om een code te herkennen en een overlap tussen frames te voorkomen zeggen ze dat je 2 keer of veiliger 3 keer langzamer je code moet uitzenden.
Voor 30 frames/sec heb je dan dus maar 10 tot 15 1'en of 0'en die opgenomen worden door de camera.

Kan iemand mij hierbij helpen?
Ik ben opzoek naar een uitleg van de berekening, zodat ik die zelf kan maken of dat jullie die toelichting. Hoeveel mogelijkheden zijn er dus met die verschillende binaire sequences te maken?

Alvast bedankt! Groet

P.S. Mijn vraag is misschien een beetje O.T. excuus hiervoor wanneer dit het geval is

[FireDrunk]

Misschien is de vraag wel: Waarom wil je IR met een Camera opnemen, en niet met een IR ontvanger?

[RobIII]

wexel schreef op dinsdag 16 april 2013 @ 17:21:
Nu vraag ik me af hoeveel verschillende codes er binnen een seconde herkend kunnen worden van deze sequences. Hierbij loop ik namelijk bij in de knoop.

De camera heeft 30 FPS.

In 't beste geval 30 bits; en je geeft zelf al aan dat je die 30 bits nooit (veilig) kunt halen (tenzij je een sync-signaal o.i.d. zou hebben).

wexel schreef op dinsdag 16 april 2013 @ 17:21:
Ik ben opzoek naar een uitleg van de berekening, zodat ik die zelf kan maken of dat jullie die toelichting. Hoeveel mogelijkheden zijn er dus met die verschillende binaire sequences te maken?

2^{aantal_bits_ontvangen} / tijdseenheid

Als je 10 bits per seconde kunt ontvangen kun je dus 2¹⁰ = 1024 verschillende codes ("mogelijkheden") ontvangen (of sturen, hoe je wil) per seconde. En dan ga je uit van 0 CRC of anderssoortige verificatie ("overhead") van je "frames". Ik denk, maar ik ben geen kenner, dat je iets als Reed Solomon o.i.d. kunt gebruiken. Je kunt, over het geheel, nog wat compressie gooien bij grotere/langere 'berichten' om nog wat extra "doorvoersnelheid" te winnen.

Maar verder sluit ik me aan bij FireDrunk: WHY?

[ Voor 26% gewijzigd door RobIII op 16-04-2013 17:51 ]

[wexel]

Bedankt voor de snelle reacties

FireDrunk schreef op dinsdag 16 april 2013 @ 17:23:
Misschien is de vraag wel: Waarom wil je IR met een Camera opnemen, en niet met een IR ontvanger?

Ik ben student productontwikkeling / industrieel ontwerpen en ben bezig met een nieuwe bedieningsmethode voor de computer. Om de computermuis over te nemen heb ik een camera nodig. Het zichtpunt van de camera (midden) wordt berekend ten opzichte van het scherm, dit wordt dan vertaald naar een muispointer op het scherm. Deze camera gebruik ik dan meteen om deze I.R. codes te ontvangen. Het wordt naast een computerpointer ook gelijk een domotica selectiesysteem. De I.R. leds worden aan deuren / lichten / ramen / multimedia gekoppeld. Vandaar dat ik een camera nodig heb en hiermee gelijk de I.R. signalen mee ga ontvangen. (hoop dat het een beetje duidelijk is zo)

RobIII schreef op dinsdag 16 april 2013 @ 17:43:
[...]

In 't beste geval 30 bits; en je geeft zelf al aan dat je die 30 bits nooit (veilig) kunt halen (tenzij je een sync-signaal o.i.d. zou hebben).


[...]


2^{aantal_bits_ontvangen} / tijdseenheid

Als je 10 bits per seconde kunt ontvangen kun je dus 2¹⁰ = 1024 verschillende codes ("mogelijkheden") ontvangen (of sturen, hoe je wil) per seconde. En dan ga je uit van 0 CRC of anderssoortige verificatie ("overhead") van je "frames". Ik denk, maar ik ben geen kenner, dat je iets als Reed Solomon o.i.d. kunt gebruiken. Je kunt, over het geheel, nog wat compressie gooien bij grotere/langere 'berichten' om nog wat extra "doorvoersnelheid" te winnen.

Mijn studie focust niet op programmeren (als ik het zo mag noemen ) ik ben dus zeker geen pro hierin, maar wat ik ervan begrijp is dus dat je met 10 bits veilig zit en 1024 verschillende codes kan maken in een tijdsduur van 1 seconde. Hebben de codes die ik noemde (Kasami / Gold etc.) hier dan nog invloed op? dat ik bijvoorbeeld maar de helft aan codes kan gebruiken zodat ze sterk van elkaar verschillen? Dit bedoel je zeker met CRC / overhead? Dat die 1024 zonder zo'n code is.

De laatste zin:

'Je kunt, over het geheel, nog wat compressie gooien bij grotere/langere 'berichten' om nog wat extra "doorvoersnelheid" te winnen'

Gaat mijn petje een beetje te boven hier snap ik niet veel van.

Ik zal eens kijken wat Reed Solomon is.

Ben vooral op zoek naar een getal, zodat ik kan aanwijzen dat ik genoeg aantal codes heb.

Als je mij hiermee nog kan helpen zal ik je eeuwig dankbaar zijn
Anders ook super bedankt het is allemaal weer wat helderder geworden

[RocketKoen]

Als je een computer met een webcam gebruikt als ontvanger. Dan is het misschien praktischer om je remote gewoon over BT of wifi te laten werken.
Wat je nu wil is op zn minst enorm onpraktisch.
Een webcam is geen goede ontvanger, en IR is niet praktisch vanwege de line-of-sight. Ook huisdieren die wel IR kunnen zien gaan jouw ontwerp niet leuk vinden.

[Mavamaarten]

Met een camera en IR leds gaat het niet erg ver komen qua gebruiksvriendelijkheid, vrees ik.
Is het niet makkelijker om een bestaand iets te gebruiken, à la Leap?

EDIT: Whoops, had even naast het idee van de deuren etc gekeken.

[ Voor 14% gewijzigd door Mavamaarten op 16-04-2013 18:36 ]

[RobIII]

wexel schreef op dinsdag 16 april 2013 @ 18:19:
Mijn studie focust niet op programmeren (als ik het zo mag noemen ) ik ben dus zeker geen pro hierin, maar wat ik ervan begrijp is dus dat je met 10 bits veilig zit

Dat is nergens gezegd (door mij); het is een natte-vinger schatting die ook op 5 of 29 zou kunnen uitkomen.

wexel schreef op dinsdag 16 april 2013 @ 18:19:
1024 verschillende codes kan maken in een tijdsduur van 1 seconde

Aangenomen dat je dus 10FPS zonder fouten kunt ontvangen ja; maar je zult altijd wat overhead hebben door controlebits / "frame separators" (if any) etc.

wexel schreef op dinsdag 16 april 2013 @ 18:19:
Hebben de codes die ik noemde (Kasami / Gold etc.) hier dan nog invloed op?

Geen idee maar ga er maar van uit dat alles dat je toevoegt ter "stabilisering" of "verbetering" van je signaal je ook overhead kost dus: ja, geheid.

wexel schreef op dinsdag 16 april 2013 @ 18:19:
dat ik bijvoorbeeld maar de helft aan codes kan gebruiken zodat ze sterk van elkaar verschillen? Dit bedoel je zeker met CRC / overhead? Dat die 1024 zonder zo'n code is.

Jep.

wexel schreef op dinsdag 16 april 2013 @ 18:19:
'Je kunt, over het geheel, nog wat compressie gooien bij grotere/langere 'berichten' om nog wat extra "doorvoersnelheid" te winnen'

Gaat mijn petje een beetje te boven hier snap ik niet veel van.

Als je 5MB probeert te versturen via je IR -> Webcam (lees 41.943.040 bits ofwel ~48,5 dagen bij 10bps voordat 't ontvangen is, en dat is nog gerekend zonder overhead) dan kan 't zich lonen om je data eerst te "zippen" om maar even in jip-en-janneke te blijven. Als je de data kunt comprimeren tot 25% dan ben je opeens nog maar 12 dagen kwijt
Compressie zal echter, bij (erg) kleine berichten (lees: "codes" in jouw geval, bijvoorbeeld "A" voor raam open, "B" voor raam dicht) in eerste instantie alleen maar extra data opleveren; je zult een break-even moeten evenaren om iets aan die compressie te hebben.

RocketKoen schreef op dinsdag 16 april 2013 @ 18:27:
Ook huisdieren die wel IR kunnen zien gaan jouw ontwerp niet leuk vinden.

Zullen we dan ook maar meteen alle afstandsbedieningen afschaffen? Of, hell, gewoon (lampen/zon/...) licht?

[ Voor 6% gewijzigd door RobIII op 16-04-2013 18:37 ]

[wexel]

RocketKoen schreef op dinsdag 16 april 2013 @ 18:27:
Als je een computer met een webcam gebruikt als ontvanger. Dan is het misschien praktischer om je remote gewoon over BT of wifi te laten werken.
Wat je nu wil is op zn minst enorm onpraktisch.
Een webcam is geen goede ontvanger, en IR is niet praktisch vanwege de line-of-sight. Ook huisdieren die wel IR kunnen zien gaan jouw ontwerp niet leuk vinden.

Ik zal het even kort verduidelijken, er zijn nog wat essentiele punten die ik niet heb vermeld.
De techniek is via wat engineers naar mij toegekomen.
De bedieningsmethode is voor mensen met een zware beperking die alleen nog maar hun hoofd kunnen bewegen. De camera wordt dan in een brilvorm verwerkt zodat deze mensen hun computer nogsteeds kunnen gebruiken. Linker en rechtermuisknop zal met het knipperen van het linker en het rechter oog gaan werken. Huidige systemen zijn momenteel veel minder gebruiksvriendelijk.

Voor een valide persoon zal deze bedieningsmethode dus niet gebruikt worden, maar voor de minder validen is het een stap voorwaarts.

en @ RobIII bedankt voor je uitleg. Jip en janneke style heeft geholpen voor mij

[RobIII]

Juist voor minder validen zou ik geen IR gebruiken (want: line of sight vereist _{met een piepkleine tolerantie voor bouncing signalen}). Juist in zo'n geval wil je iets van BT ofzo gebruiken dat de nodige meters haalt, ook zonder line-of-sight. Ik ben geen signaal-expert ofzo dus er zijn mogelijk nog andere alternatieven (hell, voor mijn part FM ), maar IR is wel 't laatste waar ik aan zou denken. Een BT dongle (die je dan nodig zou hebben aan de PC kant iig) kost je een hele 5 euro (en geheid (veel) minder als je ze in bulk inkoopt) en in ruil krijg je een applicatielaag waar je tegenaan kunt lullen, zit je niet te frotten met (dure) webcams en signaalverwerking en ga zo maar door. Ik zou dan ook heel graag de reden van "wat engineers" horen om met IR op de proppen te komen. Misschien is er nog iets dat we niet weten?

Je zult moeten 'detecteren' of een oog open/dicht is, maar daar lijken me ook vele betere methoden voor beschikbaar die geen "webcam in een bril" vereisen (reflecteer bijv. een licht op de oogballen en meet de teruggekaatste lichtsterkte; bij pieken/dalen in dat signaal kun je waarschijnlijk stellen dat er geknipperd is met het oog). En stuur dan via BT dat signaal over. Zoiets. Maar ik ben geen industrieel ontwerper

Verder heb je dus eigenlijk, in den beginne, maar 2 signalen: linker- en rechtermuisknop zoals ik je nu begrijp. Laat daar nog eens een handvol, hell, 100 signalen bijkomen. Die kun je allemaal prima versturen op de houtje-touwtje methode die je nu hebt in < 1 sec (again: natte-vinger-werk / schatting). Met BT verstuur je in 1 seconde al gauw 2.1Mbit => 262.5KBps. Dat zijn een héle, hééééééle boel codes

[ Voor 70% gewijzigd door RobIII op 16-04-2013 19:02 ]

[RocketKoen]

RobIII schreef op dinsdag 16 april 2013 @ 18:32:
[...]
Zullen we dan ook maar meteen alle afstandsbedieningen afschaffen? Of, hell, gewoon (lampen/zon/...) licht?

lampen en zon knipperen niet met 30Hz. en een afstandsbediening stuurt niet constant signalen enzo.

wexel schreef op dinsdag 16 april 2013 @ 18:43:
[...]


Ik zal het even kort verduidelijken, er zijn nog wat essentiele punten die ik niet heb vermeld.
De techniek is via wat engineers naar mij toegekomen.
De bedieningsmethode is voor mensen met een zware beperking die alleen nog maar hun hoofd kunnen bewegen. De camera wordt dan in een brilvorm verwerkt zodat deze mensen hun computer nogsteeds kunnen gebruiken. Linker en rechtermuisknop zal met het knipperen van het linker en het rechter oog gaan werken. Huidige systemen zijn momenteel veel minder gebruiksvriendelijk.

Voor een valide persoon zal deze bedieningsmethode dus niet gebruikt worden, maar voor de minder validen is het een stap voorwaarts.

en @ RobIII bedankt voor je uitleg. Jip en janneke style heeft geholpen voor mij

Als je een webcam wilt gebruiken voor het herkennen van voorwerpen, plak er dan QR codes op.

Verder is er voor bril bediening ook al een interessante techniek, eye-tracking. Dat mik je een 2e camera op het oog en kun je berekenen waar iemand precies naar kijkt.

Voor digitale communicatie is IR in ieder geval niet heel erg geschikt.

[wexel]

Beste allen die gereageerd hebben.
Een aantal van jullie voorstellen hebben de revue ook gepasseerd.
Een QR code bijvoorbeeld ook. Deze was afgevallen d.m.v. zichtbaarheid in schemer / donker.

Ik dank jullie allen voor jullie input en jullie snelle reacties.
Misschien dat ik het principe niet duidelijk genoeg heb verwoord en dat er hierdoor veel vragen over zijn.
Het is alleen een beetje off topic gegaan heb ik het idee

Wikipedia zegt bij de Kasami code het volgende:

The process of generating a Kasami sequence is initiated by generating a maximum length sequence a(n), where n=1..2N-1. Maximum length sequences are periodic sequences with a period of exactly 2N-1. Next, a secondary sequence is derived from the initial sequence via cyclic decimation sampling as b(n) = a(q*n), where q = 2N/2+1. Modified sequences are then formed by adding a(n) and cyclically time shifted versions of b(n) using modulo-two arithmetic, which is also termed the exclusive or (xor) operation. Computing modified sequences from all 2N/2 unique time shifts of b(n) forms the Kasami set of code sequences.

heeft iemand een idee of hier een getal uit te halen is voor het aantal codes die uit 1024 codes kunnen komen?

Excuses als ik teveel vraag, maar is snap er vrij weinig van =/

[RobIII]

wexel schreef op dinsdag 16 april 2013 @ 20:26:
Misschien dat ik het principe niet duidelijk genoeg heb verwoord en dat er hierdoor veel vragen over zijn.

Dan is dat dus een verbeterpunt en je weet de (quick)reply al te vinden dus: wat let je 't beter te verwoorden / te verduidelijken?

wexel schreef op dinsdag 16 april 2013 @ 20:26:
Het is alleen een beetje off topic gegaan heb ik het idee

Helemaal niet IMHO. Ik weet niet hoe "vast" de plannen al zijn, maar als je nog in een erg vroege fase zit dan is 't, mogelijk en op basis van de (wat je zelf zegt, gebrekkige / onvolledige / verkeerd begrepen) informatie die we hebben, misschien een signaal dat je even terug naar de tekentafel moet omdat je (mogelijk) een verkeerde afslag hebt genomen. Hopelijk ben je er dan nog vroeg bij en zit je nog in een fase waarin je dat kunt corrigeren. Nogmaals: ik begrijp waarschijnlijk maar de helft van de opdracht wegens deze gebrekkige informatie en ik ben al helemaal geen "signal processing" expert (verre van), maar ik heb wel heel sterk 't gevoel dat de huidige opzet erg houtje-touwtje is en uit mijn bezorgdheid gewoon (evenals anderen).

wexel schreef op dinsdag 16 april 2013 @ 20:26:
Wikipedia zegt bij de Kasami code het volgende:

Laten we eens beginnen waarom je überhaupt bij "Kasami code" bent uitgekomen voordat we gaan rekenen? Waarom juist die? Wat is voor jou aanleiding / trefwoord / zoekresultaat geweest om naar Kasami te gaan kijken? In welke gedachtengang zit je?

wexel schreef op dinsdag 16 april 2013 @ 20:26:
Excuses als ik teveel vraag, maar is snap er vrij weinig van =/

Nogmaals, en ik zeg dit niet om de lul uit te hangen, wel een signaal dat je misschien even een stapje terug moet doen zodat je in materie terecht komt waar je wél / beter in thuis bent. Wie weet, uiteindelijk kom je misschien alsnog wel bij Wasabi code ( ) uit, maar dan heb je wel een onderbouwde keuze gemaakt en niet gekozen voor iets dat in de verte leek op iets wat je misschien zou kunnen gebruiken. Je kunt een schoen prima gebruiken om een spijker in een muur te slaan maar een hamer is wel zo handig if you get my drift

Al wat ik zo snel kan vinden over die Kawasaki code ( ) is dat 't schijnbaar overal achter slot-en-grendel moet want ik moet overal een account aanmaken als ik meer wil weten en dat er klaarblijkelijk hele boeken over geschreven zijn. En als ik dan al iets concreets tegen kom dan staat 't zo vol met formules dat m'n hoofd er van begint te duizelen Wat ik zo uit de flarden tekst her-en-der begrijp is dat 't schijnbaar heel handig is bij storingsgevoelige (analoge) signaalverwerking, maar daar houdt 't dan ook op. Het kan aan mij liggen maar dat lijkt mij waaaay overkill om "Rood" of "Blauw" of "0" of "1" of "Links" of "Rechts" door te sturen zonder al te gevoelig te zijn voor interferentie.

wexel schreef op dinsdag 16 april 2013 @ 20:26:
Een QR code bijvoorbeeld ook. Deze was afgevallen d.m.v. zichtbaarheid in schemer / donker.

Zet er een IR-lichtje op Werkt prima, zelfs met een doorsnee el-cheapo webcam.

[ Voor 16% gewijzigd door RobIII op 16-04-2013 21:07 ]

[wexel]

Het is lastig om het totaalconcept uit te leggen zonder al teveel vertrouwelijke informatie vrij te geven.
Niet dat ik het hier niet vertrouw maar meer om normale veiligheidsredenen.
Ik ben sinds september bezig met dit project en in juni wordt dit afgerond.
Ik heb me tijdens het proces laten begeleiden door een engineer die gedoctereerd is in de zorgsector.
Van hem heb ik dus veel 'aangenomen'

Na heel wat trade-offs en ontwerpprocessen zijn we terecht gekomen op een werkende techniek die werkt met I.R. leds die hun ID uitstralen op enkel de momenten wanneer de gebruiker deze gaat 'selecteren' en bedienen.

Omdat mijn begeleider expert is op dit gebied neem ik aan dat hij de waarheid spreekt dan is de vraag waarom stel ik de vraag niet simpelweg aan hem? Dat is omdat hij het al een keer deels heeft uitgelegd. Vandaar dat ik op de Kasami code, Gold code etc ben gekomen. Hij heeft een voorzetje gegeven maar ik kwam er ook met dat voorzetje niet uit. Daarom stelde ik de vraag hier =)

RobIII schreef op dinsdag 16 april 2013 @ 20:54:

Zet er een IR-lichtje op Werkt prima, zelfs met een doorsnee el-cheapo webcam.

wordt de QR code dan met infrarood licht belicht (niet zichtbaar voor ons) maar voor de camera is de QR code dan wel zichtbaar? Dat is wel een interessant punt. Is hier dan een krachtige IR lamp voor nodig zeker? Het moet wel nog op het hoofd / bril van de gebruiker passen. Zodat het IR verlichtte onderdeel in 1 lijn licht met het zichtpunt van de camera

[RobIII]

wexel schreef op woensdag 17 april 2013 @ 13:22:
Van hem heb ik dus veel 'aangenomen'
...
Omdat mijn begeleider expert is op dit gebied neem ik aan dat hij de waarheid spreekt

Assumptions are the mother of all fuckups
Goed; als jij/hij zegt dat dat 't beste is moeten we dat maar voor waar aannemen. Ik zie niet direct hoe "veiligheidsredenen" of "vertrouwelijke informatie" in 't spel zouden komen als je simpelweg het (totaal)concept goed beschrijft, maar misschien verklap je inderdaad wel een gat in de markt waar massaal op ingesprongen wordt voordat jullie de eerste sale hebben gemaakt. Ook dat kunnen we niet inschatten vanuit hier. Maar meer/duidelijke(re) informatie is wel héél handig en zal ook voor een veel beter "antwoord" (al dan niet bevredigend, dat is altijd een 2e ) zorgen op je vraag/zorg.

wexel schreef op woensdag 17 april 2013 @ 13:22:
wordt de QR code dan met infrarood licht belicht (niet zichtbaar voor ons) maar voor de camera is de QR code dan wel zichtbaar? Dat is wel een interessant punt. Is hier dan een krachtige IR lamp voor nodig zeker? Het moet wel nog op het hoofd / bril van de gebruiker passen. Zodat het IR verlichtte onderdeel in 1 lijn licht met het zichtpunt van de camera

Tja, God, daar vraag je me wat. Ik ben ook maar een simpele devver Wat weet ik nou van IR en hoeveel watt/lumen/weet-ik-het je nodig hebt om iets te "verlichten" zodat 't goed zichtbaar is voor een camera. M'n boeren verstand zegt van wel. Op wat gefröbel in m'n tienerjaren met (IR)LEDjes / IR-"oogjes" en ge-hobby-Bob met een webcam en IR verlichting een paar jaar terug na heb ik totaal geen wetenschappelijk onderbouwde mening. Maar mijn gut feel zegt me wel dat als je een IR lichtje op een bril monteert dat 't nooit verder dan een paar cm hooguit van het "te verlichten object" (ooglid?) verwijderd zal zijn en dat je dus waarschijnlijk geen 60watt hoeft te hebben (en dat een enkel "LEDje" dan waarschijnlijk dus wel volstaat. Hoe je die QR-codes dan voor je ziet (op 't ooglid plakken? Tatoeëren? ) is een tweede. Ik zou (nogmaals: zoals ik 't nu begrijp) eens kijken of je niet heel makkelijk onderscheid kunt maken "in signaal" tussen oog open/dicht als je gewoon IR licht reflecteert op de oogbal/ooglid zoals ik eerder zei. Dat scheelt geplak op de ogen en komt dus uiteindelijk neer op een simpele LED + 'ontvanger' (IR gevoelige diode?). Anderhalf kwartje materiaalkosten (+montuur, batterij etc.), lage (stroom)verbruikskosten, laag gewicht en ga zo maar door. Als je dan een signaalverschil kunt meten (bijv. X volt bij oog open, Y volt bij oog dicht, thresholdje erop, spelen met een hysterese) ben je de man. Signaaltje naar BT controller die 't naar de PC stuurt en done. Sterker: laat de PC lekker bepalen of 'n oog open/dicht is, laat gewoon een constante stroom van gegevens (bijv. het gemeten voltage van de lichtgevoelige diode) naar de PC lopen. A) Weet je meteen dat "de bril online is" en wanneer 'ie uit of buiten bereik gaat en B) kun je 'tweaks' in software doen ("calibreren") i.p.v. dat je 't "in de bril in de hardware" bakt.

Maar again: dat zijn allemaal woorden van een lutser met twee linker handen die wel eens een soldeerboutje heeft gehanteerd en op een blauwe maandag een jaartje electronica op MTS niveau gestudeerd heeft en die ook maar een duit in 't zakje doet op basis van gebrekkige informatie, gebrekkig begrip etc.

[ Voor 7% gewijzigd door RobIII op 17-04-2013 14:18 ]

[__fred__]

Kasami en Gold coderingsschema's worden gebruikt om binaire codes uit elkaar te houden, voor het geval ze door elkaar gaan lopen. Deze coderingen worden bijvoorbeeld gebruikt bij het coderen van radiosignalen van GSM om ze daarna beter te kunnen (de)multiplexen.

Volgens mij heb jij geen probleem dat eventuele infrarood signalen door elkaar gaan lopen, om wille van het feit dat je IR-transmitters op verschillende pixels van je camera terecht komen. Je zou dit wel hebben bij een gewone IR-ontvanger, omdat dan meerdere signalen door elkaar kunnen gaan lopen, en je dat wel moet detecteren.

Een simpele Reed Solomon is voor jou dus prima. Eerdere suggesties zijn al gedaan, maar bij een ideaal gesynchroniseerd signaal zou je 30 bits per seconde kunnen halen. Dat is je signaal niet, dus doe dan sowieso maar een factor 2 a 3 benodigde frames per bit, dus 10 bits per seconde. Dan nog je Reed Solomon eroverheen, daar zijn verschillende varianten van, maar 8 bits dus 1 byte per seconde lijkt me realistisch.

[wexel]

Hey RobIII en Fred

Thanks voor jullie antwoorden.
Het zet me weer even aan het denken en zo kom ik weer verder =)
Ik denk dat ik dan de Reed Solomon erover gooi en kijken hoeveel codes ik over houd.

En btw RobIII over de 'vertrouwelijke informatie' ik heb zelf ook geen idee hoe ik er mee om moet gaan. Laat staan dat het daadwerkelijk gat-in-de-markt-potentie heeft. Dat denk ik eerlijk gezegd niet. Ik ben gewoon een beetje voorzichtig