BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: AP3737 op 12 August 2024, 19:43:01
-
Hallo
In deze, en een aantal vervolgbijdragen, wil ik proberen de digitale besturing van de TMC baan te beschrijven, zoals ik die nu zie, en zoals die er in de toekomst volgens mij uit zou kunnen zien. Vooraf een waarschuwing: ik schrijf hier mijn persoonlijke ideeën; wat hier staat is geen officieel TMC beleid en is in de meeste gevallen niet besproken met de leden van de TMC . Het zou dus heel goed kunnen dat ik hier een aantal ideeën beschrijf die de leden van de Vereeniging niet zien zitten, en die dus ook nooit gerealiseerd gaan worden.
De vraag die gesteld kan worden, is waarom ik dan dit draadje begin. Er zijn hierop een aantal mogelijke antwoorden. In eerste instantie helpt het mij om mijn ideeën te structureren. Vervolgens hoop ik dat hetgeen ik schrijf, een aantal leden van de TMC zal helpen, nu of later (waarom was er ook al weer een bepaalde keuze gemaakt). Tenslotte hoop ik op feedback, zodat ideeën verbeterd kunnen worden.
Het is niet mijn bedoeling mooie plaatjes van de TMC baan te tonen. Daartoe kan men beter de TMC website bezoeken: https://twentsemodelspoorweg.club/. Het baanplan is eigenlijk simpel uit te leggen: we hebben de stations Enschede, Hengelo, Delden en Oldenzaal zo goed als op schaal nagebouwd, en er zijn 3 schaduwstations (Almelo, Bad Bentheim en Gronau). Het tijdperk is midden jaren zeventig. Er liggen 230 wissels, er zijn 110 seinen en ongeveer 300 bezetmelders. Waar in het echt wissels liggen en seinen staan, hebben wij ze ook. Om een indruk te krijgen hierbij een foto van station Hengelo
(https://images.beneluxspoor.net/bnls_2024/Station-Hengelo-66ba474d8fd5c.jpg) (https://images.beneluxspoor.net/bnls_2024/Station-Hengelo-66ba474d8fd5c.jpg)
De club heeft bijna 70 leden, en een paar keer per maand zijn er drukbezochte rijavonden. Alhoewel de Vereeniging veel eigen materieel heeft, nemen de meeste leden hun eigen loks en rijtuigen mee. Gereden wordt digitaal; de centrale is een Uhlenbrock Intellibox en we hebben een groot aantal Fremo (Spax) Boosters nagebouwd (zie onder). Voor het rijden worden Fremo Freds gebruikt, die op vele plaatsen op Loconet kunnen worden aangesloten. Als men vanaf (schaduw)station Almelo via Hengelo en Oldenzaal naar (schaduw)station Bad Bentheim wil rijden, moet de “machinist” meelopen en zijn eigen Fred steeds opnieuw af- en aankoppelen. Sinds enige tijd zijn we aan het testen of Apps op mobiele telefoons een goed alternatief voor de Freds kunnen zijn.
(https://images.beneluxspoor.net/bnls_2024/Boosters-66ba474d01f02.jpg) (https://images.beneluxspoor.net/bnls_2024/Boosters-66ba474d01f02.jpg)
De stations Enschede, Hengelo en Oldenzaal hebben ieder een eigen bediening, die op rijavonden ieder bemand worden door een seinhuiswachter. We hebben dus geen vol-automatische baan, en willen dat ook niet. Wel is er op de trajecten tussen de stations een beveiliging (Lenz LG100 Bremsgenerator), die ervoor zorgt dat treinen, indien nodig, automatisch gestopt kunnen worden.
Het geheel loopt reeds vele jaren stabiel en naar ieders tevredenheid. Op zich zou er dus geen reden hoeven te zijn om iets te veranderen. Behalve één ding: voor de besturing van de wissels en seinen worden een aantal PIO kaarten gebruikt, die door zelfgeschreven (VB6) software wordt aangestuurd. Deze PIO kaarten (zie foto hieronder) zijn natuurlijk niet meer te koop, en ook al zouden we er genoeg van op voorraad hebben, passen niet meer in moderne PCs. Het is dus tijd voor iets nieuws. Daarover wil ik een volgende keer iets meer vertellen.
Groet, Aiko
(https://images.beneluxspoor.net/bnls_2024/PIO-192-kaart-66ba474d05325.jpg) (https://images.beneluxspoor.net/bnls_2024/PIO-192-kaart-66ba474d05325.jpg)
-
Leuk draadje, ideeën kan ik vast bij helpen :P
Sinds enige tijd zijn we aan het testen of Apps op mobiele telefoons een goed alternatief voor de Freds kunnen zijn.
Uiteraard heb ik een tweetal handregelaren in de toekomst, die de Fred kunnen vervangen. Maar als je naar draadloos gaat kijken, kan je ook eens kijken naar dit stukje.
Mr Gathow heeft uitgevogeld hoe je elke multimaus kan upgraden naar WLAN multimaus door een ESP en een Lipo er in te hangen. Dit werkt volgens mij wel met dat Z21 protocol. Ik weet niet hoe dat gaat icm een intellibox. Als je de Z21 app echter aan de praat krijgt, moet je dit ook werkend kunnen krijgen.
https://pgahtow.de/w/Z21_WLAN_MultiMaus#Gateway_Software (https://pgahtow.de/w/Z21_WLAN_MultiMaus#Gateway_Software)
Ik heb zelf wel eens een netwerk gemaakt van ESP8266 boards met een 'painless mesh' library. Dat vond ik redelijk simpel te doen, en ik had toen bijna 0 ervaring met draadloze dingen. Alle ESPs vormen onderling een zelf opererend netwerk. Je kan dan in applicatie code, een van de ESPs instellen als brug naar jullie systeem toe. En dan moet je zelf handregelaars fabrieken met een LiPo en ESP er in. Ik zag laatste dat er een nieuwe wemos d1 opvolger (https://hackerstore.nl/Artikel/1587) was met het acculaad circuit ingebouwd. Dat is een leuke basis om zelf draadloze throttles mee te maken, zijnde het als een mesh, met Z21 protocol, Loconet over TCP IP of met WiThrottle protocol. Wat het beste werkt met de IB, volgens mij is dan loconet wel handig, maar ik ben niet echt thuis in uhlenbrocks apparatuur. Ik weet wel dat ze een WLAN loconet interface hebben met nummer 63860.
Ik ben verder benieuwd naar jullie nieuwe wissel decoders (y)
Bas
-
Op zich zou er dus geen reden hoeven te zijn om iets te veranderen. Behalve één ding: voor de besturing van de wissels en seinen worden een aantal PIO kaarten gebruikt, die door zelfgeschreven (VB6) software wordt aangestuurd. Deze PIO kaarten (zie foto hieronder) zijn natuurlijk niet meer te koop, en ook al zouden we er genoeg van op voorraad hebben, passen niet meer in moderne PCs. Het is dus tijd voor iets nieuws. Daarover wil ik een volgende keer iets meer vertellen.
Ok, betreft het alleen de wissels en seinen? Je zoekt daarvoor een alternatief ? Vraag: Wat doet die zelfgeschreven software met die PIO kaarten ? Hangen daar aan de ene kant versterkers aan om de wissels te sturen en aan de andere kant misschien een/het bedieningstableau van het betreffende station ?
Ik lees namelijk:
Het geheel loopt reeds vele jaren stabiel en naar ieders tevredenheid.
wat mij de indruk geeft, dat je geen directe aanleiding hebt om de besturing van de locs (FREDs) te vervangen ?
Vraag: in welke orde-grootte van aantallen FREDs spreken we ? 1-5; 5-10; 10-20; > 20 ?
Grtzz,
Karst
-
Beste Bas en Karst
Dank voor jullie reacties.
Betreft het alleen de wissels en seinen? Je zoekt daarvoor een alternatief ? Vraag: Wat doet die zelfgeschreven software met die PIO kaarten ? Hangen daar aan de ene kant versterkers aan om de wissels te sturen en aan de andere kant misschien een/het bedieningstableau van het betreffende station ?
Ja, de belangrijkste reden voor verandering zijn de PIO kaarten, dus de bediening van wissels, seinen en de bezet terugmelding. Aan deze kaarten hangen inderdaad (zelfgebouwde, maar relatief standaard) versterkers en optocouplers. Aan de bedienkant zijn er wel bedieningstableaus, maar bediening gaat vooral via beeldscherm en muis. Voor ieder station zijn de sporen, wissels en seinen op een beeldscherm zichtbaar. Wisselstraten etc. kunnen zo bediend worden.
wat mij de indruk geeft, dat je geen directe aanleiding hebt om de besturing van de locs (FREDs) te vervangen ?
Vraag: in welke orde-grootte van aantallen FREDs spreken we ? 1-5; 5-10; 10-20; > 20 ?
Hoeveel Freds we precies hebben weet ik zo uit mijn hoofd niet (ik ben momenteel in Zwitserland op vakantie, en kan dus ook niet even natellen). Maar het aantal aanwezige Freds is zeker groter dan 20.
De Freds zijn niet echt een probleem, maar er zijn wel wensen waarin de huidige (oude) Freds niet goed voorzien (we hebben verschillende types). De belangrijkste wensen zijn om meer functies te kunnen bedienen. Veel leden hebben locs met prachtige geluiden, maar (afhankelijk van het type Fred) kunnen daarvan maar een beperkt aantal bediend worden. Ook is soms terugmelding van de "stand" van een functie gewenst (b.v. als F4 Rangeerstand is ingeschakeld, en de "machinist" zich afvraagt waarom de trein zo langzaam rijdt).
De Freds hebben één groot voordeel ten opzichte van de ons bekende alternatieven: het DCC loc adres is relatief vast. Een "machinist" kan dus niet (door een typefout of wat dan ook) er zomaar met een andere trein vandoor gaan.
Mr Gathow heeft uitgevogeld hoe je elke multimaus kan upgraden naar WLAN multimaus
Dat zou een mogelijkheid zijn, maar die is wel relatief duur. Bij de aantallen die wij in gebruik hebben niet meer echt leuk. Zoals ik hierboven al heb aangegeven, is de belangrijkste beperking van de bestaande Freds het beperkte aantal functies, en het niet zichtbaar zijn welke functie nu precies is ingeschakeld. Wat kosten betreft, is een App op je mobieltje natuurlijk de meest interessante oplossing. Op dit moment testen we bv. met WiThrottle. Aan mobieltjes zitten echter wel weer een aantal nadelen. De machinist kan gebeld worden, waardoor de besturing wegvalt (ja, je kan je mobieltje op niet-storen zetten, maar natuurlijk net die ene keer dat je gebeld wordt, was je dat vergeten ...). Bij mobiele Apps kan je relatief eenvoudig typefouten maken, en ervandoor gaan met de trein van iemand anders. Bij alle draadloze systemen kan de batterij opeens leeg zijn, terwijl je dacht dat je hem toch echt had opgeladen.
Ik zag laatste dat er een nieuwe wemos d1 opvolger (https://hackerstore.nl/Artikel/1587) was
Complete zelfbouw zou een optie zijn. Zelf ben ik nogal gecharmeerd van M5-Stack, omdat je daar alles al mooi ingebouwd in een kastje hebt. Maar zelfbouw kost natuurlijk veel tijd om te ontwikkelen, en de prioriteit ligt momenteel bij de vervanging van de PIO kaarten.
Ik ben verder benieuwd naar jullie nieuwe wissel decoders (y)
Komt :). Nog even geduld ;D
groet, Aiko
-
Als je zoveel POI wilt hebben voor je zo laag mogelijke prijs dan zou ik kijken naar POI bordjes met een Mcp23017 chip.
Per Mcp23017 heb je 16 IO pinnen. Deze wordt aangestuurd per i2c. Je kunt acht van deze boards aansluiten op een microcontroller met i2c interface, bv arduino of ESP32. Dat zijn dan 128 IO's.
Je zal dan wel zelf de software moeten schrijven voor de microcontroller.
Interfacing met de PC is dan afhankelijk van de interface van de microcontroller (USB, Ethernet of Wifi (niet de eerste keus)).
mvg spock
-
Als je zoveel POI wilt hebben voor je zo laag mogelijke prijs dan zou ik kijken naar POI bordjes met een Mcp23017 chip.
Per Mcp23017 heb je 16 IO pinnen. Deze wordt aangestuurd per i2c. Je kunt acht van deze boards aansluiten op een microcontroller met i2c interface, bv arduino of ESP32. Dat zijn dan 128 IO's.
Je zal dan wel zelf de software moeten schrijven voor de microcontroller.
Interfacing met de PC is dan afhankelijk van de interface van de microcontroller (USB, Ethernet of Wifi (niet de eerste keus)).
mvg spock
Beste Spock
Dank je voor de suggestie. We hebben inderdaad oplossingen bekeken op basis van een Arduino en I2C I/O extenders. Kom ik nog op terug.
Groet, Aiko
-
Voordat ik mogelijke alternatieven bespreek voor de 192 kanaal Parallelle I/O (PIO) kaarten, wil ik eerst de “ontwerpeisen” (randvoorwaarden, wensen) noemen waaraan oplossingen moeten voldoen.
De eerste en belangrijkste eis, is dat “tijdens de verbouwing” de rijavonden gewoon door moeten gaan. Het is onbespreekbaar als de baan er een aantal maanden uit zou liggen. Als er iets wordt vernieuwd, zou het eigenlijk zo moeten zijn dat, als er onverhoeds problemen optreden, er alleen wat stekkers of printjes verwijderd hoeven te worden en de oude er weer in worden gestopt. Of dat de nieuwe programmatuur wordt gestopt, en de oude weer wordt opgestart.
Het gevolg van deze eis is dat we veranderingen in kleine stapjes moeten uitvoeren.
Een tweede eis is dat de huidige wisselaansturing, op basis van “oude” telefoonrelais, behouden blijft. Het monteren en afstellen van deze aandrijvingen heeft veel tijd en energie gekost. Ze werken goed, en we hebben er (mocht er eens wat kapot gaan) nog genoeg van op voorraad. Bovendien hebben ze niets gekost, dus wat wil je nog meer?
Aan ieder telefoonrelais zit al een printje met daarop een paar componenten, waaronder een printrelais, zodat we vanuit de PIO kaarten en wat “tussen electronica” 48V op de telefoonrelais kunnen zetten, en daarmee het wissel omzetten. Ook de hartstuk polarisatie van de wissels (meest Rocoline) wordt door het printrelais verzorgd, omdat we er achter kwamen dat de contacten van de telefoonrelais niet altijd betrouwbaar werkten. Hieronder wat foto’s van de telefoonrelais en printjes.
(https://images.beneluxspoor.net/bnls_2024/Wisselaandrijving-1-66bb9ccf06322.jpg) (https://images.beneluxspoor.net/bnls_2024/Wisselaandrijving-1-66bb9ccf06322.jpg)
(https://images.beneluxspoor.net/bnls_2024/Wisselaandrijving-2-66bb9ccf5f3ed.jpg) (https://images.beneluxspoor.net/bnls_2024/Wisselaandrijving-2-66bb9ccf5f3ed.jpg)
De printjes zijn allemaal voorzien van 8-polige RJ45 connectoren. Alhoewel niet alle 8 polen aangesloten zijn, is door de keuze van deze 8-polige connectoren verwisseling met de 6-polige Loconet bekabeling (voor de Fred bediening) uitgesloten. Voor ieder station komen alle (witte 8-polige) wisselkabels op een centrale plaats samen. Hieronder een foto van zo’n centrale “schakelkast” waar de kabels samenkomen.
(https://images.beneluxspoor.net/bnls_2024/bekabeling-66bb9ccf06479.jpg) (https://images.beneluxspoor.net/bnls_2024/bekabeling-66bb9ccf06479.jpg)
Een derde eis is dat we de huidige computer programma’s, die op een grafische wijze de stationsemplacementen tonen, na wat aanpassingen, kunnen blijven gebruiken. De “seinhuiswachters / verkeersleiders” zijn aan dit user interface gewend, waardoor fouten worden beperkt.
Naast deze drie “functionele” eisen zijn er ook nog wat “strategische” wensen.
De belangrijkste wens is dat we minder afhankelijk worden van de kennis en ervaring van individuele leden, maar meer richting “standaard” oplossingen gaan. Vooral voor wat betreft de computer programmatuur is dit een lastige wens: enerzijds willen we de huidige programmatuur graag behouden, maar anderzijds zouden we ook met standaard programmatuur (zoals Koploper, RocRail, iTrain, TC, …) willen experimenteren. Een aantal leden heeft thuis dergelijke standaardsoftware in gebruik, en we zouden best eens een tijdje met verschillende programma’s ervaring willen opdoen.
Een tweede wens is dat het geheel niet te prijzig wordt. Alhoewel de Vereeniging er financieel op zich goed voorstaat, moeten we toch steeds op de centen letten. Als we bijvoorbeeld zouden besluiten alle electronica “even nieuw te kopen”, zouden de kosten voor decoders voor de huidige 300 bezetmelders, 230 wissels en 110 seinen al snel richting tienduizend Euro of meer gaan. Dat is geen realistisch plan.
Om kosten te besparen, willen we daarom liefst dingen zelf bouwen. Een probleem dat zich dan natuurlijk wel zou kunnen voordoen, is dat de kennis om bepaalde dingen te bouwen, weer bij een beperkt aantal personen aanwezig komt. Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden. Ook is goede documentatie van zelfbouw projecten essentieel, zodat iets later makkelijk nagebouwd kan worden. Indien mogelijk zouden projecten met de buitenwereld gedeeld moeten worden, via platforms zoals GitHub en OSHWLab, zodat we feedback krijgen en er ook anderen hun voordeel mee kunnen doen.
Dat was het weer voor vandaag. Wordt vervolgd.
Aiko
-
Het gevolg van deze eis is dat we veranderingen in kleine stapjes moeten uitvoeren.
Dat zou je kunnen doen door de wissels stuk voor stuk te vervangen door b.v. motoraandrijvingen. Die worden anders aangestuurd, maar dat kun je ondervangen door er andere hulpprintjes bij te zetten waarmee je de oorspronkelijk aansturing uit de centrale kast kunt behouden.
Ook de hartstuk polarisatie van de wissels (meest Rocoline) wordt door het printrelais verzorgd, omdat we er achter kwamen dat de contacten van de telefoonrelais niet altijd betrouwbaar werkten.
Een oorzaak kan zijn dat de telefoonrelais verkeerd gemonteerd zitten. Nu kan stof op de contacten blijven liggen. In een telefooncentrale werden ze gemonteerd met de contacten vertikaal, zodat stof er tussendoor kon vallen. Bovendien zat er een stofkap over een rek met relais, tenminste bij de telefooncentrale die ik ooit heb gesloopt omdat ik de relais mocht hebben.
Voor een grotere betrouwbaarheid kun je ook meerdere contacten parallel zetten.
-
Als ik jullie wensen bij elkaar optel
De belangrijkste wens is dat we minder afhankelijk worden van de kennis en ervaring van individuele leden, maar meer richting “standaard” oplossingen gaan
+
Een tweede wens is dat het geheel niet te prijzig wordt ..... Als we bijvoorbeeld zouden besluiten alle elektronica “even nieuw te kopen”, zouden de kosten voor decoders voor de huidige 300 bezetmelders, 230 wissels en 110 seinen al snel richting tienduizend Euro of meer
+
Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden
+
Om kosten te besparen, willen we daarom liefst dingen zelf bouwen. Een probleem dat zich dan natuurlijk wel zou kunnen voordoen, is dat de kennis om bepaalde dingen te bouwen, weer bij een beperkt aantal personen aanwezig komt. Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden. Ook is goede documentatie van zelfbouw projecten essentieel, zodat iets later makkelijk nagebouwd kan worden. Indien mogelijk zouden projecten met de buitenwereld gedeeld moeten worden, via platforms zoals GitHub en OSHWLab, zodat we feedback krijgen en er ook anderen hun voordeel mee kunnen doen
=
Open source decoders en terugmelders.
Dit citaat ken je wellicht.
Give a man a fish, and you feed him for a day; teach a man to fish and you feed him for a lifetime.
Naast dat ik 'vis' verkoop, leer ik ook hoe je zelf de vis moet vangen.
Mijn decoders, terugmelders en dingen, die zet ik allemaal online. Ik heb een uitgebreide instructie over je hoe die zelf kan bestellen bij de printenboer. En ik leg uit hoe je het programma er in moet schieten. Daar heb ik makkelijk te gebruiken batch files voor. Je moet nu denken over een prijs van €8,- a €9,- per stuk. En dan hebben we het over een DCC spoel/sein decoder met 16 uitgangen (goed voor 8 wissels of 5x 3 kleuren seinen)
Open Source Solenoid Decoder (https://train-science.com/ossd-open-source-solenoid-decoder/#bestellen-1)
En zo heb ik een 8 voudige DCC servo decoders zonder puntstukrelais, een 6 voudige servo decoder met puntstukrelais, S88 gnd en keerlus printjes. Loconet terugmelders worden op dit moment getest en die komen er ook bij. Ze zijn wel iets duurder te maken, ik denk ~€15 ofzo omdat er gewoon meer op zit.
Ik documenteer alles, ik maak handleidingen, aansluitschema's en ik maak instructie filmpjes. En ik heb uiteraard samples die je kan lenen. Dito voor een nieuwe nog te ontwerpen Fred opvolger.
Releases, source code, pcb files alles staat op deze git repo (https://github.com/bask185/Train-Science-DIY)
Ik heb verder geen trademark of licentie dingetjes naast OSHW ed. Dus doe er mee wat je wilt.
Er vanuit gaande dat je 2 uitgangen per PTT relais nodig en 3.5 uitgangen (sommige seinen zullen cijferbakken hebben??) voor een NS lichtsein dan kom ik met jullie aantallen
300 bezetmelders, 230 wissels en 110 seinen
29 DCC decoders voor wissels
24 DCC decoders voor seinen
19 loconet terugmelders met current sense
Kom ik uit op een schatting van €762,-. En voordat ik op iemands tenen sta, ik verdien er niks aan :P
Het is wel een grove schatting, afhankelijk van factoren kan het €100 mee of tegen zitten, maar het is iig geen €10.000 :police:
En voor de beeldvorming, aanpassingen zijn bespreekbaar. Ik weet alleen niet of dit dan handig is om te doen, want ik ken jullie prints niet. Zelf denk ik aan redesign met 3.5mm plugbare kroonsteentjes en die je kan doorsteken naar volgende decoders en waaraan je een CDU kan hangen.
(https://images.beneluxspoor.net/bnls_2024/deleteme-66bc59e3c7947.png) (https://images.beneluxspoor.net/bnls_2024/deleteme-66bc59e3c7947.png)
DCC decoders hebben wel het voordeel dat je ze lokaler bij de wissels in de buurt kan plaatsen. Dan krijg je veel minder draad en zo kan je geleidelijk je RJ45 dingen vervangen door een DCC decoder. En dito voor bezetmelders. Hoe korter de draden, hoe beter het is.
Zowel DCC als loconet zit op de IB, ik kan je alleen niet veel zinnigs vertellen over je VB6 applicaties. Als jij dat ding met de IB kan laten babbelen, kan je het wellicht werkend houden.
Ik heb zelf alleen ervaring met iTrain en daarmee kan je ook mooie emplacementen mee maken voor op de PC. Dat werkt naadloos via de IB met de bezetmelders, de handregelaars en de DCC decoders. Je kan verder dingen leuke dingen moet rijwegen en acties. iTrain ondersteunt ook de Z21 WLAN maus en daarmee ook de Z21 app. iTrain heeft zelf ook een app natuurlijk. Je kan er mee rijden, maar je kan je wisseltableaus ook op een client tablet draaien. Dan kan je een tablet rijwegen stellen. Dat is dan een optie.
Ik weet niet uit mn hoofd of ze WiThrottle ondersteunen. Dat zou me niet verbazen.
Mvg,
Bas
-
Hi Bas en Klaas
@Bas: Dank voor je aanbod en bijdrage. Inderdaad is door "zelfbouw" veel geld te besparen. Het bedrag wat ik noemde ging uit van commercieel verkrijgbare producten. Dat willen we dus niet uitgeven.
Ik heb je links en websites bekeken, en ik moet zeggen dat ze er prima uitzien (y)
Misschien dat ik echter niet goed gekeken heb, maar ik kon allen .hex en gerber files vinden. Open Source betekent volgens mij dat de broncode / Schema en PCB ontwerp ook gedeeld worden. Dat is, voor zover ik kon nagaan, bij jou niet het geval.
@Klaas:
Dat zou je kunnen doen door de wissels stuk voor stuk te vervangen door b.v. motoraandrijvingen
De bedoeling is juist de huidige wisselaandrijving (=op basis van telefoonrelais) te behouden. Vervangen is veel werk, geeft geen echter verbetering en kost veel geld.
Een oorzaak kan zijn dat de telefoonrelais verkeerd gemonteerd zitten. Nu kan stof op de contacten blijven liggen. In een telefooncentrale werden ze gemonteerd met de contacten vertikaal, zodat stof er tussendoor kon vallen. Bovendien zat er een stofkap over een rek met relais, tenminste bij de telefooncentrale die ik ooit heb gesloopt omdat ik de relais mocht hebben. Voor een grotere betrouwbaarheid kun je ook meerdere contacten parallel zetten.
Wat stof betreft, heb je zeker een punt. Maar de telefoonrelais zijn nu eenmaal al op deze manier ingebouwd. Plastic kapjes hadden we nooit gehad / zijn inmiddels weg. Initieel is wel geprobeerd meerdere contacten parallel te zetten, maar dat was toch niet betrouwbaar. En omdat er toch al een apart relais moest komen om de 48V te schakelen, bleek het tweede contact daarvan prima voor de hartstuk polarisatie bruikbaar.
Groet, Aiko
-
Jawel hoor ;D
Ik heb voor het gemak een scheiding gemaakt voor releases en source code. Je kan het pad onder software volgen naar
/SOFTWARE/DECODERS/OSSD
PCB staat onder
/PCB/DECODERS_N_OCCUPANCY/OSSD/src/PCB/OSSD/
Mvg,
Bas
-
Hi Bas
Ah, heeeeeel mooi (y)
Dan heb ik onvoldoende gezocht. :'(
Groet, Aiko
-
Oplossingsrichtingen
Alhoewel de baanbesturing op dit moment prima voldoet, zijn er op termijn twee mogelijke problemen. Het eerste probleem is dat de huidige PCs verouderd zijn. Ze draaien nog Windows XP en gebruiken PIO kaarten op basis van ISA / PCI sloten. Het tweede probleem is dat er weinig leden zijn die in staat zijn de huidige Visual Basic 6 software te onderhouden en aan te passen.
Eind 2023 zijn er een aantal discussies geweest om mogelijke oplossingsrichtingen aan te geven. Er zijn drie richtingen geïdentificeerd. Twee daarvan worden op dit moment verder uitgewerkt en getest.
1: Behoud van de PIO kaarten.
De oude Windows XP PCs zouden door nieuwe W10 of W11 PCs met PCI express slots vervangen kunnen worden. PIO kaarten zijn nog wel verkrijgbaar. Ook is de VB6 programmatuur eventueel wel om te zetten naar VB-Net. Toch is deze mogelijkheid verworpen. Het probleem dat er weinig leden zijn die de bestaande software kunnen onderhouden, wordt immers niet opgelost. Maar vooral wordt het vasthouden aan PIO kaarten als weinig toekomstgericht gezien.
2: Overstap naar USB besturingskaarten
In plaats van PIO kaarten in de PC, kan ook gekozen worden voor parallel I/O via USB. Deze oplossing heeft als groot voordeel, dat er weinig aangepast hoeft te worden aan de bestaande VB6 programmatuur. Ook hier blijft het nadeel natuurlijk wel dat het probleem van software onderhoud nu niet wordt opgelost, maar naar de toekomst wordt doorgeschoven. Maar omdat deze oplossing eenvoudig uitvoerbaar lijkt te zijn, is besloten de komende tijd hiermee te experimenteren. In wezen zijn hierbij wederom twee varianten mogelijk. De eerste variant is zelfbouw, op basis van Arduino’s en I2C IO Extender ICs. Een prototype daarvan is ontwikkeld, en lijkt te werken. De tweede variant is het kopen van 24 kanaal USB-IO adapters, zoals die bijvoorbeeld door BMC Messsysteme GmbH verkocht worden. Een aantal van deze adapters zijn gekocht, en worden momenteel getest.
Een voordeel van deze gekochte adapters is dat ze ieder een uniek serie nummer hebben, en zo vanuit de software aangesproken worden. Als iemand wat USB stekkers eruit haalt en er later weer instopt, dan blijft het geheel goed werken, ook al wordt de stekker volgorde omgedraaid. Natuurlijk waren we ook nieuwsgierig wat er nu precies in een dergelijke adapter zit, en konden we de verleiding het geheel open te maken niet weerstaan. ;D
(https://images.beneluxspoor.net/bnls_2024/PIO-via-USB-66be26fcd0610.jpg) (https://images.beneluxspoor.net/bnls_2024/PIO-via-USB-66be26fcd0610.jpg)
3: Overstap naar DCC besturing
Het mag duidelijk zijn dat deze oplossing het meest toekomst gericht is, maar ook het meeste werk kost. De grootste uitdaging zal zijn de veranderingen in kleine, reversibele stapjes te doen. De rijavonden moeten gewoon ongestoord kunnen doorgaan.
Het vervangen van de bestaande electronica door DCC electronica lijkt niet het grootste probleem. Er zijn, om te testen, zelfs al wat decoder printjes ontworpen en (door JLCPCB) geproduceerd. Het grootste probleem lijkt de aanpassing van de huidige VB6 software, zodat met DCC centrales gesproken kan worden. Daarover de volgende keer meer.
Groet, Aiko
-
De vorige keer heb ik aangegeven dat de grootste uitdaging zit in het aanpassen van de bestaande VB6 software, zodat het met de wissel / terugmeld centrales kan praten.
Ik schrijf bewust “centrales” in de meervoudvorm, omdat ik een voorstander ben van, wat mijn vroegere baas noemde, “separation of concerns”. Die slogan wil zeggen dat je geen dingen gaat vermengen die niets met elkaar te maken hebben. Concreet: voor het schakelen van wissels en voor het ontvangen van bezetmeldingen kies ik het liefst voor gescheiden centrales. Hoe minder verschillende taken een centrale te doen heeft, hoe minder er mis kan gaan. Ik ben daar bij mijn eigen baan 20 jaar geleden tegenaan gelopen: mijn toenmalige Windows XP PC hield zich niet altijd aan de RS-232 (CTS) flow-control regels, waardoor berichtjes verloren gingen als de PC en (Lenz LZV100 / LI100F) centrale gelijktijdig wilden zenden. Door gescheiden centrales te nemen voor wissels en voor terugmeldingen, kan er bij grote banen met veel data verkeer minder misgaan.
Voor communicatie tussen PC en centrale is gekozen voor XpressNet, met daaraan toegevoegd een aantal (XpressNet achtige) Z21 commando’s. Door deze keuze hebben we redelijk wat opties voor wat betreft centrales. Uiteraard kunnen we Lenz centrales gebruiken, maar ook verschillende anderen, waaronder Digikeijs / Yamorc en Roco. Daarnaast zou ook zelfbouw op basis van de Z21PG mogelijk moeten zijn.
De keuze voor XpressNet heeft nog een belangrijke reden: een aantal van de leden die zich met digitale zaken bemoeien hebben thuis ook XpressNet. Dat maakt testen eenvoudiger.
De wissels zelf worden geschakeld met behulp van DCC Accessory Commands. Bijna iedere decoder kan daar mee omgaan, en dat zal over 10 à 20 jaar waarschijnlijk nog wel zo zijn.
Misschien ten overvloede: het is niet de bedoeling dat de treinbesturing volledig geautomatiseerd wordt. De “machinisten” blijven dus zelf hun treinen besturen; de VB6 software doet dat niet. RailCom terugmelding is daarom ook niet nodig; een simpele melding of een baanvak bezit is of niet, is voldoende. Als we wel RailCom terugmelding hadden gewild, dan was XpressNet natuurlijk onvoldoende en hadden we misschien serieus naar iets als BIDIB moeten kijken. In een volgende bijdrage kom ik echter nog op bezetmelding terug, omdat dat misschien de lastigste keuze is.
Een andere belangrijke keuze is het laag 1/2 protocol tussen PC en Centrale. De eerste vraag die dan beantwoord moet worden, is USB of netwerk? En als je voor netwerk kiest, zijn de volgende keuzes bedraad (802.3) of WIFI (802.11), en TCP dan wel UDP. Mijn eigen voorkeur gaat, als het even kan, richting bedraad netwerk en TCP. Desondanks zullen we proberen alle opties open te houden.
Bij netwerken is galvanische scheiding tussen de verschillende apparaten standaard. Bij USB is dat niet altijd zo. Bij kleine banen is galvanische scheiding waarschijnlijk niet nodig, maar bij grote banen, die veel gevoeliger zijn voor storingen, wel. Natuurlijk kan je USB ook achteraf voorzien van USB-isolatoren, maar bij netwerken is dit standaard.
Een tweede voordeel is dat je communicatie over netwerken eenvoudig met tools zoals Wireshark kan analyseren. Je ziet dan precies welke berichtjes er tussen PC en centrale worden uitgewisseld, waardoor het opsporen van fouten wordt vereenvoudigd. Tegenwoordig kan Wireshark ook de data over USB-poorten wel monitoren, maar dat gaat toch minder comfortabel.
Een derde voordeel is dat netwerkinterfaces meerdere parallelle verbindingen ondersteunen. Dit is niet alleen handig voor monitor en analyse software, maar vooral ook omdat nu de bezetmeldingen van de trajecten tussen twee stations gehoord kunnen worden door de PCs van beide stations. Bij USB, maar ook in de huidige situatie waar we nog PIO kaarten hebben, is dat niet mogelijk, en is er een centrale server nodig voor de trajecten tussen de stations.
Een vierde voordeel is dat netwerk interfaces ieder een eigen adres / lokale naam hebben (mits ze juist zijn geconfigureerd). Hierdoor kan je netwerk stekkers er uit trekken, en later er gewoon (desnoods in een andere poort) weer in stoppen. Bij USB is dat vaak niet mogelijk. Ook heeft USB het nadeel dat er verschillende snelheden mogelijk zijn; als de baudrate verkeerd is ingesteld, werkt niets.
Tenslotte is data-uitwisseling over een netwerk zeer betrouwbaar, mits er gebruik wordt gemaakt van het Transport Control Protocol (TCP). Dit protocol zal transmissiefouten detecteren, en herstellen. Ook met UDP kan wel betrouwbaar gewerkt worden, mits het onderliggende netwerk betrouwbaar is. Dat is normaal gesproken het geval bij bedrade netwerken, maar niet bij altijd bij WIFI. Voor mij is het daarom ook niet goed te begrijpen dat Roco voor UDP heeft gekozen, te meer daar ze de Z21 in sets met WIFI routers aanbieden.
Dat was het weer voor vandaag.
Groet, Aiko
-
Hierdoor kan je netwerk stekkers er uit trekken, en later er gewoon (desnoods in een andere poort) weer in stoppen. Bij USB is dat vaak niet mogelijk.
Dat kan opzich wel bij USB, maar dat hangt van je hardware en een beetje software af. Als je bijvoorbeeld een originele Arduino pakt en een Chinese kopie, zie je de naam arduino uno terugkomen in je device manager bij de originele. Waarbij de Chinese verschijnt als CH340 (de USB TTL chip). Die originele arduino's hebben programmeerbare FTDI USB <> TTL chips. Die kan je dan zelf programmeren en voorzien van iets van een unieke ID waardoor je niet meer afhankelijk bent van willekeurig uitgedeelde com poort nummers. Maar zoals je waarschijnlijk al doorhebt. Dat is veel werk waarbij ethernet meer plug n play is ::)
een aantal van de leden die zich met digitale zaken bemoeien hebben thuis ook XpressNet. Dat maakt testen eenvoudiger.
Ik snap het toch niet helemaal. Zoals ik het lees, is er niet een fysieke Xnet bus? En gebruik je het Xnet protocol alleen tussen PIO kaarten en PC ???
De Freds gaan op loconet.
Terugmelders, (heb je dat nog niet verteld of zitten die ook op de PIO kaarten en heb ik het niet begrepen) Xnet kent geen terugmelders.
Dus naast PC - centrale interactie, is er ook nog een fysieke Xnet bus? Gebruiken jullie ook nog multimausen oid?
Want ik zie dan niet in wat het voordeel is van het Xnet protocol tov het Lnet protocol als je alleen kijkt naar de PC <> centrale(s) interactie.
vziw gebruikt die IB ook geen Xnet voor PC communicatie?
Ik heb gespeeld met loconet en xpressNet en ik vind loconet ansich wat makkelijker. Vooral als je zelf je dingen maakt, kan je gewoon makkelijker berichten toevoegen. Ik weet niet hoe Xnet spul zoals een Lenz centrale nou omgaat als dat ding een bericht ziet wat die niet herkent. Volgens mij kan bij Xnet de centrale het bericht gewoon tegenhouden als de payload volgens hem niet ok is.
Als je perse Xnet nodig heb voor iets, zou ik eerder kijken naar een DR5000 / yamorc / Z21 centrale die het beiden hebben.
Of anders iets van hubjes die elk een Xnet <> Lnet omzetter is zodat je zowel freds als multimausen in dezelfde hub kan prikken (wat wel lichtelijk risicovol is)
Maar ik ben wel nieuwsgierig geworden.
Treinen en Freds gaan op de IB.
Accessoires gaan over de PIO kaarten.
Terugmelders die gaan ook over de PIO kaarten?
Heb je dan 2 centrales waaronder de IB en de PIO interface aan de PC hangen?
Mvg,
Bas
-
Hi Bas (en anderen)
Dat kan opzich wel bij USB, maar dat hangt van je hardware en een beetje software af. .... Maar zoals je waarschijnlijk al doorhebt. Dat is veel werk waarbij ethernet meer plug n play is
Klopt!.
Ik snap het toch niet helemaal. Zoals ik het lees, is er niet een fysieke Xnet bus? En gebruik je het Xnet protocol alleen tussen PIO kaarten en PC ???
De Freds gaan op loconet.
Misschien dat een foto de huidige situatie duidelijker kan maken. De foto toont de PC voor 1 station, ieder station heeft zijn eigen PC.
De PIO kaarten zitten in de PC en komen met behulp van een aantal flatcables naar buiten. Meteen achter de PC worden ze gesplitst en gaan naar meerdere 25-polige SUBD-connectoren. Daarvandaan gaan ze door middel van standaard 25-polige ronde kabels, die meerder meters lang kunnen zijn, naar de elektronica om wissels om te zetten of sporen bezet te melden.
(https://images.beneluxspoor.net/bnls_2024/Flatcables-PC-tekst-66cdb8dd43c42.jpg) (https://images.beneluxspoor.net/bnls_2024/Flatcables-PC-tekst-66cdb8dd43c42.jpg)
Omdat veranderingen in kleine, reversibele stapjes moeten gaan, is het de bedoeling om in een eerste stap de VB6 software niet meer de PIO kaarten in de PC aan te sturen, maar:
- Experiment 1: USB-PIO converters, of
- Experiment 2: een Ethernet - TCP/IP - XpressNet interface. Daarvandaan gaat het naar een centrale (Lenz, Z21, Yamorc, zelfbouw, ...), die speciale TMC "test" decoders aanstuurt, die weer worden aangesloten op de 25 polige ronde kabels.
Op deze manier kunnen we, als iets niet werkt, binnen een paar minuten teruggaan naar de oude situatie (SUBD-Connectoren omsteken, oude VB6 software opstarten). Pas als het een tijd stabiel werkt, zouden we de USB-PIO converters / Ethernet / XpressNet kunnen doortrekken (en de bestaande 25 polige bekabeling kunnen verwijderen).
Er komt dus geen XpressNet bus langs de baan, om handregelaars in te stoppen. Daarvoor blijven we Loconet / IB / FREDs gebruiken (dus geen multimaus).
Ook wordt de (IB) centrale voor rijden NIET gebruikt voor terugmelding / wissels schakelen.
Terugmelders, (heb je dat nog niet verteld of zitten die ook op de PIO kaarten en heb ik het niet begrepen)
De huidige terugmelding / bezetmelding wordt ook door de PIO kaarten gedaan. Dat moet in de toekomst ook anders.
Ik zal over bezetmelding in een volgende, uitgebreid bericht, wat meer vertellen.
Xnet kent geen terugmelders.
Dat klopt niet helemaal. Lenz heeft de RS-Bus, en de meldingen van deze bus worden door de Lenz centrale via daarvoor gedefinieerde XpressNet commando's verstuurd. Roco doet iets vergelijkbaars.
Groet, Aiko
-
Nee dat klopt wel. Er bestaan geen XpressNet fysieke terugmelders, losse terugmelders zit niet in dat protocol. Wat wel bestaat is een XpressNet broadcast bericht van de Xnet master met informatie over terugmelders, daar heb jij het over. Maar die informatie komt van echte terugmelders die op andere fysieke bussen zitten en dat kan van alles zijn zoals bijvoorbeeld de RS bus. Of in het geval van Roco dan die R-bus. (fun fact: R-bus kan je zien als dialect van XpressNet. Het lijkt er veel op. Een of andere kerel uit Tsjechie heeft dat uitgevogeld maar ik kan zijn website nooit zo snel vinden)
Ik weet niet of die broadcasts ook daadwerkelijk plaatsvinden op de Lenz centrales. Ik heb ze dat ooit gevraagd maar die mail is nooit beantwoord.
Ik weet dat de DR5000 het wel doet.
En volgens de Roco customer support doet de z21 het weer niet, en om die reden heb ik ook nooit een R-bus melder gekocht om dit zelf te testen, want die zijn *** duur. Maar ik kreeg ook van de customer support te horen dat je dat 'niet nodig' hebt. Dat maak ik zelf wel uit ::)
Experiment 2: een Ethernet - TCP/IP - XpressNet interface
Die heb je dus ook voor loconet. Ik meen dat uhlenbrock er een heeft. Maar je kan ook zelf met een Arduino een USB <> loconet omzetter maken. En als je iets meer tijd heb, koop je zo'n ethernetshield en maak je zelf je Loconet <> ethernet interface.
Want dan
De huidige terugmelding / bezetmelding wordt ook door de PIO kaarten gedaan. Dat moet in de toekomst ook anders.
Kan je dus zelfbouw (bestuckte) loconet terugmelders gaan fabriceren voor weinig.
Ik zal over bezetmelding in een volgende, uitgebreid bericht, wat meer vertellen.
Ik wacht geduldig af :angel:
Mvg,
Bas
-
Je bent niet helemaal bij de tijd met jouw kennis ;)
Nee dat klopt wel. Er bestaan geen XpressNet fysieke terugmelders, losse terugmelders zit niet in dat protocol.* Wat wel bestaat is een XpressNet broadcast bericht van de Xnet master met informatie over terugmelders, daar heb jij het over. Maar die informatie komt van echte terugmelders die op andere fysieke bussen zitten en dat kan van alles zijn zoals bijvoorbeeld de RS bus. Of in het geval van Roco dan die R-bus. (fun fact: R-bus kan je zien als dialect van XpressNet. Het lijkt er veel op. Een of andere kerel uit Tsjechie heeft dat uitgevogeld** maar ik kan zijn website nooit zo snel vinden)
*) jawel hoor: Bluecher maakt(e) die dingen al ruim 10 jaar geleden. En sinds de laatste Build kunnen onze YD6016RB-CS dat truukje ook. De grap is, dat er door onze "OpenDCC" vrienden een uitbreiding op het XpressNet protokol is gemaakt. De Z/z21 pikken dat op en leiden de berichten verder naar een applicatie als ware het een LocoNet melder. Overigens heft dit gelijk het maximum aantal melders aan de RBus op. De RBuys van de z/Z21 in XBUS mode zetten, dan de YD6016RB-CS ook in XBus modus zetten, en je hebt 2048 mogelijke terugmelders !
**) nou nee hoor, dat was een Nederlander in 2014 :P
Ik weet niet of die broadcasts ook daadwerkelijk plaatsvinden op de Lenz centrales*. Ik heb ze dat ooit gevraagd maar die mail is nooit beantwoord.
Ik weet dat de DR5000 het wel doet.
En volgens de Roco customer support doet de z21 het weer niet,** en om die reden heb ik ook nooit een R-bus melder gekocht om dit zelf te testen, want die zijn *** duur. Maar ik kreeg ook van de customer support te horen dat je dat 'niet nodig' hebt. Dat maak ik zelf wel uit ::)
*) Lenz kent alleen RS melders, maar broadcast die dan ook wel degelijk via XpressNet. Geen "special-feature", staat gewoon in de specs.
**) @Roco: ken je product... de nieuwste FW op de z/Z21 heeft de mogelijkheid om ook die melders als LocoNet melders te broadcasten
Grtzz,
Karst
-
Dat klopt helemaal. Ik volg niet actief alle nieuwtjes van openDCC, roco en lenz. Druk bezig met throttles en ABC modules maken enzo. Ik vogel voor nu uit wat voor mij belangrijk is te weten. Wat een z21 precies doet, ja het zal wel ::) Ik geloof nog in het 1 bus principe.
Maar uit nieuwsgierigheid. Kan je nu met een z21 start met laatste FW nu ook 2048 terugmelders hebben?
Mvg,
Bas
-
Maar uit nieuwsgierigheid. Kan je nu met een z21 start met laatste FW nu ook 2048 terugmelders hebben?
Yep ! Ik denk momenteel zelfs dat onze YD6016RB-CS de enige Module op de markt is, die dat kan. Let wel, de aansluiting is via de tot X-Bus getransformeerde R-Bus, de meldingen volgen via het Z21-Protokol in de LocoNet tunnel. En ja, de FW voor de z21 (start) moet minimaal 1.43 zijn. Werkt zelfs met de maintenance tool en met de Z21 App ;)
Overigens werkt het ook via de "gewone" XBus van de z/Z21, maar die is langzamer dan de omgebouwde R-BUS.
Grtzz,
Karst
-
Bezetmelding
Zoals in mijn vorige bijdrage reeds vermeld, overwegen we om voor het schakelen van wissels / seinen, en voor het melden of sporen bezet zijn, verschillende (als het kan, zelfbouw) centrales te gebruiken. Dat we wissels en seinen met DCC willen schakelen, zal tot weinig discussies leiden. De keuze voor het terugmeld protocol is echter minder vanzelfsprekend. Er zijn meerdere opties, zoals S88, LocoNet, RS-Bus, X-Bus, Can, Bidib, RailCom, en waarschijnlijk nog wel een paar. Ik verwacht dat de verschillende Forum lezers hierin verschillende keuzes maken, maar als er iets niet klopt in mijn redenatie, of als er feiten zijn die ik niet ken, dan hoor ik het graag.
Voordat een keuze wordt gemaakt, is het misschien verstandig eerst de eisen te noemen waaraan de bezetmeldbus moet voldoen.
- Er moeten meerdere fabrikanten zijn die componenten maken voor deze bus.
- De bus moet betrouwbaar kunnen werken, ook bij grote banen (lange kabels, veel melders).
- Het moet voor de leden van de TMC mogelijk zijn om kosten te besparen door zelf bezetmelddecoders te maken (of bouwpakketten te kopen).
Aan de eerste eis is eenvoudig te voldoen; voor alle bezetmeldbussen zijn er eigenlijk wel een aantal fabrikanten die spulletjes leveren.
De tweede eis is makkelijk geformuleerd, maar wat betekent het precies? Daarop is geen eenduidig antwoord te geven; iedere techneut zal daarbij een ander antwoord geven. Voor mij betekent het onder andere dat de terugmeldbus en de voedingslijn galvanisch gescheiden moeten zijn. Als de voeding en de terugmeldbus met elkaar elektrisch verbonden zijn, kan stroom voor de voeding en stroom voor terugmelding elkaar beïnvloeden, wat bij lange leidingen tot moeilijk reproduceerbare fouten kan leiden. Galvanische scheiding kan door middel van opto-couplers (of moderne, maar ook duurdere, digitale isolatoren) op de terugmeld bus, maar ook door geïsoleerde DC/DC-omvormers, zoals de Recom 0505, op de voedingslijn. Verder is een bus die werkt op basis van stroomsturing minder gevoelig voor storingen dan een bus die werkt op basis van spanningssturing.
De derde eis is misschien wel de meest bepalende. Niet alleen moeten er goede open source libraries beschikbaar zijn (inclusief documentatie), maar vooral de eis dat we zelf voldoende kennis in huis moeten hebben, betekent dat de uiteindelijke keuze beperkt zal zijn.
Uiteindelijk komen er voor ons twee bussen in aanmerking: Loconet en RS-Bus.
RS-Bus heeft het voordeel dat we zelf veel kennis en ervaring in huis hebben. Ik heb zelf in het verleden een open source RS-Bus library geschreven (https://github.com/aikopras/RSbus), en denk dat deze bus nog weinig geheimen heeft. De bus is op alle decoders met opto-couplers ontkoppelt, en maakt gebruik van stroomsturing. De snelheid is relatief beperkt, maar om alleen te melden of sporen bezet zijn, is de snelheid voldoende. Bekabeling is relatief onkritisch, en er kunnen makkelijk 50 decoders aan één bus gehangen worden zonder dat er problemen optreden.
Loconet is (bij zelfbouwers) erg populair, en lijkt daarom een veilige keuze. Toch kies ik daar niet voor, omdat ik er niet van overtuigd ben dat een gemiddeld Loconet zelfbouw project, op basis van de MRRwA library en een Arduino Uno/ATMega328 (https://mrrwa.org/loconet-interface/), voor grote banen even betrouwbaar werkt als een RS-Bus zelfbouw project. Voor mij geldt: eerst zien, dan geloven. Het bewijs dat een (hardware / software) project precies zo functioneert als de specificatie zegt, is pas gegeven als het met behulp van een Logic analyser / scoop gevalideerd is. Ik begrijp niet goed dat ik, voor wat betreft de MRRwA library en de ATMega328, hierover niets kan vinden op het web. Ik weet dat in de praktijk veel mensen tevreden zijn met de MRRwA library / ATMega328, maar hoe groot zijn die banen? Voldoen ze aan de eis dat, binnen 2us nadat de Carrier Sense concludeert dat de lijn vrij is, begonnen wordt met zenden?
Ik heb al eens eerder op dit forum een draadje gestart (https://forum.beneluxspoor.net/index.php?topic=110394.0), en ik zal mijn twijfels hieronder proberen samen te vatten.
Het eerste verschil tussen een RS-Bus en gemiddeld Loconet zelfbouw project is, dat de RS-bus standaard op alle decoders met behulp van optocouplers is ontkoppelt, en een gemiddeld Loconet zelfbouw project niet. Daarnaast is de RS-Bus gebaseerd op stroomsturing, wat in mijn optiek betrouwbaarder is als spanningssturing.
Het belangrijkste verschil voor mij zit echter in de keus van de processor en hoe de processor belast wordt, vooral door tijdkritische code en Interrupt Service Routines (ISRs). De MRRwA library is geschreven voor de “oude” AtMega processoren (328, 2560, 32U4, ATTiny84, ATTiny84A, ATTiny841), alhoewel er later ook wat toevoegingen zijn gedaan, waardoor het ook zou moeten lopen op STM32F1 en de ESP8266. Ze draaien echter niet op de moderne “opvolgers” van de Atmega serie, zoals de AVR/DxCore (of PIC18) processoren. Deze nieuwe processoren zijn niet alleen goedkoper dan de oude AtMega processoren, maar het belangrijkste verschil zit in het feit dat de nieuwe AVR/DxCore (en PIC) processoren allerlei “peripherals” hebben, zoals het Event System, Core Independent Peripherals, en timers die direct aan externe signalen gekoppeld kunnen worden. Hierdoor kunnen veel taken in hardware verricht worden, zonder de processor (via ISRs) te belasten.
Hoe dit verschil tussen de oude AtMega en de nieuwe AVR/DxCore processoren in de praktijk uitpakt, kan ik misschien het beste uitleggen aan de hand van een tweetal plaatjes die ik gemaakt heb tijdens het testen van mijn RS-Bus implementatie.
Het eerste plaatje toont de belasting van de RS-Bus library op een oude AtMega processor. De bovenste lijn toont de ontvangen RS-Bus pulsjes, de onderste lijn de keren dat de processor een interrupt krijg. We zien dat iedere 200us een interrupt plaatsvindt, om het polling proces te volgen en om te bepalen of/wanneer er gezonden mag worden
(https://images.beneluxspoor.net/bnls_2024/ISR-Software-66cdecb149a07.png) (https://images.beneluxspoor.net/bnls_2024/ISR-Software-66cdecb149a07.png)
Het tweede plaatje toont de belasting van de RS-Bus library op een nieuwe AVR/DxCore processor (en gebruik van een TCB timer). Bij deze nieuwe processoren kan de Timer zelf de polling pulsjes tellen, zonder tussenkomst van de processor. Er is alleen nog maar een Interrupt nodig als we iets willen zenden (middelste lijn). Met de nieuwe AVR/DxCore processoren is het volgens mij veel gemakkelijker om de RS-Bus software in combinatie met andere software betrouwbaar te laten werken.
(https://images.beneluxspoor.net/bnls_2024/ISR-TCB-66cdecada198c.png) (https://images.beneluxspoor.net/bnls_2024/ISR-TCB-66cdecada198c.png)
Misschien dat dit enige uitleg behoeft. In het verleden heb ik met een aantal Arduino libraries problemen gehad, Voorbeelden zijn (of waren, misschien zijn de Libraries inmiddels aangepast) de MOBATOOLS (MOdellBAhn Tools) en de LCD Library. Ook heb ik problemen met Serial output gehad. De problemen werden veroorzaakt doordat de Libraries zelf gebruik maakten van lange ISR (meerdere tientallen us) of zelf strenge timing eisen stelden, waaraan niet in alle omstandigheden werd voldaan. De problemen traden slecht sporadisch op, maar waren heel vervelend (een wissel werd niet omgezet, een baanvak werd niet bezet gemeld). Bij dergelijke problemen is het heel lastig de oorzaak te vinden. Alleen door gebruik van een Logic analyser en het investeren van veel tijd, konden de fouten gevonden en verholpen worden. De les die ik hieruit heb geleerd, is dat het gebruik van ISRs, indien mogelijk, beperkt moet worden, en als ze toch nodig zijn, ze zo kort mogelijk moeten zijn (paar us, zeker geen tientallen us). Vooral bij de nieuwe AVR/DXCore is dit extra belangrijk, omdat je daar ISR geen hogere prioriteiten kan geven.
Ik ben er vrij zeker van dat ook Loconet veel betrouwbaarder wordt als deze op moderne processoren wordt geïmplementeerd. In feite hebben anderen dat al bewezen. Geert Giebens heeft een implementatie gemaakt voor een PIC18 (https://github.com/GeertGiebens/DIY_LocoNet_S88_DCC/) en Mikael Ejberg voor een AVR DA (https://www.ejberg.dk/portfolio/loconet-avr-da/). Ik denk dat deze twee implementaties veel betrouwbaarder met andere software kunnen samenwerken dan de standaard MRRwA implementatie op een oude AtMega processor.
Voor zover ik weet is er voor Geert’s Loconet implementatie geen standaard (C/C++) Arduino bibliotheek aanwezig. Voor Mikael’s implementatie is er wel een Arduino bibliotheek (https://github.com/ejbergdk/loconet-avrda), maar de documentatie daarvan is uiterst beperkt. Natuurlijk heb ik ook gekeken of ik misschien de MRRwA library zou kunnen aanpassen maar, om heel eerlijk te zijn, vind ik de source code daarvan niet erg getuigen van gestructureerd programmeren (de .cpp file telt meer dan 2000 regels). Ik zal mij van verdere kwalificaties onthouden.
Bij LocoNet zou ik als eis stellen, dat de voeding en terugmelding galvanisch gescheiden moet zijn, en dat een moderne processor en goede Library gebruikt moet worden, waarmee tijdkritische functies in hardware plaatsvinden. Alhoewel me dat zeker mogelijk lijkt, zou het ons op dit moment veel tijd kosten om dat helemaal alleen te ontwikkelen en te testen. Onze/mijn kennis van LocoNet is (zeer) beperkt, en als anderen weinig of geen interesse hebben in deze nieuwe hardware, dan is het voor ons (om dit alleen te doen) jammergenoeg op dit moment te veel werk. Het lijkt ons daarom op dit moment sneller en eenvoudiger als we gebruik maken van de RS-Bus voor terugmelding.
Om toch de weg naar LocoNet niet geheel af te sluiten, is een optie de bezetmelder electronica op een opsteek (piggy-back) print te zetten, die eventueel makkelijk vervangbaar is. Dus zoals Blücher dat vroeger al deed (https://www.bluecher-elektronik.de/produkte/gleisbesetztmelder-gbm16xn-vers-2-x/) en ik dat dankbaar heb gekopieerd: https://oshwlab.com/aikopras/rs-bus-smd
Groet, Aiko
-
Hallo Aiko,
Geboren en getogen in Hengelooooo :) laat dit mijn hart wel sneller kloppen. Als klein jongetje (met toen nog een peronkaartje) altijd staan kijken naar de treinen helemaal naar Utrecht en Amsterdam en naar het voorzichtig klaarzetten van de goederenwagons aan het perron van van Gent&Loos.
Overigens, de kruiswissels bij het kopspoor lijken me niet helemaal te kloppen. Je kon vanuit het kopspoor alleen naar Oldenzaal, niet naar /enschede. Maar dat zullen jullie wel uit praktische redenen zo hebben gedaan.
Ik las ook over de telefoonrelais? Dat doet me denken aan de modelspoorclub van de PTT in Hengelo waar ik lid van was (via de buurman). Daar waren toen ook plannen om Hengelo na te bouwen. Ik ging tegen die tijd elders wonen, hoe dat afgelopen is weet ik niet. Of is de TMC een voortzetting vanuit o.a. de modelspoorclub van de PTT?
Ik kom zeker een keer kijken als ik weer in Twente ben.
Ik vraag me af hoe de machinisten bij jullie communiceren met de verkeersleiding. De VL zal toch moeten weten waar de machinist naar toe wil terwijl jullie handmatig rijden?
-
Beste Bas, Karst en Joop
@Joop
Geboren en getogen in Hengelooooo :) laat dit mijn hart wel sneller kloppen. Als klein jongetje (met toen nog een peronkaartje) altijd staan kijken naar de treinen helemaal naar Utrecht en Amsterdam en naar het voorzichtig klaarzetten van de goederenwagons aan het perron van van Gent&Loos.
Leuk dit te lezen; heel herkenbaar. Ik woon "pas" sinds 1974 in Twente (wisselend Enschede en Hengelo), maar als klein jongetje deed ik dit ook maar dan in Zwolle!
Overigens, de kruiswissels bij het kopspoor lijken me niet helemaal te kloppen. Je kon vanuit het kopspoor alleen naar Oldenzaal, niet naar /enschede.
Je bedoelt de kruising op onderstaande foto? Ja, je hebt volgens mij gelijk, en kan je daarvandaan alleen naar Oldenzaal. Maar volgens mij hebben we daar ook een normale kruising liggen, en klopt dat ook. Maar ik zal volgende keer eens precies kijken, als ik weer op de club ben.
(https://images.beneluxspoor.net/bnls_2024/Station-Hengelo-detail-66cf63c4139cf.jpg) (https://images.beneluxspoor.net/bnls_2024/Station-Hengelo-detail-66cf63c4139cf.jpg)
Ik las ook over de telefoonrelais? Dat doet me denken aan de modelspoorclub van de PTT in Hengelo waar ik lid van was (via de buurman). Daar waren toen ook plannen om Hengelo na te bouwen. Ik ging tegen die tijd elders wonen, hoe dat afgelopen is weet ik niet. Of is de TMC een voortzetting vanuit o.a. de modelspoorclub van de PTT?
Oei, goede vraag. TMC heeft inderdaad haar wortels in Hengelo, en bestaat al sinds 1957 (zie: https://twentsemodelspoorweg.club/historie/). Maar of / hoe de relatie met de PTT was, weet ik niet. Er zijn een paar leden die de beginjaren nog kennen, maar ik ben "jongste lid", en moet nog veel leren. Maar ik zal onze voorzitter eens vragen. Die weet veel!
Ik kom zeker een keer kijken als ik weer in Twente ben.
Dan moet je op de opendag langskomen (als ik het me goed herinner, de laatste zondag van oktober). Dat is voor bezoek veruit het leukst!
Ik vraag me af hoe de machinisten bij jullie communiceren met de verkeersleiding. De VL zal toch moeten weten waar de machinist naar toe wil terwijl jullie handmatig rijden?
We communiceren "draadloos", indien nodig met stemverheffing ;D :police:
Wat wel bestaat is een XpressNet broadcast bericht
De Lenz XpressNet specificatie kent meerdere berichten die te maken hebben met terugmelding. Terugmelding kan betrekking hebben op wissels die van positie veranderen, maar ook de veranderde bezetmelding van sporen. Er zijn niet alleen broadcast meldingen, maar je kan ook zelf de status opvragen, waarna je een "gewoon" bericht terug krijgt. Wat Karst zegt, klopt helemaal! Kan ik niets meer aan toevoegen.
Ik geloof nog in het 1 bus principe
Ik vermoed dat ik weet welke bus dat voor jou is. Je hebt mijn vorige bericht gezien, dus ik zou zeggen: maak een goede opvolger van de MRRwA library die de mogelijkheden benut van de DxCore processoren, en ik ben bij je (y)
Groet, Aiko
-
Als je een lcsc nummer heb van een geschikte chip. Kan ik het huidige ontwerp kopiëren. En de cpu uitwisselen. Ik kon op mn phone ff snel C1019766 opgraven. Ze hebben er niet superveel van.
-
Hi Bas
Als je een lcsc nummer heb van een geschikte chip. Kan ik het huidige ontwerp kopiëren. En de cpu uitwisselen. Ik kon op mn phone ff snel C1019766 opgraven. Ze hebben er niet superveel van.
Nu wordt het leuk (y)
JLCPCB heeft ze niet zelf op voorraad (dus een nummer geven is niet voldoende), maar je kan ze heel makkelijk als "Global Sourcing parts" bestellen. Ik weet niet of je dat ooit al eens gedaan hebt, maar het is een echte aanrader. Via Global Sourcing Parts kan je via JLCPCB bij alle grote componentverkopers (Farnell, Mouser, ...) direct inkopen, voor de standaard prijs van die leverancier. Je betaald JLCPCB niets extra's. Je betaald de componenten wel meteen zelf, waarna ze in "My Parts Library" komen. Zo hoef je nooit meer componenten die JLCPCB niet zelf heeft, met de hand te solderen.
Ik heb er zelf een aantal in "voorraad":
- AVR32DA48-I/PT C1016536
- AVR64DA64-I/PT C3228496
De 32/64/128 geeft het geheugen aan.
DA = de eerste D serie.
DB = een iets anderee serie, heeft o.a. ingebouwde OpAmps.
28/23/48/64 = aantal pootjes.
Een alternatief voor JLCPCB is gewoon een DIL28 AVR te kopen bij b.v. Mouser. Je zou dezelfde kunnen nemen als Mikael Ejberg, dus de AVR128DA28 (of de AVR64DA28 of AVR32DA28).
Tenslotte kan je ook een curiosity AVR kopen van microchip. Ik meen dat ik daar ooit iets als 30 Euro voor heb betaald.
Als je met deze nieuwe processoren aan de gang gaat in een Arduino (of PlatformIO) omgeving, heb je de DxCore board definitie nodig die je op GitHub kan vinden. De auteur (Spence Konde) heeft geweldig werk verricht door alle peripherals makkelijk toegankelijk te maken.
Je kunt, zoals Michael, de AVRs ook met Microchip Studio programmeren, maar daar ben ik niet echt fan van.
Realiseer je wel dat je met deze chips in een "nieuwe wereld" komt. Registers etc. hebben allemaal andere namen en structuren. dat is in het begin even wennen. Ik meen dat deze nieuwe wereld al door Atmel met de XMega serie is ingevoerd, dus dat is ook al weer meer dan 10 jaar geleden.
Ook moeten ze met UPDI geprogrammeerd worden. Als je dat door hebt, is het veel simpeler en sneller dan de oude methode.
groet
Aiko
-
Beste allemaal
Vandaag een korte status update.
Zoals in een eerdere bijdrage reeds vermeld, willen we onze (zelfgeschreven VB6) baanbesturing-software koppelen aan één of meerdere digitale centrales via het XpressNet protocol. Een eerste versie van de XpressNet library is inmiddels geschreven, en wordt getest. Alhoewel we eigenlijk maar een paar XpressNet commando's nodig hebben (schakelen van accessories en terugmelding), hebben we alle XpressNet V4 commando's geïmplementeerd, behalve dubbel en multi-tractie. Als de library is goed bevonden, zal het als open source DLL via GitHub worden gedeeld. Maar voor die tijd moeten we eerst uitgebreid testen.
Tijdens het schrijven van de library merkten we dat het Z21 protocol veel gelijkenis vertoond met het XpressNet protocol. We hebben daarom meteen ook maar een aantal Z21 commando's geïmplementeerd, zodat we straks flexibel zijn in de keuze van centrale (Lenz, OpenDCC, Yamorc, Z21, Z21PG, ...)
Om de library goed te kunnen testen, hebben we ook een eenvoudige applicatie gemaakt (zie screenshot hieronder). Ook worden alle commando's en alle antwoorden van de centrale in een logfile opgeslagen, zodat we exact kunnen zien wat er gebeurd. De eerste tests met de Lenz LZV100 centrale gaven geen echte verrassingen. Toen we andere centrales gingen testen, liepen we echter tegen een aantal problemen aan. Die willen we eerst helemaal begrijpen, voordat we verder gaan.
(https://images.beneluxspoor.net/bnls_2024/Test-UI-66dc8e4d0565b.png) (https://images.beneluxspoor.net/bnls_2024/Test-UI-66dc8e4d0565b.png)
Verder wordt, als het goed is, vanavond nog de door Bas gemaakte handregelaar afgeleverd. Die gaan we natuurlijk ook testen (y)
Groet, Aiko
-
Hebben jullie al eens aan een OC32 gedacht?
-
Hi Martin
Hebben jullie al eens aan een OC32 gedacht?
Goede vraag. Voor zover ik weet, hebben we nooit aan de OC32 (Dinamo) gedacht. Als ik lees wat de OC32 kan, dan denk ik dat dat zeker een alternatief geweest zou zijn. We zijn nu echter al twee dingen aan het testen: een USB PIO converter en een zelf ontwikkelde print. Deze laatste print kan 24 kanalen besturen, heeft DCC-in en RSBus-uit (en serieel), en zou je als een soort "eenvoudige OC32" kunnen zien.
Groet
Aiko
-
Ik heb een kopie getrokken van de loconet terugmelder en in de DIY repo gezet. Nu heb ik de atmega en het loconet comperator circuit er uit geknikkerd tbv een redesign.
(https://images.beneluxspoor.net/bnls_2024/deleteme1-66f1caf93824f.png) (https://images.beneluxspoor.net/bnls_2024/deleteme1-66f1caf93824f.png)
(https://images.beneluxspoor.net/bnls_2024/deleteme-66f1cad8ae67f.png) (https://images.beneluxspoor.net/bnls_2024/deleteme-66f1cad8ae67f.png)
Ik wil er tzt een AVR32DA48-I/PT in knikkeren. Die zijn niet al te duur en in worst case wordt de €15 loconet terugmelder, een €16 loconet terugmelder.
Niet veel werk opzich, maar all in good time.
Mvg,
Bas
-
Hi Bas
Ik wil er tzt een AVR32DA48-I/PT in knikkeren. Die zijn niet al te duur en in worst case wordt de €15 loconet terugmelder, een €16 loconet terugmelder.
(y)
Nu je toch bezig bent. Denk ook eens aan een galvanische scheiding tussen voeding en Loconet. Waarschijnlijk is dat het makkelijkst in de voedingsleiding, met iets zoals een Reko 0505.
Aiko
-
Waarom zou je dat doen? naast dat dat ding duur is. De rails zijn zelf al galvanisch gescheiden van de inputs. Ik wil het 5V circuit wel vanuit loconet voeden.
-
Beste Forum lezers
Zoals in een eerdere bijdrage al vermeld, Hebben we een XpressNet library (DLL) geschreven, zodat onze (Visual Basic) PC-programmatuur makkelijk kan praten met met DCC Command Stations. Alhoewel het ons vooral om wissel (accessory) en terugmeld commando's gaat, hebben we ook de meeste andere XpressNet commando's geïmplementeerd. Omdat het XpressNet protocol op een aantal plaatsen overeenkomt met het Z21 protocol, hebben we de library ook meteen maar uitgebreid met een aantal Z21 commando's.
Tijdens het testen van wissel commando's met de Lenz en Yamorc centrales liepen we tegen een aantal (voor mij verrassende) verschillen op. Aan de hand van een tweetal plaatjes zal ik deze verschillen uitleggen.
(https://images.beneluxspoor.net/bnls_2024/Accessory-Activate-Lenz-670668a029f19.png) (https://images.beneluxspoor.net/bnls_2024/Accessory-Activate-Lenz-670668a029f19.png)
Het bovenste plaatje toont wat er gebeurt als de PC een XpressNet "Schaltbefehl" (blauw) naar een Lenz centrale (LZV100/LZV200) stuurt (zie §3.2.24 van de XpressNet V3.6 mit
LAN/USB Interface specificatie). In dit XpressNet commando is het "Ausgang aktivieren" bit gezet (het rode bit).
Na ontvangst van dit commando begint de centrale met het versturen van een continue stroom van identieke DCC "Zubehördecoder" pakketjes (zie
§2.1 van RCN 213). Bij ieder van deze DCC-pakketjes is eveneens het "Ausgang aktivieren" bit gezet (rode bit). Zolang de "Ausgang" geactiveerd is, zet de decoder spanning op de betreffende uitgang (bv. een wisselspoel). Afhankelijk van wat de centrale nog meer te doen heeft, wordt ruwweg elke 20ms dit pakketje opnieuw gestuurd. Het idee hierachter is dat je op je handbediening net zo lang een knop ingedrukt kunt houden, totdat "iets" zijn eindstand heeft bereikt. Ik vermoed dat deze manier van werken door Lenz is bedacht, in een tijd dat er alleen handbediening, maar nog geen computer besturing bestond.
De stroom pakketjes stopt pas, als de PC een XpressNet "Schaltbefehl" (groen) stuurt, met daarin het "Ausgang aktivieren" bit op 0 (het rode bit). De Lenz centrale stopt dan met het sturen van DCC wissel commando's. De Lenz centrale stuurt echter geen DCC "Zubehördecoder" pakket met het activeren bit op 0!
Het continue versturen van identieke DCC wissel commando's zorgt voor een onnodige belasting van de DCC centrale en bekabeling, zeker als er ook veel andere DCC commando's verstuurd moeten worden. De DCC-specificaties (van de NMRA en RCN) geven daarom ook alternatieven om een decoder uitgang te deactiveren. Het eerste is gebruik te maken van specifieke CVs (Configuratie Variabelen), die aangeven hoelang (im ms) een uitgang geactiveerd moet zijn. Het tweede alternatief is het versturen van een DCC "Zubehördecoder" pakketje waarin het "Ausgang aktivieren" bit is uitgezet (dus de waarde 0). Het blijkt dat Lenz dit laatste pakketje NIET verstuurd.
Zoals uit het onderstaande plaatje blijkt, stuurt de YAMORC centrale dit DCC deactiveren commando WEL. Ook dit commando wordt een (instelbaar) aantal keren herhaalt (default: acht). Mocht de PC geen Xpressnet deactivate sturen, dan zal de YAMORC centrale na een bepaalde tijd (2,5 sec), uit zichzelf een DCC deactiveer commando sturen (de groene pijlen rechts onder).
(https://images.beneluxspoor.net/bnls_2024/Accessory-Activate-Yamorc-670668a029f19.png) (https://images.beneluxspoor.net/bnls_2024/Accessory-Activate-Yamorc-670668a029f19.png)
De vraag die je nu zou kunnen stellen is "waarom zijn bovenstaande details voor de TMC van belang?". Het antwoord is eenvoudig: de meeste wisselaandrijvingen hebben 2 spoelen. Als er spanning wordt gezet op de eerste spoel, schakelt de wissel in een bepaalde positie; als er spanning wordt gezet op de tweede spoel, schakelt de wissel in de andere positie. Bij de TMC worden wissels echter geschakeld met (oude) telefoonrelais. Als er spanning op het relais wordt gezet (activeren), schakelt de wissel naar de ene positie. Als de spanning weer wordt weggehaald (deactiveren), schakelt de wissel naar de andere positie. We dachten dus door middel van het activate bit in het XpressNet (en DCC) commando de wissel in de ene dan wel andere stand te kunnen zetten. Dat blijkt dus niet zo te zijn.
Weer wat geleerd,
Aiko
-
Ik weet nog van experimenten met die Xnet library van Gathow dat de Xnet bus ook echt vast liep als ik niet op tijd een nieuwe instructie verstuurde met die activation bit op 0. Dan zag ik op de multimaus bijvoorbeeld zowel de stand voor rechtdoor als gebogen tegelijkertijd en niks werkte dan nog.
Ik weet dat marklin hun eigen Motorola decodeer chip had laten ontwikkelen. Zo konden ze zonder software een accessoire decoder op de markt krijgen. Dan wordt zo'n activation bit best belangrijk. Ik heb het idee dat de nieuwe K83/M83 decoders er nog steeds gebruik van maken. Ik weet nog mij de MSA dat die marklin banen (bediend) door iTrain altijd absurd lange pulsen stuurde en dat in 2 voud. Die schakelde 2x 500ms per wissel ofzo. Met de verwijderde eindafschakelaars kon je dat goed horen brommen.
Het blijkt dat Lenz dit laatste pakketje NIET verstuurd.
Dit vind ik heel raar eigenlijk. Je zou denken dat dit met sommige oudere decoders mis zou moeten gaan? Wanneer de spoelen niet meer uit gaan.
In mijn source negeer ik die activation bit als die 0 is. Ik kijk dan alleen naar de direction bit. Een goede decoder doet zijn eigen puls tijd regelen. Misschien 1x instellen maar dan heb je nooit meer last van 'vreemd handelende centrales'.
We dachten dus door middel van het activate bit in het XpressNet (en DCC) commando de wissel in de ene dan wel andere stand te kunnen zetten.
Ik zou dan eerder denken om de code van de decoders aan te passen? Ik neem aan dat jullie wissels al een tijdje operationeel zijn toch? Wat is er veranderd?
Mvg,
Bas
-
Beste allen
Eerst een vraagje aan de mensen met verstand van loconet: is er ergens een loconet monitor waarmee ook de belasting op de bus, aantal collissions (=te korte berichten) en transmissie fouten (XOR?) bekeken kunnen worden?
Achtergrond, we hadden gisteren tijdens testen massieve problemen, die pas overgingen nadat we de JMRI PC met Z21APP en monitor software helemaal afkoppelden. We merken dat we behoefte hebben aan betere monitoring.
@Bas: volgens de NMRA/RCN specs is het versturen van een DCC Accessory Command met activation bit =0 OPTIONEEL. Vind ik ook raar, en kan dat alleen verklaren uit het feit dat (de "uitvinder van DCC) Lenz het niet stuurt.
@Bas: Natuurlijk schrijven we onze decoder software zodanig dat het gewoon werkt. Een gedachte dat we gewoon het relais (de spoel) activeren dan wel deactiveren, leek echter ook best verdedigbaar. Maar werkt dus toch niet.
@Bas: de Z21PG gaan we ook nog wel testen :-)
Groet, Aiko
-
Ik denk dat je de mrrwa library redelijk makkelijk kan aanpassen om minstens het aantal berichten te monitoren en te tellen hoeveel verkeerde checksums er binnen komen. Dan kan je met een Arduino en een loconet interface het eea monitoren via usb en een terminal.
Het moet ook mogelijk zijn om collisions te volgen die andere apparaten veroorzaken. Het laatste wat ik me herinner is dat er dan een pauze plaatsvindt waardoor iedereen weet van de collisie. Maar ik moet dan met mn neus de documentatie induiken en dan iets van een callback toevoegen aan die Library.
Bas
-
Ik denk dat je de mrrwa library redelijk makkelijk kan aanpassen om minstens het aantal berichten te monitoren en te tellen hoeveel verkeerde checksums er binnen komen.
Ja, aanpassen van de mrrwa library is inderdaad een mogelijkheid
Het moet ook mogelijk zijn om collisions te volgen die andere apparaten veroorzaken. Het laatste wat ik me herinner is dat er dan een pauze plaatsvindt waardoor iedereen weet van de collisie. Maar ik moet dan met mn neus de documentatie induiken en dan iets van een callback toevoegen aan die Library.
Ik vermoed dat collisions het makkelijkst gedetecteerd kunnen worden door te kijken of er een signaal is, dat na korte tijd (enige us) wordt afgebroken. Daarna moet het even stil zijn. Pauze alleen lijkt me een onvoldoende voorwaarde.
Het lijkt me dat dit alles low-level in de mrrwa library moet worden aangepast, dus in de statemachine die het loconet pakket samevoegd. De mrrwa library is helaas niet bijzonder "onderhouds vriendelijk" geschreven. Heeft niemand anders zoiets geschreven?
Groet, Aiko
-
Tja.... mrrwa...
dit zijn de autoren: Alex Shepherd, John Plocher, Damian Philipp, Tom Knox, Hans Tanner, Björn Rennfanz (https://www.arduinolibraries.info/authors/mrrwa)
Stuk voor stuk "kopstukken" van de internationale LocoNet scene...
Ik heb geen ervaring met hun LocoNet lib, alleen... dat heb ik wel met de DccNMRA lib. Gemaakt door dezelfde mensen. En daarover heb ik een hele stellige mening, die ik hier niet zal ventileren ::)
De mrrwa library is helaas niet bijzonder "onderhouds vriendelijk" geschreven.
dat geldt ook voor de dccNMRA lib, Aiko heeft het naar mijn menig hééél erg netjes verwoord ;)
Grtzz,
Karst
-
Ik vermoed dat collisions het makkelijkst gedetecteerd kunnen worden door te kijken of er een signaal is, dat na korte tijd (enige us) wordt afgebroken. Daarna moet het even stil zijn. Pauze alleen lijkt me een onvoldoende voorwaarde.
Correct. Collisions kunnen echter uitsluitend op bitlevel ( en dan ook nog de 1 bits ) door de zender gedetecteerd worden! ( 1 bit wil gestuurd worden, maar 0 bit wordt gelezen. Dat betekent, dat een andere deelnemer mee zit te blèren op de lijn)
Vanaf extern kun je alleen een evt. framing error of de al genoemde "break" detecteren. Dat break-detecteren kun je gewoon met de UART doen als je daarvoor kiest.
Voor alle andere gevallen ben je aangewezen op het controleren van de het hele bericht én de daarbij behorende XOR.
Allemaal niet heel makkelijk dus. Je moet dus eigenlijk bit-bangend verzenden. en een paar microseconden daarna teruglezen wat er op de lijn staat. Allemaal niet erg timing en processor vriendelijk. Ik gebruik daarom zowel voor het zenden als het ontvangen gewoon de UARTs. Dat doet de job uitstekend. Het enige dat me kan overkomen, is dat ik een paar honder microseconden te laat door heb dat er een collision is. Maar het is toegestaan door De LN specs
All transmitters are responsible for detecting TRANSMIT COLLISIONS on a 1 bit or whole echo-byte basis. If a TRANSMIT collision is detected the TRANSMITTER will force a line BREAK of 15 BIT times with a Low or "SPACE" on LocoNet, and decrement the Transmit Attempt count. (The device can attempt the next acess at the same Priority, or change it by some small amount, depending on an internal Phase reference, if the delay from Network free to Seizure is greater than 2uS).
All receivers will process the BREAK as bad data framing and reset Message parsers The network is then free to re-arbitrate access. Any message that has format or framing errors , data errors or is a fragment caused by noise glitches and does not completely follow the MESSAGE FORMAT will be ignored by ALL receivers, and a new OPCODE will be scanned for re-synchronization.
Grtzz,
Karst
-
Hi Karst
Ik gebruik daarom zowel voor het zenden als het ontvangen gewoon de UARTs. Dat doet de job uitstekend. Het enige dat me kan overkomen, is dat ik een paar honder microseconden te laat door heb dat er een collision is. Maar het is toegestaan door De LN specs
Klopt het dat je dan, nadat een compleet byte is verstuurd, het ontvangen byte vergelijkt met het verstuurde? Hierdoor wordt dus na ongeveer 500us gecheckt of er een collission heeft plaatsgevonden? Lijkt me (bij hoge belasting) niet ideaal, maar ik ben met je eens dat continue interrupts afhandelen nog minder is. Ik heb het nog niet in detail begrepen, maar misschien is de aanpak van Mikael Ejberg (https://www.ejberg.dk/portfolio/loconet-avr-da/) toch wel interessant.
Groet, Aiko
-
Hallo Aiko ..
<dames en heren, nu iets heel anders>
is dat lage houten stoeltje met afgezaagde pootjes nog steeds op de club?
Die pootjes afzagen heb ik iets van 32 jaar geleden gedaan .....
:-)
Guus
-
Ik heb wel eens gelezen dat iemand bij gebruik van RS485 op een atmega een pin change interrupt gebruikte op TX om daarmee een hardware timer en een ISR te starten waarmee hij periodiek (1 bit lengte) de niveaus deed checken van zowel Rx als Tx. Als Rx dan niet gelijk was aan Tx, dan had je een collision te pakken. Wordt wel een interrupt feestje zo ;D, maar als het werkt?...
-
Klopt het dat je dan, nadat een compleet byte is verstuurd, het ontvangen byte vergelijkt met het verstuurde? Hierdoor wordt dus na ongeveer 500us gecheckt of er een collission heeft plaatsgevonden?
Correct, zo wordt het behandeld. Maar het is minder erg dan gedacht. Bij bit-wise check zit je tussen 120 en 540 us aleer je een collision detecteerd.
Lijkt me (bij hoge belasting) niet ideaal, maar ik ben met je eens dat continue interrupts afhandelen nog minder is.
A) het valt binnen de specs, B) bitbangen is een groter euvel in een RTOS omgeving ;)
Ik heb het nog niet in detail begrepen, maar misschien is de aanpak van Mikael Ejberg (https://www.ejberg.dk/portfolio/loconet-avr-da/) toch wel interessant.
De AVR-DAx is zo in te stellen, dat het teruglezen op bit-level gedaan kan worden door de USART zelf. Dan zit je dus op het niveau van bitbangen, zonder te bitbangen :P
@bask,
Het gaat over LocoNet, niet over XpressNet (RS485) en op XpressNet heb je geen collisions, omdat dat een gepolled protocol is, met voorgeschreven time-out tijden.
Grtzz,
Karst
-
Ja dat weet ik, ik had ook helemaal niet over XpressNet. Waar het om ging is dat bij je loconet dezelfde approach zou kunnen gebruiken voor een snellere collision detectie op de genoemde primitievere atmega. Bij beiden heb je een Rx en Tx pin.
-
::) :-X
-
@Bas: Zou je niet veel beter een logisch poortje kunnen nemen, in plaats van iedere 60us een interrupt? Want interrupts zijn behoorlijk kostbaar.
@Karst: Ik ken de precieze structuur van Loconet berichten niet, maar voor zover ik begrijp kan een zender pas een collision vaststellen als hij zelf een HIGH zend (en dus een lijnspanning verwacht van > 4 Volt) terwijl een ander een LOW zend (dus de lijnspanning naar 0V trekt). Een collision kan daarom alleen gedetecteerd worden als de bitpatronen die twee zenders versturen, ergens verschillen. Dat kan dus best een tijdje duren. 500us lijkt me dus inderdaad geen probleem; ik vermoed zelfs dat het kan voorkomen dat de collision pas in het tweede byte gedetecteerd kan worden.
Om heel eerlijk te zijn, verbaast het me wel als nog niemand een Loconet monitor heeft geschreven die ook collissions en transmissiefouten kan tellen.
Groet, Aiko
-
@Bas: Zou je niet veel beter een logisch poortje kunnen nemen, in plaats van iedere 60us een interrupt? Want interrupts zijn behoorlijk kostbaar.
Geen slecht idee. een XOR poortje op RX en TX. Is er een verschil, geeft die 1, anders 0. Moet nog wel een filtertje van ca. 500nS achter.
@Karst: Ik ken de precieze structuur van Loconet berichten niet, maar voor zover ik begrijp kan een zender pas een collision vaststellen als hij zelf een HIGH zend (en dus een lijnspanning verwacht van > 4 Volt) terwijl een ander een LOW zend (dus de lijnspanning naar 0V trekt). Een collision kan daarom alleen gedetecteerd worden als de bitpatronen die twee zenders versturen, ergens verschillen. Dat kan dus best een tijdje duren. 500us lijkt me dus inderdaad geen probleem; ik vermoed zelfs dat het kan voorkomen dat de collision pas in het tweede byte gedetecteerd kan worden.
Klopt, schreef ik eerder al van die 1 (high) bits. Bovendien is het juist heel waarschijnlijk dat het pas na de OPCODE fout gaat. Een bezetmeldbericht heeft als eerste byte bijvoorbeeld altijd dezelfde waarde.
Om heel eerlijk te zijn, verbaast het me wel als nog niemand een Loconet monitor heeft geschreven die ook collissions en transmissiefouten kan tellen.
Even een stukje terug lezen. Een collision kun je als zodanig niet extern detecteren. ( en dus ook niet loggen )
Een benadering zou zijn om Framing errors en Break condities te monitoren. Maar daarvoor heb je direct access naar je UART nodig. Wat nog het eenvoudigst zou zijn is om paketten waarvan de XOR ;) :P niet klopt te loggen. Dat "zou" een collision indicatie kunnen zijn. Maar evengoed één of andere lijnstoring.
Grtzz,
Karst
-
Hi Karst
Geen slecht idee. een XOR poortje op RX en TX. Is er een verschil, geeft die 1, anders 0. Moet nog wel een filtertje van ca. 500nS achter.
Daarom zijn volgens mij de DxCore processoren juist voor Loconet interessant. Ze hebben dit allemaal hardwarematig aan boord.
Even een stukje terug lezen. Een collision kun je als zodanig niet extern detecteren. ( en dus ook niet loggen )
Een benadering zou zijn om Framing errors en Break condities te monitoren. Maar daarvoor heb je direct access naar je UART nodig. Wat nog het eenvoudigst zou zijn is om paketten waarvan de XOR ;) :P niet klopt te loggen. Dat "zou" een collision indicatie kunnen zijn. Maar evengoed één of andere lijnstoring.
Algemeen (=niet Loconet) kan je collissions vaak detecteren door te checken of de gemeten framelengte niet minder is dan de minimale framelengte. Want als een CD-mechanisme het zenden onmiddellijk stopt nadat de collision optreed, worden er minder bits verstuurd dan zou mogen. Als Loconet implementaties dat allemaal ook zouden doen, was mijn oorspronkelijk vermoeden dat je hierdoor misschien collisions zou kunnen detecteren.
Ondertussen heb ik geleerd (dank hiervoor :)) dat a) zenders niet onmiddellijk hoeven te stoppen, maar dat ook kunnen doen nadat een compleet byte is verstuurd, en b) dat een Break wordt verstuurd door de zender(s) die de collision detecteert. Dit break signaal trekt de lijn 15 bittijden (=900us) laag;een toestand die normaal gesproken niet zou mogen voorkomen (of zie ik dit mis?).
Zou je daarom niet een heel eenvoudige Loconet collision counter kunnen maken door te meten hoe vaak de lijn 900us (of langer) laag is? In DxCore (en waarschijnlijk ook moderne PIC) processoren zou dit zeer eenvoudig te programmeren moeten zijn, met nauwelijks CPU belasting. Of zie ik wat over het hoofd?
Groet, Aiko
-
Daarom zijn volgens mij de DxCore processoren juist voor Loconet interessant. Ze hebben dit allemaal hardwarematig aan boord.
Zeker interessant.
Algemeen (=niet Loconet) kan je collissions vaak detecteren door te checken of de gemeten framelengte niet minder is dan de minimale framelengte. Want als een CD-mechanisme het zenden onmiddellijk stopt nadat de collision optreed, worden er minder bits verstuurd dan zou mogen. Als Loconet implementaties dat allemaal ook zouden doen, was mijn oorspronkelijk vermoeden dat je hierdoor misschien collisions zou kunnen detecteren.
Dat is dan de Framingerror die door een UART gezien en gemeld wordt. (vanwege ontbrekend stop-bit)
Dit break signaal trekt de lijn 15 bittijden (=900us) laag;een toestand die normaal gesproken niet zou mogen voorkomen (of zie ik dit mis?).
Zou je daarom niet een heel eenvoudige Loconet collision counter kunnen maken door te meten hoe vaak de lijn 900us (of langer) laag is?
Dat klopt, en dat zal de Break-detector van de UART al helemaal zelfstandig doen.
In DxCore (en waarschijnlijk ook moderne PIC) processoren zou dit zeer eenvoudig te programmeren moeten zijn, met nauwelijks CPU belasting. Of zie ik wat over het hoofd?
Voor break-detection heb je die faciliteiten niet nodig. Dat zit in elke UART die ik sinds 1980 "onderhanden" heb gehad ;)
Grtzz,
Karst
-
Hi Karst
Voor break-detection heb je die faciliteiten niet nodig. Dat zit in elke UART die ik sinds 1980 "onderhanden" heb gehad ;)
Dank :)
Mijn ervaring met UARTs “beperkt” zich vooral tot zenden en ontvangen. Natuurlijk check ik wel op fouten, maar dan alleen is het “goed” of “fout”. Ik zal daarom maar eens wat dieper in de fout afhandeling van UARTs duiken! Ik zie dat je de Frame Error (FEn) Flag gebruikt.
Andere vraag, gewoon uit nieuwsgierigheid: gebruik jij bij zenden ook de truc dat je de baudrate generator reset om het versturen zo snel mogelijk te starten nadat de lijn vrij is?
Groet, Aiko
-
Foutje tijdens typen. Sorry :o
-
Ik zie dat je de Frame Error (FEn) Flag gebruikt.
Correct.
Andere vraag, gewoon uit nieuwsgierigheid: gebruik jij bij zenden ook de truc dat je de baudrate generator reset om het versturen zo snel mogelijk te starten nadat de lijn vrij is?
Nope, heb dat ook al eens gelezen. Het effect daarvan is volgens mij niet éénduidig en kan startbit-jitter veroorzaken.
Voor het zenden wachten (indien al nodig) totdat de CD afgelopen is, RX checken dat die hoog is, en het byte in de TXD storen. Een ATtiny/ATxmega kan dat makkelijk binnen 2us voor elkaar krijgen ( Clock-cycle is max. 50ns ==> 2000 / 50 = 40 instructies na de test op TX hoog heb je de tijd. Ruim genoeg ;) )
Grtzz,
Karst
-
Hi Karst
Nope, heb dat ook al eens gelezen. Het effect daarvan is volgens mij niet éénduidig en kan startbit-jitter veroorzaken.
Voor het zenden wachten (indien al nodig) totdat de CD afgelopen is, RX checken dat die hoog is, en het byte in de TXD storen. Een ATtiny/ATxmega kan dat makkelijk binnen 2us voor elkaar krijgen ( Clock-cycle is max. 50ns ==> 2000 / 50 = 40 instructies na de test op TX hoog heb je de tijd. Ruim genoeg ;) )
Dank voor de info. Ik heb me zelf niet echt verdiept in het resetten van de baudrate generator, dus ik zie dit als een "waarschuwing vooraf". Ik kan me ook voorstellen dat dit verschillend werkt bij verschillende types processoren. Iets wat ik dus voor gebruik goed zou moeten testen.
Of je 2us haalt, ligt denk ik heel erg aan wat de processor verder nog te doen heeft. Als je een dedicated ATtiny voor Loconet neemt, en hierop geen Arduino omgeving zet (en er dus geen Arduino timer interrupts zijn), moet dat (als je het goed doet) zeker kunnen.
Als je, zoals veel mensen doen, een standaard Arduino omgeving gebruikt, met nog een aantal libraries die ook ISR hebben, wordt het een heel ander verhaal. Er worden immers eerst allerlei registers op de stack gesaved voordat je eerste eigen code begint.
Toen ik mijn DCC Library schreef, heb ik daarom veel tijd besteed aan het tellen van assembler instructies / clock cycli van wat er precies gebeurd als er een interrupt optreedt. Nick Gammon heeft daarover een heel goed verhaal geschreven: https://www.gammon.com.au/interrupts / How long does it take to execute an ISR?. Citaat uit dat verhaal: "So from the moment the interrupt occurs, to the first line of code being executed, would be 16 + 7 cycles (23 cycles), at 62.5 nS per clock cycle, that would be 1.4375 µS."
Groet
Aiko
Edit: later realiseerde ik mij dat je natuurlijk de 'zend code" moet beschermen met cli(),sei() (interrupts disabled/enabled). Dan haal je de 2us makkelijk.
-
Beste allen
Zondag hebben we bij onze Twentse Modelspoorweg Club (TMC) een open dag (https://twentsemodelspoorweg.club/opendag-2024/).
Naast onze baan (met op schaal de stations Hengelo, Enschede, Oldenzaal en Delden) zijn er ook een aantal gastbanen, een beurs, diverse workshops en natuurlijk "digitaal". Theo Maassen komt weer langs om de MobaLedLib (MLL, https://wiki.mobaledlib.de) te demonstreren. Ben Vreeman laat zien hoe hij de MLL bij onze TMC inzet; ook toont hij zijn seinen (https://www.modelspoorseinen.nl) en 3D prints. Ik zal zelf ook 3D prints van een dubbele kruiswissel meenemen, en natuurlijk een aantal decoders.
Ik hoop een aantal van jullie zondag te ontmoeten.
Groet, Aiko
-
Ik kom morgen even kijken, ik ben benieuwd.
En misschien rij ik daarna ook even door naar Oldenzaal naar de Spoor 0 bijeenkomst.
Groeten,
Jos
-
Hi Jos
Zou leuk zijn :-)
RTV Oost is gisteren langs geweest en heeft een leuk filmpje gemaakt: https://www.oost.nl/nieuws/2746981/modeltreinfanaten-kijken-hun-ogen-uit-in-enschede-mensen-denken-dat-het-speelgoed-is
Groet, Aiko
-
Mooi filmpje. Het bezoek aan deze modelbaan was zeer de moeite (vanuit Emmen) waard.
-
Vanuit Epe was ook de moeite waard (y)
Maar dat wist ik vantevoren al, want ik mocht al 2x eerder komen kijken.
De manier hoe jullie de baan bedienen is geweldig. En alles reed zeer mooi soepel, toen ik er was. Complimenten!
Aiko, leuk je gesproken te hebben!
Groeten,
Jos
-
Beste allemaal
Één van de projecten waar we momenteel aan werken, is het zoeken van alternatieven voor de bestaande FRED-handregelaars. We testen op dit moment een LocoNet handregelaar die we van Bas hebben gekregen. Maar we kijken ook naar (draadloze) Aps die clubleden op hun mobieltjes kunnen zetten.
De afgelopen maanden hebben we wat testen gedaan met WiThrottle, en momenteel testen we de Z21 App. Omdat onze oude IB centrale natuurlijk geen Z21 spreekt, hebben we als eerste de Z21 server applicatie op JMRI geïnstalleerd. De mobieltjes praten dan met de Z21/JMRI server, die vervolgens via LocoNet met de IB centrale communiceert. Deze aanpak hebben we (helaas) nog niet stabiel kunnen krijgen.
Vandaag zijn we daarom een ander experiment gestart: we hebben de IB (tijdelijk??) vervangen door de Yamorc YD7001. De Yamorc centrale heeft immers standaard Z21 aan boord, en zou daarom wel eens stabieler kunnen zijn dan de JMRI/Z21-server combinatie.
Mijn vraag is nu hoeveel (UDP) clients (dus mobieltjes) gelijktijdig gebruikt kunnen worden. UDP is weliswaar connection-less, maar centrales moeten een lijstje bijhouden, zodat ze ook meldingen kunnen terugsturen (afhankelijk van de Broadcast-Flags die zijn gezet). Zijn (met de Yamorc) 25 mobieltjes mogelijk? Indien niet, zijn er centrales die gelijktijdig wel 25 mobieltjes aankunnen? Of zijn er andere oplossingen?
Groet, Aiko
-
De AVR-DAx is zo in te stellen, dat het teruglezen op bit-level gedaan kan worden door de USART zelf. Dan zit je dus op het niveau van bitbangen, zonder te bitbangen :P
Hoi,
Mijn abuis: Het is niet de AVR-DAx maar de SAM Dx/DAx:
(https://images.beneluxspoor.net/bnls_2024/ATSAMD-Collision-Detect-67387e1bc5f87.png) (https://images.beneluxspoor.net/bnls_2024/ATSAMD-Collision-Detect-67387e1bc5f87.png)
... Pagina uit de datasheet.
Dat ga ik dus gebruiken in de nieuwe YD6016LN_RC, die een SAMD21G processor heeft :) Het heeft nog wel wat voeten in de aarde, omdat de UART de TXD van zichzelf compleet disabled na het detecteren van een collision.... :-\
Groet,
Karst
-
Hi Karst en anderen
Dank. Ja de SAMD family is weer een stapje geavanceerder. Ik heb er ook wel naar gekeken, maar op de schaal waarop ik werk is de overgang naar (weer) een nieuwe processor best een grote stap.
Overigens dank voor de feedback dat de YD7001 meer dan 8 gebruikers via Z21 kan bedienen. Gaan we proberen. Ik ben trouwens heel benieuwd of er in Nederland modelbaan verenigingen zijn waar met Apps op mobieltjes wordt gereden, en hoe de ervaringen zijn.
Nu de open dag van onze club achter de rug is, kunnen we weer verder experimenteren met de baan electronica. We willen nu proberen of voor station Oldenzaal we de PIO kaart kunnen vervangen door onderstaande 24-kanaal DCC I/O decoders, met RS-Bus feedback.
(https://images.beneluxspoor.net/bnls_2024/TMC-IO24-Bord-6738a33aa2f41.jpg) (https://images.beneluxspoor.net/bnls_2024/TMC-IO24-Bord-6738a33aa2f41.jpg)
Ik zie deze decoders nog als test. Ik verwacht dat we op termijn geen decoders met 25 polige SUBD connectoren gaan gebruiken, maar "complete" decoders, dus met wat drivers voor de wissel aansturing / bezetmeld hardware reeds op de decoder print. Op dit moment hebben we echter behoefte aan iets waarmee we snel kunnen switchen tussen oude en nieuwe hardware. Vandaar de 25 polige connector. Binnenkort zal ik wat meer vertellen over de software aanpassingen die nodig zijn.
Zoals gebruikelijk is de hard- en software te krijgen via onderstaande URLs:
- https://oshwlab.com/aikopras/io-24-channel_copy
- https://github.com/aikopras/TMC-24-Channel-IO-Decoder
Groet, Aiko
-
Overigens dank voor de feedback dat de YD7001 meer dan 8 gebruikers via Z21 kan bedienen
Ik denk dat ik wat gemist heb? Waar komt deze magic 8 vandaan?
Weten jullie eigenlijk welk gedeelte tussen IB en mobieltjes niet stabiel was? Als ik nu zelf zoveel als mogelijk draadloos spul zou willen gebruiken zou ik of voor mqtt gaan of een painlesh mesh netwerk opzetten met esp's. Ik weet alleen of daar voor ons handige apps voor zijn.
Als de brug tussen PC en IB onbetrouwbaar blijkt, zou ik een esp direct aan Loconet hangen. Die moet dan mqtt berichten omzetten van en naar loconet. Ik ben benieuwd hoeveel cliënten de YD centrale met de jmri sw afhandelt zonder problemen.
Met de BMB rijden we met een z21 en wlan mausen en phones. Dat gaat meestal goed. Maar bij een erg grote setup hebben we ook wel eens het probleem dat sommige wireless dingen er mee ophouden. De smartphones geven het minst problemen, de wlan mausen kappen er als eerste mee. Ik heb geen precieze nummers, ik denk dat tot 10 wlan apparaten nog goed gaat.
-
Hi Bas
Ik denk dat ik wat gemist heb? Waar komt deze magic 8 vandaan?
Implementatie keuze. Bij XpressNet (waar Z21 op een bepaalde manier vanaf stamt) wordt TCP gebruikt, en daar (Lenz 23151) is 8 clients het maximum. Ook een aantal Arduino Ethernet libraries (zoals W5500) hebben voor TCP een maximum (van 8; als ik met het goed herinner heeft de W5100 4 als max). Dat is allemaal TCP, maar ook Z21 UDP implementaties moeten per client een administratie bijhouden. Daarom zou daar waarschijnlijk ook een maximum zijn.
Weten jullie eigenlijk welk gedeelte tussen IB en mobieltjes niet stabiel was?
Combinatie JMRI en Z21 server. Als die actief was, ging na een bepaalde tijd van alles mis. Zonder dat hebben we geen problemen. Ik ben in gesprek met de JMRI/Z21 App ontwikkelaar(s).
Als ik nu zelf zoveel als mogelijk draadloos spul zou willen gebruiken zou ik of voor mqtt gaan of een painlesh mesh netwerk opzetten met esp's. Ik weet alleen of daar voor ons handige apps voor zijn.
Als de brug tussen PC en IB onbetrouwbaar blijkt, zou ik een esp direct aan Loconet hangen. Die moet dan mqtt berichten omzetten van en naar loconet. Ik ben benieuwd hoeveel cliënten de YD centrale met de jmri sw afhandelt zonder problemen.
Met de BMB rijden we met een z21 en wlan mausen en phones. Dat gaat meestal goed. Maar bij een erg grote setup hebben we ook wel eens het probleem dat sommige wireless dingen er mee ophouden. De smartphones geven het minst problemen, de wlan mausen kappen er als eerste mee. Ik heb geen precieze nummers, ik denk dat tot 10 wlan apparaten nog goed gaat.
Wat we willen is dat standard Aps voor mobieltjes gebruikt kunnen worden. Niet alle TMC leden hebben affiniteit met ICT, en we moeten zaken zo eenvoudig mogelijk houden.
Natuurlijk is het mogelijk "alles" zelf te gaan ontwikkelen, maar het schrijven van de XpressNet library heeft me al maanden tijd gekost. Dus "kant en klaar" is soms ook wel handig ;D
Groet, Aiko
-
Hi Aiko,
Mooiste is natuurlijk dat de apps rechtstreeks verbinden met een centrale, mocht je naast JMRI nog een alternatief willen proberen, Traintastic (https://traintastic.org/en-us/download/develop/master) kan ook een WLANmaus/Z21 app en WiThrottle server zijn, en die commando's doorzetten naar een centrale. Op dit moment moet je nog wel de lok adressen aanmaken in Traintastic zodat ze bestuurd kunnen worden. Dat is voor jullie toepassing niet ideaal denk ik, daar kan ik eventueel wel wat aan doen :)
Groeten,
Reinder
-
Beste allemaal
Het is alweer een tijdje geleden dat ik in dit draadje iets heb geschreven. Daarom is het hoogste tijd voor een status update.
Op dit moment testen we de 24-kanaals I/O decoders, in combinatie met de door ons geschreven XpressNet DLL en onze bestaande (VB6) besturingssoftware.
Voor eenieder die het vergeten is: de decoder is beschreven in bijdrage 59 (van 16 november 2024) en de XpressNet DLL in bijdrage 25 (7 september 2024). De XpressNet software is (zoals gebruikelijk) te vinden op GitHub: https://github.com/aikopras/XpressNet. De tests betreffen alleen de accessory commands (wissels, seinen en bedieningspaneel), en de spoor-bezet-terugmelding, via de RS-Bus.
De tests voeren we uit bij één van onze leden thuis, en natuurlijk op onze club baan, voor de bediening van station Oldenzaal.
De testen lopen goed, en binnenkort gaan we op grotere schaal (tijdens rijavonden) testen. Het enige probleem waar we nu tegenaan lopen, is dat het Lenz 23151 LAN/USB interface problemen heeft met onze nieuwe (Brother) printer. Deze printer stuurt namelijk regelmatig (heel grote) MDNS (= Multicast DNS, bonjour, zeroconf) berichtjes, die het Lenz interface doen crashen. We hebben hierover contact opgenomen met Lenz, en hopen dat dit probleem met een firmware-update verholpen kan worden. Mocht dat niet lukken, dan zijn er wel wat alternatieve oplossingen mogelijk, zoals een ander merk centrale of het bouwen van een eigen LAN/XpressNet interface. ::)
Een ander iets waarover ik geschreven heb, is de test met de Z21 App. Deze App hebben we (nog??) niet stabiel kunnen krijgen in combinatie met de JMRI Z21 extensie, die via Loconet verbonden is met onze IB (zoals eerder beschreven, gebruiken we voor rijden en schakelen/terugmelden verschillende centrales). We hebben daarom de IB vervangen door de Yamorc YD7001, die zelf Z21 spreekt. Hiermee werkt de Z21 App wel goed, maar hebben we een nieuw probleem gekregen: onze oude Freds blijken niet met de YD7001 overweg te kunnen. We hebben ruim 20 van deze oude Freds in gebruik, en (wat nu blijkt) hebben ook een aantal leden indertijd een dergelijke Fred gekocht om bij de vereniging te kunnen rijden. Hopelijk kan het probleem met de oude Freds eveneens verholpen worden door een nieuwe firmware-update.
Van Bas hebben we zijn nieuwe handregelaar mogen testen. Die testen zijn tot nog toe prima verlopen. Op termijn zou die regelaar misschien een alternatief voor onze bestaande Freds kunnen worden, zeker als er nog wat aanpassingen mogelijk zijn (waar ik, zoals ik Bas ken, wel van uitga). Als we echter 50 à 60 Freds willen vervangen, wordt dat een substantiële investering. Niet al onze leden zijn even geïnteresseerd in dergelijke vernieuwing, en ook Apps op mobieltjes blijven een mogelijkheid. De discussie over handregelaars zal dus nog wel even voortduren.
Genoeg voor vandaag,
Groet, Aiko
-
mocht je naast JMRI nog een alternatief willen proberen, Traintastic (https://traintastic.org/en-us/download/develop/master) kan ook een WLANmaus/Z21 app en WiThrottle server zijn, en die commando's doorzetten naar een centrale.
Hi Reinder
Ik heb in jouw eigen draadje je berichtje van 12 januari, met screenshot, bekeken. Misschien is dat wel een interessante oplossing voor ons: alle mobieltjes openen gewoon een webpagina met daarop een eenvoudige pagina, om precies 1 trein plus een aantal functies te bedienen. Voor onze clubbaan is het wel belangrijk dat de trein onmiddellijk stopt als er iets anders met het mobieltje gebeurd (zoals lezen en versturen van app berichtjes, telefoontjes, het maken van foto’s). Dat zou waarschijnlijk wel makkelijk oplosbaar zijn, met behulp van een of ander HTML/JavaScript commando.
Het voordeel van jouw systeem is dat het aanpassen van een stukje HTML/Javascript relatief makkelijk te doen is; in ieder geval veel makkelijker dan een eigen App schrijven voor Android en IOS.
Groet, Aiko
-
Hi Aiko,
Ja de Traintastic WebThrottle, nieuwe feature die ik aan het ontwikkelen ben :). Ik heb ooit eens een beginnetje gemaakt met een Android app, maar dat is een hele klus, zeker omdat ik dat nog nooit gedaan heb. Vandaar idd een WebThrottle, dan werkt het ook direct op iOS.
Wat betreft die noodstop, het nadeel van zn webapp is dan weer dat je iets minder dicht op het systeem zit. Voor de communicatie gebruik ik WebSocket, zodat ik ook data vanuit Traintastic naar de WebThrottle kan sturen. Als deze verbinding wegvalt (aan de Traintasic kant) wordt de trein gestopt. Als je wisselt naar een andere app dan blijft de verbinding gewoon open, ik vermoed dat de telefoon hem nog een tijd open houdt. Ik zal es kijken of daar met JavaScript nog wat slims mee te doen is.
Bij het besturen van treinen met de WebThrottle is er altijd een eigenaar. Als een andere persoon hem wil krijgt die een melding dat de trein in gebruik is, je kan hem overigens wel "stelen".
De WebThrottle feature leeft nog op een ontwikkel branch, mocht je het alvast willen proberen dan kun je op https://traintastic.org/en-us/download/develop/178-add-web-based-throttle-for-phone de laatste build vinden.
Groeten,
Reinder
-
Hi Aiko,
Heb nog even gekeken naar het stoppen van de trein als je je browser verlaat op je telefoon, dat was niet zo ingewikkeld :)
Alle moderne browsers hebben daar een simpel event voor:
document.addEventListener("visibilitychange", function ()
{
if(document.hidden)
{
/* EStop train */
}
});
Heb ook nog even gekeken naar het scherm actief houden als de webapp open staat, ook dat kan, maar alleen als je in een secure context zit, wat dus neer komt op een HTTPS verbinding. Nu is dat niet zo moeilijk om toe te voegen, nadeel is wel dat je dan zn self signed certificate melding krijgt bij het openen van de webapp.
Reinder
-
Hi Reinder
Dank. Als je het eenmaal weet, is het niet meer moeilijk ;D
Zou je het certificaat niet gewoon via let’s encrypt kunnen krijgen / laten updaten?
Groet, Aiko
-
Hi Aiko,
Nee helaas, voor let's encrypt moet je systeem via internet bereikbaar zijn en een domein naam hebben, voor websites werkt dat prima (gebruikt ik voor traintastic.org (http://traintastic.org) ook), voor zaken die draaien op het interne netwerk zoals Traintastic is het geen optie.
Reinder
-
Hi Reinder
Ik begrijp dat je voor Let’s Encrypt een domeinnaam nodig hebt. Maar ik begrijp niet dat je traintastic niet aan het Internet kan hangen. Dat kan je met RocRail, I train, TC etc toch ook?
En ja, je moet een webserver hebben. Maar het ging er toch juist om dat traintastic de mogelijkheid biedt om via een web browser je trein te besturen? Dan is het, technisch gezien, toch een web server?
Ik begrijp dat je, om praktische redenen, geen gebruik wilt maken van https / certificaten, maar technisch zou het toch moeten kunnen?
Groet, Aiko
-
Beste allemaal
Onze testen met zelfgebouwde decoders verlopen voorspoedig. We hebben nu al een aantal rij avonden gehad zonder dat deze decoders / onze software problemen gaf.
Wel hebben we weer een ander probleem. Het zou kunnen zijn dat onze (YD7001) centrale problemen heeft met de belasting van de ruim 30 (Fremo Spax) boosters die we aangesloten hebben.
Nu hoor en lees ik verschillende verhalen over hoever de Loconet-B (Booster) uitgang belast mag worden. Soms lees ik 200 mA, maar ik hoor ook 750 à 800 mA. Ik het eerste geval begrijp ik dat we te veel boosters zouden hebben, in het tweede geval lijkt het maximum nog niet bereikt te zijn.
Zover ik weet, gaat het DCC signaal dat door de microcontroller wordt gegenereerd 1) via een wat sterker driver IC naar de DCC uitgang, en 2) via een zwak driver IC naar de Loconet-B (Railsync) uitgang. Verder lees ik dat de spanning van het Loconet-B signaal ietsje lager dan het DCC signaal, namelijk 12 tot 14 Volt. Klopt dit?
Mijn belangrijkste vraag is echter of we de Loconet-B uitgang überhaupt wel zouden moeten gebruiken, en of dat we niet beter alle boosters direct op de DCC uitgang zou kunnen aansluiten.
Groet, Aiko
-
Mijn belangrijkste vraag is echter of we de Loconet-B uitgang überhaupt wel zouden moeten gebruiken
Dat hangt er vanaf. Het voordeel van loconet is dat je kan zien, welke booster kortsluiting heeft. Tevens kan je bij sommige boosters dingen uitlezen zoals stroomgebruik en temperatuur.
Nu ken ik die Fremo Spax dingen niet en ik weet niet wat ze wel en niet kunnen. Maar als je hier toch geen gebruik van maakt, dan kan je net zo goed de sniffer ingang (als die Spax dat heeft) gebruiken en aan je DCC lijntjes hangen.
Ik dacht dat 500mA wel een beetje de standaard was. De YD centrale is gerate op 800mA. De spanning op de railsynch zou onbelast tussen 12V en 26V moeten liggen, nu is 12V veel voorkomend. Elk apparaat mag officieel ook maar 15mA trekken uit de railsynch lijntjes.
Je kan in theorie ook halverwege de loconet keten een booster knopen die de railsynchlijntjes versterkt. Het is wel moeilijk doen voor weinig gain, maar het is mogelijk :P.
Mvg,
Bas
-
Dit misschien een oplossing?
https://www.floodland.nl/aim/info_locohubsupply_1.htm
-
Dit misschien een oplossing?
https://www.floodland.nl/aim/info_locohubsupply_1.htm
Dank voor de suggestie, maar dat is voor de gewone Loconet bus. Bij Loconet-B werkt dat (volgens mij) niet.
Groet, Aiko
-
Hi Bas
Het voordeel van loconet is dat je kan zien, welke booster kortsluiting heeft. Tevens kan je bij sommige boosters dingen uitlezen zoals stroomgebruik en temperatuur.
Nu ken ik die Fremo Spax dingen niet en ik weet niet wat ze wel en niet kunnen. Maar als je hier toch geen gebruik van maakt, dan kan je net zo goed de sniffer ingang (als die Spax dat heeft) gebruiken en aan je DCC lijntjes hangen.
Dat een aantal Boosters via Loconet meldingen kunnen terugsturen, begrijp ik. Dat zou vaak handig kunnen zijn.
Voor zover ik weet stuurt de Fremo Spax booster echter niets terug. Ik begrijp je opmerking over een sniffer ingang niet goed, maar ik kan toch gewoon aan de centrale kant de stekker er af knippen en de buitenste draadjes op de YD DCC uitgang aansluiten?
De YD centrale is gerate op 800mA. De spanning op de railsynch zou onbelast tussen 12V en 26V moeten liggen, nu is 12V veel voorkomend. Elk apparaat mag officieel ook maar 15mA trekken uit de railsynch lijntjes.
Kan ik de waarde van 800mA ergens op Internet vinden? In de YD handleiding kon ik dat niet vinden.
De Spax boosters hebben een 2K2 weerstand voor de optocoupler (https://fremodcc.sourceforge.net/booster/spaxbooster/710_F628_04_sch.GIF), en zouden dus zoiets als 7mA per stuk moeten trekken. Als de YD 800mA kan leveren, zouden we daar ruim onder moeten zitten. We zullen binnenkort eens gaan meten hoeveel er precies verbruikt wordt.
Groet, Aiko
-
Staat op de product pagina
Booster Interface by LocoNet-B with strong, 800mA LocoNet RailSync signals
http://yamorc.de/upcp_product/yd7010/ (http://yamorc.de/upcp_product/yd7010/)
Ik begrijp je opmerking over een sniffer ingang niet goed,
Sommige boosters zoals een DR5033 hebben meerdere 'interfaces'. Deze heeft loconet-B, B-bus, CDE terminal en sniffer ingang. Sniffer ingang is niks meer dan de DCC draadjes uit je centrale. Voordeel is: werkt altijd en met elke centrale. Soms heb je de sniffer ingange ook specifiek nodig als je booster de railcom data van zijn global detector kan doorgeven aan de sniffer ingang. Alleen handig voor POM programmeren en railcom++ kan er iets mee dacht ik. Maar feitelijk voegt het bijna niets toe. Dit kan bijvoorbeeld niet via CDE, B-bus of Loconet-B. Een nadeel van de sniffer ingang daarentegen is dat de booster niet kan doorgeven aan de centrale dat hij sluiting heeft. Volgens mij kan je die ook gelijktijdig gebruiken, loconet-B en sniffer, maar dat weet ik niet zeker.
(https://images.beneluxspoor.net/bnls_2025/image-67d96a91251c2.png) (https://images.beneluxspoor.net/bnls_2025/image-67d96a91251c2.png)
Wat doen R10 en C13 eigenlijk?
Mvg,
Bas
-
Hi Bas
Staat op de product pagina
Dank. Daar had ik niet gekeken (wel in de handleiding).
https://fremodcc.sourceforge.net/booster/spaxbooster/710_F628_04_sch.GIF
Wat doen R10 en C13 eigenlijk?
Dat is een zogeheten "snubber" schakeling. Om het DCC signaal te verbeteren.
Zie: https://www.opendcc.de/elektronik/opendcc/opendcc_hw_sch_e.html
Wat ik ook interessant vind, is R4, die het Loconet GND signaal met 330K (=soft) verbindt met de lokale GND.
Groet, Aiko
Groet, Aiko
-
Beste forumlezers
Het is al weer een tijdje terug dat ik wat heb laten horen. Geen nieuws, goed nieuws :)
Voor eenieder die geïnteresseerd is, desondanks maar weer eens een status update.
Het probleem dat ik op 18 maart heb beschreven, lijkt opgelost. Ter herinnering: op bepaalde momenten “hield de YD7001 ermee op”. Ons eerste vermoeden, dat er te veel boosters aan de Loconet-B uitgang van de YD7001 hingen, bleek niet te kloppen. Toch leek de YD7001 ergens informatie vandaan te halen dat een booster overbelast was / werd kortgesloten. Omdat geen van onze 30 SPAX boosters iets terug kan sturen via Loconet, begrepen we maar niet hoe dat kon. Totdat iemand opmerkte dat we nog ergens wat Lenz boosters hadden aangesloten, die via remgeneratoren er voor zorgden dat treinen die door de machinist hadden moeten stoppen, tot stoppen werden gedwongen. En die Lenz boosters zijn via een Loconet-CDE interface aangesloten. Dit interface kan wel kortsluit-informatie (E van Lenz) via loconet terugsturen. Bingo!
Ik heb al eerder geschreven dat onze XpressNet DLL en 24 kanaal zelfbouw decoders tot nu toe goed werk verrichten. Deze decoders zijn eigenlijk heel simpel: ze bieden een 24 pinnetjes die als ingang of uitgang geschakeld kunnen worden. Deze in en uitgangspinnetjes zijn verbonden met de overige elektronica, die ook al weer 20 jaar geleden is gemaakt. Tijd dus voor een volgende stap.
Als eerste gaan we nu een decoder print maken die specifiek geschikt is om onze wissel aandrijvingen (=oude 48V PTT relais) te besturen. De oude printen gaan we vervangen, alleen behouden we de bedrading die RJ45 connectoren heeft. De kern van de decoder wordt vergelijkbaar met onze bestaande 24 kanaals I/O decoder, alleen lijkt het wel leuk om eens te gaan experimenteren met Railcom, zodat de decoders (die reeds door PoM geprogrammeerd kunnen worden), ook hun CV waarden via RailCom kunnen terugsturen. Daarover heb ik net vanochtend al een nieuwe draadje geopend, dus dit wordt vervolgd.
Groet, Aiko
-
Beste lezers
Vandaag even niets over de voortgang van de digitalisering van onze clubbaan, maar een aardigheidje tussendoor: de verlichting van rijtuigen.
Begin dit jaar wilde ik wat ESU-Pullman rijtuigen op de baan zetten, maar die gaven meteen kortsluiting. Na wat zoeken op het Internet bleek dat er een constructiefout in de rijtuigen zit: het metalen gewicht ligt zonder isolatie op de stroomafname strips. Ik begrijp niet hoe ze zoiets in de handel kunnen brengen, maar dat terzijde. De conclusie was dat de rijtuigen geheel uit elkaar moesten, en dat een stukje papier tussen het balast-gewicht en de strips voor de stroomafname moest komen. Nu de rijtuigen toch uit elkaar moesten, konden de Chinese reizigers die al lang op de trein stonden te wachten plaats nemen, en de verlichting worden ingebouwd.
De verlichting hoeft niet uitschakelaar te zijn, dus er komt geen decoder in. De LEDs zijn standaard LED-strips van Ali, met 120 warm-witte LEDs per meter. Kosten: nog geen euro per meter. Zie onderstaande foto's.
(https://images.beneluxspoor.net/bnls_2025/Ledstrip-68028e0b1ba09.jpg) (https://images.beneluxspoor.net/bnls_2025/Ledstrip-68028e0b1ba09.jpg)
(https://images.beneluxspoor.net/bnls_2025/LEDstrip-detail-68028e0b09cdb.jpg) (https://images.beneluxspoor.net/bnls_2025/LEDstrip-detail-68028e0b09cdb.jpg)
Deze LEDs zijn gespecificeerd tot 20 mA per stuk, maar bij 20 mA komt er zoveel licht af, dat je er een voetbal stadion mee kan verlichten. Veel realistischer is 0,1 à 0,2 mA per LED, waardoor er (gemeten) 2,575 Volt over iedere LED valt. Helaas is het mij niet gelukt de precieze specificaties van deze LEDs te achterhalen.
Om het makkelijk te maken, heb ik een standaard schakeling genomen; het schema staat hieronder. De 470 Ohm weerstand voor de condensator is nodig om de "in-rush" stroom te beperken. Er is een diode brug, zodat stroom wordt afgenomen bij een positieve als ook een negatieve DCC-spanning. Een condensator van 470 µF is ruim voldoende; een weerstand van 4K7 is nodig om de (maximale) stroom per LED te beperken tot 0,135mA (in totaal passen er 7 keer 3 LEDs in het rijtuig).
(https://images.beneluxspoor.net/bnls_2025/Schema-Eenvoudig-680290332d41c.png) (https://images.beneluxspoor.net/bnls_2025/Schema-Eenvoudig-680290332d41c.png)
Omdat het weer snel in elkaar moest, heb ik de schakeling met "gewone" (THT) componenten opgebouwd (zie foto hieronder). Om geen kortsluiting te krijgen, zijn alle verbindingen met krimpkous geïsoleerd. Dit priegelwerkje bleek toch tijdrovender dan verwacht, en het resultaat is ... nou ja, het werkt.
(https://images.beneluxspoor.net/bnls_2025/Schakeling-THT-68028e8ef1b68.jpg) (https://images.beneluxspoor.net/bnls_2025/Schakeling-THT-68028e8ef1b68.jpg)
Omdat er nog meer rijtuigen in de revisie staan, leek het me daarom een goed idee om niet alleen de Chinezen in de trein plaats te laten nemen, maar ze ook te vragen of ze even konden helpen met het aanbrengen van de verlichting. Dat konden ze wel; ik hoefde de schakeling alleen maar even naar JLCPCB te sturen, en dan zou ik een aantal mooie kleine printjes terugkrijgen. Zo gezegd, zo gedaan; en enige weken later had ik 5 van onderstaande printjes ontvangen. Genoeg voor 125 rijtuigen. De kosten voor alles bij elkaar zijn nog geen 30 euro: Componenten: 4.39€, print maken en assembleren: 17,25€, verzenden en belasting: 14,30€, en een tegoedbon van ruim 8€. Dus nog geen kwartje per rijtuig.
(https://images.beneluxspoor.net/bnls_2025/Printplaat-68028ecab5c64.jpg) (https://images.beneluxspoor.net/bnls_2025/Printplaat-68028ecab5c64.jpg)
Voor de technisch geïnteresseerden: Ieder printje is 13,5 x 9 mm. Om de kosten te drukken heb ik panels laten maken van 5x5 printjes. Om de individuele printjes af te breken, is het gebruik van "V-Cuts" het mooist, maar ook het duurst. Daarom heb ik "stamp holes" genomen, want deze kosten niets extra's.
Uiteraard kon ik het niet nalaten om de schakeling ook nog wat te "verbeteren" (zie schema hieronder). Hierbij liet ik me inspireren door de schakeling op de OpenDCC website, waarin de LEDs niet meteen op de Elco, maar via een stroombron worden aangesloten. Zie: https://www.opendcc.de/elektronik/stromquelle/stromquelle.html. De OpenDCC schakeling geeft 20mA, maar voor mij is 0,135mA per "set" van drie LEDs voldoende. Omdat er 8 tot 10 van deze "sets" in een rijtuig van 30cm passen, heb ik de weerstand van 33 Ohm (R3) vervangen door een weerstand van 390 Ohm.
(https://images.beneluxspoor.net/bnls_2025/Schema-gebouwd-68028f186d5fb.png) (https://images.beneluxspoor.net/bnls_2025/Schema-gebouwd-68028f186d5fb.png)
(https://images.beneluxspoor.net/bnls_2025/Enkel-printje-68028eff7ebb2.jpg) (https://images.beneluxspoor.net/bnls_2025/Enkel-printje-68028eff7ebb2.jpg)
Hierboven een foto van een enkele print met Elco. Het geheel werkt redelijk, maar (en dit is moeilijk om toe te geven ;D), toch iets minder goed dan verwacht. Wat de printjes goed doen, is de LEDs bij contact onderbreking nog even op hetzelfde niveau door te laten branden. Dat is dus beter dan de initiële versie, zonder stroombron. Wat iets minder goed gaat, is de tijd dat de LEDs blijven branden. Alhoewel dat ruim 1 seconde is, had ik meer verwacht.
Wat heb ik verkeerd gedaan? Om daar achter te komen deed ik iets wat Frank Schumacher (fschum) een tijdje geleden in het OpenDCC forum ook heeft gedaan in een bijdrage van Dennis (Dennis1984, ook actief in dit forum) met de titel "DCC train decoder mit LED-Streifen": simuleren met LTspice. LTspice is een simulatie programma voor digitale schakelingen dat alle moeilijke berekeningen voor je uitvoert. Handig dus. LTspice is ingebouwd in EasyEda, maar om heel eerlijk te zijn kan ik dat niet aanbevelen. Iedere berekening wordt in de (Chinese?) cloud gedaan, en kost veel tijd. Beter is het om het (gratis) LTspice pakket op je eigen machine te installeren. De versie voor Mac loopt vele jaren achter, maar dankzij CrossOver kan ik op mijn eigen Mac LtSpice V17 (2023) probleemloos installeren en draaien.
Hieronder een simulatie van de initiële schakeling, waarbij er alleen een weerstand van 4K7 tussen de Elco en LED-strip aanwezig is. Op tijdstip t = 0 wordt het DCC-signaal aangesloten; op tijdstip t = 2 verbroken. Zoals verwacht, loopt de stroom door de LEDs nadat het DCC-signaal is verwijderd exponentieel af. De LEDs blijven lang branden, maar wel steeds zwakker (zie plaatje hieronder).
(https://images.beneluxspoor.net/bnls_2025/Schakeling-1-ESU-68028f618efc8.png) (https://images.beneluxspoor.net/bnls_2025/Schakeling-1-ESU-68028f618efc8.png)
Vervolgens heb ik mijn "nieuwe" schakeling gesimuleerd. De stroombron zorgt er inderdaad voor dat het licht van de LEDs nog even (redelijk) constant blijft, maar na 1 seconde is het voorbij (zie plaatje hieronder).
(https://images.beneluxspoor.net/bnls_2025/Schakeling-2A-Stroombron-Gebouwd-470uF-68028f8a0b567.png) (https://images.beneluxspoor.net/bnls_2025/Schakeling-2A-Stroombron-Gebouwd-470uF-68028f8a0b567.png)
Als ik de Elco van 470 µF vervang door 1000 µF, dan blijft de verlichting, zoals te verwachten, wat langer branden: ongeveer 2,5 seconde (zie plaatje hieronder).
(https://images.beneluxspoor.net/bnls_2025/Schakeling-2A-Stroombron-Gebouwd-1mF-68028fa47fcd2.png) (https://images.beneluxspoor.net/bnls_2025/Schakeling-2A-Stroombron-Gebouwd-1mF-68028fa47fcd2.png)
Maar waarom niet langer? Is de weerstand van 10K misschien te klein? Door in het simulatieprogramma even op deze weerstand te klikken, kan ik zien hoeveel stroom er doorheen loopt. Die stroom is 1,1 mA (de blauwe lijn), en dus bijna net zo groot als de stroom door alle LEDs samen. Bijna de helft van de lading in de Elco wordt dus nodeloos "verstookt" in deze 10K weerstand.
(https://images.beneluxspoor.net/bnls_2025/Probleem-68028fc933d42.png) (https://images.beneluxspoor.net/bnls_2025/Probleem-68028fc933d42.png)
Door deze weerstand te veranderen in 100K werkt de schakeling nu wel na behoren (zie onder, de Elco is wederom 470 µF). Bijna alle lading die in de condensator is opgeslagen wordt nu gebruikt om de LEDs gelijkmatig te laten branden. Ook bij slechte stroomopname vanaf de rails hebben de Chineesjes die in de ruituigen hebben plaatsgenomen geen last meer van een flikkerende binnenverlichting.
(https://images.beneluxspoor.net/bnls_2025/Schakeling-verbeterd-100K-68028fced27a7.png) (https://images.beneluxspoor.net/bnls_2025/Schakeling-verbeterd-100K-68028fced27a7.png)
Als ik door bovenstaand verhaaltje iemand heb gemotiveerd om met LTspice te gaan spelen, of als iemand de schakeling wil nabouwen en/of de printjes wil nabestellen, dan is deze missie weer geslaagd :) De schakeling en printplaat is te vinden op: https://oshwlab.com/aikopras/konstante-stroom_copy
Groet, Aiko
-
Leerzaam Aiko. Dank voor de uitleg en het idee. (y) Eric
-
Je kan nog overwegen om aan de onderzijde een smd elco te plaatsen. Zou je kunnen laten doen, maar zelf doen is goedkoper.
Deze heeft een lm317 stroombron en een potmeter om de helderheid in te stellen. Hij was met 9x14.5mm iets groter dan ik wil. De potmeter vind ik zelf wel onmisbaar
(https://images.beneluxspoor.net/bnls_2025/image-6803b6c0cd269.png)
-
Beste Eric en Bas
@Eric: Dank :laugh: Zelf leer ik veel van anderen, dus is het fijn als ik ook wat kan teruggeven.
@Bas: Een (SMD) elco op de print is een kwestie van persoonlijke voorkeur. Zelf ben ik daar niet zo'n fan van, want dan wordt de plaatsing van het geheel lastiger. Ik zal binnenkort wat foto's laten zien van hoe ik het inbouw; dan wordt mijn keuze misschien wat duidelijker.
Je voorkeur voor een potmeter begrijp ik, maar dat maakt het geheel wel weer wat groter. Alle 25 à 30 cm lange rijtuigen kunnen met eenzelfde stroom / weerstandswaarde werken, zolang ik maar dezelfde LED-strips gebruik. Bij kortere strips kan ik een klein weerstandje over het einde van de strip solderen, en daarmee de helderheid verminderen.
Maar waarom gebruik je een LM317? Dat lijkt me een overkill, omdat de stroom slechts 1,5 mA hoeft te zijn. iedere PNP transistor (liefst C type, met hoge hfe) is bruikbaar. Een simpele transistor is ook nog eens duidelijk goedkoper.
Groet, Aiko
-
want dan wordt de plaatsing van het geheel lastiger.
Dat hangt van de grootte van de print af, denk ik. Het idee kreeg ik van lightmytrain. Daar zit, als ik zo kijk, geen stroombron op, maar als je kijkt naar de grootte. Die is niet veel groter dan de elco. En als die print zelf ook maar 0.8mm of 1mm dik is.
(https://shop.lightmytrain.nl/media/catalog/product/cache/b5976e8bff9ffd752f8cd35927cb48cb/w/v/wv005_portrait-transformed.png)
Ik maak zelf kant en klare strips, dus heb ik zeeen van ruimte. Dan maakt 1 sot223 me niet zo veel uit. En je hebt hem ook in SOT-89. En die kosten? Het gaat over €0.06 ofzo, dus op een strip van €7.50.. in een rijtuig van €20-€70.. ::) Dus een 10ct potmeter mag dan van mij ook wel. En ook die vg039 of tc33x dingen, die zijn ook niet echt super groot.
(https://images.beneluxspoor.net/bnls_2025/C719174-C719174-OyAae-6803fe7078fbf.jpg) (https://images.beneluxspoor.net/bnls_2025/C719174-C719174-OyAae-6803fe7078fbf.jpg)
Klanten hebben ervaren dat de kleur van het interieur nog wel eens wilt meespelen in de juiste helderheid.
Ik weet niet precies hoeveel stroom je uit zo'n 12V strip trekt. Maar ik heb strips met 18 leds die ik per 3 in serie heb staan. Ik reken dan 0.5mA tot 2mA per groepje en dan kom ik uit op 12mA. En dan is het nog steeds overkill, maar net als die 16 cent aan kosten maakt het me gewoon weinig uit (y)
Mvg,
Bas
-
Beste allemaal
Vandaag wil ik tonen hoe ik de LED strips en de hiervoor besproken printjes met stroombron in een Roco wagon (30cm) heb ingebouwd.
De onderstaande foto laat zien hoe ik het printje verbind met de Led strip. Twee korte draadjes zijn genoeg.
(https://images.beneluxspoor.net/bnls_2025/01-Print-Strip-6804ddfee650b.jpg) (https://images.beneluxspoor.net/bnls_2025/01-Print-Strip-6804ddfee650b.jpg)
Vervolgens soldeer ik een (rood) draadje om de plus pool van de elco op aan te sluiten, en een tweede (groen) draadje voor de stroomafname.
(https://images.beneluxspoor.net/bnls_2025/02-Print-Draad-6804ddfee63a1.jpg) (https://images.beneluxspoor.net/bnls_2025/02-Print-Draad-6804ddfee63a1.jpg)
Het printje voorzie ik van dubbelzijdig (tesa) plakband, vergelijkbaar met de plakstrip onder de LED strip.
(https://images.beneluxspoor.net/bnls_2025/03-Plakband-1-6804ddffaf28d.jpg) (https://images.beneluxspoor.net/bnls_2025/03-Plakband-1-6804ddffaf28d.jpg)
(https://images.beneluxspoor.net/bnls_2025/04-Plakband-2-6804ddff7126e.jpg) (https://images.beneluxspoor.net/bnls_2025/04-Plakband-2-6804ddff7126e.jpg)
De print en LED strip kunnen nu geplakt worden op (onder) het dak van de wagon. De LEDs stralen naar beneden, want het aantal LEDs is zo groot (120 per meter) dat indirecte verlichting niet nodig is.
(https://images.beneluxspoor.net/bnls_2025/05-Strip-en-Print-geplakt-6804de006b25f.jpg) (https://images.beneluxspoor.net/bnls_2025/05-Strip-en-Print-geplakt-6804de006b25f.jpg)
Vervolgens soldeer ik de 470uF / 25V elco met de min aan de min van de LED strip vast. Ik vind dit handiger dan een elco direct op de print, omdat ik nu wat meer mogelijkheden heb voor de montage. De gebruikte elco is dun genoeg om probleemloos onder het dak te passen.
(https://images.beneluxspoor.net/bnls_2025/06-Elco-1-6804de011c8ac.jpg) (https://images.beneluxspoor.net/bnls_2025/06-Elco-1-6804de011c8ac.jpg)
Uiteraard moet ook de plus van de elco op de eerder aangebrachte rode draad worden aangesloten.
(https://images.beneluxspoor.net/bnls_2025/07-Elco-2-6804de0180406.jpg) (https://images.beneluxspoor.net/bnls_2025/07-Elco-2-6804de0180406.jpg)
Het leuke van sommige Roco rijtuigen is dat er al een draadje van de stroomafname strips naar boven loopt. We hoeven de wagon dus niet verder uit elkaar te halen en aan te passen. Helaas is dit niet bij alle Roco rijtuigen zo, dus vaak is meer werk nodig.
(https://images.beneluxspoor.net/bnls_2025/08-Draad-1-6804de0254740.jpg) (https://images.beneluxspoor.net/bnls_2025/08-Draad-1-6804de0254740.jpg)
(https://images.beneluxspoor.net/bnls_2025/09-Draad-2-6804de02d528d.jpg) (https://images.beneluxspoor.net/bnls_2025/09-Draad-2-6804de02d528d.jpg)
(https://images.beneluxspoor.net/bnls_2025/10-Draad-doorverbinden-6804de033bf9a.jpg) (https://images.beneluxspoor.net/bnls_2025/10-Draad-doorverbinden-6804de033bf9a.jpg)
De onderstaande foto toont als alles is aangesloten. Voordat het dak er weer op gaat, is het verstandig eerst even te testen. Bij mijn eerste wagon werkte het geheel niet, maar het bleek dat de vorige eigenaar de dubbel geïsoleerde wielen had vervangen door enkel geïsoleerde wielen, en de stroomafname-strips had verbogen. Vervelend, maar gelukkig ook weer snel te verhelpen.
(https://images.beneluxspoor.net/bnls_2025/11-Alles-aangesloten-6804de039e6a4.jpg) (https://images.beneluxspoor.net/bnls_2025/11-Alles-aangesloten-6804de039e6a4.jpg)
Zo ziet het geheel er uit nadat het dak er weer op zit. Wat mij betreft "missie geslaagd".
(https://images.beneluxspoor.net/bnls_2025/13-Resultaat-2-6804dede58da3.jpg) (https://images.beneluxspoor.net/bnls_2025/13-Resultaat-2-6804dede58da3.jpg)
Eerder heeft Bas zijn voorkeur voor een potmeter uitgesproken, om de stroom / licht sterkte aan te passen als we met bijvoorbeeld veel kortere rijtuigen te maken hebben. Dat kan zeker handig zijn, maar verschillen in de lengte van de LED strips kunnen ook anders worden opgelost. Als voorbeeld neem ik een 3-assige Roco Umbauwagen, met een lengte van 15 cm. Daarin passen niet 10 "setjes" van 3 LEDs, maar slechts 5. Omdat de stroombron is ingesteld op 1,35 mA, krijgt in het hierboven beschreven geval iedere "set" van drie LEDs 0,125mA, want er zijn immers 10 'setjes". Als we echter slechts 5 "setjes" aansluiten, krijgt ieder ;setje" de dubbele stroom, dus 0,27mA. Dat is natuurlijk niet de bedoeling. Een simpele oplossing is (zie foto hieronder) om een extra weerstand van 22 KOhm parallel aan de LED-strip te monteren (helemaal rechts). Nu gaat ongeveer de helft van de stroom door de weerstand (0,7 mA), en de rest door de LEDs (0,135 mA per "setje" van drie). De lichtopbrengst per LED van de kortere LED strip is dus weer gelijk aan de hierboven getoonde 30 cm wagons.
(https://images.beneluxspoor.net/bnls_2025/14-22K-weerstand-6804dede58d96.jpg) (https://images.beneluxspoor.net/bnls_2025/14-22K-weerstand-6804dede58d96.jpg)
Opgemerkt moet worden dat aan de onderkant van (versie 2) van de printjes ook ruimte is gemaakt om parallel aan de 390 Ohm weerstand die de stroomsterkte bepaald (R2), nog een tweede weerstand parallel te zetten. Op deze manier kan de stroom ook verhoogd worden, mocht dat nodig blijken.
De volgende foto toont hoe de LED strip, het printje en de elco onder het dak van de 3-asser zijn geplakt.
(https://images.beneluxspoor.net/bnls_2025/14-Print-3By-6804dedf04b76.jpg) (https://images.beneluxspoor.net/bnls_2025/14-Print-3By-6804dedf04b76.jpg)
En tenslotte nog een foto waarbij ook de stroomafname van de wielen is aangesloten, en het geheel getest kan worden.
(https://images.beneluxspoor.net/bnls_2025/15-Ingebouw-3By-6804dedf43b1a.jpg) (https://images.beneluxspoor.net/bnls_2025/15-Ingebouw-3By-6804dedf43b1a.jpg)
Misschien nog wat slotopmerkingen aan het einde. In vergelijking met mijn initiële poging een eenvoudige schakeling met gewone componenten en krimpkous als "3D kunstobject" te solderen, zijn de eerder besproken printjes een grote vooruitgang. Het in elkaar solderen van het initiële "kunstobject" kost ongeveer 30 minuten per "object". Het compleet monteren van het printje kost 1 à 2 minuten, en daarnaast is het veel netter en werkt ook nog eens beter. Veruit het meeste, en ook het vervelendste werk, is het afnemen van het dak van de rijtuigen, en in veel gevallen moet zelfs het hele rijtuig uit elkaar. Soms zijn de klikverbingen waarmee het dak vast zit ook heel kwetsbaar, en breken die af (heb ik uit eigen ervaring moeten vaststellen :'(). Ook het vastplakken van de reizigers kost tijd. Het aanbrengen van de verlichting zelf is echter triviaal.
Wat mij ook verbaasd is hoe weinig stroom moderne LED strips nog hebben. De door mij gebruikte strips (Ali, Warm White, 12V 120LEDs 8mm, IP20 Non Waterproof, 5m) hebben genoeg aan 0,1 à 0,2 mA per (setje van 3 in serie geschakelde) LEDs. Ik lees dat oudere LED strips vaak meerdere milli-amperes per LED nodig hebben. Ik vind dat behoorlijk veel.
Voor 3 strips van ieder 5 meter heb ik, inclusief verzending, 13,50 Euro betaald. Dus ongeveer 30 cent per rijtuig van 30cm). Daar komen de printjes (0,25 cent per stuk) nog bij, en een elco van 470 uF / 25V, die ongeveer 10 cent kost. Totaal kost de verlichting per rijtuig me dus 65 cent.
Groet, Aiko
-
Als analoge rijder heb ik nog veel rijtuigen met gloeilampjes als binnenverlichting. Voorlopig ben ik daar nostalgisch tevreden mee, maar ik denk ook weleens na over vervanging door LED-verlichting.
Als ik het goed begrijp is de schakeling ook geschikt voor analoog gebruik. Daar heb je misschien extra profijt van de stroombron, omdat die ervoor zorgt dat ook bij lage rijspanning de binnenverlichting al op volle sterkte brandt (mits boven de mininumspanning voor de LED’s). Klopt dat?
En over die potmeter of parallelle weerstand: is de print niet zo te ontwerpen dat je er een losse weerstand aan kunt solderen, net als de elco? Ik bedoel zo een met ouderwetse afmetingen, dus geen SMD. Scheelt:
- Een potmeter die je maar een keer gebruikt
- Een parallele weerstand die onnodig stroom verbruikt
En maakt het nog steeds makkelijk de juiste helderheid in te stellen.
-
Analoog is lastiger met die 12V strips. Ze zouden het wel goed kunnen doen als je rijdt met een pwm regelaar. Maar 'normaal' analoog zijn die 12v strips niet handig. Ze gaan pas aan op een relatief hoge spanning.
Wat beter zou zijn voor analoge rijtuigen, is om iets van een buck converter te plaatsen voor je stroombron. Dan zou je al volledige lichtsterkte hebben op de laagste snelheden. Je kan experimenteren met zo'n boost converter printje van Alie.
Mvg,
Bas
-
Je kan deze (https://nl.aliexpress.com/item/1005006246444345.html?spm=a2g0n.productlist.0.0.2c7532a6f7EIEP&browser_id=02a45975f7b34ed4a7bce4a59f90c1eb&aff_trace_key=d82839a8a03949a6b2e3e13ef6ccc820-1737369648957-05833-UneMJZVf&aff_platform=msite&m_page_id=juhgepjcawmkicbe19653a027eb1410e2c40a1efd9&gclid=&pdp_ext_f=%7B%22order%22%3A%22196%22%2C%22eval%22%3A%221%22%7D&pdp_npi=4%40dis%21EUR%211.57%211.12%21%21%2112.74%219.10%21%40211b807017451597270603659e8a64%2112000038475237909%21sea%21NL%210%21ABX&algo_pvid=c20f7168-9a00-4a38-ab18-52e885073414&search_p4p_id=20250420073527368662748516700007472755_4) proberen, maar ze werken vanaf 3V.
Er bestaan buck converters die van nog lager werken. Dan gaan je lampjes al aan voordat de trein rijdt ;D
Bas
-
Dat zou helemaal mooi zijn ;D
Maar bedankt Bas, nu snap ik het. De oorspronkelijke schakeling van Aiko:
(https://images.beneluxspoor.net/bnls_2025/Schema-Eenvoudig-680290332d41c.png) (https://images.beneluxspoor.net/bnls_2025/Schema-Eenvoudig-680290332d41c.png)
…geeft aan dat op de LED-strip drie LED’s van 2,75V in serie staan. Zelfs als je de weerstand op de strip overbrugt, heb je dan minimaal ruim 8V startspanning nodig voor je binnenverlichting. Met PBM omzeil je dat. Ik rijd op mijn hoofdbaan (nog) niet met PBM, op het Rangierbahnhof wel.
-
Als het dan zo makkelijk en goedkoop is om printplaatjes met componenten te laten fabriceren, is dit misschien een gat in de markt, voor analoge rijders:
Een LED-strip ter lengte van een wagon, in de vorm van een printplaat, met alle LED’s parallel. Op de print geïntegreerd een stroombron, met een potmeter of los te solderen weerstand, om de helderheid van de binnenverlichting te regelen. Nog een elco als buffer et voilà!
Wat zou dat kosten?
-
Dat is sterk aantal afhankelijk. Als je losse strips gaat maken en batches van 30 ofzo dan zal je op iets van 3 a 4€ per strip zitten, all in clusive.
Als je panels laat maken, dan wordt dat minder maar ik kan je niet vertellen hoeveel. Ik kan voor mijn strips wel eens een offerte doen daarvoor ???
Ik denk zelf niet dat het een gat in de markt is.
Bas
-
Dat is sterk aantal afhankelijk. Als je losse strips gaat maken en batches van 30 ofzo dan zal je op iets van 3 a 4€ per strip zitten, all in clusive.
Als je panels laat maken, dan wordt dat minder maar ik kan je niet vertellen hoeveel. Ik kan voor mijn strips wel eens een offerte doen daarvoor ???
Ik heb pas eens gekeken, maar kwam, inclusief verzending en belasting, op 3,80 als je er 5 laat maken. Bij 20 stuks wordt dat 1,95 en bij 30 stuks 1,70 per stuk. Als je er panels van maakt, wordt dat nog ietsje goedkoper. Opgemerkt moet worden dat ik er alleen basic componenten op had zitten. En ik had een kortingscoupon van 8,30 ook meegerekend. De bovengenoemde kosten worden voor ongeveer de helft bepaald door verzending en belasting.
Groet, Aiko
-
Je zit met strips met de lengtes. Wanneer ze lang worden gaat, in dit geval, de 28cm een rol spelen. Ik heb hier 2x offerte gemaakt voor de 28cm strips.
(https://images.beneluxspoor.net/bnls_2025/deleteme-680550a5e2cea.png) (https://images.beneluxspoor.net/bnls_2025/deleteme-680550a5e2cea.png)
Ik kon helaas geen grotere aantallen doen omdat ze daarvoor niet meer genoeg LEDs op voorraad hadden ::).
Mvg,
Bas
-
Beste lezers,
Vandaag wil ik starten met de beschrijving van een nieuw project: de wisselaandrijving van onze clubbaan.
Onder de baan gebruiken we oude telefoonrelais (48 Volt – 1000 Ohm) om de wissels te schakelen. Oorspronkelijk verzorgden deze relais ook de polarisatie van het hartstuk. Omdat echter bleek dat deze oude relais niet altijd betrouwbaar contact maakten, hebben we naast elk telefoonrelais een apart 48V relais geplaatst voor de polarisatie (op de foto te herkennen als het blauwe relais).
(https://images.beneluxspoor.net/bnls_2025/Wisselrelais-2-68af523e76978.jpg) (https://images.beneluxspoor.net/bnls_2025/Wisselrelais-2-68af523e76978.jpg)
(https://images.beneluxspoor.net/bnls_2025/Wisselrelais-1-68af523e7b5e5.jpg) (https://images.beneluxspoor.net/bnls_2025/Wisselrelais-1-68af523e7b5e5.jpg)
(https://images.beneluxspoor.net/bnls_2025/Wisselaandrijving-1-68af523f64ea5.jpg) (https://images.beneluxspoor.net/bnls_2025/Wisselaandrijving-1-68af523f64ea5.jpg)
De wisselprintjes zijn allemaal voorzien van een RJ45-connector. Op de buitenste pinparen (1+2 / 7+8) staat 48V wanneer het wissel omgezet moet worden, en geen spanning wanneer de ruststand gewenst is.
De wisselprintjes worden via een platte, achtpolige witte kabel aangesloten op de centrale besturingselektronica. Elk station heeft zijn eigen besturing. In de oude situatie was deze elektronica verbonden met een PIO-kaart in de pc, waardoor we de wissels met 5V-signalen vanuit de computer konden aansturen. De centrale besturing bestond (in grote lijnen) uit een optocoupler per ingangssignaal, die vervolgens via kleine printrelais 48V op de RJ45-uitgangen zette.
Door de jaren heen is deze elektronica organisch gegroeid. De tijd is nu rijp voor een grondige vernieuwing. Hieronder zie je een foto van de oude besturing; de rood omlijnde delen zijn verantwoordelijk voor de wisselsturing.
(https://images.beneluxspoor.net/bnls_2025/Bedrading-onder-de-baan-05-68af52403f130.jpg) (https://images.beneluxspoor.net/bnls_2025/Bedrading-onder-de-baan-05-68af52403f130.jpg)
Zoals eerder vermeld, wordt de baanbesturing stapsgewijs overgezet op DCC. Daarom hebben we een nieuwe DCC-wisseldecoder ontwikkeld, die per decoder 16 wissels kan schakelen. Hieronder zie je een screenshot van het nieuwe printontwerp.
Zoals te zien is, zijn de oude “losse” RJ45-connectoren vervangen door moderne connectors zoals die ook in netwerkswitches gebruikt worden. Op elke connector kunnen vier stekkers worden aangesloten. Bij elke uitgang horen een gele en een groene LED.
(https://images.beneluxspoor.net/bnls_2025/3D-View-1-68af524041fbe.png) (https://images.beneluxspoor.net/bnls_2025/3D-View-1-68af524041fbe.png)
We hebben nagedacht over een nuttige toepassing van deze LEDs. Uiteindelijk is het volgende principe gekozen:
– Wanneer een wisselrelais correct is aangesloten en zich in ruststand bevindt, brandt de groene LED.
– Wanneer het relais wordt geactiveerd, dooft de groene LED en gaat de gele branden.
Na wat gepuzzel is het hieronder staande principeschema opgesteld. Dit is op een experimenteerprint getest. Daarbij is op alle punten gemeten welke spanningen aanwezig zijn en hoeveel stroom er loopt. De theorie en de praktijk bleken gelukkig met elkaar in overeenstemming te zijn. Wat wel wat tegenviel, is dat de LEDs maar liefst 1 à 2 mA nodig hebben om zichtbaar te zijn. Daarom zijn soms weerstanden parallel geschakeld om oververhitting te voorkomen.
(https://images.beneluxspoor.net/bnls_2025/Principe-68af52413a161.png) (https://images.beneluxspoor.net/bnls_2025/Principe-68af52413a161.png)
In het schema zijn spannings- en stroomwaarden aangegeven:
– Groene waarden gelden wanneer het relais niet geactiveerd is.
– Paarse waarden gelden wanneer het relais wel geactiveerd is.
In de emitter van de transistor is een kleine weerstand van 1 Ohm opgenomen. Deze dient om via de ADC-ingangen van de processor te kunnen meten hoeveel stroom er loopt. Bij een fout of overbelasting kan het wissel dan (hopelijk snel genoeg) worden uitgeschakeld. Of de ADC in de praktijk snel genoeg reageert om schade bij een kortsluiting te voorkomen, moet nog blijken – de reactietijd ligt in de orde van tientallen microseconden.
Commentaar is van harte welkom!
Groet,
Aiko
-
leuk om te zien dit! ik heb ook nog een zwik van die relais liggen ;D
-
(y) Koop je wel de goede RJ45 connectoren? Je hebt ze ook met interne RC pasieve elektronica. Die fout heb ik ook op m'n naam staan toen ik een 8 voudige kocht.
-
(y) Koop je wel de goede RJ45 connectoren? Je hebt ze ook met interne RC pasieve elektronica. Die fout heb ik ook op m'n naam staan toen ik een 8 voudige kocht.
;D ;D ;D
Ik heb ze al gekocht (LCSC) en getest. Er zit niets intelligents in :police:
leuk om te zien dit! ik heb ook nog een zwik van die relais liggen ;D
Als je die zou willen gebruiken, dan ken ik wel iemand die daarvoor een decoder heeft :D
Groet, Aiko
-
ik hou het zeker in gedachte ;)
-
Met hoeveel Volt schakel je die dingen? Als ze het gewoon op 12V~18V doen, dan volstaat mijn open-source solenoid decoder ook. Die kan er met een bepaalde pre-set 16 stuks aansturen dan
-
Aiko,
Ik ben ook benieuwd hoe je de stroomafname hebt gemaakt op de wielen.Heb je daar ook foto's van.
mvg Henk