Railcom zender bouwen

[AP3737]

Beste allen

Het lijkt me een leuke uitdaging om een accessory decoder te bouwen die via Railcom de waarden van CVs kan terugmelden. Een schakeling die ik daarvoor ken, is die van OpenDCC: https://www.opendcc.de/info/railcom/railcom_stromquelle.html. Ook staat er in de NMRA S-9.2.3 en RCN 217 standaarden een soort referentie schakeling, die weer gebaseerd zijn op een ontwerp van Lenz. Verder kan ik echter weinig vinden.

Mijn vraag is daarom wie ervaring heeft met het bouwen van decoders die Railcom data kunnen zenden, en die ervaring willen delen. Waar ik vooral benieuwd naar ben, is of de processor galvanisch gescheiden is van het DCC signaal, of niet. In het laatste geval zie ik weer twee opties: de processor voeden vanuit het DCC signal, of toch een aparte voeding via een DC/DC converter.

Groet, Aiko
(aangepast 4 april 15:30)

[AP3737]

Beste allemaal

Gezien het aantal reacties lijkt het er op dat RailCom voor accessory decoders nog niet erg populair is.
Naast de RailCom schakelingen die ik hierboven reeds genoemd had, heb ik nog een schakeling (op de OpenDCC site) gevonden: https://www.opendcc.de/elektronik/lightcontrol1/lightcontrol.html

Mijn "eigen" schakeling heb ik grotendeels van deze Lightcontrol decoder afgeleid. Uit dit schema heb ik ook het idee van de Digital Isolator overgenomen. In plaats van de ADUM 1201 (van Analog Devices) heb ik echter voor de de ISO7721DR (van Texas Instruments) gekozen. Deze laatste is relatief goedkoop en werkt tot 100 Mbps; een groot verschil ten opzichte van de aloude opto-couplers. De ISO7721DR heeft in feite 2 isolatoren: de eerste gebruik ik voor het uitgaande RailCom-signaal en de tweede voor het binnenkomende DCC-signaal. Voor RailCom heb ik wel iets nodig dat nog werkt boven de 10Mbps, dus traditionele opto-couplers zijn niet meer bruikbaar. Voor het DCC signaal is de Digital Isolator veel sneller dan nodig, maar voor 50 cent doen we niet moeilijk. Dit is overigens wel voor het eerst dat ik met een Digital Isolator werk, dus ik hoop dat ik geen fouten heb gemaakt.


De eigenlijke schakeling is eigenlijk vrij eenvoudig, en en reeds elders beschreven. T571, T572, en R571 leveren een stroombron van ongeveer 30 mA (0,65 V over 22 Ohm). T573 sluit de lus die het RailCom signaal doorloopt.

Om het RailCom signaal te kunnen versturen, hebben we ook een kleine voeding nodig, die voldoende energie moet levert tijdens de RailCom "stilte".

Ik ben van plan om deze schakeling binnenkort op een experimenteer print te zetten, samen met wat andere experimenten. Als er ideeën zijn wat anders / beter kan, dan hoor ik dat graag.

Groet, Aiko

[Ronald Halma]

Gezien het aantal reacties lijkt het er op dat RailCom voor accessory decoders nog niet erg populair is.

Bij elk decoder probleem is vaak het eerste advies; "zet Railcom uit"  Misschien daarom?

[AP3737]

Beste Allen

Bij elk decoder probleem is vaak het eerste advies; "zet Railcom uit"  Misschien daarom?

Als je baan en decoders niet goed op Railcom zijn afgestemd, dan is dat vaak een goed advies. Op onze clubbaan, waar mensen met eigen treinen rijden, verwachten we meer nadelen dan voordelen van Railcom. Daarom staat deze bij de club ook uit.

Maar mijn "experiment" richt zich op accessory decoders en Railcom. Dat wordt nog weinig ondersteund, maar zou voor CV programmering best handig kunnen zijn. Ik houd wel van nieuwe elektronica proberen; als niemand ooit iets nieuws zou doen, bouwden we onze decoders nu met EL84s


Ik heb net bovenstaande print in opdracht gegeven. Naast de eerder getoonde Railcom elektronica, heb ik, om te testen, ook een DCC-ingang met de Toshiba TLP2358 gemaakt, en één met de alom bekende 6N137. De TLP2358 is in een ander draadje door Karst voorgesteld, en wil ik eens gaan vergelijken.

Er zijn overigens tegenwoordig heel veel nieuwe componenten ter vervanging van traditionele Opto Couplers, zoals de 6N137. Deze nieuwe componenten hebben belangrijke voordelen, zoals minder veroudering, minder stroom en een constante CTR.

