RailCom, Datenübertragungstechnik

DCC-BiDi (RailCom ®)

Motivation

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.
Man kann Abschnitten eine irgendwie geartete Kodierung geben (z.B. ansonsten redundante Bits, längere 0-Phasen, auch stromlose Zeitbereiche), das kann der Dekoder erkennen und global via railcom zurücksenden (Positionsbestimmung).
Automatisches Vermessen einer Anlage: ein mit Längenmessung ausgestattetes Fahrzeug überträgt mittels Railcom die Messwerte. Das Belegtmeldesystem ordnet dies den Abschnitten zu und kann so eine automatische Längenbestimmung der Streckenabschnitte vornehmen.
Automatisches Einmessen von Fahrzeugen: Computergestützes Fahren benötigt die Kennlinie des Fahrzeuges zur genauen Zeit-Weg-Simulation. Eine Dekoder mit Zeit/Längenmessung könnte das Einmessen automatisieren.
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®)?

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

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.

Realisierung

Booster

Kompatibilität

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.
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

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.
Des weiteren kommt erschwerend hinzu, dass ein Datum, das eigentlich 'atomic' behandelt werden muß (nämlich die Lokadresse) in zwei getrennten Aussendungen übertragen wird. Das Zusammensatzen dieser beiden Teile birgt gewisse Risiken, weil sich durch Fahrzeugbewegungen hier Mischzustände ergeben 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 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 müßte 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.

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.
Die railcom-Spec (V1.2 von 2011) erlaubt Taktabweichungen von bis 2% beim Sender. Das sind bei 20 Bit (entsprechend einer kurzen Nachricht mit 2 Bytes, bestehend aus Start- und Stopbit, 20 * 4 = 80us, davon 2%) bereits 1,6us, d.h. wenn man exakt in der Mitte des Startbits beginnt, ist der Abtaster nach 2 Bytes fast neben dem Bit. Dies unter der Voraussetzung, dass exakt in der Mitte des Startbits begonnen wird. Aber selbst ein Hardware-UART hat da etwa 500ns Ungenauigkeit.
D.h. es können da insbesondere bei längeren Nachrichten Probleme auftreten, auch weil nur ein Stopbit verwendet wird und dem UART die Möglichkeit zum Resync genommen ist.
Das bedeutet: beim Empfänger sind Vorkehrungen erforderlich (z.B. eine Art mitlaufende PLL), um mit der maximalen Taktablage des Senders zurechtzukommen.
Inrush-Problematik am Ende der Cutout
Es gibt (abhängig vom Dekoder) nach der Cutout fallweise einen sehr kurzen und sehr hohen Einschaltstrom. Beobachtet wurden von mir bereits Stromspitzen über 12A (bei H0 oder N-Dekoder!). Dieser hohe Einschaltstrom entsteht primär durch eine zu geringe Abblockkapazität und fehlende Bedämpfung im Dekoder / in der Lok. Wenn die Abblockkapazität zu klein ist, fällt in der Cutoutzeit die interne Spannung des Dekoders zu weit ab und am Ende der Cutout kommt es dann bei fehlender Bedämpfung zu einer extremen Einschaltspitze. Diese Einschaltspitze kann fallweise Booster zu einer Überstromabschaltung bringen.

Weitere Verarbeitung

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.

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.

Rechtliche Situation

Projekte von OpenDCC

Lizenz erhalten

Bedingungen

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.

Wie kompatibel ist railcom?

Leider hat sich durch das Hickhack um die rechtliche Situation und durch die lange Zeit nich verfügbare Spec ein gewisse Inkompatibilität gebildet. Und leider sind auch Ende 2014 noch nicht alle Dekoderhersteller bereit, railcom komplett gemäß Spezifikation zu implementieren. Auch gibt die schleppende Pflege der Spezifikation Anlaß zur Sorge: in der Version 1.2 von 2012 sind Ungereimtheiten enthalten, das wurde bis jetzt (2015) nicht korrigiert. Hier besteht die Chance, dass es erneut zu Inkompatibilitäten kommt.

Spezifikation

Version 1.2

Version 1.3

Die Kodierung des Railcom-ACK hat sich geändert. Nunmehr ist nur noch eine mögliche ACK-Kodierung vorgesehen.
Die 4-Byte POM-Befehl wurde ersatzlos gestrichen. (Anmerkung: sehr zu meinen Leidwesen, ich hatte diese schon implementiert)
Neu dazugekommen ist dynamische Kanalzuweisung (Bit 2 in CV28). Das erweitert die Möglichkeiten der fehlerfreien Anmeldung und Rückmeldung erheblich.
Innerhalb der Railcom-Page (CV-Liste) gab es Änderungen.
Neue Nachrichten im Bereich ID07, insbesonderes Quality of service (Dirty Track, Verschmutzungssensor)
Neue Nachrichten im Bereich ID03, z.B. Betanken

