DCC-BiDi (RailCom ®)

Motivation

    Als in den 80er Jahren die Digitalsteuerung eingeführt wurde, standen die Gründe Fernsteuerbarkeit und Verdrahtungsvereinfachung im Vordergrund. Ausgehend von damaliger Technik wurden unidirektionale Protokolle (z.B. MM, DCC) entwickelt, welche es erlauben, über 2 Drähte Information und Energie gleichzeitig zu übertragen. Mit zunehmender Verbreitung der Technik entstand der Wunsch nach bidirektionaler Kommunikation. Diese gestaltet sich aber wegen Kompatibilitätsanforderungen und physikalischen Gegebenheiten schwierig: der Weg zum Dekoder ist eine Broadcast-Anwendung mit klarer hierarchischer Struktur, der Rückweg jedoch erfordert Arbitierung und Buszuteilung, wie sie in Netzen erforderlich ist. Von den diversen Vorschlägen hat sich der Vorschlag der Fa.Lenz durchgesetzt, welcher im Jahre 2007 von der NMRA in der RP9.3.1 standardisiert worden ist. Die Technik kann lizenzkostenfrei für den persönlichen, nicht gewerblichen Gebrauch verwendet werden.

Vorteile

  • Bessere Ausnutzung der Bandbreite am Gleis: dadurch, dass Befehle quittiert werden, müssen diese nicht mehr 'auf Verdacht' oft wiederholt werden.
  • Automatisches Anmelden einer Lok in der Zentrale - bis hin zum Auslesen eines Bildes dieser Lok. Neudeutsch Plug&&Play genannt.
  • Auslesen der Eigenschaften einer Lok, z.B. ob und welche Sonderfunktionen vorhanden sind.
  • Verändern der Parameter einer Lok, wie z.B. Geschwindigkeitskennlinie.
  • Übertragung weiterer Parameter (Soll- und Ist-Geschwindigkeit, Zustand der Funktionen usw.) möglich.
  • Übertragung von Fehlerzuständen. Z.B. kann der Decoder die Stromaufnahme des Motors kontrollieren und bei Überschreitung bestimmter Grenzwerte auf fällige Wartung hinweisen.
  • Simulation von Betriebsabläufen, wie z.B. Kohle und Wasserverbrauch.
  • Die Lok kann einen Zustandbericht über das Gleis melden, wie oft z.B. es zu kurzzeitigen Stromausfällen durch verschmutzte Gleise gekommen ist.
  • Mit der Möglichkeit, dass der Rückmelder erkennen kann ob und welche Lok da in seinem Bereich ist, ergeben sich neue Steuerungsmöglichkeiten:
    • Eine Rückmelder kann einer Lok Hp0 oder Hp2 verpassen: wenn die Lok in seinem Bereich auftritt, dann wird eine entsprechende Busnachricht erzeugt.
    • Die Lok (z.B. nach dem Aufgleisen) kann bei einer PC-Steuerung automatisiert zugeweisen werden.

Wie funktioniert RailCom?

    railcom cutout
    Die Datenübertragung von der Zentrale zum Decoder wird nicht mehr ununterbrochen durchgeführt, sondern es wird ein Zeitmultiplex eingeführt, welches Zeitschlitze für die Übertragung zum Decoder und für den Rückweg vorsieht. Der Zeitschlitz für die Rückübertragung (=cutout, oben grau dargestellt) wurde wie folgt definiert:
  • Die Sendepause beträgt mindestens 448µs oder 4 logische 1 Bits (=464µs). Ca. 30µs nach dem Aussenden des Endebits einer DCC-Nachricht schaltet die Zentrale ab, ca 16µs vor dem Ende wieder ein. Diese Ein-Ausschaltzeiten dienen jeweils dazu, dass Decoder die Flanken des DCC Signal erkennen können.
  • In der Sendepause kann ein Decoder zurücksenden. Die Rücksendung erfolgt mit seriellen, byteweisen Nachrichten. Diese sind wie RS232 kodiert, wobei als Übertragungsparameter 250kBaud, 8 Bit, 1 Stopbit verwendet wird. 250 kBaud bedeutet 4µs je Bit, bzw. 40µs für ein Byte inklusive des Startbits (=0) und Stopbits (=1). Es sind zwei Kanäle (Zeitschlitze) definiert:
    1. Kanal 1: Dieser folgt in einem Zeitfenster von 80µs - 95µs nach dem Ende des letzten Datenbits von der Zentrale und beinhaltet 2 Bytes, ist also 80µs lang. Dieser Kanal ist für sog. ad-hoc Meldungen vorgesehen, also zum Melden von Ereignissen, von denen die Zentrale noch nichts weiß.
    2. Kanal 2: Dieser Kanal beginnt in einem Zeitfenster von 193µs - 208µs nach dem Ende des letzten Datenbits von der Zentrale und beinhaltet 6 Bytes, ist also 240µs lang. Logisch sind diese 6 Byte wieder in 3 Paare aufgeteilt. Dieser Kanal ist für Quittungen vom jeweils angesprochenen Dekoder vorgesehen.

