Próbálj olyan CD40xx IC-ket venni, ahol a tipusjelzés "UBE"-re végződik.
Ez a pufferelt kimenetet jelenti, de jobban védetttek a sztatikus feszültség ellen is.

Még pénteken megjöttek, a pasztamaszkkal együtt.
A műhely új funkciódekódere lesz.
Made in Hungary.

Nagyon pofásan néznek ki gratula!!

Köszönjük!
Nagyobb részben az ifjabbik István munkája. Várjuk az anyagokat hozzá, sajnos idehaza csak az ellenállások, és a kondenzátorok kaphatók, az ATMEGA-t a diódákat, és tranzisztorokat Texas-ból kell hozatni.

Ezt ti fogjátok összeforrasztani???
Soklábúpicibogárka.... nemsemmi.

Már én is meggondolnám, föleg ilyen mennyiségben. Kinában ilyesmit 5 dolcsiért/panel felforrasztanak, ha tölük rendeled az alkatrészt.

Igen, a NYÁK lemezekkel együtt jött a pasztamaszk is.
Megoldjuk...

etwg!
Körbejártuk a témát, és felmerült, hogy beültetve kérjük a cuccot.
Két baj volt vele:
- Meglepő, de NYÁK gyártás majdnem olcsóbb volt, mint Kínában, és házhoz hozták, ingyen. (Mondjuk a NYÁK üzem vezetője itt lakik a szomszéd utcában, az is igaz...)
- Két lényeges alkatrész, a processzor és a funkciókat kapcsoló tranzisztorok nincsnek a gyártó raktárában, így a beültetés pár ellenállásra, kondenzátorra, és diódára korlátozódott volna.
Nem mindig jó megoldás a kínai gyártatás.
A fiam meg nem szeretné pár hónap múlva az Amazonon viszontlátni, más név alatt ugyanezt...

