reactie tijd IR sluis

een rode led zit op de ong. 460 nm

Nee, dat is blauw licht...
Een fotodiode voor ~650nm voldoet voor rood licht. Bijv: https://www.digikey.com/product-detail/en/advanced-photonix/SD019-141-…

nu ben ik even bij mouser aan het zoeken voor een geschikte foto diode/transistor, maar kan eigenlijk niet iets geschikts vinden voor een rode led, of ik snap het zoek systeem niet of ik stel teveel eisen, o.a. trough hole.
welke zou geschikt zijn voor een rode LED ?
vriendelijk bedankt.

Op 9 december 2018 10:49:28 schreef trix:
of ik stel teveel eisen,

Nee, er is eenvoudigweg teweinig vraag naar en daardoor worden er weinig componenten gemaakt.
Ga je ook 300 printjes maken met componenten voor selectieve ontvangst?

Ik stel ook vast dat je nooit iets probeert, altijd maar vragen stellen, nooit een opstelling in elkaar zetten en eens schrijven wat er goed of niet goed aan is.
Een foto van uw opstelling zou meer zeggen dan een beschrijving van 1000 woorden en zou ons ook meer inzicht geven wat je wilt.

Uittesten is juist het leukste van alles...
Je hoeft geen complete opstelling te hebben, een paar sluisjes is al genoeg om te evalueren of dit in jouw situatie volgens verwachting werkt...
Link naar een fotodiode had ik al gegeven...

Precies!

@TS: ik begrijp je echt niet. Je hebt blijkbaar een "ontwerp" van een scanner, waardoor je op een onmogelijk eisenpakket komt (scan rate, snelheid van sensoren, ongevoeligheid voor omgevingslicht, kostprijs), en dan nog blijf je stug aan je originele ontwerp en aannames vastklampen.

Doe nou eens een stap terug, en schrijf de eisen op, zonder meteen naar de implementatie te kijken. Ik zal aftrappen:

Totale hoogte 3 meter
Afstand 50cm
Verticale resolutie 10mm
Snelheid van voorwerp ?
Horizontale resolutie ? (ook 10mm?)
Kostprijs <= 1000 euro

Gezien de gestelde scanrate van 10Hz, en de aanname van een horizontale resolutie gelijk aan de verticale, zou dat object 100mm/s bewegen, klopt dat?

Je hebt, in de specificatie van de snelheid van de sensoren, aangenomen dat je nooit twee of meer LEDs tegelijk aan mag zetten. Met een afstand van 50cm en een hoogte van 3m moet het toch raar lopen wil de bovenste LED op de onderste detector schijnen. Ergo, je kunt beste meerdere LEDs en detectors tegelijk actief hebben, de vraag is wat de onderlinge afstand moet zijn voordat ze elkaar niet meer storen. Ik zou denken dat 25cm prima haalbaar moet zijn, als je kokertjes op de LEDs en detectors zet, en waarschijnlijk kan het veel beter dan dat. Met 25cm onderlinge afstand kun je 12 LED/sensor combinaties tegelijk actief hebben, en met 10Hz scan rate kom je dan op zo'n 8.3ms per sensor. Dat is triviaal te doen met die TSOP detectors, aangezien er in die 8.3ms al ruim 300 cycles van de 38kHz draaggolf passen.

Als TS perse rode leds wil gebruiken, gaat een TSOP 't niet worden...
Voor infrarood zijn er ook narrow-beam leds (3°), dat scheelt al een boel...
https://nl.farnell.com/osram-opto-semiconductors/sfh4550/led-ir-5mm-85…

Afstellen hoeft ook bij IR geen probleem te zijn, heb je indicatorkaartjes voor: https://www.conrad.nl/p/iri-4400-ir-indicatorkaart-184977