Die physikalische Realisisierung

    Beim Rücksenden der Daten sieht man sich einer Reihe von Schwierigkeiten gegenüber:
  • Ein mobiler Dekoder hat normalerweise keine eigene Energiequelle, die Rücksendung muß also aus zwischengespeicherter Energie gewonnen werden.
  • Es sind fallweise viele Verbraucher vorhanden, welche die Leitung im Rücksendefall belasten. Glücklicherweise sind diese Verbraucher i.d.R. über Dioden abgetrennt, so dass zum einem bei einem niedrigeren Spannungsniveau kein Strom fließt (da die hinter den Dioden liegenden Lade-C's noch voll sind) und zum anderen erst ab einer gewissen Mindestspannung überhaupt erst Strom fließt. Probleme entstehen daher hauptsächlich durch direkte ohmsche Verbraucher , wie z.B. Zugbeleuchtungen und leitende Achsen.
  • Auch Ersatzspannungen, wie sie z.B. von manchen Besetztmeldern zur Aufrechterhaltung der Rückmeldung bei DCC-Ausfall verwendet werden, können die Rückübertragung stören.

    • Es wurde folgende Realisierung standardisiert:
    Die Bei aktiver Rückübertragung schließt die Zentrale (oder der Booster) seine Ausgänge kurz (Cutout) und der Dekoder prägt in diese entstandene Leitungsschleife einen Strom ein. Dieser Strom beträgt mind. 30mA bei einem max. Spannungsabfall von 2,2V. Ein Stromfluß von 30mA (+4mA -6mA) bedeutet logisch 0, kein Strom (<0.1mA) bedeutet logisch 1. Die Bitdauer ist 4µs (=250kBaud), die rise- und fall-Zeiten sind zu je 0,5µs definiert. Der Spannungsabfall berücksichtigt vor allem eventuell zwischengeschaltete Stromsensoren mit Dioden.

    Dieser eingeprägte Strom wird von einem Sensor erfaßt, dieser wandelt das Signal wieder in ein reguläres RS232-Signal um, welches dann von der Zentrale ausgewertet wird.
    Laut NMRA dürfen die Taktraten um +/- 2% abweichen. Ich halte das für gewagt: sollten Sender und Empfänger die Toleranz in die entgegengesetzte Richtung ausnutzen, so ergibt sich ein max. Offset des Samplezeitpunkts von 8*4% = 32%. Typischerweise wird beim Startbit in der Mitte begonnen, d.h. gegen Ende des Bytes kommt man dem Rand des Bits gefährlich nahe, vor allem wenn man auch noch die Anstiegs-Abfallzeiten der Hardware mit in Kalkül ziehen muß.

Kompatibilität

    Wie kompatibel ist RailCom zu bisherigen Dekodern und Zentralen?
  • Durch das Abschalten wird die nachfolgende Präambel um 4 Einser verkürzt; bisher lag die mindestens erforderliche Länge beim Empfänger bei 10 Einsern, Zentralen waren angehalten, 14 Einser zu senden. Das Protokoll ist also durch diesen Zeitschlitz nicht verletzt. Jedoch gibt es Zentralen und Decoder, welche sich nicht ganz an die bisherigen Vorgaben gehalten haben. Zudem benötigen manche Decoder einen stabilen Vorgängerzustand, um das jeweils nachfolgende Bit sicher zu erkennen. Daher halte ich es für ratsam, die Zahl der '1'-Bits auf der Seite der Zentrale auf mind. 15 zu setzen. Auch kann es Probleme beim Erkennen des Endebits geben, wenn die Austastlücke knapp nach dem letzten Bit kommt - fallweise hilft ein Verpolen des DCC-Anschlusses.
  • Schwieriger wird es beim Energiehaushalt des Dekoders - dieser muß in der Lage sein, die Strompause zu überbrücken. Und eine Austastlücke von 400µs verursacht bei einem angenommenen Strombedarf des Motors von 500mA und einem Abblockkondensator von 47µF einen überschlägigen Spannungsabfall von knapp 5V. Es kann daher bei knapp dimensionierten Decodern zu Ausfällen wegen Spannungsunterschreitung am Prozessor kommen.
  • Auch die konzentrierte Stromaufnahme aller Dekoder nach der Austastlücke kann fallweise Probleme verursachen. (Bei Boostern, welche extrem schnell abschalten)
  • Wie oben bereits dargestellt, können ohmsche Verbraucher am Gleis dem eingeprägten Rückstrom eine zu geringe Impedanz anbieten. Ob und wie diese wirksam wird, hängt von der Last und den Dioden in den Sensormodulen ab. Allgemein wird empfohlen, solche Verbraucher durch Dioden abzutrennen.
  • RailCom hat fallweise Schwierigkeiten mit bereits installierten Rückmeldemodulen. Je nach Schaltungstyp und Art der verbauten Dioden können diese Rückmeldemodule wie eine Sperre für RailCom-Signale wirken.

Codierung

    Um die Datenübertragung gegen Kollisionen und Übertragungfehler abzusichern, wird eine Redundanzcodierung vorgenommen. Hierbei werden den Nutzdaten weitere Daten hinzugefügt. Umgekehrt bedeutet dies, dass in den Datagrammen weniger Nutzbits übertragen werden können.
    In NMRA RP 9.3.2 wird eine 4/8 Codierung vorgeschlagen, welche 6 Nutzbits auf 8 Transferbits abbildet. 4/8 bedeutet, dass bei 8 übertragenen Bits die Codes so gewählt sind, dass immer genau 4 Bits den Zustand '1' haben (Hamming-Gewicht = 4). 8 Bits bedeutet 256 mögliche Zustände, davon haben dann (8!/4!/4!) = 70 Zustände ein Hamming-Gewicht von 4. 64 Codes sind für die Kodierung der 6 Nutzbits verwendet, die weiteren 6 möglichen Codes dienen zum Kennzeichnen besonderer Nachrichten (sog. Acknowledge-Datagramme).

Nachteile, potentielle Probleme

  • M.E. ist das Protokoll-Verhalten im Kanal 1 (eine Lok schreit da einfach die eigene Adresse raus) nur für die Spielbahn geeignet, auf einer größeren Anlage wird man dieses Verhalten nicht brauchen können.
  • Bei einer gemischten Verwendung von Boostern mit BiDi und solchen ohne BiDi ergibt sich ein Kurzschluß, wenn während der Cutout diese Booster über ein Fahrzeug verbunden sind. Man muß also die Anlage komplett umrüsten.
  • Es fehlt noch ein genaueres Timing der Cutout, wenn mehrere Booster installiert sind. Wenn der Ausgang zweier Booster verbunden ist (z.B. durch eine Lok über der Trennstelle), dann kann es sein, dass ein Booster noch Signal erzeugt, während der Nachbar bereits Cutout macht. Da könnten dann zwei Treiber gegeneinanderstehen. Also muß die Spec noch um eine kurze Totzeit ergänzt werden, in der jeder Booster abschaltet, d.h. der Cutout muß eine kurze Idlezeit vorangehen bzw. folgen.
    Railcom mit Guardintervall
    Vorschlag für Guardintervall zur Vermeidung von Kurzschlüssen.
  • Bisherigen Beobachtungen zufolge weichen einige bereits verfügbare Booster (offenbar wegen Kompatibilitätsproblemen mit Dekodern) von der 30µs Empfehlung ab und starten mit der Cutout z.B. erst 38µs nach dem Endebit.
  • Der Inhalt der Rückmeldungen ist bis auf rudimentäre Dinge wie Adresse und CV-Quittung nicht verpflichtend und teilweise (speziell bei Zubehördekodern) auch nicht standardisiert.

Weitere Verarbeitung

    Offen ist auch noch die weitere Verarbeitung der BiDi-Daten. Zum einen müssen sie der Zentrale bekannt genacht werden, damit diese ihr Gleisprotokoll optimieren kann und z.B. beim Programmieren auch die Rückmeldung erhält. Zum anderen sind sie auch für den steuernden PC interessant: sowohl die Zuordnung, wo welcher Dekoder gerade ist (also Zugerkennung) als auch die aktuell gefahrene Geschwindigkeit dieses Dekoders ist von Bedeutung.

    Hier bieten sich neben der Erweiterung vorhandener Host-Protokolle folgende Wahlmöglichkeiten an:
  • Der BiDi-Detektor setzt eine Nachricht an eine Sammelstelle ab. Diese könnte z.B. auch mit einer entsprechenden Befehlserweiterung auf dem Xpressnet erfolgen. Die Nachricht wird spontan bei der Adressierung des Detektors gesendet. RC-Talk von Tams Elektronik ist eine mögliche Implementierung dieses Ansatzes.
  • Die Zentrale könnte die empfangene Nachricht auf ein passende Hostnachricht umsetzen oder auch notfalls komprimiert in seinen Rückmelderbits abbilden. Hierbei empfiehlt sich die Emulation einen marktgängigen Transponder-Moduls, um nicht noch eine unterschiedliche Kodierung zu erzeugen.
  • Alternativ könnte ein XpressnetSniffer am Bus mithören, und für den PC relevanten Zugerkennungsmeldungen ausfiltern und in einem passenden Protokoll abschicken. Auch hier wäre wegen der Softwareunterstützung auf PC-Seite die Emulation eines Zugerkennungssystem (z.B. Helmo oder Digitrax) sinnvoll.
    • Nachteil der Emulationen ist der eingeschränkte Befehlsvorrat dieser Protokolle - Geschwindigkeit und Richtung ist weder beim TD88 noch beim Inter-10 (beides von Littfinski) vorgesehen. Hier müßte fallweise erweitert werden, was die Softwareintegration auf dem Host wieder erschweren würde. Bliebt also zu hoffen, dass man sich mit Softwareanbietern auf eine vernünftige Erweiterung vorhandener Protokoll einigen kann.

Links