Twentse Modelspoorweg Club (TMC): Digitale besturing

[bask185]

Je kan ook op de lijnen. Van io pinnen naar schakelaars toe en led met weerstand toevoegen. De kathode hang je aan de Schakelaar kant.

Als je de led aan wilt zetten, laat je de IO pin sinken. Om je schakelaar dan in te lezen, zet je de pin kort op input met pull-up. Dan kan je binnen een ms de Schakelaar samplen en dan weer laten sinken. Als je dit elke 50ms doet, dan zie je de led niet uit gaan.

En als de led gewoon uit moet zijn dan, zet je de pin gewoon op input pull-up en kan kan je samplen.

Heb je extra led feedback.

Mvg

Bas

[AP3737]

Dank voor jullie feedback 

Heb je de bediening al uitgedacht van de functie knoppen?

Hi Bas. Daarover zijn tijdens de koffie (zijn we goed in!) al veel discussies geweest. 
Het lijkt er een beetje op dat de meerderheid voorstander is van "aanpasbare" functietoetsen. Dus (willekeurig voorbeeld) knop 1 voor b.v. F0, knop 2 voor F5 en knop 3 voor F63. Hoe dat ingesteld zou moeten worden, hebben we nog niet verder besproken. Het lijkt me dat je dat met Loconet wel zou moeten kunnen doen.

Maar je kan voor elk knopje de functie nummers naar keuze toepassen per slot. Dan kan elke gebruiker de handregelaar finetunen naar zijn eigen treinen.

Precies zo dus. Op de club is het vaak zo dat er een vaste koppeling is tussen loc en FREDI. Op de achterkant van de behuizing zit een stickertje dat aangeeft waar welke knop voor is.

Maar je kan maybe die klagers ook eens aanleren hoe ze functiemapping op de treinen kunnen doen.

    Het is makkelijker om dit gewoon zo te bouwen, in plaats van een halve vereniging op DCC-herhalingscursus te sturen . Bovendien is dit ook leuker.

Heb je ook nagedacht over het stroomverbruik en de belasting van de loconet bus?

Goed punt. Loconet handregelaars worden vaak met 12 tot 15V gevoed. De standaard FREDI wordt intern gevoed op 3,3V. De gebruikte ATMega8 heeft dan ongeveer 5mA nodig (7,3728MHz). De LEDs (drie stuks) trekken ongeveer 3mA per stuk. Ik verwacht daarom dat in de praktijk een FREDI iets als 10mA zal trekken (ik heb dit niet nagemeten, dus ik kan het mis hebben). Wat bij de FREDI belangrijk is, is dat de spanning door een LDO (LM2936M-3.3) van Loconet spanning naar 3,3V wordt gebracht. Driekwart van het vermogen wordt daarbij in warmte omgezet en gaat verloren. Deze nieuwe schakeling gebruikt echter een Buck-Down converter, die de Loconet spanning "omzet" na 3V3 (of 5V) zonder warmte verlies. Dus als ik "transformeer" naar een 3x lagere spanning, dan kan ik daar ongeveer 3x meer stroom trekken. Daarom kan ik van de Loconet 10mA halen, maar intern ruwweg 30mA ter beschikking hebben. De AVR128DA28 processor vraagt ongeveer 50% van wat de ATMega8 nodig heeft, laten we zeggen 3mA. Het display is de grote stroomtrekker (20mA?), maar dankzij de buck-converter is dat voor Loconet 5 tot 7mA belasting. Bij elkaar verwacht ik daarom dat deze handregelaar ongeveer evenveel stroom trekt als de FREDI.

Dat ziet er uit als een mooie regelaar Kan me zo voorstellen dat daar ook buiten TMC wel interesse voor is

Hi Reinder. Dank  . Ik kan me ook voorstellen dat daaraan best behoefte is, vandaar dat ik dit probeer als eenvoudig zelf te solderen print. Helaas is het display waarschijnlijk net iets te breed voor de bestaande FREDI kastjes, dus moet er misschien zelf een 3D kastje geprint worden.

als je dit (perongeluk) op een LocoNet-B aansluiting aansluit dan sluit je het booster signaal kort.

Auw  . Even helemaal niet aan gedacht. Meteen toegevoegd. Dank 

want in een standaard LocoNet setup ( b.v. Digitrax ) bestaat alleen "LocoNet-B". En dan achter die twee diodes nog een 22-47uF/16V elkootje.

Hi Karst. Dank, ik wist niet dat er ook centrales zonder LocoNet-T waren. Ook het elco-tje meteen toegevoegd, en nog wat andere kleine aanpassingen. 

De "uitdaging" zit nu vooral in de Loconet software. Ik ben daar altijd met een wijde boog omheen gelopen (als je wat dieper in de Arduino Loconet library duikt begrijp je misschien wel waarom  ). Op de club zijn er echter personen die meer van LocoNet weten. Misschien is een aanpak om van de Loconet2 library uit te gaan, die een soort interface tussen de hardware en hogere Loconet laag specificeert. Of misschien de code van Mikael Ejberg omzetten naar een Arduino Library. Maar misschien hoef je voor een handheld echter maar een paar Loconet functies te implementeren, en valt het allemaal straks wel heel erg mee. We zullen zien (maar eerst moeten we de centrale afmaken; als de printen binnen zijn daarover meer).

Groet, Aiko
 

[bask185]

Dat scherm kan ook nog wel wat tijd opslokken hoor en geheugen vooral, afhankelijk van welke library je pakt. De verkeerde library gebruikt 1 bit ram per pixel, met 128x64 pixels, zit je al op een kb, maar je kan wel mooie dingen er mee maken.

