38 kHz via PCF8574

al word de ontvanger zijde met het opslaan van de status v/d ontvanger (licht of donker) wel lastig met een schuif register of iets dergelijks.

Wat mij betreft is een schuifregister gelijkwaardig aan die PCF8574.

Als je een 16 bit schuif register hebt dan moet je altijd 16 bits inschuiven en je doet dus alle uitgangen in 1 keer veranderen.
Bij een PCF8574 kan je dacht ik maar 1 uitgang per keer veranderen dus als je veel tegelijk moet veranderen kan dat trager zijn. Bij een PCF8574 heb je dan wel weer ingangen.

ik denk dat ik het toch maar ga maken met een atmega 32, dat werkte gewoon goed. moet ik alleen weer uitzoeken hoe ik dat ook alweer programmeerde, volgens mij met een dragon.
probleem (of eigenlijk niet, als het werkt dan werkt het :)) van de code is dat het moeilijkste deel niet door mij is geschreven maar door dekees, ook hier van dit forum.
maar ik zal ook eens kijken of er een atmega is met meer dan 32 I/O pinnen.
in dat geval zal ik de code moeten "om programmeren" en heb ik waarschijnlijk weer wat hulp nodig.

maar ik zal ook eens kijken of er een atmega is met meer dan 32 I/O pinnen.

https://www.bitsandparts.nl/Arduino-Mega-2560-(compatible-clone)-p1220…

Totaal 70 io pinnen

die atmega 2560 heb ik dacht ik al eens gebruikt :?

De ontvanger hoeft niet heel moeilijk te zijn, je kunt een complete ontvanger gebruiken, of gewoon een sensor die je synchroon met het 38kHz signaal sampled. Als je dat signaal in de microcontroller maakt, kun je de ADC daar triviaal op synchroniseren. Met een multiplexer met enable input kun je een LED kiezen, een dat 38kHz signaal zet je dan op de enable.

Als je genoeg I/O pinnen hebt, kun je het aansturen van de LEDs ook in software doen, een simpele interrupt op 76kHz kan nog wel. Voor de ADC heb je waarschijnlijk wel multiplexers nodig.

[Bericht gewijzigd door SparkyGSX op (21%)]

Waarom alle led's apart en beurtelings aansturen/moduleren?
Alle led's kunnen tegelijk worden gemoduleerd en de ontvangers sequentieel/beurtelings worden uitgelezen om te bepalen of ze wel of geen licht ontvangen. Op de plek waar het object staat ontvangen de ontvangers geen licht en dat is wat je wilt detecteren.

Precies, dat zat ik ook te denken. De timing wordt alleen beperkt door de (maximale) snelheid van het te meten object. Je wilt de ontvangende kant minimaal 2 keer uitlezen als het object binnen komt en er weer uit schuift. Afhankelijk van de snelheid van het object, kan de timing aan de ontvangende kant worden berekend. Als de timing het toelaat, kan je die ontvangende kant prima uitlezen met de eerder voorgestelde schuifregisters.

Nog een tip voor je dipswitch: gebruik een weerstandsdeler. Dan heb je slechts 1 analoge ingang nodig voor zoveel switches als je wilt!

[Bericht gewijzigd door OPTOdesign op (14%)]

Dat ligt eraan hoeveel licht ze zijwaarts kunnen ontvangen, als je steeds één LED aanstuurt en de bijbehorende ontvanger leest, krijg je veel betere informatie over de positie van het object. Je zou wel kunnen proberen of het goed gaat als je elke 8ste LED bijvoorbeeld tegelijk aanstuurt; je hebt dan maar 8 cycli nodig om alles uit te lezen, en je kunt 3 1-naar-8 multiplexers gebruiken voor de ADCs.

Optisch is dat "probleem" makkelijk te verhelpen door de led's in een buisje (o.i.d.) te monteren en te richten op de tegenoverliggende ontvanger. Geen cross-talk meer.

