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

[FreekH]

Op de momenten dat de booster zich stil houdt op het booster/rail-circuit, zet een daartoe uitgenodigde decoder zijn railcom-informatie op de rails.
Die informatie bereikt dan niet alleen de booster c.q. een losse railcom-detector, maar ook alle andere decoders die op de rails zijn aangesloten.

[Klaas Zondervan]

Freek, lees eerst eens dit verhaal op de NMRA site: https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.3.2_bi-directional_communication.pdf
Daar zie je dat de boosteruitgang wordt kortgesloten. Het RailCom signaal komt dus zeker niet bij de booster en ook niet bij andere decoders. Het komt alleen bij de RailCom detector van de sectie waar de trein op dat moment is.

[FreekH]

De booster wordt losgekoppeld van de beide railzen, en beide railzen worden dan met elkaar verbonden.
Daarna zet een railcom-decoder zijn signaal op de rails - en dat signaal kan dus elk apparaat bereiken dat maar aan die rails hangt. Dus - zeker als je niet met blokken werkt - ook elke wisseldecoder die ook op diezelfde booster is aangesloten.

Anders gezegd: als de booster zich koest houdt, kan een railcom-decoder even als "booster" werken en zijn ding op de leidingen zetten.

[Klaas Zondervan]

De beide rails worden inderdaad met elkaar verbonden, anders gezegd: kortgesloten om een stroomlus te vormen voor het RailCom signaal. Andere decoders hangen aan de kortgesloten rails, dus hoe zouden die het signaal moeten zien?

[VvKan]

Het RailCom signaal komt dus zeker niet bij de booster en ook niet bij andere decoders. Het komt alleen bij de RailCom detector van de sectie waar de trein op dat moment is.

Dat klopt niet helemaal, maar wel als de secties met Railcom detectoren voorzien zijn.  Is dat niet zo, dan gaat het Railcom signaal juist wel naar de booster(s), maar die heten dan "Global detector".  Die werkt dus voor het hele gebied dat door een booster van spanning/signaal wordt voorzien. Dat is wat Freek Heite ook zegt.
Vraag blijft, of een willekeurige andere decoder iets met een Railcom melding doet of kan doen, terwijl de 2 railstaven met elkaar verbonden zijn.  In mijn ogen  niet, alleen boosters die daarvoor ingericht zijn. Met een andere decoder wordt geen stroom/signaalkring gevormd.

Naar mate er meer "niet-Railcom-bestendige" decoders op de markt komen, ook van gerenommeerde merken, wordt het daardoor een zooitje, waar Railcom de schuld van krijgt, terwijl het aan die (in mijn ogen) rommel ligt, die eigenlijk het predicaat DCC niet verdienen.  Of tenminste een vermelding zouden doen:  niet voor gebruik bij Railcom geschikt.

[Jeroen Rood]

Maar hoewel geschreven wordt dat de booster de uitgang kortsluit tijdens de cutout, zit de detector nog steeds in serie met de uitgang.



Het is dus geen echte doorverbinding van de 2 rails, maar alleen een kortsluiting van de boosteruitgang.
Hierdoor kan dus wel een spanning op de rails en over de detector staan, maar die kan (volgens de NMRA) 2.2V max te zijn. Dat lijkt me onvoldoende om iets mee te activeren of te dwarsbomen.

[Joz]

Misschien zit het in het aantal pre-amble bits dat door de decoder(software) vereist wordt.

Ik vond onderstaande tekst op dccwiki.com/Term:RailCom dat wellicht in enige mate hier ook van toepassing is?

Many, but not all, command stations generate a preamble with more than the minimum number of 12 bits. The extra preamble bits can be used for the RailCom cutout. Problems arise with multifunction decoders expecting a minimum of 12 or more preamble bits. Many multifunction decoders will function with only 10 preamble bits. Should the command station generate 16 preamble bits, 4 can be used for the RailCom cutout without impairing decoder operation.

Groeten,
Jos

[Servé]

Je zou dus kunnen proberen om het aantal Preamble-bits in de centrale omhoog te krikken naar 16 bijvoorbeeld (in een DR5000 kan dat, andere centrales weet ik niet), of in de software van de decoder het minimum aantal Preamble-bits naar beneden te schroeven.

Code: (DCC_Decoder.cpp) [Selecteer]

    // Minimum preamble length
#define    kPREAMBLE_MIN    10

Als je de 10 bijvoorbeeld door 8 vervangt (lager zou ik niet gaan), en dan opnieuw de code compileert en erop zet, zou dat wel eens verschil kunnen geven. Let wel: Dit heb ik niet getest! Zondagavond heb ik pas een eerste mogelijkheid om dit te testen.

[FreekH]

Het is dus geen echte doorverbinding van de 2 rails, maar alleen een kortsluiting van de boosteruitgang.

Eh, als de twee (al dan niet eerst intern in de booster afgekoppelde) uitgangen van de booster worden kortgesloten, dus met elkaar verbonden worden,
dan heb je toch per definitie ook een doorverbinding van de twee railstaven - want die zitten immers 1 op 1 op de twee aanslutingen van de booster.

