Liebe Stummis,
anlässlich meiner geschilderten Probleme mit Railcom und einem LD-G-42-Decoder von TAMS (nachzulesen hier: TAMS Decoder LD-G-42 - Railcom Bugs?) habe ich mir mal die Railcom-Daten diverser Lok- und Funktionsdecoder näher angeschaut. Dabei interessierte mich hauptsächlich das verwendete Timing, weil meine selbst entwickelte DCC-Steuerungszentrale nebst Railcom-Detektor (siehe Vereinfachter globaler RailCom-Detector) konkret mit dem TAMS-Decoder Railcom-Empfangsprobleme hatte. Die Empfangsprobleme äußerten sich so, dass die RailCom-Daten des TAMS-Decoders im Kanal 1 oft so spät gesandt wurden, dass sie in den Zeitbereich von Kanal 2 "hineinagten". Da RC1-Daten in der Regel immer gesendet werden, solange man sie nicht per Konfiguration ausschaltet, störten diese Daten den Empfang von Railcom-Daten anderer Decoder im Kanal 2.
Nach RCN217 sieht das Timing folgendermaßen aus:
Demnach beginnen die Daten im Kanal 1 nach TTS1=80µs (besser 75µs, siehe Bemerkung) und enden spätestens nach TTC1=177µs. Die Daten im RC-Kanal 1 bestehen immer aus 2 Bytes, die mit einer Baudrate von 250.000Bd übertragen werden. Jedes Byte besteht aus 1 Startbit, 8 Bit Daten und 1 Stoppbit. Damit ergibt sich eine minimale Dauer von 2 x 40µs = 80µs für die Übertragung.
Ich habe nun für diverse Decoder gemessen, wann sie mit der Übertragung der Daten aus Kanal 1 (TTS1) und der Übertragung der Daten aus Kanal 2 (TTS2) begannen. Gemessen habe ich für diverse Railcom-fähige Decoder folgendes:
Dabei ist die Zeitauflösung jeder Messung 2µs. Es wurden für jeden Decoder 2000 Messungen im RC1-Kanal und 200 Messungen im RC2-Kanal vorgenommen. Naturgemäß ergeben sich Schwankungen, so dass ich Minimal-, Maximal-, Durchschnitts- und Differenzwerte angegeben habe. Auffallend ist, dass die Schwankungen bei den TAMS-Decodern am größten sind.
Für die Decoder ESU Lokpilot 5, Lenz Standard+ und Zimo 630 ergibt sich, dass die Daten für Kanal 1 (RC1) spätestens nach 96µs beginnen und nach 96µs + 80µs = 176µs enden. Damit halten sie auch für die gemessenen Maximalwerte die Vorgaben von 80µs bis 177µs ein.
Anders sieht es aus für die übrigen Decoder. Dabei sind die Werte für Viessmann 5244, TAMS LD-G-42 und LD-W-42 mit maximal 104µs bzw. 100µs nur etwas über dem Zeitfenster, da hier der TTC1-Wert (Ende Kanal 1) mit 184µs bzw. 180µs knapp überschritten werden. Das lässt sich aber durch eine Korrektur der Railcom-Detector-Software leicht beheben, indem man das Zeitfenster ein paar Mikrosekunden länger offen lässt. Man ist ja tolerant .
Bei dem Funktionsdecoder FD-R Basic.3 von TAMS sind allerdings die Maximalwerte so groß, dass hier TTC1 mit 130µs + 80µs = 210µs oft in den Kanal 2 "hineinragt". Hier wird TTS2 = 193µs glatt überschritten. Die Auswirkung ist, dass die RC1-Daten, welche in der Regel in jedem Cutout gesendet werden, die RC2-Daten anderer Decoder, welche durchaus die Spezifikationen einhalten (wie z.B. ESU, Lenz und Zimo) "kaputtschreiben". Das passiert nicht jedes Mal, aber in ca. 40% aller Fälle. Das heißt: Nur in 60% aller Fälle lassen sich dann die RC2-Daten überhaupt noch auswerten, sobald nur ein FD-R Basic.3 Dekoder auf der Anlage im RC1 aktiv ist.
Fazit:
Das Problem kann man nur dadurch beheben, dass man im FD-R Basic.3 Decoder den RC1-Kanal sperrt. Dann kann dieser nicht mehr stören und die Detection-Rate für alle anderen Decoder im RC2-Kanal steigt wieder auf 100%.
Warum ich so auf dem FD-R Basic.3 Decoder herumreite:
Ich benutze den FD-R Basic.3 Decoder sehr gerne in Märklin Loks, deren Original-Märklin-Decoder zwar schon DCC unterstützt, aber (noch) kein Railcom kann. Dann baue ich die kleine Platine einfach zusätzlich in die Lok, schließe einfach nur die Spannungsversorgung an und setze die Adresse gleich der Lokadresse. Schon kann ich die Lok auf der ganzen Anlage mittels RC2-Kanal lokalisieren. Sehr billig und ungeheuer praktisch.
P.S.
Zum Zeitverhalten für den Kanal 2 (RC2) kann ich nur bemerken, dass alle Decoder hier die Vorgabewerte einhalten. Das ist auch nicht weiter verwunderlich, da im RC2-Kanal bis zu 6 Bytes gesendet werden können. Die TAMS-Decoder verhalten sich zwar auch hier von den Timings sehr "großzügig", senden jedoch viel weniger Daten im Kanal 2 und reichen somit niemals bis an das Ende des Kanals 2 (TTC1=454µs) heran.