Ik heb voor die encoder een library die ook iets doet met de rotatiesnelheid van de knop. Als je sneller draait, dan maakt die grotere stapjes. Hij doet het niet zo extreem als een marklin MS2, ik heb dat wel redelijk ok gefinetuned. De library gebruikt een debounce library die we ook voor de andere knoppen kunnen gebruiken.

Als je die encoder elke ms sample't heb je ook geen externe interrupts nodig. Die encoders draaien niet zo hard.

Wat de configuratie instellingen betreft. Je kan een seriele interface maken waarop je zo'n usb-ttl ding aan kan sluiten. Dan kan iedereen het thuis doen met zoiets stoms als een putty terminal. (Je kan ook chatGpt een GUI in elkaar laten flansen die het configureren makkelijker maakt  )

Anders zit je toch vast aan LNCV programmering. En ook daarvoor kan je een GUI maken die werkt met de yamorc centrale. Het is een kwestie van een USB verbinding opzetten met de loconet com poort en je kan serieel loconet berichten heen en weer sturen.  Ik kon met de dr5000 + tooling ook lncv configureren, maar dan 1 CV per keer. En je werkt dan met nummertjes en niet met naampjes. Het is wel werkbaar verder. Ik denk dat dit een goed uitgangspunt is.

Naast de 8 functie mappings, wil je ook waarschijnlijk het DCC adres, een throttle ID, misschien nog een optie om slot stealing uit te kunnen zetten. Misschien nog een naampje van 8 characters? voor het mooi.


Ik ben zelf ook geen fan die nmra arduino library. Ze maken van die absurd lange switch statements met daarin nog meer switch statements. ze stouwen ook m.i. teveel dingen in 2 files. Er staan echt 4 of 5 classes in 2 bestandjes. En die throttle class vond ik niet lekker werken. Je moest alsnog zelf aan de gang om goed met slots te kunnen wisselen. Daar hadden ze geen knappe state machine of voorziening voor ingebakken. Daar is ruimte voor verbetering.
 
Er zijn maar handje opcodes die je hoeft af te handelen, een paar slot dingetjes en wat instructies voor speed, dir en functies enzo. En een scheiding tussen de software laag en de hardware laag. Dan kan 1 iemand aan de hardware aansturing werken terwijl de ander een goede slot afhandeling inbakt.

via OPC_IMM_PACKET kun je rechtstreeks een DCC commando naar de rails sturen...niet ideal maar het werkt. Ik gebruik dat in Traintastic om RCN-213 DCCext commando's te sturen.

Ik ging opzoeken hoe ik dcc ext op de baan zet, maar ik heb het ook gedaan 

Code: [Selecteer]

case OPC_IMM_PACKET:        processDccExtRequest() ;    return 1 ;
Maar ik heb een groot vraagteken. Als je op die manier een hoge functie nummer aanstuurt, komt die dan ook in de cyclische DCC pakketjes terecht? Ik heb een donkerbruin vermoeden van niet 
Ik weet sws niet welke centrales wel en niet hoeveel functies nu precies ondersteunen en of ze dan ook herhaald worden. Bij de z21 kwam ik er ook achter dat je de hogere functies kon aanvinken voor het herhalen. Ik kwam er pas achter doordat de interieur verlichting onder F14 niet automatisch aanging na een stroomuitval.

En de OPC_IMM_PACKET krijg je niet terug van de centrale. vzik kan je met loconet niet naar een throttle opsturen dat F61 aan is. Dus dat moet je dan zelf maar onthouden.
Deze fred specifiek kan prima zelf onthouden in EEPROM welke functies aan of uit staan. Je werkt toch maar met 1 adres en 1 trein. Maar als sommige hoge functies niet herhaald worden door de centrale, dan kan er na een stroomuitval een mismatch zijn met wat de throttle zegt dat aanstaat en wat er echt aanstaat. Ik denk niet dat je dat kan oplossen, dan moet je gewoon maar 2x op de functie knop in kwestie rammen.

Maar wie wil er nu meer dan 28 functies? Dat zijn er best heel veel  Ik heb het alleen bij sommige marklins gezien, maar al die luidspreker symbooltjes waren moeilijk uit elkaar te houden  . Je moest echt leren wat wat was, om ze te kunnen gebruiken.

Ik weet van de loconet docs dat er tot en met F28 heen en weer communicatie is. Maar ook dat moet iemand van jullie reverse engineeren en op internet zetten. Of zoeken naar iemand die dit al gedaan heeft. Je kan een loconet usb sniffer maken en dan hoge functies sturen via een multimaus bijvoorbeeld of een PC programma en dan kan je zoek de tien verschillen spelen met bitjes. t/m F12 staat in het PE document

Mvg,

Bas

[reinderlf]

Hi,

Anders zit je toch vast aan LNCV programmering. En ook daarvoor kan je een GUI maken die werkt met de yamorc centrale. Het is een kwestie van een USB verbinding opzetten met de loconet com poort en je kan serieel loconet berichten heen en weer sturen.  Ik kon met de dr5000 + tooling ook lncv configureren, maar dan 1 CV per keer. En je werkt dan met nummertjes en niet met naampjes. Het is wel werkbaar verder. Ik denk dat dit een goed uitgangspunt is.

Heb in Traintastic een LNCV programmer zitten, die kan je een mooi lijstje geven van registers en UI controls op basis van een XML file, zie: https://github.com/traintastic/lncv

ls je op die manier een hoge functie nummer aanstuurt, komt die dan ook in de cyclische DCC pakketjes terecht? Ik heb een donkerbruin vermoeden van niet 

Nee, het pakket wordt 1..7 keer verzonden, dat geef je mee met het OPC_IMM_PACKET bericht, daarna is het klaar, de centrale geeft dat gewoon door aan de rails. Overigens meen ik ergens eens gelezen heb dat de YaMoRC centrale daar nog wel wat slims mee doet in sommige gevallen.

