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