Ik heb gisteren een eindje gefietst en rustig kunnen nadenken.
Je gaat het mechanisch/optisch niet voor mekaar krijgen dat op een afstand van meer dan 20cm iedere led op maar 1 ontvanger schijnt.
Dus.. Wat je doet is je zet alle zendende leds in een matrix zodat je ze individueel kan aansturen. (een andere optie is om een groot schuifregister te maken, daar een enkel bitje in te schuiven en dan met de enable de 38kHz gaan maken.).
Nu zet je alle sensoren parallel: Je hebt maar 1 enkel bitje om uit te lezen. Dit werkt als iedere led precies 1 sensor aanstuurt. Omdat je maar 1 led aanstuurt, kan er maar 1 sensor tegelijk actief zijn, dus je hoeft geen onderscheid te maken welke.
Maar dat is dus erg lastig om mechanisch voor mekaar te krijgen. Door nu 8 groepen met sensoren te maken, kan iedere led 7 sensoren links en rechts beschijnen, maar je gebruikt de tegenoverliggende sensor (gecombineerd met de sensor 8 en 16 verder, maar DAAR moet je dus op mikken dat die niet beschenen kunnen worden.)
De lol dat je wat spreiding toestaat is ook dat je niet ieder van de 300 leds prcies op z'n sensor hoeft te mikken.
nu zit trix de hele tijd te hameren dat de sensoren "gelijk" uitgelezen worden. m.i. is dat helemaal niet nodig. Als we een plaatje maken van het geheel en dat staat 1 op 300 scheef, dat is zo weinig: dat zie je niet. Maar dan nog, je kan het in hardware oplossen door de sensor lijn 1cm op 3 meter scheef te zetten, dan kan je in alle rust de 300 sensoren scannen alvorens weer bij het begin te beginnen. Als de verplaatsingssnelheid 0.1m/s is, dan doe je 10cm in 1 seconde, dus 100ms over 1 lijn. Als je nu ook scant met 300 pixels per 100 ms, dan is het object in 100ms 10mm verschoven, terwijl je dus de laatste pixel scant heb je de scanlijn 1cm scheef gezet en meet je dus precies recht tegenover de eerste pixel.
De volgende vraag, waar ik antwoord op nodig heb om te kunnen rekenen aan het probleem is hoe snel de scan moet gebeuren. Dat weet je hoeveel pixels per seconde er gedaan moeten worden.
Als je dus 300 pixels per 100ms doet is dat 300 microseconde per pixel. Dat is zelfs met 30kHz IR sensoren volgens mij haalbaar: afstandsbedieningen doen ook 10 cycli aan 10 uit om wel of niet een bitje door te geven.
Als het sneller moet, dan zou ik overwegen om steeds bijvoorbeeld 10 leds aan te hebben, maar dan dus met tussenpozen van 30 leds. Dus led 1-31-61 doe je tegelijk aan, en dan lees je sensor 1-31-61 uit. Vervolgens doe je leds 2-32-62 aan en lees je sensoren 2-32-62 uit....
Als je dit nu met "32" ipv met 30 doet dan komt het binair mooi uit. Dan kan je voor de aansturing weer een matrix maken, waarbij je een "x32" architectuur kiest. Dan stuur je hele rijen tegelijk aan. Of je maakt weer een lang schuifregister waar je nu dus 10 bitjes tegelijk in hoog maakt.
Kortom, zat oplossingen....