Ik weet van de loconet docs dat er tot en met F28 heen en weer communicatie is. Maar ook dat moet iemand van jullie reverse engineeren en op internet zetten. Of zoeken naar iemand die dit al gedaan heeft. Je kan een loconet usb sniffer maken en dan hoge functies sturen via een multimaus bijvoorbeeld of een PC programma en dan kan je zoek de tien verschillen spelen met bitjes. t/m F12 staat in het PE document

F13-F28 heb ik "afgeluisted" van een Intellibox en DR5000, al heb ik het vermoeden dat dat de Uhlenbrock extensie is, heb nog geen Digitrax centrale in mn handen gehad om dat es uit te puzzelen.

Groeten,
Reinder

[AP3737]

Beste Bas en Reinder

Dank voor jullie feedback.

Dat scherm kan ook nog wel wat tijd opslokken hoor en geheugen vooral, afhankelijk van welke library je pakt.

Geheugen lijkt me niet het grote probleem (128kB beschikbaar), maar tijd zou dat wel kunnen zijn. Dank voor de waarschuwing; we zullen daarop moeten letten.

Ik heb voor die encoder een library die ook iets doet met de rotatiesnelheid van de knop. Als je sneller draait, dan maakt die grotere stapjes.

Ik weet niet of dat nodig is. We rijden met 28 stapjes, en mensen worden geacht natuurgetrouw te remmen en op te trekken.

Wat de configuratie instellingen betreft. Je kan een seriele interface maken waarop je zo'n usb-ttl ding aan kan sluiten.

Technisch zou dat kunnen. Gisteren stelde iemand echter voor om de keuze gewoon via de draaiknop te laten doen, en net zo lang te draaien totdat je op het display de gewenste Functie ziet. Lijkt me ook wel aardig.

Er zijn maar handje opcodes die je hoeft af te handelen, een paar slot dingetjes en wat instructies voor speed, dir en functies enzo. En een scheiding tussen de software laag en de hardware laag. Dan kan 1 iemand aan de hardware aansturing werken terwijl de ander een goede slot afhandeling inbakt.

Dat klinkt goed 

Heb in Traintastic een LNCV programmer zitten, die kan je een mooi lijstje geven van registers en UI controls op basis van een XML file, zie: https://github.com/traintastic/lncv

Dank. Uiterst nuttig!

Groet, Aiko

[bask185]

Geheugen lijkt me niet het grote probleem (128kB beschikbaar), maar tijd zou dat wel kunnen zijn. Dank voor de waarschuwing; we zullen daarop moeten letten.

Dit ging over het RAM geheugen  Maar dat zie je niet terug in de compiler output, dat zie je pas terug als de rest van je programma net even teveel RAM gebruikt. Dan gaan dingen de soep in lopen en dan zoek je je wezenloos.

Gisteren stelde iemand echter voor om de keuze gewoon via de draaiknop te laten doen, en net zo lang te draaien totdat je op het display de gewenste Functie ziet. Lijkt me ook wel aardig.

Ik zou doen:
encoder knop lang indrukken -> opent menu.
Dan kan je scrollen door een handje menu's zoals
- throttle ID (zit in slot writes)
- Dcc adres (of doen via dispatchen, dat kan beiden)
- snelheidsstapjes (28 is niet echt meer gangbaar)
- trein naam?
- custom functie mapping aanzetten
- F0 aanpassen
.. Fx aanpassen (alternatief functie nummer, en evt zelf resettende pulse tijd?)
- F8 aanpassen.
- fabriekinstellingen
- dispatch uit zetten
- club mode

Kort drukje kiest een van de sub-menu's, lang drukje ->  terug naar vorige menu, ben je in al in het hoofd menu -> exit menu.

Ik weet niet of dat nodig is. We rijden met 28 stapjes, en mensen worden geacht natuurgetrouw te remmen en op te trekken.

Nadat een throttle een slot heeft bemachtigd, kan de throttle doorgeven aan centrale met een slot data write dat hij 28 stapjes wilt. Waarschijnlijk is 128 stapjes de default voor meeste centrales. Ik weet alleen niet of je dan de snelheidswaarde ook moet doorgeven in 0-28 of 0-127 (trial en error lost dat snel op denk ik)

Waarom wil je perse met weinig stapjes werken. Ik geef toe het is genoeg, als je max snelheid niet te hoog staat. Maar waarom zou je? Meer is wel beter in dit geval. Elke half moderne decoder doet 128 stapjes. Pas als een trein een probleem geeft, zou ik de 28 stapjes optie aanzetten. Maar anders gain je eigenlijk alleen maar achteruitgang.

Ik zou die alt knop gebruiken voor F0, default. Maar met een lang drukje zou ik dan adres acquireren ofzo.... en een sub-menuutje om dit uit te zetten.

Ik denk ook altijd aan universeelheid. Vandaar die extra opties/gedachten spinsels die je ziet in het menu lijstje. Het is imo beter als straks elke club dit ding kan gebruiken. En zoveel mensen zoveel wensen.

Mijn throttle Fx had aanvankelijk een "feature" waarbij de snelheid 0 moest zijn, voordat je van adres kon wisselen dmv een dispatch. Dat leek me handig en veilig voor clubs dat iemand geforceerd wordt om zijn oude trein eerst stil te zetten voordat hij een ander bedient.

Maar voor de thuisgebruiker is dat een mega bug. Want als je maar 1 throttle heb, kan jij niet eens effies 3 treintjes op je 3 ovaaltjes laten rondtouren met die ene throttle. Dus de feature/bug was toen gepromoveerd naar  "clubmodus optie". Dat kan je aanzetten als je het wilt gebruiken. Toen werd de bug weer een feature 

