Warum sollte man über­haupt RFID auf der Mo­dell­bahn ver­wen­den? Wenn man wis­sen will, wel­ches Fahr­zeug sich auf wel­chem Gleis­ab­schnitt be­fin­det, kann man doch Rail­Com ver­wenden.
Si­cher, Rail­Com setzt aber eine ge­eig­ne­te In­fra­struk­tur vor­aus, die na­tür­lich für neu­ere An­la­gen und neu­en Fahr­zeu­gen im­mer mehr zum Stan­dard wird. Sie ist aber längst noch nicht über­all vor­han­den. Das fängt bei der Zen­trale und den Boos­tern an, die die so­ge­nann­te Aus­tast­lü­cke be­reit­­stel­len müs­sen, damit Rail­Com über­haupt funk­tio­niert. Nicht nur müs­sen die Fahr­zeu­ge, die er­kannt wer­den sol­len, einen ak­tu­el­len Rail­Com-fä­hig­en DCC De­co­der ha­ben, auch die Gleis­an­lage muss für Rail­Com ge­eig­net sein. Eine Tren­nung in Gleis­­ab­schnit­ten und der Ein­satz von Rail­Com De­tek­to­ren für je­den die­ser Gleis­ab­schnit­te ist not­wendig. Für Be­sitzer ei­ner ana­lo­gen oder ei­ner äl­te­ren di­gi­ta­len An­la­ge be­deu­tet die Au­to­ma­ti­sie­rung mit­tels Rail­Com also erst ein­mal ei­nen Um­bau der An­la­ge und der Fahr­zeu­ge. Dann kom­men die In­vestierungen in De­co­der, De­tek­tor­en, Boos­ter und even­tu­ell auch eine neue Zen­tra­le dazu.
Die Ver­wen­dung von RFID zur Er­ken­nung von Fahr­zeu­gen ist da­ge­gen we­ni­ger an­spruchs­voll:

  • RFID funktioniert bei analogen und di­gi­ta­len Mo­dell­bah­nen in allen Maß­stä­ben und al­ler Mar­ken.
  • RFID braucht keine Trenn­stellen (Gleis­ab­schnit­te)
  • Mit RFID kann man Loks und Wa­gen er­ken­nen, kein De­co­der er­for­der­lich.
  • RFID Tags sind günstig
  • RFID Tags sind ohne Umbau ein­fach un­ter je­dem Fahr­zeug an­zu­brin­gen.
  • Mit RFID kann man auch die Auf­gleis­rich­tung er­ken­nen
  • Der erforderliche RFID Leser kann aus we­ni­gen preis­wer­ten Kom­po­nen­ten selbst ge­baut wer­den.
  • RFID kann auch zusammen mit Rail­Com ver­wen­det wer­den
  • Der RFID Tag kann außer einer Fahr­zeug-Iden­ti­fi­ka­tion auch zu­sätz­liche In­for­ma­tio­nen spei­chern.

Im Vergleich zu RailCom hat RFID aber auch ei­ni­ge Nach­tei­le:

  • RFID löst eine Punkt­mel­dung aus, keine Be­legt­mel­dung und ist in die­sem Punkt ver­gleich­bar mit Gleis­kon­tak­ten oder Reed­kontakten. Die Mel­dung er­folgt nur in dem Mo­ment wo das Fahr­zeug über den Le­ser fährt.
  • RFID er­for­dert eine An­ten­ne im Gleis, die je­doch re­la­tiv leicht an­zu­brin­gen ist.
  • Für die Er­ken­nung der Auf­gleis­rich­tung (wo ist Füh­rer­stand 1?) sind 2 Lese­stel­len er­for­der­lich