De print heeft het bekende Arduino UNO (STM32 Nucleo) bord formaat. Mocht iemand interesse hebben om zelf te experimenteren, dan hoor ik het wel. 

Groet, Aiko

[maartenvdb]

Bij elk decoder probleem is vaak het eerste advies; "zet Railcom uit"  Misschien daarom?

Nou, dan doet zich toch wel de vraag voor of dat aan RailCom ligt of aan de decoders, die niet niet geschikt zijn voor RailCom.
RailCom is een standaard binnen DCC, waaraan, zeker oudere, maar ook zelfs nieuw ontworpen decoders soms niet aan voldoen.  Soms hardwarematig, soms softwarematig.  Dat is hier in diverse draadjes aan de orde geweest, waarop als voorbeeld een paar jaar geleden een Nederlandse producent zijn software in een veelgebruikte decoder heeft aangepast en toen werkte zijn apparaat wèl met RailCom in de centrale aan.

Dat geeft tevens aan, dat "zet Railcom uit" dan bedoeld is als:  "zet Railcom in de centrale uit" , want als de decoder geen RailCom kent kun je die daarin niet uitzetten. 
Dat betekent weer niet, dat iedere decoder zonder RailCom ook problemen zou geven.  Dat blijft heel ongewis, dus daar kun je geen pijl op trekken.  Maar een risico zou ik daarin niet nemen, dus dan kom je toch weer op het advies (om te kijken of het daaraan ligt) :  "zet Railcom in de centrale uit".

Wat ik zelf niet snap is, dat er blijkbaar nog steeds producten verkocht en zelfs nieuw gemaakt worden, ook door "grote" fabrikanten, die niet tegen de cut-out van RailCom kunnen.  Ik dacht de "prehistorie" toch voorbij te zijn.  Blijkbaar niet.

[Joz]

Nou... hoeveel gevallen zijn er niet geweest waar het opvolgen van het advies "zet RailCom uit" helemaal niet de oplossing bleek...
Volgens mij vaker niet dan wel...

Ik vind jouw experiment wel interessant Aiko 

Groeten,
Jos

[maartenvdb]

Juist helemaal mee eens. Maar als test om zaken uit te sluiten wel aan te raden.  Want stel .....  (en vergeet ook niet als test om de draden vanuit de centrale een keer om te draaien, heeft blijkbaar ook wel geholpen).

En ook voor mij een interessant onderwerp.

[Karst Drenth]

Maar mijn "experiment" richt zich op accessory decoders en Railcom. Dat wordt nog weinig ondersteund, maar zou voor CV programmering best handig kunnen zijn.

Inderdaad, er zijn niet veel accessoire decoders die dat "kunnen" op het moment. Naar mijn weten de, nieuwe, Roco Schakel- en Seindecoders en de ESU SwitchPilot.

Verder is de ondersteuning bij centrales zo mogelijk nog zeldzamer. Deze moeten dan het z.g. ACC-POM beheersen. Naast bovengenoemde merken kunnen dat b.v. ook onze YD70xx centrales met daaraan gekoppeld een RailCom Terugmelder.  Technisch kan de DR5088RC dat, maar niet met de originele Firmware Onze binnenkortverschijnende YD6016LN-RC kan dat ook.

om te testen, ook een DCC-ingang met de Toshiba TLP2358 gemaakt, en één met de alom bekende 6N137. De TLP2358 is in een ander draadje door Karst voorgesteld, en wil ik eens gaan vergelijken.

Zet er maar eens een scoop op, als je het uitgangs-signaal gezien hebt wil je niet meer 6N137 Bovendien "lachen" deze TLP2358  optos om de 250kBps van RailCom.

Nou, dan doet zich toch wel de vraag voor of dat aan RailCom ligt of aan de decoders, die niet niet geschikt zijn voor RailCom.

100% eens. ( aan de decoders dus )

RailCom is een standaard binnen DCC, waaraan, zeker oudere, maar ook zelfs nieuw ontworpen decoders soms niet aan voldoen.  Soms hardwarematig, soms softwarematig.  Dat is hier in diverse draadjes aan de orde geweest, waarop als voorbeeld een paar jaar geleden een Nederlandse producent zijn software in een veelgebruikte decoder heeft aangepast en toen werkte zijn apparaat wèl met RailCom in de centrale aan.

....

Wat ik zelf niet snap is, dat er blijkbaar nog steeds producten verkocht en zelfs nieuw gemaakt worden, ook door "grote" fabrikanten, die niet tegen de cut-out van RailCom kunnen.

