Dekoder und ihre Railcom®-Eigenschaften

    Bei der Inbetriebnahme des GBMBoost sind Unterschiede in der Implementierung von railcom bei verschiedenene Lokdekodern aufgetaucht, diese Seite listet die gemachten Erfahrungen und klärt auf, welcher Dekoder ab welcher Softwareversion wie gut railcom-kompatibel ist.

    Ergänzung zu dieser Softwareanalyse gibt es auch mögliche Hardwareprobleme durch fehlende oder zu klein dimensionierte Pufferkondensatoren. Hier verweise ich auf einen Thread im stummiforum.de, in dem diese Problematik auch schon bei normaler DCC-Übertragung zum tragen kommt. Bei railcom ergibt sich ergänzend das Problem, dass fehlende oder zu kleine Kondensatoren nach der Cutout des Gleissignals zu einem fallweise sehr heftigen Nachladen des Dekoders führen - eine Lok mit einem durchschnittlichen Stromverbrauch nimmt dann auch schon mal einen Peakwert von über 13A auf. Das kann zum ungewollten Auslösen von Überstrom-Schutzschaltungen in Boostern führen - mit entsprechenden Folgeproblemen. Im verlinkten Thread auf Stummi sind Dekoder von Uhlenbrock und ESU negativ aufgefallen.

    Erläuterungen:
  • Channel 1, Adresse: in diesem Kanal sendet ein railcom-fähiger Dekoder seine Adresse permanent und spontan aus. Diese Aussendung dient zur Erkennung neuer Dekoder auf der Anlage und wird nur dann sicher erkannt, wenn sich nur ein einziger Dekoder im überwachtem Abschnitt befindet. Die Aussendung ist mittels CV28, Bit 0 abschaltbar.
  • Channel 2: in diesem Kanal sendet ein railcom-fähiger Dekoder (und nur dieser Dekoder) eine Antwort, wenn er adressiert wird. Der OpenDCC Belegtmelder GBM16T erkennt dann den Dekoder an der Antwort (egal, welcher Inhalt). Wenn die Antwort nutzbare Information enthält (wie z.B. aktuelle Geschwindigkeit), ist es in der Tabelle entsprechend gekennzeichnet. Die Aussendung in Channel 2 ist mittels CV28, Bit 1 abschaltbar.
  • Erklärung
    ACK Dekoder antwortet im Channel 2
    PoM Dekoder beherrscht Programmieren auf dem Normalgleis
    Speed Dekoder übermittelt gefahrenen Geschwindigkeit
    QoS Dekoder übermittelt Informationen über die Gleisverschmutzung/Kontaktgabe (Dirty Track) (Quality of Service)
    Funktion vorhanden
    Funktion vorhanden, jedoch Abweichungen zum Standard, siehe Bemerkung
    Funktion nicht vorhanden