@Trix, ik heb zoiets al eens gemaakt voor een kunstwerk, gebruikte lasermodules (KY-008 650nm) als zender, ontvangers gekoppeld aan een 74HC164 & Arduino. Die 74HC164 aan de hardware SPI aansluiten op de Arduino.

Ik heb het vroeger al eens geschreven, maak de opstelling modulair, niet teveel software in dezelfde controller maar 'veel' controllers met dezelfde software en enkel onderscheid maken met uw dipswitches.
Zoiets is veel overzichtelijker, werkbaarder en makkelijker om fouten op te sporen.

Of je nu tal van logische ic's gebruikt of evenveel controllers dat zal de prijs niet bepalen.

Meerdere controllers met dezelfde software vind ik altijd een beter idee dan verschillende software; het voordeel is dan ook dat je het ding altijd langer kunt maken als je dat wilt. In plaats van dipswitches en een gedeelde communicatiebus, kun je ook een SPI of UART gebruiken, ofwel 2 SPI/UART periferal, één voor communicatie met de vorige en één voor communicatie met de volgende module, of je splitst er één op, ontvangt van de vorige en zend naar de volgende, eventueel met een verbinding van de laatste module terug naar de eerste.

Als je de sensors zelf analoog gaat lezen, en niet meer standaard IR ontvangers, zit je ook helemaal niet vast aan die 38kHz, aangezien je het aansturen van de LEDs kunt synchroniseren met het uitlezen van de sensors. Je leest de sensor dan met de LED uit en met de LED aan, en bepaalt het verschil tussen die twee metingen (met een gemiddelde over een groot aantal cycli) om te bepalen welke lichtbundels onderbroken zijn.

Op zondag 14 juli 2024 22:41:59 schreef trix:
die atmega 2560 heb ik dacht ik al eens gebruikt :?

klopt dus die heb ik al eens gebruikt,...maar het is nogal wat overkill in deze toepassing.
eens wat verder gezocht in de atmega familie, en de atmega 64 gevonden, deze heeft 53 I/O pinnen, en een TQFP 64 behuizing (0,5 mm pitch).
lijkt mij heel goed bruikbaar, ik heb dan alleen bij de zender nog 3x ULN2803 nodig. kan je volgens mij ook programmeren met atmel studio.

Op zondag 14 juli 2024 23:37:29 schreef Bobosje:
Alle led's kunnen tegelijk worden gemoduleerd en de ontvangers sequentieel/beurtelings worden uitgelezen om te bepalen of ze wel of geen licht ontvangen.

dan krijg je waarschijnlijk "cross over" dat zender 18 ontvanger 19 beschijnt, dat heb ik al eens getest.

Op maandag 15 juli 2024 00:00:20 schreef Bobosje:
Optisch is dat "probleem" makkelijk te verhelpen door de led's in een buisje (o.i.d.) te monteren en te richten op de tegenoverliggende ontvanger. Geen cross-talk meer.

dit pas ik al toe.

Op zondag 14 juli 2024 23:48:48 schreef OPTOdesign:
Nog een tip voor je dipswitch: gebruik een weerstandsdeler. Dan heb je slechts 1 analoge ingang nodig voor zoveel switches als je wilt!

dan is iedere print "uniek" en dat had al ik in de werkende opstelling (adres ingebakken in de code) als het even kan heb ik dat liever niet.

Op maandag 15 juli 2024 11:05:30 schreef SparkyGSX:

Als je de sensors zelf analoog gaat lezen, en niet meer standaard IR ontvangers, zit je ook helemaal niet vast aan die 38kHz, aangezien je het aansturen van de LEDs kunt synchroniseren met het uitlezen van de sensors. Je leest de sensor dan met de LED uit en met de LED aan, en bepaalt het verschil tussen die twee metingen (met een gemiddelde over een groot aantal cycli) om te bepalen welke lichtbundels onderbroken zijn.