Ik denk dat ik van het weekend eerst eens de al door Klaas genoemde specs ga doorlezen, maar dan in z'n geheel en op mijn gemak.
Mijn eigen Lenz-systeem is te oud voor Railcom, ik kan er dus niet mee experimentenrent, maar ik wil de theorie toch wel graag helemaal begrijpen.

[Jeroen Rood]

@Freek,
als je het plaatje bekijkt zie je dat er tussen de booster uitgang en de railverbindingen nog de detector zit. (Volg het lijntje)
Hierdoor blijft de detector als enige nog aanwezig tussen de 2 rails, en is er geen kortsluiting van de rails, alleen in de boosteruitgang zelf.
Maar ik denk dat dit verder niet zoveel met het probleem te maken heeft.

Jeroen.

[VvKan]

De vraag is, waarom er in het plaatje een detector getekend is.  Ook zonder detector werkt Railcom, alleen kun je dan niet per sectie iets zien, maar alleen "global", dus via de centrale op je handregelaar. De tekening geeft  "local"weer.
Ik spreek in dit geval uitsluitend over Lenz, andere merken ken ik niet.

[VvKan]

Herstel:  ik zie nu bij de NMRA wat ze bedoelen. Feitelijk is de tekening niet geheel correct, de detector zou IN de centrale/booster getekend moeten zijn, dus een "global"detector.  Anders zou het geen Railcom centrale/booster zijn.
Om het plaatje volledig te maken, zouden er volgens de tekst ook 2 detectors getekend kunnen zijn:  ééntje in de centrale/booster en de tweede ("local") aan de rails (zoals getekend).

[Gerke]

Beste allemaal,

Met interesse maar ook huivering lees ik het steeds ingewikkelder wordende verhaal.  Ik denk dat ik inmiddels de conclusie kan trekken dat mijn aanvankelijk geschetste probleem dus niet 1,2,3 op te lossen is. De zaken die ik vooral op pagina 3 en verder voorbij zie komen gaan mijn kennis ver, ver te boven. Ik zou ook niet weten hoe ik aanpassingen zou moeten doen in de software van welk onderdeel dan ook, dus dat is voor mij geen optie.

Ik denk dat ik gewoon de conclusie moet trekken dat de Z21 met Railcom aan en deze decoder mekaar niet begrijpen. Ik ga het weekend gebruiken om een andere oplossing te vinden. (die is er eigenlijk al) Jammer, want het programmeren van deze decoder is een verademing t.o.v. het CV gebeuren. Net als de mogelijkheden die deze decoder biedt voor de prijs.

Zou mooi zijn als er tóch iets uit komt voor mensen die wél de kennis hebben om deze tekortkoming te repareren.

[Klaas Zondervan]

Inderdaad, ik zie nu ook dat de rails niet geheel worden kortgesloten, er kunnen nog twee detectors tussen zitten, de locale en de globale.
Het NMRA document stelt dat de spanning op de rails ten gevolge van de RailCom stroompulsen niet hoger mag worden dan 2,2V. De vraag is maar of de opto-coupler in de DCC-Next decoder daarop reageert. De ingaande stroom is heel klein, maar de CTR van die opto is weer behoorlijk groot, dus ik kan moeilijk inschatten wat er gaat gebeuren.
Maar los daarvan vind ik nog steeds dat die decoder daardoor niet van slag mag raken.

[Karst Drenth]

Hoi Allemaal,

Ik zie net dit topic voor het eerst en lees met stijgende verbazing wat er allemaal bij gehaald wordt. Zelfs tot en met het werkingsprincipe van DCC en RailCom.

Dit terwijl het antwoord op Ger's vraag eigenlijk heel simpel is:

- er is geen "device" dat de cutout weghaalt.
- zo een device is ook nauwelijks te maken ( zonder het DCC signaal uit te lezen, te interpreteren het het opnieuw te genereren ! zonder CutOut )
- Het beschreven "probleem" is geen tekortkoming van Z21 of booster.
- Het werkelijk enige probleem is de DCC decoderings firmware in de decoder. En is derhalve alleen in die firmware op te lossen. ( en ja, ik heb die library ook al eens bekeken en gebruikt in 1 van mijn projecten en weet dus waar het probleem zit )
- veel van de Arduino "decoder" oplossingen hebben dit probleem. Dat is al tijden bekend, helaas is de maker van die library niet te porren voor het maken van een correcte, DCC compliant, decodeer-routine.
- Als dan de "uitgever" van deze servodecoder zich verschuilt achter "het is een library van het internet en kan daar niets aan doen", is dat denk ik een flauw excuus. Alle Arduino libraries komen met de volledige firmware in source vorm. Dus als je het wilt, kun je het zelf aanpassen...
- Al laatste dan nog een mogelijke oplossing voor Ger:  Draai de twee draden die van je DCC bron komen naar de DCC ingang van je decoder eens om. 1 van problemen in deze libraries is het polariteitsgevoelig zijn van de decodeer-routine.

zover "My seven Cents" over dit onderwerp

Grtzz,
Karst