Lokdekoder

    HerstellerTyp / VersionBildChannel 1Channel 2Bemerkung
    Typ / Version   Adresse Individuelle Antwort  
    Döhler und Haass DH05C ACK:
    PoM:
    Speed:
    QoS:     		getestete Version 3.03.14; railcom per default freigeschaltet
    ab Version 3.05.104 QoS enthalten
    Vorgängerversion 3.02.73; CV28 wird korrekt unterstützt, POM kann read/write
    Vorgängerversion 3.01.23: kein Channel 2 ACK
    Vorgängerversion 3.02.53: Channel 2 ACK wird nicht sicher erkannt.
    Döhler und Haass DH10C ACK:
    PoM:
    Speed:
    QoS:     		getestete Version 3.03.14; railcom per default freigeschaltet
    ab Version 3.05.104 QoS enthalten
    Vorgängerversion 3.02.073; CV28 wird korrekt unterstützt, POM kann read/write
    Vorgängerversion 3.01.023: kein Channel 2 ACK
    Vorgängerversion 3.02.053: Channel 2 ACK wird nicht sicher erkannt.
    Döhler und Haass DH16A ACK:
    PoM:
    Speed:
    QoS:     		ab Version 3.05.104 QoS enthalten
    Version 3.03.14; railcom per default freigeschaltet
    Vorgängerversion 3.02.073; CV28 wird korrekt unterstützt, POM kann read/write
    Vorgängerversion 3.01.023: kein Channel 2 ACK, Railcom, muß mit CV29, Bit 3 eingeschaltet werden
    Vorgängerversion 3.02.053: Channel 2 ACK wird nicht sicher erkannt.
    Döhler und Haass SD18A ACK:
    PoM:
    Speed:
    QoS:     		getestete Version 3.03.14; railcom per default freigeschaltet
    Vorgängerversion 3.02.073; CV28 wird korrekt unterstützt, POM kann read/write
    Vorgängerversion 3.01.023: kein Channel 2 ACK
    Vorgängerversion 3.02.053: Channel 2 ACK wird nicht sicher erkannt.
    ESU Lokpilot 3.0   ACK:
    PoM:
    Speed:
    QoS:     		Version ist nicht in CV7 kodiert, sondern in CV287/CV288. Version CV288; Sub-Version CV287. Zusätzlich gibt es eine Built-Number, diese erhält man mit: (CV286 * 256) + CV285
    Zum Lesen von CV285-CV288, muß man vorher die Indexregister einstellen: CV31 = 0, CV32 = 255
    getestet: Firmware: 0.0.6607
    ESU Lokpilot Fx 3.0   ACK:
    PoM:
    Speed:
    QoS:     		Laut Beschreibung gibt es ein Bit2 in CV28 (nicht normkonform).
    getestet: Firmware 0.0.6642
    ESU Lokpilot Standard   ACK:
    PoM:
    Speed:
    QoS:     		Version ist nicht in CV7 kodiert, siehe hierzu ESU Lokpilot 3.
    Hinweis: ACK in Chan2 erfolgt nur, wenn RailcomPlus in CV28.Bit7 eingeschaltet ist.
    getestet: Firmware 1.2.1387
    ESU Lokpilot 4   ACK:
    PoM:
    Speed:
    QoS:     		Version ist nicht in CV7 kodiert, siehe hierzu ESU Lokpilot 3.
    Hinweis: ACK in Chan2 erfolgt nur, wenn RailcomPlus in CV28.Bit7 eingeschaltet ist.
    getestet: Firmware 4.14.9217; getestet auf LP 4.0, LP 4.0 DCC, LP 4.0 DCC PX, LP FX 4.0
    Kühn T65 Version 35 ACK:
    PoM:
    Speed:
    QoS:     		CV7 nicht lesbar, CV28 nicht vorhanden
    Kühn N45   ACK:
    PoM:
    Speed:
    QoS:     		Keine Antwort bei PoM-Write, fehlerhaftes Verhalten bei Bit setzen! (alle anderen Bits werden 0)
    Lenz Spur 0   ACK:
    PoM: (ungetestet)
    Speed:
    QoS:     		CV28 Bit 1 nicht beschreibbar, keine Channel 2 Pakete
    Lenz Silver mini 9.6 ACK:
    PoM: (ungetestet)
    Speed:
    QoS:     		 
    Lenz Silver+ Version 9.5 ACK:
    PoM: (ungetestet)
    Speed:
    QoS:     		 
    Lenz Standard+ Version 9.3 ACK:
    PoM: (ungetestet)
    Speed:
    QoS:     		CV7 = 93
    Lenz Railcom Sender LRC100 ACK:
    PoM:
    Speed:
    QoS:     		Nachrüstmodul zum Senden in Ch1.
    Tams LD-G-32 Version 2.1
    (sendet nicht permanent)    		 ACK:
    PoM:
    Speed:
    QoS:     		Dekoder unterstützt dynamische Kanalnutzung (Bit 2 in CV 28)
    Die railcom-Anwort jittert und liegt teilweise außerhalb der Channel 1 Spezifikation, wird aber durch die Filterung des GBM16T i.d.R. erkannt.
    Versionen vor 0x21 (Mai 2014) senden kein ACK und unterstützen dynamische Kanalnutzung nicht. Zudem jittert bei älteren Versionen die Channel 1 Antwort so stark, dass sie teilweise in Channel 2 zu liegen kommt und dort die Übertragung anderer Dekoder stören kann.
    Tams LD-G-33 Version 1.8
    (sendet nicht permanent)    		 ACK:
    PoM: (ungetestet)
    Speed:
    QoS:     		Die railcom-Anwort liegt teilweise außerhalb Channel 1 Timing, wird nicht sicher erkannt
    Tams LD-G-33Plus Version 2.1 ACK:
    PoM:
    Speed:
    QoS:     		Dekoder unterstützt dynamische Kanalnutzung (Bit 2 in CV 28) und railcom+. CV7 = 0x21
    Viessmann Schienenstopfexpress ACK:
    PoM:
    Speed:
    QoS:     		Timing: Ch1: 94us, Ch2: 203us, kaum Jitter. CV7=8, CV8=109
    Viessmann Weichendekoder 4559     ACK: Verletzung der Spezifikation: Der Viessmann Dekoder antwortet nach einem DCC-Schaltbefehl auf seine eigene Adresse sporadisch erst in der cutout des auf den Schaltbefehl folgenden Lokbefehls, dort dann im Channel 2
    Vermutlich trifft das auch auf Viessmann 4558 zu.
    Viessmann Lokdekoder 5241  
    sendet zu viel    		 ACK: Verletzung der Spezifikation: Der Viessmann Dekoder sendet in Channel 1 auch bei Idle. Gelegentliche Aussendung in der falschen cutout (Ghost).
    ZIMO MX620 Version 31.1 ACK:
    PoM: (ungetestet)
    Speed: (noch als ID3)
    QoS:     		CV7: 31 (= Version 31), CV65:1 (=Subversion 1); QoS ab Q2/2015
    ZIMO MX622 Version 31.1 ACK:
    PoM: (ungetestet)
    Speed: (noch als ID3)
    QoS:     		CV7: 31 (= Version 31), CV65:1 (=Subversion 1); QoS ab Q2/2015
    Speed: CV#158, Bit2 auf 1 setzen
    ZIMO MX623P12 ACK:
    PoM:
    Speed:
    QoS:     		CV7: 31 (= Version 31), CV65: 57 (=Subversion 57);
    ZIMO MX630 Version 31.0 ACK:
    PoM:
    Speed:
    QoS:     		CV7: 31 (= Version 31), CV65:0 (=Subversion 0);
    POM funktioniert ab Version 2.01 vom GBM16T. (gilt auch für MX631D) bis einschl. SW Version 31.52 konnte ACK sporadisch im falschen Cutout kommen. 31.53 (02/2015) behebt den Fehler.; QoS ab Q2/2015
    ZIMO MX630P16 ACK:
    PoM:
    Speed:
    QoS:     		CV7: 31 (= Version 31), CV65: 14 (=Subversion 14);
    ZIMO MX631 ACK:
    PoM:
    Speed:
    QoS:     		CV7: 31 (= Version 31), CV65: 57 (=Subversion 57); CV250: 213 (=MX631)
    ZIMO MX632D ACK:
    PoM:
    Speed:
    QoS:     		relativ starker Jitter der Railcomdaten (15µs), in etwa 2% der Telegramme wird das receive-Window verletzt. QoS ab SW 34.* enthalten.
    ZIMO MX634D ACK:
    PoM:
    Speed:
    QoS:     		CV7: 31 (= Version 31), CV65: 14 (=Subversion 14);
    ZIMO MX64
    (sendet nicht permanent)    		 ACK:
    PoM: (nur sporadische Antwort)
    Speed:
    QoS:     		Ch1 und Ch2 nicht getrennt abschaltbar. Speed noch in veralteter Codierung.
    (Dieser Dekoder wurde 2002 in den Markt gebracht, die railcom-Standardisierung erfolgte erst 2007)
    ZIMO MX644D ACK:
    PoM:
    Speed:
    QoS:     		Test 2015, Version *****, Ch1 Jitter bis 8us. Ab SW 34.* QoS enthalten
    ZIMO MX645P ACK:
    PoM:
    Speed:
    QoS:     		Test 2015, Version *****, Ch1 Jitter bis 8us. Ab SW 34.* QoS enthalten
    ZIMO MX685P16 ACK:
    PoM:
    Speed:
    QoS:     		Funktionsdekoder, technisch baugleich zu MX630P16
    Hinweise:
  • Adressmeldungen im Channel 1 funktionieren problemlos, solange ein Dekoder im Abschnitt ist. Wenn zwei oder mehr Dekoder in einem Abschnitt sind, so entstehen durch die fortlaufende Aussendung beider Dekoder Kollisionen im Channel 1 und die Adressmeldung wird verstümmelt. Der GBM16T kann dann keine Adresse erkennen.
    Wenn ein Dekoder in Channel 1 nicht permanent sendet (das ist nicht normkonform), dann können bei zwei oder mehr Dekodern in einem Abschnitt falsche Adressmeldungen entstehen.
    Hier kommt ein Konstruktionsfehler von railcom zum Tragen: die Adresse (eigentlich ein 'ATOMIC'-Objekt) wird in zwei getrennten Teilen übertragen und bei nicht permanenter Aussendung kann es passieren, dass zwei nicht zueinander gehörende Teile im Detektor kombiniert werden.
  • Laut mündlicher Auskunft am 04.11.13 von Herrn Richter, Fa. Uhlenbrock senden alle Dekoder von Uhlenbrock kein ACK in Channel 2. Diese sind damit nicht konform zur Spezifikation. Auch antworten Uhlenbrock Dekoder nicht auf PoM-Write mit einer eigentlich vorgeschriebenen Railcom-Antwort.
  • Bei Zimodekodern mit Software Stand bis Jan. 2015 oder eher kommt es sporadisch zu einer Verschiebung der Channel 2 Nachrichten in die cutout des nachfolgenden DCC Befehls. Dies ist abhängig von der internen Prozessorauslastung wie Motorregelung/Sound/Zusatzfunktionen. Eine Aussendung in der falschen cutout verursacht eine sog. 'Geisterlok'. (Behoben ab Zimoversion 31.53)