Bestaat er zoiets als een Railcom signaal blocker (voor Arduino decoder)?

[Gerke]

Ooooooowwwww. Ja, dat ligt zó vreselijk voor de hand dat ik dacht dat dát wel snor zou zitten. 

Klonk dit overtuigend?

Zonder gekheid: ik refereer nog even graag naar de laatste alinea van mijn voorgaande post.

Ben hier wel blij mee. Karst: Dank!! 

Nog één vraag: dit is dus wel een betrouwbare bedrijfstoestand? Dus geen gedoe dat halverwege een tentoonstelling opeens de draadjes andersom moeten?

[Gerke]

Aan de ene kant mooi dat je het nu werkend hebt. Aan de andere kant: er klopt iets niet. DCC is juist ontworpen met als uitgangspunt dat de polariteit van aansluiten niks uitmaakt.

Eens. Hoop dus op een foolproof oplossing.

[Karst Drenth]

Helemaal correct Klaas,

Maar het is nu eenmaal makkelijker in een Arduino omgeving om de staat van een input uit te lezen, dan met behulp van timers, interrupts etc. een "correcte" routine te bouwen.

Dus veel van de Library bouwers, vaak nog uit de tijd dat RailCom helemaal niet zo wijd verbreid was ( of non-existent zoals tegenwoordig nog steeds bij de twee grootste USA merken !! ), hebben er geen aandacht aan besteed.

Grtzz,
Karst

[Karst Drenth]

Ben hier wel blij mee. Karst: Dank!! 

Graag gedaan, there is more to come

Nog één vraag: dit is dus wel een betrouwbare bedrijfstoestand? Dus geen gedoe dat halverwege een tentoonstelling opeens de draadjes andersom moeten?

Jazeker... bij de Z21 zeker.