Verzachtende omstandigheid: Veel van deze "projecten" maken gebruik van de Arduino NMRA libraries. Initieel ontworpen door mensen van "over de plas". Daar, uit eigen ervaring, wordt RailCom gezien als iets "Europees" en een niche in de USA. Men schenkt er dus geen aandacht aan. ( dit was letterlijk het antwoord van Digitrax op een vraag van mij over het ondersteunen van RailCom in hun centrales en via LocoNet. )

De door Maarten genoemde "fabrikant" maakt ook gebruik van deze library. Ik heb hem destijds geholpen door zijn library "cut-out-proof" te maken

@Aiko,

Ik ben benieuwd, vooral naar je ervaringen met de "isolator"

Grtzz,
Karst

[maartenvdb]

Dank voor je aanvullende achtergrond - info !

[AP3737]

Beste allemaal.

Nu de servo decoder zo goed als af is (daarover binnenkort in een ander draadje meer), heb ik weer tijd om aan wat andere projectjes te werken. Eén van deze projectjes is Railcom, maar daaraan voorafgaand het verschil tussen een aantal chips die het DCC signaal omvormen tot een voor de microcontroller begrijpelijk signaal (0..5V / 0..3,3V). In mijn bijdrage van 1 mei heb ik de Digital Isolator ISO7721DR hiervoor genoemd als één van de mogelijke chips. Vervolgens heb ik een printje ontworpen om deze chip te vergelijken met de Toshiba TLP2358 (voorstel Karst) en de 6N137. Het printje is al weer enige tijd binnen, en vandaag heb ik de ontbrekende spulletjes daarop gezet. Hieronder de kale print, zoals ik die van JLCPCB heb ontvangen.


Vervolgens de print met alle onderdelen daarop, en een variant die past op de Arduino UNO en STM32 Nucleo boards.




Helaas bleek ik ergens een klein foutje gemaakt te hebben, maar nadat ik één verbinding met een scherp mesje had verwijderd, werkte alles naar behoren. Tijd om de scoop aan te sluiten. Als signaal generator diende een Lenz LZV100.

Hieronder de plaatjes van de 6N137, met een tijdbasis van 250ns en 100ns. Het gele signaal (kanaal 1) is de LZV100, het turquoise signaal de uitgang van de opto-coupler. Omdat de 6N137 het signaal inverteert, heb ik het turquoise signaal ook geïnverteerd. Voor de opto-coupler zit in serie een (standaard waarde, die iedereen neemt) 1k5 weerstand. Hierdoor loopt er tot 20mA door de optocoupler, wat veel is, maar waardoor de opto-coupler wel hoge frequenties haalt. Wat goed te zien is, is dat de H-Bridge van de LZV100 wat moeite heeft bij de “nul doorgang”, dus het moment waarop geschakeld wordt tussen het ene paar MOSFETs en het andere paar. Wat ook opvalt, is dat de “steilheid” (slew-rate) aan de ene kant van de H-Bridge wat anders ligt dan de aan de andere kant. Omdat ik het signaal gewoon van de baan afhaal, ligt dit misschien ook wel aan de electronica die verder is aangesloten (zou ik eens moeten onderzoeken).




Het uitgangssignaal van de 6N137 ziet er in principe prima uit. Als we de nul doorgang van het (gele) DCC signaal nemen als “trigger punt”, dan is de delay die door de 6N137 wordt veroorzaakt 2 “blokjes”, dus ongeveer 200ns. Niet slecht.

Vervolgens de TLP2358. In serie staat dit keer een weerstand van 4K7. Het uitgangssignaal van de TLP2358 lijkt niet veel anders dan dat van de 6N137. Het grootste verschil lijkt dat de vertraging iets langer is, ongeveer 280ns.