Ben van hetzelfde gedacht, je zou immers de zenderled laten oplichten en desbetreffende ontvangled inlezen, dan moet je u ook geen zorgen maken door overlappende belichting, het is een 1 of 0 voor die betreffende ingang.
Dat maakt wel 24 zender- en 24 ontvanger leds, je kunt ze wel bv. per 8 sturen met 1 controller.... en het hoeven geen 38kHz items te zijn ...mogelijkheden genoeg.

Als je een (lichtgeleidings)buisje toepast voor de leds moet dat wel matzwart zijn aan de binnenkant... (anders krijg je reflecties)

Een grotere MPU kost inderdaad niet veel meer als een kleinere (voor een paar euro heb je een 80/100 pins pic)
Meerdere processoren probeer ik zoveel mogelijk te vermijden (of ze moeten een duidelijke stand-alone functie binnen het geheel hebben)

Meerdere processoren met elkaar laten babbelen geeft meer kans op storingen en meer overhead: daarbij is het ook lastig bij firmware updates...

Op maandag 15 juli 2024 11:47:06 schreef Arco:
...
Meerdere processoren met elkaar laten babbelen geeft meer kans op storingen en meer overhead: daarbij is het ook lastig bij firmware updates...

In mijn gedachten gingen ze niet met elkaar 'babbelen', enkel op eenvoudige aanvraag hun IDnummer en ledstatus (2bytes?) doorsturen via RS485.
De controllers die de leds scannen kunnen onderling niet met elkaar babbelen, die kunnen enkel aan de gemeenschappelijke datacontroller hun data kwijt.

Maar mijn herinneringen zeggen dat het systeem veel groter is dan hier door Trix wordt voorgesteld.

Laatste keer dat ik veel processoren heb gekoppeld was nog met de 8042(!)... ;)

Er zaten toen 21x 8042's in een 19" ruif.
Dat was uit noodzaak omdat de processor niet een van de snelste was, en veel reken en detectiewerk te doen had.

Op maandag 15 juli 2024 11:12:21 schreef trix:
dan krijg je waarschijnlijk "cross over" dat zender 18 ontvanger 19 beschijnt, dat heb ik al eens getest.

Je schrijft "waarschijnlijk" dus niet goed getest of er is veel ruimte voor verbetering met matzwarte / langere buisjes?

Wanneer er dan toch nog teveel cross-talk is (ik verwacht het niet) wanneer alle led's tegelijk worden gemoduleerd dan kun je i.p.v. de led's IR-laser diodes toepassen dan maak je perfecte lichtsluizen.

Tevens kan je het aantal zenders verminderen zodat er geen 'cross over' meer mogelijk is omdat de zenders elkaar niet overlappen. Afhankelijk van de toepassing of dit stabiel kan werken.
Wat is de toepassing?

Als het buisje aan de binnenkant reflecterend is, krijg je nooit een nette convergente bundel. (waaiert uit)

Ik dacht net, hey... hoe gaat het eigenlijk met Trix z'n grote scanner?

Goed... Nog steeds bezig dus....

Dit project begint er bij om een goede "architectuur" te kiezen die gaat werken.

En, als je niet veel ervaring hebt met "de materie" (maakt niet uit wat!) dan moet je "bottom up" werken. Beginnen met kleine proef-opstellingen en als je die goed werkend hebt, ga je dat als bouwsteen gebruiken om "groter" te gaan.

----------- ter illustratie -----------
student: REW(toen ook student), Wil je m'n informatica huiswerk voor me maken?
REW: Nope, dat heet academische fraude, daar werk ik niet aan mee. Ik wil je best helpen met je huiswerk.
student: ok.

We moesten van de prof "top down" werken met steeds verder uitwerken van de "modules".

Dus we moesten "getallen inlezen", "iets er mee doen" en "afdrukken resultaat".