Bij een eventuele DR5000 niet... die kan namelijk de polariteit van de cutout wisselen. Maar die heeft danook een speciale setting voor zulke decoders die e.e.a. (railcom) niet snappen zoals de (oudere ?) LDT decoders en... verbaas, verbaas, verbaas... de nieuwe DK50018 :O  ( https://roadmap.digikeijs.com/c/EjXyEU8b/31-investigate-fix-issues-when-railcom-is-enabled-on-the-z21-command-station )

Maar ik dacht dat jij een Z21 in gebruik had hè ?

Grtzz,
Karst

[Klaas Zondervan]

Maar het is nu eenmaal makkelijker in een Arduino omgeving om de staat van een input uit te lezen, dan met behulp van timers, interrupts etc. een "correcte" routine te bouwen.

Kun je dit wat verder uitleggen? Volgens mij bepaalt de lengte van een DCC puls of het een 0 of een 1 is. Ik verwacht dan dat de decodeersoftware op de een of andere manier "meet" hoe lang die puls is. Alleen kijken of de signaal hoog of laag is, is niet voldoende.

[Gerke]

Graag gedaan, there is more to come

Jazeker... bij de Z21 zeker.

Bij een eventuele DR5000 niet... die kan namelijk de polariteit van de cutout wisselen. Maar die heeft danook een speciale setting voor zulke decoders die e.e.a. (railcom) niet snappen zoals de (oudere ?) LDT decoders en... verbaas, verbaas, verbaas... de nieuwe DK50018 :O  ( https://roadmap.digikeijs.com/c/EjXyEU8b/31-investigate-fix-issues-when-railcom-is-enabled-on-the-z21-command-station )

Maar ik dacht dat jij een Z21 in gebruik had hè ?

Grtzz,
Karst

Dat is supergoed nieuws! En idd, hier draait een Z21. 

[meino]

Ik weet niet of het zou helpen, maar ik gebruik zelf de DCC_Decoder bibliotheek. Daarin heb ik een kleine wijziging gemaakt waardoor ik alle state wijzigingen op de decoder pin die korter duren dan een bepaalde minimum waarde, weggooi. Dit heeft voor mij een groot probleem met spikes op het oorspronkelijke DCC signaal opgelost. Ik weet niet welke bibliotheek hier gebruikt is, maar ik wil best de wijziging beschikbaar stellen.

Groet Meino

[Karst Drenth]

Het is inderdaad die Meino,

Helaas is het niet de spikes die ervoor zorgen dat de decoder het laat afweten.

Vraag: welke centrale gebruik jij ?


Grtzz,
Karst

@ klaas. Graag ! Maar wat later. Nu ff geen tijd

[meino]

Karst

ik gebruik de MDRRC-II Centrale van Robert Everts. Verder zet ik Railcom standaard af op mijn lokdecoders.

Groet Meino

[FreekH]

Gerke vraagt: _{dit is dus wel een betrouwbare bedrijfstoestand? Dus geen gedoe dat halverwege een tentoonstelling opeens de draadjes andersom moeten?}
Karst antwoordt:_{Jazeker... bij de Z21 zeker. Bij een eventuele DR5000 niet}

Bedoelt Karst: Jazeker, dit is dus een betrouwbare bedrijfstoestand.
Of bedoelt Karst: Jazeker, bij de Z21 krijg je zeker gedoe... maar bij de DR5000 geen gedoe?

 

[Karst Drenth]

Z21 geen gedoe, DR5000 afhankelijk van de „Auto CutOut polarity“ setting. Uit is geen gedoe, aan is mogelijk gedoe na een (micro)kortsluiting.

[FreekH]

Dank je, zo is 't duidelijk 

Vervolgvraag is dan uiteraard, wat het voordeel kan zijn van het in een DR5000 aanzetten van die Auto Cutout polariteit?

[Karst Drenth]

Heeft te maken met hoe eventueel aangesloten boosters met RailCom cutout omgaan.

Je kunt met een HBrug een z.g. high-side of low-side brake maken.
Met een „brake“ wordt dan bedoeld dat de uitgangen van de Hbrug kortgesloten worden.
High—> via de voedingsspanning
Low—> via Ground

[Karst Drenth]

Maar het is nu eenmaal makkelijker in een Arduino omgeving om de staat van een input uit te lezen, dan met behulp van timers, interrupts etc. een "correcte" routine te bouwen

Kun je dit wat verder uitleggen? Volgens mij bepaalt de lengte van een DCC puls of het een 0 of een 1 is. Ik verwacht dan dat de decodeersoftware op de een of andere manier "meet" hoe lang die puls is. Alleen kijken of de signaal hoog of laag is, is niet voldoende.

Daar gaatie dan

De Arduino-omgeving heeft een aantal slimme zaken standaard aan boord, zoals o.a. het aanhaken van Interrupt-routines aan bepaalde ingangen etc. Verder heeft het ook makkelijk toegangkelijke zaken voor het meten van tijd in zowel milli- als micro-seconden...

Maarrr.... nu komt het

Geef een ( misschien iets minder ervaren...) programmeur, zonder elektrokennis van het DCC signaal, de volgende tekening:



En hij zal al snel tot de conclusie komen, dat er sprake is van een 1 en een 0 signaal op de "draad". ( dit zijn dus niet de logische 0 en 1, dat snapt die programmeur ook wel )

Om nu iets slims te doen in je software, ga je een interrupt knopen aan de DCC-IN pin... dat moet je op de "rising" (standaard in Arduino), "falling" of op "both" flanken doen...

Als je kiest voor Rising of Falling ben je al de pineut... wand daarmee bouw je al je polariteitsgevoeligheid in... Overigens is dat wel zo makkelijk, het "ontslaat je van de plicht om bij te houden of je 2x "kort" en/of 2x "lang" hebt gehad. En dus krijg je dan de problemen beschreven in dit draadje

De goede methode is dus: Interrupt op "both", beide keren meten of je al 2x dezelfde (bij benadering) tijd hebt gemeten. Pas dan mag je een bit tellen als 1 of 0.
Voor het initieel synchroniseren zijn de z.g. Pre-amble bits, zodat je software ervan kan uitgaan dat er steeds logische 1-en achter elkaar komen. Deze reeks wordt beeindigd met het z.g. startbit. Dat altijd een logische 0 is.

Anywee, zoals zovaak, vele manieren om het fout te doen en eigenlijk maar 1 om het goed te doen


En dan nog de oorzaak van het "fout gaan" van RailCom cut-out detectie:

Zie dit:



Zoals je ( Klaas ) wel kunt uitknobbelen is de uitgang ( Arduino pin 2 ) Laag als er stroom door de LED van de OC loopt... en dus hoog als er geen stroom loopt.

In het geval van de, inmiddels in dit draadje beruchte, Cut-Out, loopt er geen stroom door de LED van de OC. En dus levert de uitgang (Arduino Pin 2) een "hoog" op.... hetgeen hetzelfde is voor de software als een "0" op de "draad" ... omgekeerd levert het een "1" op de draad op als de ingangs-draden omgekeerd verbonden zijn...

Plaatjes:





Zoals je ziet, valt dan de detectie van het Packet End Bit in het water, omdat de verkeerde polariteit verwacht wordt.



De rest laat ik aan jouw/jullie eigen fantasie over. Krijg eelt op m'n vingers van al dat typen 


Grtzz,
Karst

[Hasenwald]