dynamische Kanalzuweisung wurde wieder aus der Spec entfernt.
(Kommentar: über die Gründe kann man rätseln. Technisch wäre es ein elegante Möglichkeit gewesen, die vorhandenen Designfehler beim Channel 1 zu umschiffen und zugleich hätte es einen erheblichen Kundennutzen gebracht. Ich kann die Anwender eigentlich nur ermutigen, bei den Herstellern auf diese Probleme hinzuweisen und Abhilfe einzufordern.)

Tipps zur Anwendung von Railcom

Erkennung im Channel 1: Im Channel 1 sendet eine Lok ungefragt ihre Adresse.
Erkennung im Channel 2: Im Channel 2 darf (und muß!) nur die Lok antworten, die angesprochen wurde.

beiden untersten Bits in der CV28

Probleme:

Channel 1: Wenn zwei oder mehr Loks auf einem Abschnitt stehen, dann kommt es auf dem Gleis zu einer Überlagerung der Datenübertragzng und der Belegtmelder findet im Channel 1 entweder gar nichts mehr (oft bei gleicher Aufgleisrichtung), oder er entscheidet sich für eine Lok (bei entgegengesetzter Aufgleisrichtung). Leider kann es auch vorkommen, dass die Kollision ein gültiges Ergebnis bringt - aber diese Lok gar nicht existiert. Deshalb ist z.B. im GBM16T ein Filteralgorithmus drin, der solche Falschmeldungen aussortiert.
Channel 2: Channel 2 funktioniert nur, wenn die Lok angesprochen wird, also 'fährt', auch wenn es nur Fahrstufe 0 oder Licht ist.

Ich schlage daher dem railcom-Normungsgremium vor, dass eine Ergänzung eingeführt wird: Ein Lokdekoder soll Channel 1 abschalten, wenn er x Pakete auf seine Adresse erhalten hat. Dann wird er ja von der Zentrale angesprochen und braucht den Channel 1 nicht mehr. So könnte die Kollision vermieden werden und der Channel 1 für weitere Loks freigehalten werden.

Checkliste:

Railcom muß in der Zentrale aktiviert sein.
Railcom muß generell im Dekoder aktviert sein (CV29, Bit 3)
Railcom Channel 2 muß aktiviert sein (CV28, Bit 1)
Zentrale muß den Dekoder ansprechen. Eine PC-Software sollte hierzu nach dem Startup an alle Loks auf der Anlage einen Fahrbefehl (z.B. mit v=0) absetzen.

Dekodierung von Railcom-Daten anhand eines Beispiels

Channel 1, kurze Adresse, Wert 11:
```
Empfangsdaten:
  153 = 0x99 = 10011001
  150 = 0x96 = 10010110
```
Diese Datenbytes haben je 4 Einsbits, sind also korrekt kodiert. Im ersten Schritt macht man die 4/8-Kodierung rückgängig (z.B. mit Hilfe einer Referenz-Tabelle) und erhält:
```
  153 = 0x99 = 10011001 := 0x08 = 00001000
  150 = 0x96 = 10010110 := 0x0B = 00001011
```
Von jedem rückübersetztem Byte sind nur die untersten 6 Bit gültig, die obersten beiden Bits jedes Byte sind ungültig. Diese 2 Bytes liefern also 12 Bit Nutzbits (=payload). Zur Analyse werden dann diese 12 Bit in 4 Bit 'Identifier' und 8 Bit 'Wert' aufgeteilt:
```
  00001000 -- 00001011 wird zu: 001000.001011, anders aufgeteilt wird es zu: 0010.00001011
```
Es handelt sich also um ID02 (kommt von 0010), Wert = 00001011 = 0x0B = 11 (dez). ID02 bezeichnet den unteren Teil der Adresse.
Channel 1, lange Adresse, Wert 201:
```
Empfangsdaten:
  150 = 0x96 = 10010110
  149 = 0x95 = 10010101
```
Diese Datenbytes haben je 4 Einsbits, sind also korrekt kodiert. Im ersten Schritt macht man die 4/8-Kodierung rückgängig und erhält:
```
  150 = 0x96 = 10010110 := 0x0B = 00001011
  149 = 0x95 = 10010101 := 0x09 = 00001001    
```
Extrahieren der Payload und Aufteilen der 12 Bit Payload in 4 Bit Identifier und 8 Bit Wert liefert:
```
  00001011 -- 00001001 wird zu: 001011.001001, das wird zu: 0010.11001001
```
Es handelt sich also um ID02, Wert = 0xC9 = 201.