REW: Kan je het probleem opdelen?
student: inlezen, verwerken, afdrukken.
REW: Ok, dan gaan we nu naar het eerste blokje kijken, kan je dat opdelen?
student: Sure. lus tot end-of-file lees getal.
REW: Ok, kan je dat opdelen?
student: eehhh lees karakter, ... ehhh.

We moesten in Pascal programmeren: lees-getal is gewoon ingebouwd, hoef je niet zelf te doen.

Conclusie: Als beginner moet je eerst leren wat de basis-bouwblokken zijn voordat je top-down kan werken.

----------------------------------------------------

Voor jou project, moet je eerst een prototype gaan maken. Een (1!) zender en een ontvanger en kijken of er wat tussen zit.

Als dat werkt ga je kijken of je een module kan bouwen waar 5 of 10 van die zenders/ontvangers naast mekaar zitten en of je een truuk kan verzinnen om te zorgen dat je niet met zender 1 in ontvanger 2...10 schijnt. (ik denk aan schotjes tussen de zenders/ontvangers in de "zendrichting". Als je dan nog steeds met 1 in 2 en 3 schijnt, maar niet meer in 4-5-6, dan ben je een heel eind: Dan moet je zend 1, monitor ontvanger 1. zend 2, monitor ontvanger 2, enz. doen, maar je kan dan tegelijk zeg 11, 21 en 31 doen in de grote opstelling).

Als je nu hebt besloten om de PICO te gebruiken: Prima zet.

Maar je moet dan tzt gewoon een communicatie-systeempje opzetten tussen alle "modules" die ieder zeg 10 of 16 leds doen en ieder een RP2040 (processor op de PICO) bevatten. Dat is gewoon VELE malen makkelijker dan met een een of andere K*** trage IO expander alles op 1 CPU te proberen te doen. Dat is "de verkeerde architectuur".

Samenvattend: We weten nu allemaal wat het uiteindelijk moet worden, maar begin met de bouwstenen. De RPI is prima kapabel om de 38kHz te maken. Dus toon aan dat je een (IR) ledje op 38 khz kan laten knipperen en dat je sensor dat dan detecteert.

wat ik al eerder heb gezegd, ik heb het perfect (binnen de grenzen wat ik kan testen) werkend gehad, dus die opzet voldoet gewoon.
waarom wil ik dan wijzigen met name om het "moderner" en kleiner te maken.
dus ik zit nu te overwegen om een SMD atmega 64 toe te passen, 53 I/O pinnen, lekker klein. ik denk niet echt modern, maar zo oogt het wel :).
ik heb daar werkende code voor, daar is 1 probleem mee, deze is voor een belangrijk deel geschreven door dekees ook hier actief op het forum,
en dat deel is best lastig te begrijpen voor mij, echt geschreven door een pro, al zal het voor vele hier wel lees/begrijpbaar zijn.

in 1e instantie had ik de raspberry pico in gedachten omdat ik deze al toepas in de "hoofd PCB" die o.a. deze "scanner" aanstuurd. maar te weinig I/O, en dan moet ik een hoop improviseren om toch die pico te kunnen gebruiken...en dan is het middel erger dan de kwaal.

dus dan natuurlijk de controller die ik al gebruikte in de werkende situatie, de atmega 32 ook in SMD verkrijgbaar, maar eigenlijk net te weinig pinnen, daardoor zit het adres "in gebakken" in de code, daar heb ik liever een klein dipswitch voor.

dus ik wil een atmega met net wat meer pinnen --> de atmega 64

Dat is niet wat je vroeg in de startpost en wat later ook niet :S

Ik ben eens gaan zoeken naar de topic's van het oorspronkelijk project met die foto's enzo maar ik vind ze niet terug.

in de start post vroeg ik of 38kHz mogelijk was met I2C (PCF8574).
niet dus, en via wat voorstellen, een beetje afdwalen, tot de conclusie gekomen in mijn laatste post,