Unser erster RFID Leser für die Modell­bahn be­stand aus ei­nem Ar­dui­no Uno mit ei­nem Shield für den An­schluss eines RFID-RC522 Lese­mo­­duls (Ti­tel­­bild). Der Shield hatte zur Über­tra­gung der ge­le­se­nen In­for­ma­tion eine S88 Schnitt­stel­le (S88-N IN und OUT).
Als Information sollten anfänglich 2 Byte aus der 5 oder 7 Byte langen UID (Unique Identifier) des Tags ge­sen­det wer­den. Es stell­te sich heraus, dass das recht schnell zu Du­pli­ka­ten führt. Des­we­gen gab es auch eine Variante, die 4 Byte sendet. Aber auch hier gab es Ein­schrän­kung­en bei der Aus­wahl der Tags. Eine dritte Variante berechnete aus der kompletten UID eine CRC 16, von dem die niederwertigen 15 Bit für die Fahrzeug ID und 1 Bit als Trigger für die CS2 oder die Modellbahnsoftware dienten.
Diese Entwicklung wurde in der DiMo 03/2015 veröffentlicht.


Abbildung 1 – Professionell hergesteller RFID-S88-Light Shield, nun für 2 Lesemodule.

Es stellte sich heraus, dass die Rechenleistung des Arduino Uno auch für den Betrieb von zwei (und mehr) RFID-RC522 Lesemodule ausreicht. Die 16 Bit CRC aus der Tag-UID wurde verlassen und in Anlehnung an die Länge der DCC Adressen auf eine 14 Bit CRC re­du­ziert. Nun konnte eine 14-Bit Fahrzeug ID, die Auf­gleis­rich­tung und ein Strobe-Bit mit einem 16 Bit Wort über­tra­gen werden. Um nicht DCC „kompatible“ Fahrzeug IDs zu ver­meiden, wurden diese auf IDs von 1 bis 10239 normalisiert. Es bestand bei diesem und auch beim CRC 16 Ver­fahren eine sehr geringe Chance, dass zwei verschiedene Tags dieselbe CRC er­zeu­gen. In dem Falle sollte einfach ein anderer Tag Verwendet werden. Um nicht mit unterschiedlichen Fahr­zeug-IDs und Fahrzeugadressen hantieren zu müssen, wurden meistens die Fahrzeug-IDs auch als Adresse verwendet.
Die Weiterverarbeitung der S88 Information in der CS2, besonders die Wiederherstellung der 14-Bit Fahrzeuginformation aus den 14 einzelnen Bits war aber ziemlich aufwändig und für den Prozessor der CS2 sehr belastend.
Als Alternative zur Anzeige im Display der CS2 sollte die Fahrzeug-ID in einem Modellbahn­pro­gramm angezeigt werden. Mit einem geliehenen Littfinski HSI88 Scanner wurden die Fahrzeug-IDs in den PC eingelesen. Ein Script im Rocrail Programm war nun in der Lage, die 14 einzelnen Bit der RFID Meldungen wieder in eine Fahr­zeug­num­mer zu verwandeln und im belegten Block anzuzeigen. Waren allerdings viele der 14 Bits logisch „1“ , kam manchmal auch das Script zeitlich an seine Grenzen.


RFID auch auf LocoNet

Parallel zu meinen RFID Ent­wick­lun­gen mit S88 als Schnitt­stel­le gibt es auch eine Ent­wick­lung von meinem DiMo Ko-Au­tor Robert Friedrich. Er ent­wick­el­te ein uni­ver­sel­les Modul COL13,56 mit 2 RFID Lesern und verschiedenen Schnittstellen wie LocoNet und RS485. Der erste Artikel dazu wurde in der DiMo 1/2016 veröffentlicht. Hier wird u.a. die ganze UID der gelesenen Tags über LocoNet an das Mo­dellbahn­steuer­pro­gramm Rocrail gesendet.
Dieses Projekt und die Wei­ter­ent­wick­lung für an­de­re Sys­teme als Loco­Net ist auf seiner „Converts“ Web­seite be­schrie­ben, die auch Links auf die da­zu­gehö­ri­gen DiMo Ar­ti­kel der Ver­lags­ge­sell­schaft Bahn ent­hält.

