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

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.

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. Deshalb habe ich mir die Mühe gemacht, eine Lokdekoder-Übersicht zu erstellen, welche Dekoder wo 'patzen' bzw. konform zur publizierten Spezifikation sind. 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
    Im Mai 2012 wurde die Spezifikation V1.2 (als pdf) auf der Webseite von Lenz veröffentlicht.

    Version 1.3
    Die erste Publikation der V1.3 erfolgte im Herbst 2014 auf tams-online.de und wurde aber kurz darauf wieder von der Seite entfernt. Folgende Änderungen fanden sich:
    • 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
    Irritierend ist, dass diese Veröffentlichung wieder zurückgezogen wurden und seitdem keine weitere Veröffentlichung erfolgte. Es scheint, als gäbe es Blockadehaltungen hinsichtlich neuer Funktionen.

    [Update]: Im Herbst 2015 wurde die Spezifikation V1.4 bei Lenz veröffentlicht. Wesentliche Änderungen gegenüber 1.3:
    • 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

    Um eine Lok per Railcom detektieren zu können, gibt es zwei Möglichkeiten:
  • 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.
  • Ob und in welchem Channel eine Lok sendet, wird durch die beiden untersten Bits in der CV28 festgelegt.

    Einige Belegtmelder am Markt arbeiten nur mit der Channel 1 Methode, die Belegtmelder GBM16T arbeiten mit beiden Methoden und können so bis zu vier verschiedene Loks auf einem Abschnitt erkennen und melden.

    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.

Links