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 RP 9.3.1 standardisiert worden ist. Die Technik kann lizenzkostenfrei für den persönlichen, nicht gewerblichen Gebrauch verwendet werden.
    In der NMRA wird diese Technik als BiDi bezeichnet, der Name RailCom® ist ein Markenzeichen der Firma Lenz für diese Technik.

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, Fahrstrecke 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:
    • Ein 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 BiDi (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). 29µs (+/-3µ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 190µ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 Realisierung

    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. Deshalb ist der zulässige Spannungsabfall an einem Detektor auf 200mV (bei einem Strom von 34mA) begrenzt.
  • 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. Die Schwelle am Detektor soll 8mA, mit einem Totband von 2mV sein. Der Spannungsabfall berücksichtigt vor allem eventuell zwischengeschaltete Stromsensoren und ABC-Module 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. Auch wenn das Rückmeldermodul (wie gelegentlich bei direktem Optokoppler in der Gleiszuleitung) mit zwei Dioden in Reihe arbeitet, können andere Verbraucher am Gleis vorher leitend werden, bevor sich ein Strom über den kurzgeschlossenen Booster ausbildet. Wichtig ist also ein geringer Spannungsabfall am Rückmeldemodul wie z.B. hier.
  • RailCom® erfordert korrekt verdrahtete Lokomotiven. Wenn ein Licht nicht gegen Dekoder-Plus (blauer Anschluß), sondern über das Chassis gegen Gleis geschaltet ist, dann funktioniert die Übertragung nur halb: in einer Aufgleisrichtung funktioniert RailCom®, in der anderen Aufgleisrichtung nicht.

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 mehreren Fahrzeugen in einem elektrischen Abschnitt (z.B. Doppeltraktion) kommt daher in Kanal 1 keine gültige Datenübertragung zustande.
  • 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 umstellen.
  • 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 26µs/30µs Empfehlung ab und starten mit der Cutout z.B. erst 38µs nach dem Endebit.
  • Der Inhalt der Rückmeldungen war bis auf rudimentäre Dinge wie Adresse und CV-Quittung nicht standardisiert, daher gibt es aus der Anfangsphase von Railcom® auch noch Dekoder, welche 'unübliche' Pakete senden. Auch hat man zu Beginn den Kanal 2 vernachlässigt bis hin zum Punkt, daß es Dekoder gab, welche die Kanaltrennung nicht einhielten. Es entstand durch die Mitwirkung vieler OpenDCC Anwender eine Liste, was die einzelnen Lokdekoder bei RailCom® können.

Weitere Verarbeitung

    Interessant ist auch die weitere Verarbeitung der BiDi-Daten. Zum einen müssen sie der Zentrale bekannt gemacht 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 wichtig: sowohl die Zuordnung, wo welcher Dekoder gerade ist (also Zugerkennung) als auch die aktuell gefahrene Geschwindigkeit bzw. aktueller Ort dieses Dekoders ist von Bedeutung.

    Railcom ist Rückmeldung und eine der wesentlichen Rückmeldung ist die Lokalisierung bzw. Belegtmeldung. Am Anfang der railcom-Entwicklung standen Ideen zur Erweiterung vorhandener Rückmelde-Protokolle in der Diskussion. Es zeigten sich aber schnell Grenzen hinsichtlich Bandbreite und logischer Befehlsstruktur. Bisherige Zugerkennungssysteme sind mit ihren Protokolle stark an die jeweilige Hardware gekoppelt.
  • Emulation Transpondermodule:
    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.
  • Loconet:
    Mit einer Datenrate in der Größenordnung 10kBaud kann man zwar einzelne Lokerkennungen transportieren, bei einer größeren Anlage mit mehr Meldern und Geschwindigkeitsmeldungen vieler Fahrzeuge reicht die Bandbreite nicht.


  • Also entstanden von Beginn an auch neue Ansätze:
  • RC-Talk von Tams Elektronik ist ein recht simpler Ansatz, um wenige Melder in den PC zu bringen, eine Verbindung zur Zentrale ist nicht vorgesehen. Es wird Adresse, CV und Belegung seriell mit 19200 Baud übertragen.
  • ECos-Link benutzt einen CAN-Bus mit 250kBaud und bietet damit mehr Bandbreite. Allerdings ist CAN inherent ein Producer-Consumer-System, eine Sicherung der Belegtmeldung ist nicht vorgesehen.
  • BiDiB ist ein Master-Slave Ansatz, welcher sich besonders auf einfache Installation und maximale Sicherheit orientiert. Es wird Adresse, CV, Geschwindigkeit und Belegung übertragen und zuverlässig abgesichert.


  • In 2011 wurde von Lenz und ESU eine Erweiterung für das automatische Anmelden einer Lokomotive vorgestellt (Railcom plus), damit soll eine automatische Übertragung der im Decoder gespeicherten Parameter für Name, Funktionssymbole und Loksymbol erfolgen. Es bleibt zu hoffen, dass diese Erweiterung einheitlich standardisiert und offen gelegt wird. Zusammen mit der Rückmeldung besteht dann auch die Möglichkeit, das DCC-Protokoll zu erweitern: Lok und Zentrale können sich auf einen 'erweiterten' Befehlssatz oder gar auf eine andere, aufgesetzte Datenübertragung verständigen und das bisherige DCC nur als Sprungbrett und Stromversorgung nutzen. Denkbar sind z.B. kurze eingestreute OFDM-Pakete.

Rechtliche Situation

    Die Rückübertragung im Halbduplexverfahren wurde von Lenz zum Patent angemeldet und dieses ist auch erteilt worden. Bis 2011 war die Situation schwierig: BiDi wurde von Lenz an die NMRA und interessierte Firmen lizenziert und in einem NMRA Dokument steht, man dürfe es lizentzkostenfrei verwenden, wenn eine Kompatibilitätsprüfung erfolgreich durchlaufen sei. Bei Nachfragen hierzu verweist die NMRA darauf, dass man diese nicht selbst durchführen könne und man möge sich an Lenz wenden.
    Das war relativ geschickt gemacht, sowas hat RAMBUS bei der JEDEC auch schon mal geschafft. Aber was mir nicht ganz klar ist: welcher Patentprüfer erteilt denn im Jahre 2000 ein Patent auf Halbduplex? Das haben die Nachrichtentechniker doch schon in den 50er-Jahren gemacht ...

    Zudem habe ich auch Veröffentlichungen aus dem 80er und 90er Jahren gefunden, wo genau das im Railcom-Patent angegebene Verfahren beschrieben ist: dort wird auch eine Modellbahn mit einem 2-Draht Digitalsignal angesteuert, dann nach einem Datentelegramm das Digitalsignal nullgesetzt, in der Sendepause (bei Railcom heißt diese cutout) erfolgt eine Rückübertragung mittels einer gepulsten Stromquelle, diese wird aus einem vorher aufgeladenen Energiespeicher gespeist. Vergleicht man das mit dem railcom-Patent, so ist exakt der gleiche Sachverhalt beschrieben, nur die Anzahl der rückübertragenen Bits und die Stromstärke ist anders.
    Also war das zum Patent angemeldete Verfahren zum Zeitpunkt der Anmeldung bereits 'anerkannter Stand' der Technik, das Patent hätte demzufolge gar nicht erteilt werden dürfen.

    Im Zuge der europäischen Neuausrichtung der DCC-Normung ab 2010 änderte sich die Lizenzierungspolitik und Railcom wurde offener lizenziert, u.a. auch die Projekte von OpenDCC haben eine Lizenz erhalten. Diese Lizenz hat als Hauptanliegen die Sicherung der Kompatibilität von Railcom-Komponenten untereinander und legt dabei den Erstellern von Baugruppen bestimmte Pflichten auf, die auch von Nachbauern von OpenDCC-Projekten einzuhalten sind. In folgenden fasse ich diese Bedingungen kurz zusammen:
  • Produkte, welche die in den Patenten beschriebene Technik benutzen, müssen mit der Marke 'railcom' gekennzeichnet sein. Bei der Markennennung ist (wie sonst auch) der Markeninhaber (hier Lenz Elektronik GmbH) anzugeben.
  • Produkte müssen 'kompatibel' sein, d.h. sich an veröffentlichte Spezifikationen halten.
  • Bei Kompatibilitätproblemen gibt es vorgegebene Schlichtungsverfahren zwischen den beteiligten Herstellern (u.a. Arbeitskreise und mögliche Unterlageneinsicht), um das Problem zu lösen. Innerhalb OpenDCC bitte ich daher, das Problem zuerst im Forum anzusprechen, ich werde mich dann um eine Lösung bemühen.
  • OpenDCC-Projekte dürfen die in den Patenten beschriebene Technik benutzen. Fertige Baugruppen, welche diese Technik nutzen, dürfen nicht an Dritte verkauft werden (sog. OEM-Geschäft). D.h. derjenige, der Baugruppen in den Markt bringt, muß auch selbst eine Lizenz haben.

Links