( Ik had toen meteen een nieuwe feature nodig. Dat was de catch functie. Je moest eerst je draaiknop gelijk~ish stellen aan de nieuw verkregen trein, voordat je hem kan bedienen. De reden waarom was simpel. Er zat een absolute potmeter op en dan heb je dit ook nodig. Multimausen hebben het ook sinds V2.x. Met een encoder is het niet belangrijk. )

Zoals jullie niet van adres gaan wisselen, willen jullie waarschijnlijk de dispatch mogelijkheid gewoon uit hebben staan. Maar grote kans dat de rest het wel wilt hebben. En ik zou functie mappen ook achter een optie zetten. Eerst de optie aan, dan zie je nieuwe menu's. Hoe minder dingen gebruikers tegenkomen, hoe minder vragen er ontstaan.

Wat me nu te binnen schiet. Misschien dat mensen er een kleine bibliotheek in hebben willen. Een instelbaar handje aan adressen. In code is dat niet veel meer werk ofzo als je het goed aanpakt.

Ik had nog een laatste brainfart over hoe settings aan te passen. Aangezien je toch al I2C toepast, je zou evt een externe eeprom kunnen gebruiken in IC voet. Die eeprom kan je er uit trekken, ff configuren in de dedicated arduino met ook een IC voet

Wat kan je er mee, je kan config bestandjes maken en bewaren (denk aan .ini files met key:value pairs) van elke throttle. Dan klop je ff een textbestandje en via putty of zo iets, schiet je dat gehele bestandje serieel naar de arduino en zijn programma verwerkt de seriele data en prakt de data in de EEPROM. En als klap op de vuurpijl. Je kan bij opstarten de EEPROM data eenmalig uitlezen en overlepelen naar je interne EEPROM. Dan kan je de eeprom chip er weer uit trekken. Klinkt misschien als veel werk, maar ik denk dat een menu maken, meer werk is. Anyways just a  thought.

Mvg,

Bas

[reinderlf]

Ik weet alleen niet of je dan de snelheidswaarde ook moet doorgeven in 0-28 of 0-127 (trial en error lost dat snel op denk ik)

Is altijd 0 STOP, 1 ESTOP, 2-127 snelheid, ongeacht het aantal stappen wat de centrale doet voor een decoder, wel zo handig (XpressNet heeft dat niet dan heb je per aantal stappen 14/27/28/128 een ander commando)

Groeten,
Reinder

[AP3737]

Beste lezers

In een eerdere bijdrage heb ik al even kort genoemd dat we momenteel bij de TMC bezig zijn met het ontwikkelen van een nieuwe DCC centrale. Niet omdat bestaande centrales niet goed genoeg zouden zijn, maar gewoon omdat het leuk is te proberen zelf een centrale te ontwikkelen. En omdat we meerdere centrales nodig hebben (1 per station), kunnen we met zelfbouw misschien ook nog wel wat geld besparen.

Laat ik beginnen te vertellen waar we de centrales voor gaan gebruiken. Primair is dat voor de bediening van wissels (accessory decoders) en de terugmeldingen van bezetmeld decoders. Het is niet de bedoeling dat onze zelfbouw centrale ook gebruikt gaat worden voor het rijden van de treinen; daarvoor blijven we onze Yamorc gebruiken. Desondanks bouwen we in de nieuwe centrale toch ook wat zaken in waardoor rijden in principe mogelijk wordt; alleen zullen we in de ontwikkeling daarvan weinig energie steken en dat ook maar beperkt testen.

Wat onze ontwikkeling bijzonder maakt, is dat we geen bestaande open source centrale gaan nabouwen, zoals DCC-EX , Z21PG of OpenRemise, maar dat we echt iets nieuws gaan ontwikkelen. Uiteraard laten we ons door deze bestaande open source centrales inspireren, en nemen we stukken software en hardware over. Maar in essentie wordt het een nieuwe open source centrale. Maar als je onze ontwikkeling toch in een hokje wilt plaatsen, dan zou je het als een moderne variant van de Z21PG kunnen zien.

Maar laat ik beginnen met de ontwerpeisen. Zoals gezegd moet de centrale wissels kunnen bedienen, dus DCC accessory commando’s kunnen sturen, en bezetmeldingen kunnen terug ontvangen. Als terugmeldbus gebruiken we bij de TMC de Lenz RS-bus. De centrale moet verder via Ethernet en XpressNet kunnen worden aangestuurd. Tot zover de “must have” eigenschappen. Qua specs zou je het dus met Lenz (met Lenz interface) of Yamorc kunnen vergelijken.

Maar nu we toch bezig gaan, bouwen we er meteen maar wat zaken bij. Zo wordt ook het Z21 protocol over Ethernet geïmplementeerd, en is aansturing via USB (XPN en Z21) voorzien. Ook Loconet (B en T) wordt geïmplementeerd, komt er een CDE booster interface, en worden ook de meeste DCC commando’s geïmplementeerd, zodat rijden en programmeren ook mogelijk moet zijn. Op de print komt daartoe een kleine “versterker” (DRV8871), maar via CDE / Loconet-B kunnen ook volwaardige boosters worden aangesloten. Verder is er een (RS485) XpressNet interface (DIN alsmede LMAB), waarop bijvoorbeeld handhelds (Lenz LH, MultiMouse) aangesloten kunnen worden.

Laat ik ook expliciet noemen wat we niet gaan implementeren. Ten eerste is dat WIFI (omdat dat instabieler is dan bedraad Ethernet). Ook komt er geen S88-bus (dergelijke modules hebben we niet, en we hebben een beperking aan pinnetjes en print ruimte). Ook gaan we geen RailCom terugmelding en automatische aanmelding implementeren.