Én csak a soklábut ültettem be Kinában, a többit meg otthon. ( érdekes modon azt megusztam vám nélkül.

Sajnos a beültetö gép, amin korábban szoktam dolgozni már EUn kivül van, igy sajnos nagyon bonyolult lett minden.
A teljesen meghülyült EU vámosok ép a minap vasaltak be rajtam 5,5 eurot egy ingyenes klubkártyáért ( hitelkártya méretü müanyag lap), mert szerintük mindent el kell vámolni ami nem papir egy boritékban. A kollégám sem tud már semmit sem küldeni ilyen idiota szabályok miatt.
A habot a tortára ma a tarfikosom tette fel. A 3,90 dolláros magazint 18,50 Euroért árulják és csodálkoznak, hogy csak a port fogja a boltban.

Mhhh, csak mint írtam nincs náluk.
Így aztán maradt az a megoldás, hogy Magyarországon készül a nyomtatott áramkör és a pasztamaszk.
A Mouser-től jönnek azok az alkatrészek (FET, Atmega, diódák, Zener), amik nincsenek a szomszéd nagykereskedésben, ahová egyébként járok.
Forrasztó paszta van, megfelelő forrasztóállomás is.
Megcsináljuk mi.

Azt egy kicsit kétlem, hogy az Lcsc-n nem találtak, mert szinte minden nagykereskedés innen szerzi be a chipeket az egész világon, nemcsak a kinai eredetüeket.
De mindegy ez a ti dolgotok.
Sok sikert, és örülni fogunk sokan, ha lesz magyar dekoder is.

Pedig sem a megfelelő AVR, sem FET nincs náluk, ami nekünk kell...

Kellett nektek ilyen egzotikus eszközöket beletervezni...
Csak vicc.

Persze, csak több tervezési szempontunk volt.
A korábbi FD2013T-hez képest:
- 2+4 valós funkció kimenet;
- több szolgáltatás, jobb dimmerelhetőség;
- nem lehet nagyobb, mint 11*15mm;
- csak egy oldalon lehet beültetve, hogy ne legyen vastag.

Nos ez sikerült, eddig. Csak, amit a fiam kitalált CV listát, és szolgáltatásokat, az nem fér be egy kisebb kapacitású PIC-be, vagy AVR-be. Ráadásul olyan procit kellett keresnünk, aminek a mérete eléggé kicsi, hogy elférjen a NYÁK-on! Ugyanez a helyzet a kimenetekre dolgozó FET-kel is. Ekkor még nem a kínai gyártó raktára alapján gondolkoztunk. Olyan félvezetőket kerestünk - elvitt pár munkaórát - amelyek raktáron vannak a kedvenc külföldi alkatrész forrásunknál, a Mouser-nél, és nem csak minimális darabszámban.

Amikor a terv már készen volt, akkor merült fel, hogy mi van, ha készre, beültetve rendeljük meg?
El is kezdtük kitölteni az online kalkulációt a kínai gyártó honlapján, és ekkor futottunk bele abba, hogy két kulcsfontosságú elem nincs náluk, azt nem tudják beültetni.

Ekkor fordultunk a hazai NYÁK üzemhez, ami eddig is dolgozott nekünk. És nem lett drágább, mint a kínai gyártatás. Beültetni - ha már az AVR-t, és a FET-ket úgyis nekünk kell - akkor azt pár ellenállást, kondenzátort és diódát mi is be tudjuk majd, azokkal biztos nem lesz bajunk.

Egyébként a próbapanelen összedobott dekóderhez kivezetékeztünk egy Tillig E5 vezérlőkocsit, amiben a menetfényeket egy fehér LED, és a zárfényt egy piros adja, utána fényvezetőkkel vezetik el a fotonokat a lámpákhoz. Mivel az FD2023 funkció dekóderben nem csak a funkció kimeneteket lehet az NMRA ajánlása szerint funkció gombokhoz rendelni, hanem a dimmerelést is, így azt is meg lehet csinálni, hogy a három fehér menetfényhez úgy állítjuk be a dekódert, hogy pl. az F0-lal megy a normál menetfény, az F1-gyel álló helyzetben a halványabb helyzetjelző, és F2-vel pedig a jóval erősebb távolsági fényszóró. Mindezt ugyanazzal a funkció kimenettel. Mindezt pár CV átírásával el lehet intézni. A célunk az volt, hogy ne legyen olyan komplikált ezt megcsinálni, mint az ESU-nál. Az egy agyrém, különösen a 4. és 5. generáció. Azt mindenképpen kerülni szerettük volna, hogy annak a modellezőnek vigye el a dekóder beállítása az idejét - meg az idegeit! - aki nem informatikus. A tesztjeink alapján sikerült.

Most egy pici szünet van, mert finisbe ért a második szolnoki, templomi orgona átépítése, holnap, vagy a jövő hét elején szeretnénk át is adni, utána megy rendelés a Mouser-hez, az 3-4 nap alatt iderepül Texas-ból (a számla az hamarabb itt van a lengyelektől), aztán meglátjuk.

Üdv!

Arduinohoz keresek Xpressnet implementációt. Látott valaki ilyet?

Ezeket találtam, de kétségeim vannak:
https://github.com/nzin/xpressnet_arduino (10 éves és azóta semmi fejlesztés nincs rajta)

https://pgahtow.sourceforge.net/wordpress/?page_id=11 (nekem itt maguk a zip-ek törött linkek kb, de máshonnak ezt az oldalt nagyon linkelik)



Vagy Loconet implementációt csinált már valaki esetleg?

Megkérdezem a fiamat, ő mit használ. Viszont ő csak kiindulási alapnak veszi elő ezeket, rengeteget változtat általában ezeken a programokon, mert nem mindenben felel meg.
A LOCONET, az kompletteb az Arduino-ra, de az annyira ritka mifelénk (is), hogy a modulosokon kívül senki nem használja. Jellemző, hogy csak a PIKO Smartcontroll Light, és a Tillig Daisy2 (Uhlenbrock) használja a gyártók közül ezt a protokollt, senki más.

XPressNetre a https://michaelteeuw.nl/post/the-train-automator-part-1-prototyping/ oldalon lévő szájbarágós dolgot próbálom egy Arduino UNO-val de mégsem megy, sajnos. Egy Roco 10764-es központba van bedugva egy multimaus masterként és slave-ként a 5 voltos https://www.waveshare.com/rs485-board-5v.htm, ami az UNO-hoz van kötve (GND, VCC, TX, RX és egy digitális pinen)

Futtatáskor az uno-n az RX led folyamatosan világít, a TX soha és a küldött parancs nem jut el a sínen lévő mozdonyig.

Az XPressNet libraryt innen importáltam az arduino fejlesztői környezetbe: https://github.com/Digital-MoBa/XpressNet/tree/main

Nekem az rémlik, hogy az arduino-t a masterbe kell dugni, és nem a slave-be. Csak meg kell oldani, hogy a 12V ne jusson be.

Azt hogy a 12 volt ne jusson be hogy érted?

Van master és van slave library is.

Most újra kezdtem és

A https://pgahtow.de/wiki/index.php?title=XpressNet#XpressNet_Client oldalról letöltöttem a "XpressNet Client Library v2.6 (19.11.2021) Download - Zum realisieren eines Handreglers (ROCO Multimaus) oder PC-Interface." linkenlévő Xpressnet.zip fájlt. Ahogy látom ez a slave verzió. A zipben van a mellékelt "architektura" ábra, ez alapján ezen xpressnet zip változathoz a slave aljzatba kell dugni az arduinot.

Nem tudom, mit bénáztam el. A kábeleket megnéztem, ha multimaus-szal használom őket, akkor jók. Tehát gondolom, az nem hiba.

A ROCO erősítők (a "központ" az maga az egér, vagyis a MultiMaus) Xpressnet csatlakozóján át ad stabil +12V tápfeszt az Xpressnet eszköznek. Na ez nem túl egészséges egy Arduino-nak.

Működik a dolog, volt két apró forrasztás, ami bár benne volt a leírásban, kifelejtettem. Alkatrészszükségleg: 1 arduino (pl UNO is elég, 1-2 ezres talán most) + egy kb 1-2 ezerért kapható RS485 converter + 1 darab szokásos multimaus kábel a Roco 10764 slave-jébe dugva.

Annyi issue-m van, hogy az elindulás után az elején valahogy nem mindig találja meg az XPressnet buszt, kell neki idő, majd ennek még utánanézek. De egyébként a Roco 10764-es erősítőm a multimaus mellé slave-ként bedugott LocMaus 2-t is rendszeresen elég soká, néha 1-2 perc alatt veszi észre. Tehát itt szinte biztosan nem az arduinos library a hibás.

Ha valakit érdekel, szóljon és kiteszek ide egy normális tesztprogramot+leírást, persze kell majd hozzá kis idő. Az említett library dokumentációja szerintem elég gyenge, meg azért az implementáció sem mindenhol szép, gondolkozom rajta, hogy írok egy sajátot normális dokumentációval.

A mozdony világítás kikapcsolás pl ennyi

// elso nulla: mozdony cím felső byte
// a következő kettes: mozdony cím alsó byte, tehát ez a kettes mozdony
// a következő nulla: funkció kikapcsot jelent
// az utolsó nulla: a nullás funkció a világítást jelenti
XpressNet.setLocoFunc(0, 2, 0, 0);

A kettes mozdony világítás bekapcsolás meg nyilván ez pl:
XpressNet.setLocoFunc(0, 2, 1, 0);

Lenne két kezdő kérdésem

Miért vannak a váltó címzések 4-es csoportba rendezve, mi értelme van ennek? Egy sima kitérőnek elég lenne 1 cím és azon vezérelni, hogy egyenesben vagy kitérőben van, nem? Pl a https://wiki.rocrail.net/lib/exe/fetch.php?media=xpressnet:xpressnet-v2.pdf oldalon található xpressnet spec 58. oldalán azt látom, hogy "The address is turnout / 4 (group)" (ez egy sima accessory dekódernél használt xpressnet üzenethez van, tehát pl egy váltóállítás)


A másik kérdésem (szintén az 58. oldalra vonatkozóan), hogy mit jelent az, hogy egy kitérőnél aktiváljuk vagy deaktiváljuk az egyik kimenetet? Én megint csak azt gondolnám, hogy egy kitérőnek elég lenne egy cím meg egy darab érték (ami itt a D2, ha jól értem), hogy kitérő vagy egyenes állásban van-e. De mi az az aktív dolog?

Az van a leírásban, hogy

öööööööö, lehet, hogy az egyikre rájöttem

A 4-es csoportosítás azért van, mert tipikusan 4 kimenettel rendelkezik egy eszközdekóder? Tehát pl van egy dekóder, aminek az eszközei a 20,21,22,23 címeken elérhetőek? Szóval ez csak ennyi?

Vagy ha mondjuk 8 kimenetet tud vezérelni egy dekóder, akkor mondjuk a 20,21,22,23,24,25,26,27-es címekre lehet konfigolni? Tehát tulajdonképpen a dekóder konfignál mindig a kezdő címet adjuk meg (ebben az esetben a 20) és a többi következik ebből?

Én saját eszközdekódert akarok csinálni, azért nem vagyok ezekben járatos.


Viszont ezt az aktív flag-et továbbra sem értem

Már régen foglalkoztam ilyesmivel, és ugy rémlik, hogy az eszközön ( cimen) belül a kimeneteket kellett cimezni. Sok dekodér sok mindent tud kezelni ( több váltot, jelzöt, világitást) igy célszerü ezeket igy csoportositani, megsporolnak egy sereg extra dekodert és kihasználják a DCC csomagokat.( cim + adatok).

kösz!

Az aktív flag-et is tudod esetleg, hogy mire jó?

Már nagyon mélyre kellene kutatnom a fejemben, de talán arra van, hogy az jelzi, hogy még mindig azonos cimen vagy, azaz meg nem ment át minden parancs, ami arra a cimre lett tervezve.
De ezt csak találgatom, ne akard, hogy most elövegyem a régi cuccaimat es keresgéljek.
Gondolom még a google is segithet.
Elég kevés ember foglalkozik ilyen mélyen a DCC alapstrukturával, csak az tudna egyböl válaszolni.

Próbáld meg feltenni az index digit vasútmodellezős topikban a kérdést.
ForumIndex digit topic

Lehet, hogy rájöttem, de majd később talán betolom oda is.

Egy alap probléma, hogy váltó dekóderem nincs, most a multimaus kijelzőjén nézem a váltó szimbólumot és abból következtetek arra, hogy az általam küldött váltás jel megfelelő volt-e. Veszek majd egy váltódekódert, mert ez így nem jó teszt, amit csinálok.

Ugye a másik lehetőség az lenne, hogy sniffelem az xpressnet adatfolyamot, de ahhoz arduino mega kellene, az nekem pont nincs, de majd veszek. Azon két soros port is van, az uno-n, nano-n csak egy, az kevés, mert az xpressnet elfoglalja az egyiket az RS 485 miatt.


Szóval ahogy látom, egy váltó dekódernek több kimenete van és ahhoz, hogy szépen átváltson, nem elég az egyik kimenetet átállítani x-re, hanem a másikat is kell ellentétesre állítani. Ez csak feltételezés, majd szerzek egy váltódekódert és azzal le tudom tesztelni normálisan

Ahogy látom, így lehet egyik irányba állítani a váltót:




A 8-as helyiérték (a legelső nulla a bináris jel mellett) azt jelenti, hogy aktiválunk vagy nem aktiválunk egy kimenetet és az egyes helyiérték meg azt jelenti, hogy melyik kimenetről van szó. Na majd ha lesz dekóderem, megírom, mi lett a végső megoldás.

Ha most az elektromágneses váltókra gondolunk, amikben az ide-oda állást egy-egy tekercs végzi, akkor ezeket a tekercseket kell legfeljebb 0,1sec időtartamra áram alá helyezni, annak megfelelően, hogy merre akarjuk állítani. Ezt praktikusan egy-egy nyitott drain-es FET fokozat.

A Lenz által kiagyalt rendszerben egy váltócímen négy eszköz kezelhető, ha megnézed egy ilyen kézivezérlő gombkiosztását (Lenz Set100, Trah HR3), akkor négy váltógomb van rajta. A MultiMaus-n csak egy váltóhoz tartozó kettő, így a címtartomány is el fog térni. Egy Multimaus-n beállított 2-es váltócím az a Lenz rendszerében nem lesz megfelelő, és viszont.

Húha, úgy látom, ez nem olyan egyszerű, mint képzeltem...

A váltóállítók MTB MP5-ösök (lesznek). Akkor először ehhez kellene váltóállító dekódereket választani és utána jön az, hogy meg tudom-e hajtani egy arduinos domino szerű vezérlőpulttal?

Stimmel, az motoros állítómű. Azt másképpen kell kezelni.

Ajánlom figyelmedbe ezt az oldalt. Több helyen fenn van a forráskód is.
PACO

Minden ingyenes, de PIC-re van írva, ha azt a programnyelvet érted, akkor világos lesz, hogy a váltódekóder hogyan működik.
Én nagyon-nagyon nem értek ehhez, csak használom a végeredményt.

Egyébként ez a rendszerek, protokollok közötti inkompatibilitás, amit, ha jól értem, írsz azt is jelenti, hogy ha egy multimaus/wlanmaus vagy micsoda van csatlakoztatva egy mondjuk Z21-hez (vagy akár egy sima multimaus egy Roco 10764-hez) és mondjuk egy traincontrollerrel vagy JMRI-vel van vezérelve az asztal részben és a traincontrollerrel vagy JMRI-vel állítunk egy váltót, akkor a wlanmaus-on a váltóállító ikon helyzete inkonszisztens is lehet? (nem feltétlenül, de ha más váltókezelés, váltódekóder van, mint amit a wlanmaus tud kezelni, és akkor ez az inkonzisztencia egy üzemszerű állapot?)

Nézem, kösz. Elég elkötelezett a srác, jól látom, hogy pl az egyik saját kontrollerénél assembly-ben implementálta az xpressnet protokollt? Azért az kemény

Nem találok bizonyos dolgokhoz forrást. Pl a https://usuaris.tinet.cat/fmco/home_en.htm oldalon a "17. Boards Manager and Queue: XpressNet Route Launcher"-hez van ábra de semmi több dokumentáció.

EDIT:
ja azt hiszem, megvan, a https://usuaris.tinet.cat/fmco/download/Lenguaje_de_programacion_Arduino.pdf oldalon lévő SPANYOL nyelvű leírásból több is kiderül...

Igen, így van. Az adott váltócím nem mindegy, hogyan értendő.
Ugye a MultiMaus-kon, vagy WLAN-os Multimaus-on ez nem kérdés, mert csak a sajátjához van gomb. A baj ott kezdődik, ha egyszerre van kétféle Xpressnek kézivezérlő a rendszerben, vagy mondjuk a Z21-t nem MultiMaus-szal használod. Szerencsére utóbbi esetben a Z21-nél be tudod állítani, hogy Lenz, vagy MultiMaus, és ez a lehetőség meg van a Paco-féle nanoX-s88 központ esetében is.
Egyébként nekünk a műhelyben most épp nincs, mert átdolgozás alatt van, de a váltódekóderünk felismeri, hogy mivel programoztad, és aszerint dolgozik utána. Egyetlen kikötés van vele, hogyha egyszer az egyikkel állítottuk be, akkor azzal is használjuk, mert másik rendszerű vezérlővel újra be kell állítani a címét.

Megvan a megoldás, benbe megírta itt: http://forum.index.hu/Article/viewArticle?a=165255429&t=9043718

"A Roco 1=egyenes, 0=kitérő, a Lenz 9=egyenes, 8=kitérő kódolást használ"

Szerintem ez nem biztos, hogy igaz. Az eltérés a Roco és a Lenz címzés között az, hogy a 4-el való osztás után a Lenz eggyel csökketi a címet, a Roco pedig nem. A 4 váltó csoportosítása a címzés kialakításában keresendő. Részletesebb megismeréshez javaslom a Lenz XpressNet dokumentációjának átnézését. Én ez alapján írtam a Maus és az eszközdekóder programomat is.

Nem pontosan értem, miért írod, hogy nem biztos, hogy ez volt a megoldás.

A címzéssel nem volt problémám, azt hamar megtaláltam, még ha a pontos szabályt nem is ismertem és egyértelműen látszódott, hogy az egyik irányba át is állt a kitérő jelzés a multimauson, majd miután a benbe féle szabályt használtam, minden rendbejött. Persze ez csak teszt volt, ha majd a végleges cuccot használom, akkor rendesen lekódolom a címzés szabályt meg a kódokat is.

Ha jól értem, ez a címzési különbség egy kényelmetlen dolog de nem nagy mágia alkalmazkodni hozzá. Akár jelezhetnénk az ABC betűivel is a kitérőket az meg, hogy 1-essel, ötössel vagy akár ZS betűvel és nem nullával kezdődik a számozás nekem mindegy, leprogramozom, oszt' annyi

Egyébként én ezt találtam a címzéssel kapcsolatban:

https://digitools.hu/wp-content/uploads/2021/08/UM_DigiSwitch-2Gx_ver32_20210817_HU.pdf


https://wiki.rocrail.net/lib/exe/fetch.php?media=xpressnet:xpressnet-v2.pdf

Az XpressNet 4.0 szabvány már 2048 eszköz címzését tette lehetővé. Megnövelték egy Bytetal a címzést, amiből jelenleg csak egy bitet használnak. Így 512*5=2048 a lehetséges cím. Az új XpressNet 4.0 a Lenz-től letölthető.

Elkészültek az első példányok! A képen a kézzel, hagyományos pákával beültetett első példány van. 15*10*1,2mm.
Most jön a neheze, írhatom a használati utasítást hozzá...

Elképzelni nem tudom, hogy lehet azt a chip-et, meg a FET-eket hagyományos pákával beforrasztani - még lábuk sincs. Még a vezetékeket csak-csak megértem, az még talán nekem is sikerülne.
Gratulálok a munkához! Ezek szerint működik!

A 20 éves szem még virgonc...

Nem a szemmel van a baj (ahhoz van nagyító szemüveg).
Nincs LÁBA. Hogyan forrasztod oda???
SMD-t forrasztok én is Sot23-6 méretig megy. (A next 18 már nem megy 0,25 az osztástáv ott már összeforrasztom a két kivezetést...)

Van annak, csak elbújt!
De ez nagyon időrabló módszer. Vizsont így kiderült az is, mennyire strapabíró a cucc, hogy egy nem ideillő technológiával is lehet belőle működőt csinálni.

Ez csak az első példány volt, a mostaniak már forrasztópasztával, és a hozzávaló maszkkal készülnek, infravörös forrasztással.

Csináltunk egy ilyen kis segítséget:
CV kalkulátor

A dekóder alapbeállítás, a hosszú címzés, és a consist mód, és az NMRA funkció mapping az érvényes minden olyan dekóderre, ami ezeket alkalmazza. Az NMRA funkció mapping-t nem használó dekóderekre nem lesz jó: ESU és a koppintásai.

A tartalék funkciók irányfüggését megadó CV-k pedig szintén az NMRA-n alapulnak, de ezek csak specifikusan az FD2023 funkció dekóderre vonatkoznak.

A táblázatokban csak ki kell pipálni az egérrel a kívánt részt, és írja is a CV-kbe írandó értékeket. Az alapbeállítás, például a hosszúcímek esetén csak be kell írni a rubrikába a kívánt címet.

Volt itt, vagy a másik fórumon régebben (6-7éve) egy kérdés, hogy az elkészített sínkavics ágyazat valamennyire vezette az áramot, így az üres sínszakasz is bejelzett a foglaltságérzékelőbe.
Erre volt egy megoldási javaslat, de nem találom...
A kapcsolás ott is ez a 4 diódás volt.
(nekem nem a sínágyazattal van bajom, hanem szeretném csökkenteni az érzékenységét ennek az áramkörnek - ha lehetséges)

Univerzális megoldás nincs. Én már többször irtam, a kapcsolást is közzétettem, és jo 40 éves tapasztalataim vannak ebben a témában. A jelenlegi pályámon is több mint 30 OD van.
Szoval ilyen primitiv áramkörtöl ne várj el csodákat. Ha DCC a rendszer akkor valamivel egyszerübb a dolog, mert ott a sinekben stabil a tápfeszültség. Ott elvben be lehetne állitani az érzékenységet az egyes szakaszokban, de ezt söntöléssel lehetne csak megoldani, ami veszteséggel jár és aránylag kis ellenállásokkal párhuzamosan a diodákkal.
Probálkozhatsz a 2 AC pont közé egy kb 1 kOhmos trimmert berakni, és az ellenállás csökkentésével beállitani a kapcsolási szintet, de számolj azzal, ha az 100 Ohm körül lesz akkor a trimmer hosszu távon tönkre fog menni. Esetleg ha megtalálod a jo értéket akkor egy nagyobb teljesitményü ellenállást használni (>1W).

Itt a rajzon az "érzékelő diódákon" (istenem, de primitív!) esik egy 1,2-1,4V feszültség. Ezt vezetjük ki az optocsatoló LED-jére. A LED-t árammal kell meghajtani, ehhez, attól függ, hogy milyen az optocsatoló, kell egy előtét ellenállás. A LED-n eső feszültség az legyen annyi, amennyi esik az "érzékelőn". A LED stabil működéséhez meg kell legalább 5mA áram.
Vagyis - vegyük a jobb esetet, hogy 1,4V-unk van - 1,4V/5mA =0,28kOhm, vagyis 280Ohm ez előtét ellenállás értéke. A rajzon ez 33Ohm, vagyis 0,042A áramot kerget át az optocsatoló LED-jén, 42mA-t jelent! Nem tudom, hogy milyen optocsatolót használt a kapcsolás kiagyalója, de egy LED maximális árama általában 20mA szokott lenni.
Meg kellene nézni pontosan a következőket, hogy jobb számítást tudjunk végezni:
1: Az alkalmazni kívánt optocsatoló LED-jének paramétereit, vagyis mennyi a minimális árama, és mennyi a maximális?
2: Az "érzékelőben" alkalmazott diódákon mennyi feszültség esik nyitóirányban?
Ha ez a két érték meg van, akkor tudni fogjuk, hogy mekkora feszültségből indulhatunk ki, hogy működtessük vele az optocsatolóü LED-jét, és mekkora előtét ellenállás kell hozzá, hogy elérjük a minimális LED nyitóáramot.

Egyébként meg: a neten megtalálható a LENZ LB100 kapcsolási rajza, ennél lényegesen komplikáltabb áramkörök kerültek már ki a kezed alól. Az egy sokkal jobb, megbízhatóbb, kezelhetőbb kapcsolás, mint ez a vacak.

Ok, köszi Mindkettőtöknek!
Marad a Lenz Tranyós megoldása. Kettő kell csak belőle.