Abbildung 2 – COL13,56 RFID Leser mit Arduino Nano und LocoNet Schnittstelle

Direkte Übertragung

Der nächste Entwicklungsschritt bestand darin, die doch recht mühsame und anfällige Wandlung der 16 oder 14 einzelne S88 Bits in eine Lok-ID und Aufgleisrichtung zu umgehen. Hier bietet sich das RC-Talk Protokoll von Tams an, das von Herrn Tams für die private Verwendung freigegeben wurde. Das Protokoll wird im Tams RC-Link Modul für die Kommunikation von RailCom Daten zwischen Detektoren und PC verwendet.
Der RFID-S88-Light Shield wurde bei dieser Wei­ter­ent­wick­lung erst einmal bei­be­halten. Als Schnitt­stel­le zum PC dien­te nun der USB-Port des Arduino Uno. Das auf dem Shield vor­han­de­ne S88 In­ter­face wurde nicht ver­wen­det. Der Arduino schickt in diesem Projekt die Fahrzeug-ID (normierte CRC14, 1 – 10239) über USB Kabel direkt in den PC. Dabei wird das RC-Talk Pro­to­koll verwendet und so sieht der RFID Leser aus Sicht der PC Software aus wie ein RC-Link Modul. Mit dem RC-Link-Tester, ein kleines Dienstprogramm von Tams, kann die Funktion des RFID Lesers getestet werden. Je nach dem, welcher USB Baustein auf dem Arduino verbaut ist, muss das CTS Bit im Tester abgewählt werden. Klappt der Test, kann in der Modell­bahn­soft­ware ein TAMS RC-Link Modul angelegt werden, das mit den gleichen Parametern wie der RC-Link-Tester eingestellt wird.
Unser RFID Leser emuliert zwar den RC-Link, kann aber dem PC nur bis zu 2 RFID Kanäle an­bieten und nicht die 24 RailCom Rückmeldungen, die beim Original möglich sind. Wenn man beide RC522 Lesermodule für die Erkennung der Fahrzeug IDs verwendet, bietet das Modul 2 von 24 möglichen Kanälen. Wird zusätzlich die Aufgleisrichtung ausgewertet, kann von den 24 Kanälen nur ein einziger verwendet werden. Aber das Experiment zeigte: das ist der richtige Weg! Leider hat eine Zentrale wie die CS2 mit RC-Link und RailCom nichts am Hut und ist die Lösung nur einem PC vorbehalten.


RFID-S88-RC-Talk

Abbildung 3 – S88 Scanner, der die CRC14 Fahrzeuginformation im RC-Talk Format über USB dem PC übergibt.

Jetzt lag es nahe, ebenfalls bis zu 24 RFID Leser einzubinden. Wieder bot sich die Wei­ter­ver­wen­dung des RFID-S88 Shields an, dieses mal jedoch mit Verwendung der S88 Schnittstelle. Ein spezieller S88 Scanner wurde gebaut. Er wurde aus einem bereits früher ent­wickelten S88 Scanner mit HSI 88 Protokoll abgeleitet (Abbildung 3). Dieser Scanner sollte die RFID Leser über S88 einlesen und mit RC-Talk Protokoll über USB an den PC weiterleiten. Das war eine reine Software-Entwicklung, die 2017 fertiggestellt wurde. Ein zweiter, bau­glei­cher Scanner mit der HSI88 Firmware übernimmt die Bedienung der Standard S88 Rückmelder. Diese Konstruktion konnte nun wirklich befriedigen und wurde bis zur Einführung der WLAN Kommunikation beibehalten. Abbildung 3 zeigt den Scanner mit dem S88-N Anschluss, einem 6-poligen S88 Anschluss und der Mini-USB Buchse, die vorne aus dem Gehäuse herausschaut.


Gemeinsam mit RailCom