[Bericht gewijzigd door Arco op zondag 9 december 2018 15:53:49 (23%)

Nee, maar met die TSOPs krijg je de demodulatie en detectie cadeau. Met fotodiodes moet je het versterken en demoduleren nog zelf doen. Een voordeel is wel dat je precies weet waar je naar moet kijken als je de LEDs ook vanuit de microcontroller moduleert. Als je de fotodiodes achter een analoge multiplexer hangt met een fatsoenlijke versterker en met een goede ADC meet (lees: geen antieke AVR met een trage 10-bit ADC dus), kun je meten op de momenten waarvan je weet dat de LED aan en uit is, en daar het verschil van berekenen, met nog wat oversampling moet dat prima betrouwbaar te maken zijn.

Ik zou een STM32F3 nemen, met 16 analoge ingangen (of meer), en 16 multiplexers om op 256 sensors te komen. Met de ADC, in combinatie met de DMA controller, kun je heel hard samplen en heb je genoeg rekentijd over om de data te verwerken. Bij een AVR moet je ofwel op elk sample wachten, of voor elk sample een ISR door, met de nodige overhead. Met minimaal 5120 samples per seconde wordt dat toch een keer een probleem.

Afstellen hoeft ook bij IR geen probleem te zijn, heb je indicatorkaartjes voor

Goh, wist niet dat dat bestond, ik gebruik de smartfone cam voor zoiets. Kaartje is wel iets makkelijker bij het afstellen!

@SparkyGSX, wat jij schrijft als oplossing is om van de duizelen, je komt blijkbaar van een andere wereld ofwel is de mijne aan het krimpen, kan ook

Op 9 december 2018 17:03:37 schreef MGP:
je komt blijkbaar van een andere wereld

Is niet erg, ze kennen me hier

Ik neem aan dat de betekenis van ISR (interrupt service routine) bekend is, en dan blijft eigenlijk alleen DMA over. DMA staat voor Direct Memory Access, dat is een betrekkelijk eenvoudige periferal die data van en naar andere periferals (zoals de ADC) en CPU RAM kan verplaatsen. Op die manier kun je een serie ADC samples starten die automatisch naar RAM worden geschreven, zonder tussenkomst van de CPU. Dit kunnen meerdere kanalen zijn, of hetzelfde ADC kanaal een willekeurig aantal keren heel snel achter elkaar.

De STM32F3 heeft 4 12-bit ADCs, die elk tot 5MSps kunnen doen, voor 20MSps samen; vergeleken met de enkele 10-bit 15kSps ADC van de ATMEGA32. Dat lees je goed: 1333x sneller, met nog 2 bitjes extra resolutie helemaal gratis. De grootste package heeft 39 analoge ingangen beschikbaar, en een groot deel daarvan zijn verbonden met meer dan één ADC. Vanwege de DMA controller heb je daar geen omkijken naar totdat een hele serie conversies is voltooid, en het starten van de conversies kun je doen met de timer periferal die ook de draaggolf voor de LEDs maakt, zodat de timing daarvan altijd perfect klopt met die draaggolf.

En dat alles voor minder dan 5 euro/st bij Farnell! Snap je nu waarom ik 8-bit AVRs/PICs antiek en achterhaald vind? Owja, die F3 rekent ook nog 32-bit breed op 72MHz, de F4 op 168MHz, en als dat niet snel genoeg is doet het stoere broertje, de H7, gewoon 400MHz als je dat wilt. Toegegeven, die is dan ook een stukje duurder, 15-20 euro per stuk.

Ik weet wel wat dat allemaal betekend, ben van de oude stempel toen dat allemaal werd uitgevonden en heb dat ook op de voet opgevolgd, maar als de TS al zoveel problemen heeft met een fotocel, wat moet dat niet zijn als hij uw "oplossing" leest.

Op 9 december 2018 17:33:38 schreef SparkyGSX:
[...]Is niet erg, ze kennen me hier

Wilde ik maar zeggen dat je u soms een beetje moet inleven in de kennis van de TS, dat is ook niet altijd eenvoudig voor sommige mensen.
Altijd die grote hamer bovenhalen doet ook soms pijn al je ermee in het wildeweg slaat.

Op 9 december 2018 17:43:25 schreef MGP:Wilde ik maar zeggen dat je u soms een beetje moet inleven in de kennis van de TS, dat is ook niet altijd eenvoudig voor sommige mensen.

Uiteraard, maar het wordt nog veel moeilijker als de TS daar geen informatie over geeft. Ik ken mensen die zich prima kunnen redden met alles wat ik genoemd heb, maar werkelijk niet weten hoeveel pootjes de gemiddelde transistor heeft. Uiteindelijk is dat een vraag waar alleen de TS antwoord op kan geven.

In mijn beleving is een draaggolf maken en synchroon daarmee analoog samplen helemaal niet zo ingewikkeld, maar ik zou het niet voorstellen als ik een eenvoudigere, adequate oplossing zag.

Voel je vrij om iets voor te stellen wat simpeler is en aan de gestelde eisen voldoet, vooral 300 "pixels" voor <= 1000 euro is een uitdaging. Ik zat al hard te denken over een oplossing met een camera of een scannende laser of zo, maar dat lijkt me ook niet eenvoudig.

Op 9 december 2018 14:11:07 schreef MGP:
[...]
Ik stel ook vast dat je nooit iets probeert, altijd maar vragen stellen, nooit een opstelling in elkaar zetten en eens schrijven wat er goed of niet goed aan is.
Een foto van uw opstelling zou meer zeggen dan een beschrijving van 1000 woorden en zou ons ook meer inzicht geven wat je wilt.

klopt, ik snap dat je het zo ziet. ik wil dus ook eerst een testopstelling maken. maar IR zat in mijn hoofd, tot dat (ik geloof GJ kwam) dat het met gewoon rood licht natuurlijk ook kan, dus dat ga ik dan even bekijken, waarbij ik dus tot de conclusie kwam dat hier moeilijk receivers voor te krijgen zijn....dus terug bij af en 2 vragen van mijn kant verder.
ook ben ik ondertussen ook met het programma bezig waardoor niet de volledige focus op de scanner ligt.

dat je op meerdere plaatsen tegelijk kan scannen had ik ook al bedacht b.v.
1 t/m 10
11 t/m20
21 t/m 30
daardoor heb je gigantisch veel meer tijd om te zien of het licht of donker is. nadeel is dan dat de bitjes anders worden binnen geklokt, wat wel weer kan worden opgelost in de software.

de horizontale resolutie is inderdaad ook 10 mm
snelheid v/h voorwerp is 6 m/min. terug gerekend is dat dus 0,1 sec/10 mm

klopt arco van die link, alleen is die smd

camera en scannende laser gaat niet omdat je niet genoeg afstand kunt nemen tot het werkstuk voor een camera en bij een scannende laser te hoge snelheden gehaald moeten worden in het mechaniek.

Wat voor vorm heeft het te scannen object eigenlijk? Is dat een dichte "doos" waarvan je de bovenkant probeert te zoeken, of kan dat een willekeurig ingewikkeld object zijn? Weet je iets over de breedte en de plaats binnen die 50cm totale breedte van de constructie?

Onvoldoende ruimte om afstand te nemen kun je oplossen door de camera via een slim geplaatste en eventueel gekromde spiegel te laten kijken, de vervorming daarvan kun je corrigeren in software.

Ik zat ook te denken of je een laser kunt laten scanner met een slim geplaatste spiegel, waarbij de laser alleen roteert over een kleine hoek, en de spiegel ervoor zorgt dat hij in een min of meer horizontale lijn over het object gaat. Dat leek simpel totdat ik er goed over na ging denken, en dat zou een machtig ingewikkelde spiegel worden denk ik.

Als je de voorwaartse beweging van het object kunt meten, omdat het op een lopende band met een encoder staat bijvoorbeeld, hoeven die sensors niet allemaal boven elkaar in een lijn te staan, misschien dat die observatie nog bruikbaar is.

Het klinkt toch als onnodig veel werk om 300 LEDs en 300 fotodiodes te gaan bedraden, dat moet toch gemakkelijker kunnen...

Op 9 december 2018 18:18:06 schreef SparkyGSX:
Voel je vrij om iets voor te stellen wat simpeler is en aan de gestelde eisen voldoet, vooral 300 "pixels" voor <= 1000 euro is een uitdaging.

U overtreffen kan ik niet en heb ook niet de nodige kennis om zoiets te programmeren maar ik zou het doen zoals de TS voorstelt, per µC een reeks sluizen scannen en doorsturen.

In principe geeft ik u gelijk maar zoals ik al eerder schreef is het project veel te groot in omvang en complexiteit om te behandelen op een forum.

En nu terug naar de fotocel

het is niet zo complex. het is vooral veel.
het moeilijkste voor mij is het kiezen v/d juiste componenten. dit is de basis die je niet zo maar even snel veranderd (b.v. omdat je die moet bestellen).
ik ga inderdaad maar eens wat bestellen om mee te testen. ik begin met de TSOP, eigenlijk niet ontworpen voor deze toepassing. maar daar zit al filtering e.d. in.

@MGP: Een microcontroller per zoveel cellen kan wel, maar dan moeten die onderling weer communiceren, en je hebt op verschillende plaatsen intelligentie zitten. Persoonlijk zou ik het met multiplexers, I/O extenders, of externe ADCs oplossen, maar dus met 1 enkele microcontroller om het simpel te houden.

Toch heb ik het gevoel dat er een simpelere oplossing mogelijk moet zijn, met een ander meetprincipe of zo.

Hmm.. je zou een rij goedkope laserpointers kunnen gebruiken, die allemaal horizontaal tegen een vlak laten schijnen, en dan met een camera aan de andere kant kijken welke puntjes je kunt zien. Je hebt dan geen 300 sensoren nodig, en die lasers kunnen allemaal gewoon constant aan staan; je weet immers waar elke laser in beeld staat.

@TS: wat is nou de bedoeling van dit geheel? Waarom wil je dit? Waar komt die eis van 1cm resolutie vandaan?

Op 9 december 2018 21:35:20 schreef SparkyGSX:
@MGP: Een microcontroller per zoveel cellen kan wel,

Ik ben een hevige fan van modules, veel gezien op het werk vroeger.
Ook veel gemakkelijker bij het foutzoeken of defecten om nog niet te spreken over ontwikkeling en hardwareproblemen bij zoveel bedrading.

Je moet natuurlijk alles onderzoeken, ook zoals je zegt, de communicatie van de data.

Misschien eerst de data opslaan en na 300 scans dan pas de data verzamelen, maar omdat we het geheel niet zien is dat allemaal wazig.

Ik ben op zich ook wel een fan van modules, maar dan van simpele, domme modules met alle intelligentie op één plaats.

Als je lang moet zoeken naar een fout, is meestal de software engineer lui of incompetent geweest (of allebei). In software kun je prima zien dat één van de sensoren buiten bereik zit, of het signaal overmatig veel ruis bevat, en dat melden, inclusief het nummer van de sensor, de foutcode en meetwaarde van die sensor.

Uiteraard maken losse modules reparaties sneller en eenvoudiger; je kunt modules uitwisselen tot een apparaat/machine weer werkt, en achteraf thuis uitzoeken wat er met die defecte module aan de hand was.

Met de eerste 2 beweringen ga ik totaal niet akkoord, maar elk zijn mening hierover.
Jij bent waarschijnlijk beroepsmatig ontwerper en ik was beroepsmatig lange tijd hersteller, een wereld van verschil