[url=https://images.beneluxspoor.net/bnls_2025/TLP2358-100ns-684088662160f.jpg]

Tenslotte de ISO7721 optical-isolator. Het verschil met de TLP2358 lijkt miniem, behalve dat het uitgangssignaal iets sneller lijkt te stijgen (iets hogere slew rate), wat niet verrassend is omdat deze optical-isolator tot 100Mhz is gespecificeerd.




Wat denk ik hieruit te leren? In ieder geval hoeft de 6N137 niet meteen bij het grof vuil. Op het oog lijkt deze oude opto-coupler het niet slechter te doen dan zijn nieuwere broertjes, misschien wel wat beter. Momenteel vraagt JLCPCB voor de 6N137 (C142297) 0,24€. De TLP2358 kost het dubbele (0,51€), en de ISO7721DR (C366164) 0,37€. Dus ook wat prijs betreft wint de 6N137.

Toch zijn er wel wat opmerkingen te maken. De ISO7721DR heeft twee isolatoren in één behuizing, dus je bespaart hiermee de tweede opto-coupler voor het RailCom dan wel het DCC-ACK signaal. Een ander belangrijk verschil is dat de 6N137 wel heel veel ruimte inneemt op de printplaat, en dat dit type optocouplers naar verloop van tijd ook minder wordt (de lichtopbrengst van de LED neemt af). Daarnaast wordt de 1K5 weerstand ook best wel warm; iets waar je bij de beide alternatieven geen last van hebt. Een belangrijk nadeel van de ISO7721DR is echter dat deze ook aan de DCC-kant gevoed moet worden, waardoor je extra componenten nodig hebt en ook weer ruimte op de print verliest.

Ik ben benieuwd of jullie andere voor/nadelen zien, of dat ik misschien wat over het hoofd zie of misschien wel ergens denkfouten maak.

Groet, Aiko

[AP3737]

Ik was eigenlijk nog wel even benieuwd naar de kwaliteit van de Lenz LZV100 als er, behalve de scoop, niets verder aan hangt. Dan blijkt het signaal er toch veel mooier uit te zien; de problemen bij de nuldoorgang zijn dan voorbij. Zie onderstaand plaatje. Interessant is wel dat de slew-rate, zonder belasting op de LZV100 uitgang, lager is dan wanneer de LZV100 belast wordt.


En nu ik toch bezig was, heb ik ook de LZV200 maar eens aan de scoop gehangen. Zie plaatjes hieronder. Merk op dat de tijdbasis nu niet 250ns, maar 100 en 50ns is.




Groet, Aiko

[AP3737]

Beste allemaal

Nu mijn servo decoder (zie ander draadje) af is, heb ik weer wat meer tijd om eens te spelen met moderne microcontrollers. Één van de dingen die ik heb gedaan, is het reorganiseren van mijn Arduino DCC library (https://github.com/aikopras/AP_DCC_library). Doel is het geheel nog iets modulairder op te bouwen (https://github.com/aikopras/AP_DCC_library/blob/main/extras/modules/modules.md), zodat ik verschillende drivers kan ontwikkelen voor verschillende types processoren.

Als eerste heb ik een generieke driver gemaakt die gebruikt kan worden met alle mogelijke processoren die binnen de Arduino omgeving kunnen draaien. Hiervoor het ik alleen attachInterrupt() en micros() nodig. Allemaal vrij triviaal (en ook al gedaan door de NMRA-DCC library), maar niet optimaal.

Vervolgens ben ik wat gaan spelen met drivers voor specifieke processoren, zoals STM32, ESP32, RP2040 en nog een paar.

Van deze processoren is de ESP32 misschien wel de meest populaire. Maar is deze ook het beste geschikt voor DCC decodering (en railcom terugmelding?). De ESP32 heeft een RMT timer, waarmee heel precies (fracties van µs) de tijdsduur van DCC pulsjes gemeten kan worden. Dat lijkt dus precies wat we nodig hebben. De RMT driver geeft een interrupt als zijn buffer bijna vol is, waarna we kunnen beginnen met een aantal bits van het DCC signaal te “decoderen”. Helaas kan de ESP32 geen interrupt genereren onmiddellijk nadat het laatste DCC bit is ontvangen. We kunnen dus niet exact bepalen wanneer we moeten beginnen met het zenden  van de Railcom terugmelding in kanaal 1 / 2 (precies 80 µs / 193 µs na de het laatste DCC bit, ±10 µs). Hierdoor kunnen we de standaard RMT driver  dus niet gebruiken. Gelukkig is het wel mogelijk om de waarden die de RMT in zijn (circulaire) buffer schrijft zelf uit te lezen. Hiervoor kunnen we een gewone pin Interrupt gebruiken. Als het DCC signaal van polariteit veranderd, wordt de ISR aangeroepen en kunnen we in de ISR de RMT waarden uitlezen. Prachtig toch?

Helaas draait standaard op de ESP32 ook een Real Time Operating Systeem (RTOS), en draait (met hoge prioriteit) software voor het afhandelen van de WIFI interrupts. Als software ontwikkelaar hebben we dus geen 100% controle meer over wat de ESP32 doet. Op het Internet zijn een aantal discussies (en metingen) te vinden waaruit blijkt dat er soms best veel tijd (meer dan 10 µs) vergaat tussen het moment waarop het DCC signaal van polariteit veranderd, en de code begint die in de interrupt routine moet worden uitgevoerd, waaronder het versturen van de railcom terugmelding. We moeten dus (helaas) constateren dat de ESP32, ondanks zijn populariteit, misschien toch niet zo ideaal is om DCC decodering en Railcom te implementeren.

Groet, Aiko

[bask185]

waarmee heel precies (fracties van µs) de tijdsduur van DCC pulsjes

Is dat niet overkill? Als je al een resolutie heb van 4us dan heb in principe genoeg, om een '1' en een '0' en 'garbage/flikkeringen te onderscheiden. Als je alleen al foutloos '0' en '1' kan vinden, dan ben je er technisch gezien al.

Helaas kan de ESP32 geen interrupt genereren onmiddellijk nadat het laatste DCC bit is ontvangen

Dit snap ik niet en ik krijg hiervan de indruk dat je misschien onnodig 'moeilijk' doet.

Om te beginnen.. je hebt toch iets van een flank change interrupt right? Een fysiek extern interrupt, elke keer dat je een Rising flank heb, dan ga je vaststellen of je een '1', '0' of jitter heb. Ik neem aan dit je dit hebt, anders zou je code niet eens gewerkt hebben in de eerste plaats. Maar als je je 8 bits heb, en je krijgt bit 9 binnen. Dan kan je die eerste 8 bits al parsen in een niet-ISR functie, je typische round robin dcc.update()

Tijdens het ontvangen, kan je al dingen parsen. Voordat jij je eerste data pakketje komt, kan je het adres al weten.
Tegen de tijd dat je de laatste '1' bit ontvangen heb, kan je je data ook al geparsed hebben en klaar staan.

Wat ik zou doen. Ik zou zodra je die allerlaatste '1' bit krijg van het pakket en het adres lijkt voor jou te zijn. Dan zou ik het zelfde ISR al ff snel de checksum runnen, en als die functie true return't dan of de nodige callback functies direct vanuit ISR callen, of een vlag zetten dat een van je round robin dcc.update() zsm je railcom transmissie begint. Dan moet je er alleen voor zorgen dat je geen lang durende functies met for-loops heb ofzo. En evt prak je jouw dcc.update() equivalent op 20 plaatsen.. zodat je zeker weet dat die op tijd handelt.

Ik denk zelf, dat je gewoon een callback functie kan uitvoeren vanuit je externe ISR. Zodra de checksum bevestigd is, hoef je het eerst volgende DCC pakket toch niet aan te horen. Dus je kan dan gewoon je ISR killen, je callbacks uitvoeren en ISR weer aan zetten. Want als je 1 pakketje mis, er komen er nog 5... minstens voor een accessoire decoder. Ik weet alleen niet hoe dit precies steekt met CV programmering. Ik zou verwachten dat een centrale dat een X aantal keer probeert totdat antwoord wordt ontvangen.

Mvg,

Bas

[AP3737]

Hi Bas

Is dat niet overkill?

Je kunt de vraag ook omdraaien. Als een processor de mogelijkheid heeft om in hardware heel precies de pulsbreedte te meten, waarom zou je het dan minder precies in software doen?

Dit snap ik niet en ik krijg hiervan de indruk dat je misschien onnodig 'moeilijk' doet.

Natuurlijk kost het eenmalig tijd om uit te zoeken hoe het in hardware kan. Maar dat vind ik juist wel leuk, want ik leer daarvan. Maar nee, nodig is het natuurlijk niet 

Om te beginnen.. je hebt toch iets van een flank change interrupt right?

Klopt. Maar ik wilde uitleggen dat de standaard RMT driver geen interrupt geeft als je een (half)bit binnen hebt. Dus ja, je moet dat zelf doen.

De aanpak die jij beschrijft, is precies wat ik (aan het einde van de één na laatste alinea) probeerde te zeggen (maar blijkbaar niet duidelijk genoeg  ).

Wat ik in de laatste alinea probeer te beschrijven, is dat de aanpak met ISRs op de ESP32 toch tot problemen kan leiden als je een nauwkeurige timing nodig hebt voor het Railcom terugmeld signaal. Misschien dat ik daar de komende dagen wat metingen aan kan doen. Op YouTube staat overigens een aardige video van iemand die dit heeft gemeten: https://youtu.be/CJhWlfkf-5M?feature=shared  Ik kan die video aanraden. 

Groet, Aiko

[piksov]

Ik heb in sommige stuurstandrijtuigen een TAMS FD-R of opvolgers zitten.

Dat is een combi van een functie decoder -en- een railcom zender.

Het railcom deel hoef ik niet, dat schakel ik altijd uit en gebruik alleen het functie decoder deel.

Ik heb er volgens mij nog een aantal in mn voorraad, als je er eens mee wilt spelen kan ik er 1 voor je opsturen.

Guus