Misschien moet ik ook uitleggen waarom we niet een  bestaand open source ontwerp gewoon nabouwen. DCC-EX is, wat ons betreft, een te gesloten / monolitisch ontwerp. DCC-EX bouwt voort op de Arduino Mega (wat ons betreft een verouderde en veel te dure processor), of de ESP32 / STM32. DCC-EX heeft geen Ethernet interface, en ondersteunt geen XpressNet / Z21. De software is niet modulair (in de vorm van libraries), en daarom moeilijk aanpasbaar (take it or leave it). OpenRemise (Vincent Hamp) is wat ons betreft een veel leukere ontwikkeling, maar heeft (op dit moment) nog geen Ethernet / XpressNet interface. Ook is OpenRemise wat duurder, omdat de print compleet geassembleerd is. Wat voor ons het dichtst in de buurt komt, is de Z21PG ontwikkeling (Philipp Gathow). De Z21PG is echter een wat ouder ontwerp, gebaseerd op de Arduino Mega (zie boven). Geen van deze bestaande ontwerpen ondersteunen RSBus terugmelding dan wel XpressNet via Ethernet. Vandaar dat we kiezen voor een nieuw ontwerp, waarbij we delen van de Z21PG verbeteren en hergebruiken.
Waar we voor de eerste versie bewust voor gekozen hebben, is gebruik te maken van Through Hole componenten en bestaande (AliExpress) modules voor voeding (12V en 3V3), DRV8871 versterkers (DCC en CDE), polariteitprotectie (XL74610, “ideale diode”), Ethernet (W5500) en de processor (Raspberry Pico 2). Misschien dat we later alsnog een ontwerp gaan maken dat (gedeeltelijk) door JLCPCB wordt geassembleerd, maar dat is nog niet besloten.
Rond de kerst zijn we begonnen met wat eerste tests. In overleg met Philipp Gahtow hebben we zijn DCC library onder handen genomen. Het resultaat is een complete rewrite van de hardware specifieke code; zijn DCC scheduler en packet generator hebben we grotendeels hergebruikt. We hebben twee varianten van de hardware specifieke code gemaakt. De eerste gebruikt, net als de oorspronkelijke PG code, bit-banging om het DCC signaal te genereren (brrr). De bestaande code is compleet herschreven en modulair opgebouwd. Veel leuker is de tweede variant, waarbij we de hardware peripherals van moderne processoren gebruiken voor het genereren van het DCC signaal. Voor de ESP32 is dat de RMT, voor DxCore moderne timers, voor STM moderne timers en DMA, en voor de Raspberry Pico de PIO en DMA. Van al deze vier varianten levert de Pico het “mooiste” DCC signaal op, met rotsvaste timing en nauwelijks belasting van de processor. Ook is de Pico dual core, en loopt op 125/200Mhz. Voor onze “TMC” centrale hebben we daarom voor de Pico gekozen.

Hieronder een foto van de eerste print. Er zitten nog wat foutjes in, maar zoals het er nu uit ziet kunnen we met deze print al behoorlijk testen. De status is dat we al een uiterst precies DCC signaal kunnen genereren, eerste versies hebben van het XpressNet / Z21 Ethernet interface, en met andere functies (Loconet, RSbus) eerste test software hebben. Wordt dus vervolgd.



Meer details over de library om DCC signalen te genereren is (voorlopig) te vinden op: https://github.com/aikopras/DCCInterfaceMaster_workInProgress

[Eric v C]

Aiko,

Dat klinkt als een ambitieus en complex project.
Maar jullie gaan er vast ook veel van leren.
En zelf doen is gewoon ook leuk denk ik dan.

Succes met de verdere ontwikkeling.
Ben benieuwd.

Eric

[spock]

Even een kleine vraag: Bestaat er een NMRADCC library die geschikt is voor de RP2040/RP2350?

mvg spock

[AP3737]

Succes met de verdere ontwikkeling.
Ben benieuwd.

Hi Eric. Dank. Ik weet dat ik ook nog een ander projectje heb wat moet worden afgerond 

Even een kleine vraag: Bestaat er een NMRADCC library die geschikt is voor de RP2040/RP2350?

