High-speed detectie systeem ontwerp met line array sensor.

Amaai een hele opgave.
Ik heb al heel wat laserafstandsmeters opengedaan om te zien wat erin zit.
Allemaal hadden ze een vierkante sensor, enkele mm², en ik vraag mij af of die lijnsensor zal werken.

Of het gaat werken, zeker ben je nooit. Maar gezien de voorgaande versie's ook al kijken naar een object tot 1x1mm en dit werkt heb ik er veel hoop op.

De linesensor zou geen probleem mogen zijn omdat de laserstraal vast opgesteld staat en horizontaal tov de meetlens. De laser projectie op de linesensor kan bijna niet anders of deze line richting volgen. Zijn er andere ongewenste reflecties die naast de line vallen dan zijn ze toch niet belangrijk voor het resultaat.

Ik ga het project in fazen uitwerken, dit om nutteloze kosten te sparen. Zo heb ik nog verschillende FPGA boards liggen (DE1 Terasic) die ruim voldoende zijn voor de signaal verwerking. Werkt alles zoals gehoopt dat wordt de definitieve board een DE0-nano (listprijs ongeveer 80 euro + BTW en verzending).

De eerste meting kan zich beperken tot de linesensor monteren en aansturen zodat hij de analoge pixels uitschuift. Daarmee kan ik op de picoscope de waarden capteren, opslaan en analyseren. Tot daar is het een zeer eenvoudige meet opstelling. Laser, lens en object zijn reeds mechanisch beschikbaar. Ik heb vroeger ook al dergelijke opstellingen moeten maken iets zoals deze:

Temporary setup to measure the external shutter range 29338 by fotoopa, on Flickr

De huidige meetlens die ik nog in gebruik heb ( hier met een 50mm lens) is deze:

IR optical detector system for 3D capture 300057 by fotoopa, on Flickr

Hier is de photodiode vrij klein en bevat zelfs geen pcb meer, enkel de beide draden. Hier staat zelfs een klein spiegeltje voor de lens om onder een hoek van 90 graden te kunnen kijken. Maar voor de lasersignalen maakt dit niets uit.

Straks teken ik het eerste printje en schema waar de linearray opkomt met de 2 ADC SPI convertors. Waarschijndelijk moet ik nog eerst enkele symbolen aanmaken in eagle. Printje etsen kan ik maar als de componenten binnen zijn zodat ik zeker ben van de juiste package en layouts. De eerste kosten kan ik zo beperken tot een goede 100 euro, ik bestel altijd alles in dubbel zodat ik tijdens de proeven niet vast zit als er eens een ongelukje gebeurt. Zodra er iets klaar is geef ik wel de schema's en layout.

Het zal vooral op de data verwerking zijn dat ik waarschijndelijk de meeste hulp zal nodig hebben. Maar er zitten hier wel wiskundige cracks. Zodra ik de eerste metingen heb zal het duidelijker zijn welke de signaalvorm is samen met juiste timingen en wat ik wil bereiken.

Zonder signalen te zien is het natuurlijk koffiedik kijken, maar ik zou een gewogen gemiddelde berekenen van de sensor waarden met de sensor posities:

Je kent elke sensor positie: P_i, en elke sensor waarde: w_i.

Een goede schatting van de positie is dan:

P_e = \frac{\sum_{i=1}^{128}w_i*P_i}{\sum_{i=1}^{128}w_i}

Dit is geen moeilijke berekening: vermenigvuldig elke sensorwaarde mijn zijn positie (dat mag ook een ID zijn: een int van 1...128), tel al die getallen op, en deel door de som van alle sensor waarden.

Dan heb je een maximum-likelihood achtige schatting gemaakt van de positie van de piek (indien de sensorwaarden ongeveer normaal verdeeld zijn... Om dat te verifieren moeten we sensorsignalen kunnen zien)

Dan nog een simpele compare operatie:

\left\{\begin{matrix}
P_e>T_l \;\; \& \;\; P_e<T_H \rightarrow D=1
\\
else \rightarrow D=0
\end{matrix}\right.

Als de geschatte positie binnen een bepaald interval valt( lage threshold T_l=63 en hoge threshold T_H=65, geef je een 1, anders een 0 naar buiten. Als dit nog noisy is, kunnen we nog wel eens kijken naar iets beters dan een simpele compare.

Dit kan werken als:
* de sensordata ongeveer normaal verdeeld is (beter gezegd: de "bult" over de sensoren moet ongeveer symmetrisch zijn....)
* de SNR hoog genoeg is.

Het kan ongetwijfeld beter, maar dit is toch al een eerste aanzet die kan werken denk ik. Je moet slechts 1 deling uitvoeren, dat zal nogal meevallen in de FPGA...

Ah dat is al een mooie aanzet, vooral je uitwerking want zo een formule alleen is moeilijk leesbaar voor mij.

ik ben al aan tekenen van de testschakeling, ttz de nieuwe symbolen aanmaken. De line array is reeds klaar, nu nog de ADC. Maandag bestel ik de componenten, einde volgende week zouden ze hier moeten zijn. Mijn eerste werk zal zijn die datacurve op te nemen en dan zal je een beter overzicht hebben.

Ik vermoed een heel scherpe piek omdat het laserlicht slechts over max rond de 10 pixels zal liggen. Het omgevingslicht kan ik waarschijndelijk bijna volledig wegfilteren via een R72 IR filter voor de lens te plaatsen. Enig probleem is een beetje dat de line array eigenlijk zijn piekwaarde rond de 680 nm heeft maar die loopt toch nog redelijk door langs beide zijden. Die R72 filter blockt sterk af beneden 700 nm maar dan moet ik een laser gebruiken erboven. Ik heb 850 nm lasers maar dan is het rendement op de sensor maar 60% meer. Dat moet ik testen. Mogelijks vind ik een iets lagere filter.

Anderzijds zit in het zonlicht een volledig spectrum, dus ook de range boven de 700 nm bevat heel veel licht bij zon. Zolang echter de sensor hierdoor niet in saturatie gaat zou het verschil in uitlezing behoorlijk moeten zijn. Nu heb ik met die enkele photodiode een omgeving lager dan 50 mV terwijl een goede uitsturing IR boven de 600 mV ligt. Als detectie neem ik nu een verschil tussen omgeving en omgeving+IR van 6 eenheden vd 256. Volle uitsturing (wit vlakje van min 3mm) gaat boven de 100 eenheden. Nu doe ik 2 metingen na elkaar, eerst omgeving en dan omgeving+IR. Maar met de line array zou dit niet meer nodig zijn omdat je daar van een integratie tijd vertrekt. Die ligt minimaal rond de 30 us (is te berekenen uit de CLK en de stuurtimingen.

Maar ik kijk ook uit naar de eerste opgenomen kurve!

Als de piek echt heel scherp is, kan je eventueel met een maximum operatie ook de piek vinden:

Je neemt een 8 bit buffer, en stockeert er de eerste sensor waarde in. In een buffer met piek_ID steek je dan het getal 1. Dan vergelijk je sensor waarde 2 met de buffer. Indien die groter is, stockeer je sensor waarde 2 in de buffer, en zet je piek ID op 2. Dan ga je verder met 3, 4, enzovoorts.

Hier gaat zeker het maximum uit komen. Nadeel: je gebruikt niet alle informatie (maximum is nogal ruisgevoelig), maar geen sommen en delingen nodig... Ik heb zoeiets wel eens gebruikt als peak-detector in een sonar systeem op een FPGAtje... Ging goed

Als je het helemaal mooi wil doen, neem je in je gewogen gemiddelde nog een weging voor elke sensor mee, die afhankelijk is van het ruisniveau: stel dat elke sensor niet even ruisig is, kan je slechtere sensoren minder in rekening brengen dan goede sensoren. Je kan zelfs de koppeling tussen de sensoren in rekening gaan brengen, maar dat zal wel iets te ver gaan vermoed ik)

Een mooi experiment zou zijn als je de laser spot systematisch over de line array zou kunnen laten glijden... Dan kunnen we ziek hoe robuust de schatting is, en of ze lineair blijkt te zijn (toch in de omgeving van het centrum)

Jan

[Bericht gewijzigd door stecj366 op vrijdag 13 juli 2012 11:57:43 (10%)

De nonuniformity afwijkingen geven zo op als typisch 4% max 10%.
De Nonlinearity of analog output voltage is 0.4% FS. Dat zou nogal moeten meevallen. Ik kan die ook vrij eenvoudig meten via een grijskaart en erop te flitsen. Dat doe ik ook voor camera sensor controles en dat valt best mee. Je hebt geen invloed van het omgevingslicht. Trouwens tijdens de proeven moet ik mij voorlopig weinig zorgen maken over omgeving omdat binnen je daar nauwelijks last van hebt en het lasersignaal velemalen erboven komt.

Maar ik zou ook de opeenvolgende 128 pixels willen opslaan om te zien of ik hieruit de richting kan bepalen. De verschuiving van de belichting op de array geeft eigenlijk een directe afstand en daardoor zou ik moeten kunnen bepalen hoever het object voor of na de focus positie is.

Maar het wordt wel complexer als vb een insect bewegingen maakt met de vleugels. Dan is er een snelle meetverandering te verwachten. Deze studie wordt dan het 2de gedeelte, eerst correct detecteren.

Update:
Flitsen en laser hebben andere golflengtes, de smalle freq van de laser zou idd anders kunnen reageren op array fouten.

Array's zijn mijn stokpaardje Wat bedoel je met verschuiving? In de tijd? Of de fase van een modulerend signaal? Bedoel je de hoek schatten vanwaar het licht op de array valt? Of zie ik het verkeerd? Of bedoel je de lokatie van de piek op de array als verschuiving?

[Bericht gewijzigd door stecj366 op vrijdag 13 juli 2012 12:43:56 (14%)

Als een object zich verplaatst tov het focuspunt, laten we zeggen naar voor bewegen dan zal door de schuine opstelling van de laser het geprojecteerde punt op de array ook verschuiven. De array met lens wordt zo afgeregelt dat de laserstraal net in het focuspunt moet weerkaatsen en in het midden van de array vallen. puur theoretisch zou dit een piek rond de pixels 64 moeten geven met een breedte van 8 tot 10 pixels ( door de gebruikte lens en de vaste meetafstand. Verschuiven wil dus altijd zeggen verplaatsen naar voor of naar achter wat overeenkomt met afstand. Is het object te klein dan zal het geen reflectie meer kunnen geven omdat de laserstraal ernaast schiet. Maar dan moet ik ook geen trigger hebben want het zal niet infocus zijn. Meestal zijn de objecten wel groter. de tekening geeft deze zones weer.

[Bericht gewijzigd door fotoopa op vrijdag 13 juli 2012 12:52:55 (18%)

Ok, ik ben weer mee

Merkop dat bij de hoogste vliegsnelheden het slechts enkele ms zal duren dat er signaal kan gemeten worden. Het zou wel fijn zijn als je daarop kunt optimaliseren omdat er nu eenmaal verschil is tussen naderen en verwijderen. Dit door de shutter-lag van 6 ms die er nog altijd zal bijkomen. Juist daar heb ik nu zoveel last van omdat die shutter-lag nu nog 53ms is!

Maar de eerste bedoeling is om iets nauwkeuriger informatie over de diepte te hebben waardoor te vroege detectie signalen kunnen vermeden worden ( vooral bij heldere grote vlakken).

Update1:
Mijn voorlopige berekeningen geven aan de 128 pixels in te lezen en converteren naar 8 bit waarden + opslaan in een tijd van 50 us. De FPGA moet de nodige clokken maken zodat line array en ADC synchroon samen kunnen werken. Dit wordt een mooi stukje statemachine voor de FPGA. De integratie tijd voor de sensor wordt ook ongeveer 50 us wat een mooie tijd zou zijn. Er zouden 20 metingen per ms kunnen gebeuren. Parallel heeft de FPGA hierdoor ook 50 us om alle bewerkingen van de voorgaande samples uit te voeren. Moet haalbaar zijn.

Zopas zijn alle componenten besteld, nu nog even wachten op de levering, hopelijk ten laatste woensdag.

Update2:
Trackcode ontvangen, levering bevestig voor woensdag.
Ondertussen schema en layout verder afwerken ( iets meer werk gezien ik nu ook SMD componenten heb en de bestukking gemengd is, deels boven, deels onder maar als enkelface print ).

We zijn weer al een stapje verder in het project. Pakje met de nieuwe componenten is aangekondigd voor woesdag, hoog tijd voor schema en layout klaar te maken. Het schema is voorlopig af:

line_array_schema by fotoopa, on Flickr

Mogelijks zijn er nog kleine wijzigingen als de layout klaar zal zijn. Hier heb ik wat meer tijd nodig dan gedacht want ik moet de meeste componenten nu herzien omdat het SMD versie's zijn. De nieuwe IC's bestonden ook niet, dus ook eerst aangemaakt in een nieuwe Lib. Schema bevat de mogelijkheid om parallel uit te lezen 2 x 64 pixels) ofwel hem serial als 1 lijn van 128 pixels maar dan met slechts 1 ADC.

Een detail is ook dat het printje moet passen op mijn bestaande lenshouder, mechanisch is er niet zo veel plaats maar ik hoop dat ik er de volgende dagen wel geraak. Ik zou graag mijn printje etsen tegen woensdag. Maar er is ook nog een redelijke verilog software te schrijven om het geheel aan te sturen. Daar moet ik vanaf nul beginnen.

Zodra de layout klaar is komt die hier ook wel. De eerste test is bedoeld om een plot op de scoop te hebben van een 128 pixel string uit de sensor. Hiervoor heb ik de AD convertors nog niet nodig omdat ik direct kan meten op de analoge output. Hierdoor is de hardware aansturing in dze stap heel eenvoudig, de latere moet volledig synchroon verlopen tussen line-array en ADC convertors en opslag in de FPGA. Dat zal langer duren dan een dag. Zodra ik de eerste kurve heb zal ik zien of het nog de moeite is om verder te gaan, gaat het dan is het tijd om de algorithmes verder te bekijken voor de bewerkingen. voorlopig zou ik in 50 us de 128 pixels moeten kunnen uitlezen. Tot 10.000 metingen per seconde zou moeten realiseerbaar zijn.

Hé, de robotjes zouden hier ook hun positie snel en juist mee kunnen bepalen...

Ik zie dit topic nu pas, blijkbaar heb ik er al een paar dagen overheen gelezen.

Ik vraag me wel af of een FPGA wel de meest geschikte device is voor het gegeven probleem; ik zou zelf eerder een DSP pakken, denk ik. Ik ben zelf erg tevreden over de Picollo serie van TI; 32-bit @ 60MHz, met een 12-bit dual-channel ADC die 4.5Msps kan halen.

Met een DSP kun je iets gemakkelijker dingen doen als de minimale en maximale waarden bepalen, daarmee de grenswaarde berekenen, vanaf beide uiteinden van de array gaan zoeken naar de buitengrenzen van de stip, etc.

Ik zie daarbij nog wel andere mogelijkheden om het sneller te maken; aangenomen dat je nooit meer dan 1 object hoeft te volgen, kun je steeds het stuk van de array rondom de laatste detectie uitlezen, in plaats van de hele array opnieuw te verwerken, als je eenmaal een object hebt gevonden. Eigenlijk is het midden van de stip ook niet zo interessant, maar alleen de buitengrenzen ervan. Met 2 ADCs (zoals de Picollo serie heeft), zou je er steeds een kunnen gebruiken voor elke grens.

Een ADC leest dan de waarde van het pixel op de huidige grens van de stip; is deze boven de drempelwaarde, dan gaat die ADC een pixel terug, om te kijken of die inmiddels ook binnen de stip valt. Is de waarde onder de drempelwaarde, dan is de stip blijkbaar de andere kant op verplaatst, en wordt het volgende pixel gelezen om vast te stellen of die wel binnen de stip valt. De andere ADC doet hetzelfde, maar dan voor de andere kant van de stip.

Met andere woorden: aan beide kanten van de stip ben je steeds de pixels op de grens aan het lezen, om de nieuwe plaats van de stip te bepalen. Dit kan natuurlijk alleen goed werken als de lichtvlek niet zodanig snel kan bewegen dat deze over een van de trackers heen kan springen, waardoor je in de verkeerde richting zou gaan zoeken. Dit is overigens een situatie die vanzelf gecorrigeerd zou worden, want zodra beide trackers elkaar raken, ben je blijkbaar de lichtvlek kwijt, en moet je terug naar scanning mode, waarbij je wel steeds de hele array uitleest. Overigens zou een dergelijke algoritme natuurlijk ook prima in een FPGA geïmplementeerd kunnen worden.

Misschien is het geheel nog wel wat eenvoudige te maken door de analoge waarden niet met een ADC te bemonsteren, maar ze met een paar snelle comparators te vergelijken met een (dynamische) referentie. Door deze bewerking in hardware uit te voeren, kun je wellicht de verwerking van de data een stuk sneller en eenvoudige maken. Een comparator lijkt me sneller dan een successive-approximation ADC, en tenzij je maar een hele lage resolutie verwacht, zal een flash ADC de conversie ook in meerdere stappen moeten doen.

Heb je al gekeken naar een sensor uit een optische muis o.i.d.? Ik meen me te herinneren dat de high-end gaming muizen in de orde van grootte van 10k frames per seconde namen, bij 16*16 of 18*18 pixels of zo. Nu lijkt de resolutie me wel wat laag, maar daarmee zou je wel in 2 richtingen het object kunnen volgen.

EDIT: ik kijk nu pas naar de datasheet van de TSL202R, en dan blijkt dat een dergelijke tracking algoritme helemaal niet mogelijk is, simpelweg omdat je die sensor alleen sequentieel kunt uitlezen, en dus geen random access hebt. Als ik de datasheet goed lees, zou je elke 13us de hele sensor kunnen uitlezen, waarmee je dus op ~77k frames per seconde uit zou komen. Daarvoor heb je natuurlijk wel een ADC nodig die 5 MSps kan halen, en dan moet je nog voorzichtig zijn met de timing, zodat je de sensor clock genereert net na het acquisition window van de ADC.

Met een snellere ADC kom je waarschijnlijk toch uit op een parallelle interface, maar dat lijkt me niet echt een onoverkomelijk probleem, of wel?

Ik zou, waar mogelijk, de analyse niet uitstellen tot je de hele array hebt ingelezen; waarschijnlijk kun je een deel ervan ook al doen terwijl de data binnenkomt.

Overigens lijkt het me handig goed te bekijken wat de handigste manier is om de rand van de stip op te zoeken; misschien kun je beter naar het verschil tussen aangrenzende pixels kijken (of daarbij steeds een of meer pixels overslaan), in plaats van de absolute waarde van elk pixel te vergelijken met een grenswaarde o.i.d. Als je weet dat de stip 4 tot 5 pixels breed zou moeten zijn, zou je dus de waarde van een pixel kunnen vergelijken met de waardes van de pixels 3 posities verder en terug. Als het huidige pixel de eerste is die buiten de stip valt, zou ofwel het pixel 3 plaatsen terug, ofwel 3 plaatsen verder midden in de stip moeten vallen, en dus het grootste verschil hebben.

Wat me ook een aandachtspunt lijkt, is het feit dat er een tijdverschuiving zit tussen de laatste pixel van de eerste helft van de sensor, en het eerste pixel van de tweede helft, als je die twee helften tegelijk zou inlezen. Dit kan rare effecten geven als het object over het midden van de sensor verplaatst, en dit is juist het belangrijkste gedeelte. Om dit te voorkomen zou je de data van de eerste helft 1 frametijd kunnen vertragen, zodat je weer een frame krijgt dat helemaal sequentieel is uitgelezen, maar dat betekend wel dat die data 13us extra vertraging krijgt. Aan de andere kant is dat eigenlijk hetzelfde als de hele sensor achter elkaar uitlezen (dus niet de twee helften parallel), behalve dat je op deze manier de dubbele framerate kunt halen.

[Bericht gewijzigd door SparkyGSX op zondag 15 juli 2012 04:00:34 (28%)

Bedankt voor het meedenken in dit project. Zoiets helpt ernorm en soms moet je even weer naar de datasheets om iets na te zien, een kleine denkfout kans soms zware gevolgen hebben.

Om met het laatste te beginnen, mijn voorkeur gaat idd naar parallel uitlezen van de 2 gedeeltes elk 64 pixels waardoor de uitleestijd op de helft komt. Tijdsverschuiving zal er niet zijn omdat de SI puls aan beide arrays samenligt en die start en stopt de integratietijd. Er is hierdoor geen verschil in integratie tijd van de pixel belichting door het uitlezen.

Update:
Ik heb hier waarschijndelijk een fout gemaakt door eerst de datasheet van de TSL1401 te lezen en dan de TSL202R. Ik had de TSL1401 niet genomen vanwege de moeilijke packege. Maar de 1401 neem de lading in eenmaal over, de 202 blijkbaar niet. Ook de 1402R heeft een hold maar was 256 pixels 400 dpi. Spijtig ik had nog getwijfeld om deze ook mee te bestellen maar had eerst bezwaar tegen die 256 pixels. Enfin als dat een echt probleem is doe ik een nieuwe bestelling. Ondertussen kan er bepaald worden of dit een praktisch probleem is.

Ik heb gekozen voor serieele uitlezing (spi) van de beide ADC's, dit zijn snelle 8 bit versie's (ADS7888)en met een clock tot 25 MHz. Het is juist de bedoeling van de line array en ADC's op elkaar te synchroniseren zodat de ADC gedaan wordt tijdens de pixel uitlezing van de array. Ik geloof dat het rond de 50 us zal duren om alle 128 bits geconverteerd in de RAM van de FPGA te hebben. Trouwens die uitleestijd bepaald ook de integratie tijd voor de pixels en die tijd zal best in dezelfde ordegroote liggen. Want is de integratie tijd te kort (minimaal 13us datasheets) dan zou het gereflecteerde laser signaal te zwak kunnen zijn waardoor ik een te dure lens zou nodig hebben of te veel power in de laser.

Hoe het data verloop in de 128 pixels zal zijn is nu nog koffiedik kijken. Een testkaart die je beweegt zou wel een heel smalle piek kunnen geven maar de praktijk van een vliegend insect is geheel anders. Kleine objecten kunnen slechts een reflectie signaal geven als ze perfect in het focuspunt zijn, dus de piek zou dan perfect in het midden moeten liggen. Ik dat geval moet er niets meer berekend worden want het enige die nog kan gebeuren is dat het object zich verwijderd uit het focuspunt en dat is niet de bedoeling.

Maar voor grotere insecten kan de laserstraal reflecteren als het object verwijderd is van het ideale focuspunt ( vooral de diepte) Een typisch voorbeeld is de vleugelslag van een nachtvlinder. De toppen kunnen vroegtijdig ( naar voren toe) detectie geven terwijl het lichaam zich veel dieper bevind en dat zou achter de focuslijn liggen en onscherp zijn op de foto. Dit zijn nu de meeste detectie problemen en zullen ook in dit systeem blijven. De toppen zullen even een piek buiten het center geven, hun body mogelijks aan de andere kant van de array of zelfs in het midden (wat dan focus geeft voor de body) Maar de vleugelslag ritme is bij deze insecten algauw rond de 200 slagen per seconde, anderen hebben tot 1000 slagen per seconde. Of deze variatie nog te meten en te berekenen valt is af te wachten 200 slagen geeft 5 ms maar de tijd dat de laser erop reflecteerd kan slechts een heel kort gedeelte zijn, zeker minder dan 1 ms, de body zou wel langer een signaal kunnen geven omdat daar enkel de vliegsnelheid een rol speelt en niet de vleugelslag. Die vliegrichting uit het body signaal berekenen zou wel enorm interessant kunnen zijn. Ook de kleur van het object speelt bijna de grootste rol. Witte vlakken reflecteren ernorm, mat zwarte zelfs helemaal niets. Deze variatie is nu ook het moeilijkste. Als daar nog eens de invloed van het omgevingslicht bijkomt dan is het helemaal om zeep (saturatie) Het diafragma van de lens kan hier gebruikt worden om dag/nacht instellingen eventueel te compenseren maar het heeft in vele gevallen wel invloed op de totale gevoeiligheid.

Moest ik reeds goed de positie van de body kunnen berekenen en de vleugelslagen weg filteren dan zou dat een super zaak zijn. Ik denk dat dit slechts een droom zal blijven. Eerst wat metingen en dan kom ik weer met beide voeten op de grond.

Ik ben al ver gevorderd met de layout en de tracking geeft aan dat ze de onderdelen reeds dinsdag voormiddag zouden leveren ( zitten deze morgen al in Parijs om naar Brussel te vertrekken)

Ik werk voorlopig liever met FPGA's omdat er hier 4 stuks DE1 van terasic in voorraad liggen. Daar kan ik alle berekeningen op plannen en verilog kan ik nu al een beetje zodat dit vrij vlot verloopt. De timingen maken voor de line array en de ADC's is zeer eenvoudig met een FPGA. Werkt het dan kost een DE0-nano boardje minder dan 100 euro en is hier binnen 3 dagen kant en klaar en vooral heel klein van inbouw. Dit laatste is ook heel belangrijk omdat het een draagbaar toestel is dat minstens 3 uur in de field moet kunnen werken op 1 set batterijen (7.2v).

Op de berekeningen zelf kom ik nog terug zodra ik de eerste uitlezing van de line array heb. Dan plaats ik hier een aantal plots van de 128 pixels, via de picoscope is dat maar enkele seconden extra werk. Ondertussen werk ik nog wat aan de layout zodat ik de print kan etsen. Layout duurt deze maal iets langer, ik moet nu SMD gebruiken en die pads moeten nog eens extra nagezien worden, het blijft enkelzijdige print en is de tekening klaar dan moet lieft een uur later de PCB geetst zijn!

Update2:

Layout PCB is ook klaar. De meeste onderdelen zijn SMD, de linesensor is een dip versie en komt aan de bovenzijde. Afmetingen 66 x 66 mm. Kleinste baantje 10 mils.

line_array_layout by fotoopa, on Flickr

Ik blijf volgen, en wacht rustig de plots van de pixels af.. Moedt je de getalwaardn in een textfile kunnen dumpen, kunnen we er zelf eens mee aan de slag....

Ja die plots van de scoop kan ik exporteren naar een excel file en dan kun je daar alle kanten mee op. Maar er is nogal wat voorbereidend werk, mijn werkplaats is nu niet beschikbaar, mijn vrouw heeft daar een volledige kamer opgeslagen tijdens schilderwerken in een andere kamer. Zelfs mijn lichtbak zit er ergens onder. Maar ik hoop toch tegen vrijdag iets te kunnen meten.

Ondertussen ga ik nog een klein printje maken om de signalen en de detector direct op de DE1 FPGA board aan te koppelen + de buffer voor de laser te sturing. Ook het verilog programma voor de DE1 moet nog geschreven worden om de line array te sturen. Dat kan ik allemaal verder zetten zonder toegang tot mijn werkplaats. De DE1 signalen kunnen vooraf al uitgemeten worden met de LA. Er is voorlopig nog werk genoeg.

Update:

Alle componenten zijn al binnen, 2 dagen vroeger dan verwacht!
En ja die SMD...tjes, verdomt klein voor opa. De layout op het scherm ziet er zo groot uit tot je een plot maakt. En ik had dan nog de groote package versie genomen. Ik moet nog ergens een bril hebben van +5 die zal ik kunnen gebruiken om te solderen. En... nu nog beter een SMD soldeerboutje kopen zeker anders is mijn stift breder dan de volledige IC!
Voor de rest is alles in orde, FPGA board staat al naast de computer en daar ga ik nog een klein interface printje voor maken om direct op de 40 polige connector te pluggen.

[Bericht gewijzigd door fotoopa op maandag 16 juli 2012 13:07:54 (28%)

SMD componenten kun je waarschijnlijk beter met een soldeerpasta positioneren en bevestigen d.m.v een pincet en daarna alles opwarmen in een oventje. Ik vrees dat anders de kleine componenten aan een conventionele soldeerbout zullen blijven kleven. Maar hoe het juist moet of kan voor een hobbyist weet ik niet hoor. Misschien even je 'licht' opsteken bij vroegere collega's ...

Ik ga eens een foto plaatsen als ze gesoldeerd zijn, zonder oventje. Voor thuis geloof ik daar niet veel in, zeker niet als je geen regelmatige produktie hebt. Maar IC's met vele pootjes hum... dat zou moeilijker worden. Zolang er maar 2 kanten zijn zie ik het nog zitten en die ADC's hebben maar 3 pootjes langs beide zijden op een pitch van 0.95 mm. Even zijdelinks tikken en ze liggen vast.

Zal wel gaan (hoop ik).

Gebruik zeker voldoende flux bij het SMD solderen. En een soldeerbout met een fijne punt. Een dun draadje soldeersel, en dan komt alles goed normaal gezien.

Ah je doet mij eraan denken, ik moet nog flux bestellen die heb ik hier niet. Fijne soldeer van 0.5mm heb ik maar moet nog een extra fijne soldeerpunt hebben voor op mijn weller bout. Voor dit printje zal het vast wel gaan.

Ondertussen is de eerste programmering op de DE1 board gestart. Ik ben nu bezig aan de timing uit te tekenen om die synchroon te hebben tussen line array en de beide ADC's. Zopas een PLL getest die op 40 MHz draait. Als ik de timing wat wil wijzigen van de ganse statemachine moet ik dan enkel maar deze PLL waarde even op een andere freq laten lopen en alles blijft synchroon.De ADC heeft dan 12 clocks nodig van 50 ns wat 600 ns is om 1 pixel serieel uit te lezen met 8 bit resolutie, of 39 us voor de 2 array's elk 64 pixels.

Mijn huidig systeem met 1 photodiode gebruikt nu 64 us meetcyclus en er zijn 2 cyclussen nodig voor validatie. Met de line sensor moet het even snel kunnen gaan maar nauwkeuriger. Ik kan maar de printjes etsen einde deze week vanwege de werkzaamheden, mijn vrouw heeft nu ook de toegang op mijn PCB en etsstoffen in beslag genomen (had mij dat niet verteld..) maar tijdsverlies zal er niet zijn, er is nog genoeg verilog code te schrijven en de timingen via de LA op te slaan. Dit moet toch eerst werken vooraleer ik de detectorprint kan aansluiten.

Oef, timingen tekenen vragen toch een behoorlijke tijd. Vooral als de verschillende IC's synchroon moeten uitgelezen worden. Maar de eerste timingen zijn klaar om in de FPGA te programmeren.

line_sensor_timing by fotoopa, on Flickr

De hogere resolutie files staan op mijn Flickr account, tekening is clickbaar en daar kun je verder klikken tot de max resolutie van 2400 pixels. De huidige timingen bevatten nog niet de opslag van de geconverteerde data maar gezien de timming reeds voorhanden is zal dat weinig problemen mogen opleveren. Volgende faze is deze getekende timingen uit de FPGA krijgen en controleren via de LA (Intronix 32 channel). Aankoppeling van deze signalen zal over nog een klein printje verlopen naar de optische sensor/lens systeem. De printen kan ik slechts begin volgende week etsen vanwege de andere lopende werkzaamheden.

Het geheel wordt gestuurd door een PLL nu op 50 MHz. Door deze waarde te wijzigen kunnen andere snelheden verkregen worden zonder dat ik de ganse programming moet wijzigen. De max data rate wordt nu 65 x 640 ns = 41.6 us om de 128 pixels uit te lezen met de adc convertie erbij. Gezien ik een sampling tijd had vooropgesteld van 100 us blijft er nog een speling van bijna 60 us over. Er is voldoende marge.

En ja die SMD...tjes, verdomt klein voor opa.

Flux en desoldeerlitze zijn je vriend. Het geeft niet als er teveel soldeer op komt en kortsluiting tussen de pootjes veroorzaakt, litze erop en het is zo weer weg. Alles gesoldeerd dan de print met IPA in een ultrasoon badje schoon maken. Dergelijke kleine ultrasoon badjes voor sieraden ed zijn voor minder dan 20 euro te koop bij blokker, kruidvat enz.

Oh dat ziet er mooi uit! Soldeerlitze gebruik iK al jaren, flux vroeger ook, we hadden dat op het werk. Dat moet ik nu even opzoeken voor nieuwe aankoop maar Mouser zal dat ook wel ergens hebben, ik moet toch nog wat extra line-sensors bestellen en ook nog 0.1uF smd c's

Maar welke vloeistof doe je dan in dat ultrasoon badje. Zal wel geen water zijn of hebben ze ook iets die erbij hoort/verkrijgbaar is?

IPA = iso propyl alcohol

Oeps had erover gekeken! Thanks weer een reden om even boodschappen te doen.