Abbildung 4 – Zwei 2-fach RFID Leser im gleichen Gehäuse wie der TAMS RCD-1 RC Detektor. In der Mitte befindet sich der Arduino Nano. Unter dem Nano findet der RS485 Treiber Platz. Die weißen Stecker rechts oben sind die Anschlüsse für die beiden RFID-RC522 Lesemodule. Der schwarze Klotz davor ist der Schaltregler, der aus der Gleisspannung die 5 V für den Arduino erzeugt.

Ein weiteres RFID Ex­pe­ri­ment be­stand nun darin, die RFID Leser direkt – mit RailCom Pro­to­koll über RS485 – mit ei­nem phy­si­ka­li­schen Tams RC-Link Modul zu ver­bin­den, genau so als wären es RCD-1 RailCom De­tek­toren. Diese Ent­wick­lung wurde nun 2-glei­sig gefahren. Auf dem COL13,56 Modul ent­wickelte Robert Friedrich seine Lö­sung wäh­rend ich im Ge­häuse des TAMS RCD-1 RailCom Detektor einen Ar­dui­no Nano für die An­steuerung der bei­den RFID Lese­module, ein 5 V Schalt­netzteil, einen RS485 Trei­ber, Tas­ter, Led und Klemm­leiste unter­brachte. Ich nannte das Modul „RFID-RC“ (Abbildung 4).
Neu in diesem Projekt war die Verwendung des bislang nicht verwendeten frei beschreibbaren NTAG2 Speichers auf den RFID Tags. Wir verständigten uns auf ein Format für die Fahrzeug-ID und weiteren Informationen und konnten uns von UID, CRC16 und CRC14 verabschieden. Jetzt war es möglich, einen beliebigen 15 Bit breiten Code in den Tag zu schreiben (1 – 31267). Das war in sofern ein Vorteil, als dass man nun die Fahrzeugadresse, die RFID Kennung und den Fahrzeugtyp (Baureihe) in Einklang bringen konnte. Meine Baureihe 64 hatte die DCC Adresse 6402 und auch die Fahrzeug-ID auf dem Tag lautete nun 6402. Kann man sich halt besser merken.
Auf dem COL13,56 gibt es Dank Op­to­kop­pler eine Tren­nung von Gleis­span­nung und RS485 Bus. Mein Mo­dul ist nicht iso­liert und Ver­drahtungs­fehler n den Klemmen führen un­weiger­lich zur Zer­stö­rung des RS485 Trei­bers. Die Klem­men­be­zeich­nun­gen für das Gleis­signal und für den RS485 Bus sind vom RCD-1 über­nom­men. Bei­de Ge­rä­te, RCD1 und RFID-Leser kön­nen be­lie­big ge­mischt wer­den. Ich ha­be mei­ne Firm­ware so ge­schrie­ben, dass sie auf dem COL13,65 und auf mei­ner Hard­ware läuft. Es gibt nur 2 Vari­anten:

  • 1 oder 2 RC522 Leser, eine Fahrzeug ID pro RC522 Lesemodul
  • mit 2 RC522 Lesern für eine Fahrzeug-ID mit Aufgleisrichtung

Die Geräte waren ebenfalls von 2017 bis zur Einführung der WLAN Rückmeldungen ohne Probleme im Einsatz.


Mit WLAN ohne USB

Noch in der Erprobung ist bei mir die RFID Fahrzeugerkenung und -Meldung mit ESP8266 über WLAN. Die vielen USB-Kabel zur Anlage machten einen USB-Hub notwendig und waren mit ein Grund für diese kabellose Entwicklung. Das Prinzip der RFID Leser ist geblieben, es wurde lediglich von der Arduino auf die ESP Plattform portiert. Man kann also nach wie vor mit 2 RC522 Lesemodulen entweder 2 Fahrzeug-IDs oder 1 Fahrzeug-ID mit Aufgleisrichtung lesen. Beide Varianten sind bei mir im Einsatz und haben sich bis jetzt bewährt.


© 2020 Gerard Clemens – letzte Aktualisierung 10.4.2020