Je vraag betreft denk ik decoders, en niet centrales? Ik vermoed dat de NMRA/DCC library ook gewoon op de RP2040/RP2350 werkt. Mijn "eigen" decoder library (https://github.com/aikopras/AP_DCC_library) in ieder geval wel. Verder weet ik dat de MobaLedLib ook een DCC decoder implementatie heeft. 

[AP3737]

Beste techneuten 

Zoals vermeld in mijn eerdere bijdrage, hebben een collega en ik ons sinds de kerst wat intensiever verdiept in DCC-programmering voor verschillende microcontrollers. Het doel is een hoogwaardige en toekomstbestendige (Arduino-)bibliotheek te ontwikkelen, die het hartstuk moet worden voor de eerder genoemde DCC centrale die we aan het bouwen zijn. Omdat we ervan overtuigd zijn dat modulair ontwerp en herbruikbare bibliotheken onmisbaar zijn, hebben we de DCCInterfaceMaster-bibliotheek van Philipp Gahtow als uitgangspunt genomen (https://github.com/Digital-MoBa/DCCInterfaceMaster). Nadat we de “bit-banging” code van zijn oude library hadden herschreven, durfden we het aan een volgende experiment te doen: hoe makkelijk / moeilijk zou het zijn om de code vanaf de basis compleet opnieuw te schrijven, dit keer met gebruikmaking van de moderne peripherals die de huidige generatie processors meebrengen. In deze stap hebben we de toestandsmachine die de kern van de “bit-banging”-code vormt, vervangen door een aanpak waarbij het volledige DCC-pakket vooraf wordt berekend, inclusief de exacte timing van alle bits. We hebben implementaties gemaakt voor DxCore-, STM32-, ESP32- en RP2040/2350-processors. Tijdens dit experiment hebben we wat ervaringen opgedaan waarbij we (voor ons) verrassende resultaten zagen. Deze ervaringen willen we hieronder beschrijven. We beginnen met de processor die we het minst geschikt vinden voor het genereren van DCC, en sluiten af met de processor die ons het beste beviel

ESP32
We zijn enigszins teleurgesteld over de ESP32. Op papier is de zogenaamde RMT-timer ideaal voor het genereren van DCC-signalen en wordt daarom ook gebruikt in projecten als DCC-EX en OpenRemise. Binnen een DCC-pakket levert de RMT een uitstekend DCC-signaal en treedt er geen jitter op. Het probleem ontstaat echter tussen de DCC-pakketten. Door de combinatie van FreeRTOS, de relatief resource-intensieve ESP-IDF-hardware-abstractielaag (HAL) en de (wat DCC betreft) ontoereikende IDF v5-RMT-drivers (dus de huidige versie) ontstaat er een aanzienlijke vertraging bij het opnieuw configureren van de RMT voor een volgend pakket. Deze vertraging bedraagt doorgaans ongeveer 20 tot 30 microseconden en is bovendien niet constant. Metingen tonen aan dat de jitter gemiddeld ongeveer 2 microseconden bedraagt, maar kan oplopen tot 7 microseconden of meer, waarbij in sommige internetfora zelfs piekwaarden van meer dan 10 microseconden worden gemeld, met name bij wifi-activiteit.
Omdat deze jitter zowel tussen DCC-pakketten als bij de RailCom-cutout optreedt, voldoet het signaal niet altijd aan de DCC-specificaties. Daarom is de ESP32 naar onze mening het minst geschikt voor het genereren van DCC-signalen.

DxCore
De DxCore-familie presteert aanzienlijk beter, zoals bijvoorbeeld de AVR64DA48, die kan worden beschouwd als de moderne opvolger van de klassieke Arduino-processoren (AtMega 328, 2560). Hier gebruiken we TCA0 voor het DCC-signaal en TCD0 (dat meestal ongebruikt blijft) voor de RailCom-cutout. Omdat deze processors geen DMA ondersteunen, wordt na elke DCC-bit (116/200 µs) een interrupt geactiveerd, waarin de timerregisters voor de volgende bit worden ingesteld. In de praktijk levert dit een uiterst stabiel DCC-signaal op zonder jitter tussen de pakketten. De RailCom-Cutout-timer wordt in de ISR aan het begin van elk pakket geactiveerd, waardoor er, afhankelijk van andere interrupts, enige jitter in de cutout kan optreden. Pogingen om de cutout-timer volledig hardwarematig aan de DCC-timer te koppelen (bijvoorbeeld via het eventsysteem) waren niet succesvol. Toch is het DCC-signaal zelf jittervrij, ook al gaat dit vanwege de vele interrupts gepaard met een relatief hoge CPU-belasting.

STM32
De STM32-serie bestaat uit moderne 32-bits microcontrollers en kent een grote verscheidenheid aan varianten. Er zijn verschillende families, zoals de C-, F-, G- en H-families, en binnen elke familie zijn er weer een aantal varianten (zoals de F1 en F4). Hoewel alle STM32’s een gemeenschappelijke basis delen, verschillen de varianten onderling aanzienlijk, bijvoorbeeld wat betreft DMA-architectuur, caching, geheugenstructuur en beschikbare randapparatuur. In de praktijk betekent dit dat (Arduino-)code niet zomaar tussen verschillende STM32-varianten uitwisselbaar is en dat aanpassingen per variant vaak nodig zijn. We hebben implementaties gemaakt voor de F4- en H7-series, waarbij we geen FreeRTOS hebben gebruikt.
We hebben Timer 3 en DMA gebruikt voor het genereren van het DCC-signaal en Timer 4 voor de RailCom-Cutout. Het volledige DCC-pakket wordt vooraf in een DMA-buffer geladen, zodat de signaalgeneratie volledig via de hardware verloopt. Alleen aan het einde van elk DCC-pakket is een interrupt nodig om het DMA-kanaal opnieuw te configureren, aangevuld met Timer-4-interrupts aan het begin en einde van de cutout.
Omdat er per pakket tientallen microseconden beschikbaar zijn voor deze herconfiguratie, is er in de praktijk geen jitter tussen opeenvolgende DCC-pakketten. Voor de RailCom-Cutout-functie is theoretisch een zekere mate van jitter mogelijk, maar in de praktijk bleek dit niet meetbaar, mede omdat de interruptprioriteit instelbaar is en geoptimaliseerd kan worden.
Het resultaat is een zeer stabiel en zuiver DCC-signaal bij een lage CPU-belasting, aangezien er per pakket slechts een beperkt aantal (3) interrupts nodig is.

RP2040/RP2350
De grootste verrassing voor ons waren de RP2040 en de RP2350, bekend van de Raspberry Pi Pico.
Originele Raspberry Pi Pico-boards kosten ongeveer 5 euro, en kleine boards zijn verkrijgbaar vanaf ongeveer 1,5 euro. De RP-familie bestaat uit slechts twee varianten, die qua software grotendeels compatibel zijn en over een interessante peripheral beschikken: de PIO (Programmable IO). Dit is in feite een kleine, gespecialiseerde coprocessor waarmee zeer nauwkeurig getakte uitgangssignalen kunnen worden gegenereerd. In combinatie met DMA kan het volledige DCC-signaal, inclusief RailCom-Cutout, volledig door één enkele PIO (waarin twee zeer eenvoudige toestandsmachines worden gebruikt) worden gegenereerd. Onze RP-implementatie levert een absoluut stabiel DCC-signaal zonder enige jitter tussen de pakketten of bij de cutout. Bovendien is de implementatie relatief eenvoudig en is de CPU-belasting minimaal: slechts één interrupt per pakket. Met een kloksnelheid van 125 tot 200 MHz en een dual-core-architectuur biedt de RP2040 bovendien heel veel rekenkracht. Voor het genereren van DCC-signalen is de RP2040 naar onze mening daarom de meest geschikte processor. Een nadeel is echter het beperkte aantal ADC-pinnen en de relatief matige kwaliteit van de ADC, wat deze processor bijvoorbeeld minder geschikt maakt voor bezettingsmelders.

Conclusie
Terwijl de ESP32 teleurstelt vanwege zijn niet-geoptimaliseerde RMT-driverimplementatie en jitterproblemen, genereren zowel DxCore als STM32 een goed DCC-signaal, zij het met verschillende compromissen. De RP2040/2350 springt er echter uit: met de beste DCC-signaalkwaliteit, de laagste CPU-belasting, lage kosten en een relatief eenvoudige implementatie. Daarom hebben we in onze centrale gekozen voor de RP2040/2350.

Opmerkingen en feedback zijn welkom; de complete code met uitgebreide documentatie is te vinden op https://github.com/aikopras/DCCInterfaceMaster_workInProgress.

Groet, Aiko

[bask185]

Nadat we de “bit-banging” code van zijn oude library hadden herschreven

Ik snap niet wat je hiermee bedoelt? Als je iets niet doet met bitbanging, dan gebruik je meestal een perifical ding zoals SPI of I2C. Behalve op die RP die die PIO's heeft, is bit banging icm timer ISR de enige manier om DCC op de baan te zetten met elke willekeurige uProcessor. Hoe wil je op een STM32 of ESP DCC maken zonder bit banging? Dat ontgaat me een beetje

Ik ben zelf bezig met een DCC centrale met een good ol' atmega328. Ik heb ook niet zoveel nodig  .  Voor het maken en versturen van DCC pakketten heb ik een dubbele buffer. Terwijl 1 buffer wordt uitgeklokt naar de rails, ben ik de andere buffer aan het vullen met het volgende DCC pakket . Als het DCC pakket uitgeklokt is, dan flip ik een pointer naar de andere buffer en ik begin opnieuw. Om iets van hardware abstractie te maken voor het uitsturen, doet het timer ISR een callback uitvoeren die je elders kan gebruiken om de pinnen uit te sturen.

Omdat deze jitter zowel tussen DCC-pakketten als bij de RailCom-cutout optreedt, voldoet het signaal niet altijd aan de DCC-specificaties. Daarom is de ESP32 naar onze mening het minst geschikt voor het genereren van DCC-signalen.

Volgens mij is dit niet zozeer een probleem, als je gewoon spanning op de rails laat staan. Bij railcom is de baan spanningsloos zodat een trein of iets kan terugpraten.. met alle potentiele problemen van dien  Maar als je wel railcom wilt hebben, dan snap ik het euvel. Maar als je centrale alleen maar wissels moet aansturen, waarom wil je dan railcom toevoegen? In 9 van die 10 decoder problemen, luidt het eerste advies om railcom uit te zetten.

Het is wel leuk coderen zo'n centrale, ken allerlei slimme dingen inbakken. Broadcast met snelheid 0 ipv een noodstop (dus een langzame stop voor alle loks) en het aantal herhaalpakketjes voor nieuwe instructies wordt minder naarmate er meer dingen verstuurd moeten worden. Dit is om het DCC plafond te verhogen.

Ik vond die DCC ex code ook niet zo fijn. Vooral groot en veel en moeilijk doen. Structureel gezien doe ik alles met callbacks.  Elke interface wat iets te melden heeft die doet een callback in het hoofd programma, dat zijn dezelfde functies. Er is 1 voor een loc snelheid, 1 voor wissels etc. Daar wordt dat naar de appropriate kanelen geleid.  Berichten die een loc of wissel of sein (dcc ext) instructie bevatten, die gaan naar de DCC packet generator.  De packet generator doet hierbij ook direct een callback uitvoeren waarbij de instructie wordt terug gestuurd naar de andere interfaces. Ik heb ook elke interface een ID mee gegeven om te voorkomen dat iets een echo krijgt van zijn eigen bericht.



Ik heb ook een DCC input. Ik had namelijk geen zin, tijd, GPIO pinnen en programma ruimte om al die bussen zoals Xnet en Lnet in te bouwen, dus deed ik dat met een DCC ingang. Je kan een netwerkje multimausen en zo'n booster er op aansluiten. Een z21 met Wlan package voor wifi uitbreiding, wees creatief.

Voor WiFi (denk aan extra schakelpanelen zoals Z21 app als toevoeging) kan ik een wemos D1 inpluggen (esp8266). Die gebruikt dezelfde Tx/Rx pinnen als de USB interface. De USB chip is echter inert als die niet aangesloten is op een PC. De wemos zet een AP op en doet vooralsnog Z21 WLAN protocol (later uit te breiden met WiThrottle en iets van MQTT).

Omdat ik mezelf tijd wilde besparen zei ik tegen chatGpt. Chad, maak ff een programma voor de wemos dat die met Z21 multimausen kan verbinden. En dat werkte daadwerkelijk ook nog  . De binnenkomende en uitgaande WLAN berichten worden geencapsuleerd in een custom loconet bericht en dat wordt serieel bij de atmega ontvangen/verstuurd. De slot manager alloceert automatisch een slot voor een nieuw gebruikt DCC adres. De Esp code in dit verhaal is zo dom als mogelijk. Als je een keer wilt neuzen voor inspiratie, hier is de repo.

En wat ik me echt afvraag. Waarom nemen jullie zoveel moeite voor een DCC centrale. Je kan de yamorc volgens mij tegelijk gebruiken voor je treinen, wissels en RS bus zonder ooit een probleem te ondervinden. En anders zou ik er een 2e bij nemen. Heb je ook meteen een reserve centrale in huis. Ik zie gewoon niet wat er nu bereikt wordt, naast het bouwplezier van een centrale tenminste. 

Mvg,

Bas

[AP3737]

Hi Bas

Ik snap niet wat je hiermee bedoelt? Als je iets niet doet met bitbanging, dan gebruik je meestal een perifical ding zoals SPI of I2C. Behalve op die RP die die PIO's heeft, is bit banging icm timer ISR de enige manier om DCC op de baan te zetten met elke willekeurige uProcessor. Hoe wil je op een STM32 of ESP DCC maken zonder bit banging? Dat ontgaat me een beetje

Met bit-banging bedoel ik dat de timer van de processor een interrupt genereert, en in de Interrupt Service Routine (ISR) een pin uitgang via een software commando wordt gezet (digitalWrite / directe register manipulatie). Als je nu de pin verandering niet in software, mee door de timer hardware laat doen (PWM-mode), en in de aansluitende ISR alleen de nieuwe timer waardes zet, krijg je een jitter-vrij DCC signaal. Alhoewel het conceptueel voor DxCore en STM32 processoren hetzelfde is, moet je door toch net iets anders oplossen.

Bij DxCore gebruiken we de TCA0 timer in single-slope PWM mode. In iedere ISR vullen we het PER (Periode / TOP) register met de bit tijd van het volgende DCC bit (1: 116 µs; 0: 200 µs), en het CMP (Compare) register met de helft ervan.  Omdat de TCA timer na iedere ISR opnieuw vanaf 0 begint te tellen, werkt dat uitstekend.

Bij STM32 doen we het vergelijkbaar, alleen reset de timer daar niet na een ISR, dus moet je steeds de registers ophogen.

De ESP32 heeft speciale Remote Control Timers (RMT). Je geeft de RMT een Array met 32 bit waarden; iedere 32 bit representeert één DCC bit. Het eerste bit geeft aan of je een 0 of een 1 wilt, en de volgende 15 bits geven aan hoe lang die waarde moet blijven bestaan. Daarna hetzelfde met de volgende 16 bits voor de tweede helft van het DCC bit. In theorie ideaal, maar de Espressif drivers zijn …. (Het is vandaag zondag, dus laat ik me inhouden). 

Met de RP2040 Pico doen we exact hetzelfde (Array met 32 bit waarden), maar dit keer programmeren we de PIO timer zelf. Voor de liefhebber, hierbij de code

Code: [Selecteer]

.program dccPulseGenerator
; State machine frequency: 1 MHz (1 µs per instruction)
; autopull is enabled
; OSR layout (LSB → MSB):
; bit 0: level A - first pin
; bit 1: level A - second pin
; bit 2: level A - third pin
; bits 3..15: durationA
; bit 16: level B - first pin
; bit 17: level B - second pin
; bit 18: level B - third pin
; bits 19..31: durationB

start:
    pull                 ; 32-bit symbol from FIFO -> OSR
    mov x, osr           ; all 32 bits in x

    ; --- first part: levelA / durationA ---
    out pins, 3          ; bit 0, 1 and 2 -> output pins (levelA)
    out x, 13            ; bits 3..15 -> X (durationA)
    nop [2]              ; compensation to make loop A and B equally long
loop_A:
    jmp x-- loop_A       ; wait for durationA
 
    ; --- second part: levelB / durationB ---
    out pins, 3          ; bit 16, 17 and 18 -> output pins (levelB)
    out x, 13            ; bits 18..31 -> X (durationB)
loop_B:
    jmp x-- loop_B       ; wait for durationB
    jmp start            ; bit is done



Ik ben zelf bezig met een DCC centrale met een good ol' atmega328.

Ik wil niet onaardig zijn, maar vergeet die "dump old atmega328". Tegenwoordige chips zijn veel krachtiger, en goedkoper. DxCore is, als je op 8-bit wilt blijven, een makkelijke overstap. Als je 32 bit wilt, dan heb je legio opties, vaak eveneens goedkoper dan de 328. Waarom neem je geen Pico en onze code als beginpunt. Als je dan verbeteringen hebt, prachtig. Zeker de scheduler code kan nog wel wat aanpassingen gebruiken.

Voor WiFi (denk aan extra schakelpanelen zoals Z21 app als toevoeging) kan ik een wemos D1 inpluggen (esp8266).

Je kan ook de Rasberry Pico W kopen. Daar zit WIFI bij op.

En wat ik me echt afvraag. Waarom nemen jullie zoveel moeite voor een DCC centrale. Je kan de yamorc volgens mij tegelijk gebruiken voor je treinen, wissels en RS bus zonder ooit een probleem te ondervinden.

Klopt. Je hebt helemaal gelijk. We willen (om het overzichtelijk te houden) het liefst ieder station (Hengelo, Enschede, Oldenzaal, Almelo, Bentheim) een eigen centrale geven. Misschien is dat niet echt noodzakelijk, maar ik merk al bij mijn eigen baan dat meer dan 60 terugmeld decoders bij sommige Lenz centrales (LZV100 / LZV 200) al opstart problemen geeft. Dus daarom ben ik huiverig om te veel op 1 centrale aan te sluiten. Dus kosten speelt wel een rol, maar de belangrijkste reden om zelf wat te ontwikkelen is toch de uitdaging 

Groet, Aiko

[Eric v C]

Hi Eric. Dank. Ik weet dat ik ook nog een ander project-je heb wat moet worden afgerond 

Aiko, Hier loopt ook zo'n ander project-je wat nog moeten worden afgerond, dus geen probleem hoor.
We spreken elkaar.

Eric