– Wie das WLAN zur Bahn kam –
Zum Ausprobieren und Testen von RailCom Detektoren, RFID Lesern, S88-Scannern und Decodern aller Art habe ich mir vor einigen Jahren einen sogenannten Hosenträger gebaut. Der Hosenträger beinhaltet 4 Stumpfgleise in einer „H“ Anordnung, die mit 4 Weichen und einer Kreuzung so verbunden sind, dass ein Fahrzeug von jedem Stumpfgleis immer beide gegenüberliegenden Gleise erreichen kann. Das Ganze ist auf einem Seitenteil eines „IVAR“ Regals aufgebaut und deswegen gut transportabel.

Fahrzeug-ID über RFID und S88 einlesen
Zunächst wurden die Fahrzeuge mit 3 RFID-S88-Light Lesern über einen selbstgebauten S88 Scanner auf der Basis Arduino Uno erkannt. Für jeden RFID Leser wurden 16 Bit (ein S88 Modul) eingelesen und im Rocrail Programm mittels Script wieder zu einer binären 14-Bit Fahrzeugadresse kombiniert. Der Scanner hat neben RFID auch die Standard Belegtmeldungen und Gleiskontakte verarbeitet und über USB unter Verwendung des HSI Protokolls an den PC weitergegeben.
RFID über Tams RC-Link
Um auf das (langsame und dadurch störanfällige) Script verzichten zu können, war der nächste Schritt die Verwendung des Tams RC-Talk Protokolls. Eigentlich ist das Protokoll dazu gedacht RailCom Information, also Decoder-Adresse und Aufgleisrichtung der Lok an den PC weiterzugeben, da aber meine RFID-S88-Light eben auch diese Informationen liefern, habe ich das Protokoll für RFID verwendet. RFID und Standard S88 mussten nun getrennt werden. Es gab jetzt also zwei s88-Scanner, einen mit HSI Ausgabe für die Standard-Rückmelder und einen mit RC-Talk Ausgabe für RFID. Beide Scanner haben über USB mit dem PC kommuniziert. Entsprechend wurden im Modellbahnsteuerprogramm 2 „Zentralen“, eine vom Typ „RC-Link“ und eine vom Typ „HSI88“ angelegt.
RFID und RailCom über RC-Talk
Der nächste Schritt war die direkte Kommunikation im RailCom Format mit dem Tams RC-Link Baustein. Meine RFID Leser wurden auf der Basis eines Arduino Nanos neu gebaut und mit einer RS485 Schnittstelle versehen. Dadurch konnte ich meine RFID Leser genauso wie und in Verbund mit Tams RCD-1 RailCom-Detektoren an den RC-Link anschließen. Durch die Verwendung des gleichen Gehäuses, gleiche Klemmenbezeichnung und Adressierungsmechanismus konnte ich 4 RFID Leser und 4 RailCom Detektoren RCD1 an einem gemeinsamen RS485 Bus betreiben und die Lok- und Richtungsdaten in den PC einlesen.
Mittlerweile hatte die Menge an Versorgungskabeln und USB Datenleitungen stark zugenommen und machte einen Transport und die schnelle Wieder-Inbetriebnahme des Testmoduls immer schwieriger. Da waren ja außer den Rückmeldebausteinen auch noch die DCC Zentrale und das Notebook anzuschließen. Weil das Notebook mit nur 2 USB-Ports ausgestattet ist, musste es mit einem USB-Hub erweitert werden.
Dann kam WLAN
Mitte 2018 sollten die diversen USB Datenverbindungen zum PC durch eine WLAN-Verbindung ersetzt werden. Die Offenlegung des Roco Z21 LAN Protokolls legte die Verwendung für meinen Zweck nahe. Im PC musste dann „nur“ eine (zusätzliche) Z21 Schnittstelle für die Modellbahnsoftware angelegt werden. Das war zumindest die Idee. Begonnen wurde mit dem Bau eines RFID Lesers auf der Basis eines Lolin NodeMCU V3, einem verbreiteten ESP8266 Entwicklungsboard mit integriertem WLAN.
Bidirektionaler Datenverkehr
Ich stellte bald fest, dass nicht nur Informationen vom RFID Leser zum PC fließen, sondern der PC über das Z21 Interface auch Informationen sendet, bzw. Anfragen an die nun virtuelle Z21 richtet. Diese Anfragen allerdings müssen vom WLAN Modul auch beantwortet werden, damit der PC nicht aufgibt, weil da keine Z21 Zentrale reagiert. Anfangs wurde die Beantwortung der Fragen nach Gerätezustand, Seriennummer und Firmware-Stand der „Z21“ in den Code des RFID Lesers integriert, bis dann der 2. und 3. Leser und der S88 Scanner auf WLAN umgebaut wurden. Es sollte natürlich nur ein einziges Sensormodul des Hosenträgers diese Anfragen beantworten. Auch wurde es zu aufwändig, jetzt 4 virtuelle Z21 Zentralen in der Software anzulegen, für jedes Sensormodul eine. Nach wenigen Tagen wurde deswegen ebenfalls auf der Basis des ESP8266 Entwicklungsboards ein „Gateway“ entwickelt, das alle allgemeinen Aufgaben einer virtuellen Z21 übernimmt. So meldet das Gateway neben einer fiktiven Seriennummer „1234567“ und Firmware-Stand sogar eine virtuelle „Temperatur“ und eine virtuelle „Gleisspannung“.
Gateway
Ein Gateway (auf Deutsch Tor) hat zwei Seiten. Auf der Seite der Sensormodule bietet es ein WLAN „SENSORNETxx“, in das sich die Sensorknoten einloggen. Alle hier eintreffenden Meldungen, Belegtmeldungen, Lokomotiv-Codes, usw. werden vom Gateway mit einem Broadcast auf die andere Seite zu den Client-PCs weitergeleitet. So können mehrere Clients die Sensorinformationen gleichzeitig verarbeiten.
Die Anfragen, die nicht einen spezifischen Sensor (oder Aktor) betreffen, werden vom Gateway abgefangen und die Antwort an den anfragenden Client (PC) zurückgeschickt. Meldungen und Anfragen an Sensorknoten werden vom Gateway in das „Sensornetz“ weitergegeben und werden dort vom Sensor bearbeitet oder beantwortet.

Nach diesem ersten Umbau auf WLAN Sensoren (S88, 2 x RFID für Lok-Code und Aufgleisrichtung, 1 x RFID für 2 x Lok-Code) blieben nur noch die USB-Kabel für die 5V Versorgung der ESP Entwicklungsboards. Der PC ist vom Kabelsalat völlig befreit und kommuniziert zu 100 % nur noch über WLAN. Um auch die Versorgungskabel am Hosenträger zu eliminieren, habe ich einen Step-Down Wandler eingebaut, der die digitale Gleisspannung in eine 5 V Gleichspannung transformiert und damit alle Entwicklungsboards versorgt.
WLAN Rückmelder auf den Modellbahntagen in Erkrath
Für eine Modellbahnausstellung im Lokschuppen Hochdahl (EHEH) sollte das Thema „Rückmelder auf der Modellbahn“ vertieft werden. Dabei kamen u. a. Themen wie S88, RailCom, RM Bus und CAN Bus auf den Tisch. Auch der Unterschied zwischen einer Punktmeldung und einer Block-Belegtmeldung wurde gezeigt. Schwerpunkt war jedoch der automatische Blockbetrieb auf einem sogenannten „Hundeknochen“. Hier wurde auf der einen Seite des Knochens der Einsatz von Roco / Fleischmann RailCom Rückmeldern 10808 im K-Gleis vorgeführt und auf der anderen Seite im TRIX C-Gleis die drahtlose Belegtmeldung über Stromerfassung.
Die SMD-Stromerfassungsmodule „RMEM2xI“ für 2 Rückmeldekanäle waren in der Bettung des Trix C-Gleises eingebaut und somit für das Publikum nicht sichtbar. Ein Teil der C-Gleise wurde sogar auf einen normalen Tisch verlegt. Der halbe Hundeknochen mit den C-Gleisen wies keinerlei sichtbare Verdrahtung auf, weder auf noch unter den Tischen und Modulplatten. Eine im Gleis versteckte Ringleitung brachte die Gleisspannung zu den Rückmeldemodulen und Decodern. Das TRIX C-Gleis wurde übrigens mit den Märklin E 520050 Mittelleiter-Kontaktfedern zu einem Gleis mit Energie-Bus (Ringleitung) umgerüstet. Ein rares Ersatzteil, das aber exakt auf die Plastiknasen der Trix C-Gleise passt.
Eine (richtige) Z21 versorgte die Gleisspannung für die Loks und die Weichen. Die zugehörigen Weichendecoder bezogen die DCC Information und die Energie aus dem Gleis und waren ebenfalls in der Bettung versteckt. Es wurden 4 WLAN-Rückmeldebausteine verbaut, die mit insgesamt 8 Meldern 4 Blocks überwachten (4 Bremsabschnitte und 4 Halteabschnitte).

Der automatische Blockbetrieb wurde mit Rocrail gesteuert. Die Funktion der 2-Bit WLAN Rückmelder wurde mit WIN-Digipet gezeigt, funktioniert aber auch mit iTrain und Rocrail.
Auch einfache WLAN-Rückmelder

Abseits des Hundeknochens wurde gezeigt, wie mit einfachsten Mitteln ein WLAN-Rückmelder aufgebaut wird. Der eigentliche Sensor war ein Märklin Schaltgleis. Das ist ein Schalthebel, der vom Schleifer eines Fahrzeuges nach links oder rechts umgelegt wird und dabei einen von zwei Mikroschaltern betätigt. Das Schaltgleis übermittelt also die Betätigung des Hebels und die Fahrtrichtung des auslösenden Fahrzeugs. Die Information gelangt vom Schaltgleis über Draht in das ESP Entwicklungsboard, von dort über WLAN zum Gateway und von dort in den PC. Der einfachste WLAN-Rückmelder besteht aus einem Wemos D1 Mini WLAN Entwicklungsboard und braucht an externen Komponenten lediglich 2 10 kOhm Widerstände. Er kann über einen USB-Powerpack, ein USB-Ladegerät oder über einen USB-Port des PCs und einem Micro-USB-Kabel mit 5 V versorgt werden. Mit dem Freeware Programm ESP8266Flasher.exe wird die Firmware geladen und das Modul anschließend über ein Web-Interface konfiguriert. Im Normalfall wird nur die gewünschte Adresse der Rückmelder verändert. Braucht man mehr Details über Status und Konfiguration des Rückmelders, kann man mit einem Terminal Programm online gehen (über USB und emulierten COM-Port mit 115200 Baud). Neben dem Serial Monitor der Arduino Entwicklungsumgebung nutze ich dafür auch das Freeware Programm HTerm.exe.
Für das Gateway wurde ebenfalls ein Wemos D1 Mini Entwicklungsmodul verwendet. Es braucht keine externen Komponenten und sogar die mitgelieferten Stiftleisten sind eher hinderlich als nützlich. Mit dem ESP8266Flasher lädt man das passende .BIN File auf das Modul.
Da das Sensorgateway mit dem PC kommunizieren soll, muss es sich über WLAN mit demselben Router verbinden, an dem auch der Modellbahn-PC über WLAN oder LAN hängt. Um die betreffende SSID, das Password und die gewünschte IP-Adresse des Gateways einzugeben, stellt das Gateway ein Web-Interface zur Verfügung. Der Modellbahn-Router sollte nicht mit dem Internet verbunden sein. Nur zur Not kann der hausinterne Internet-Router, z. B. die Fritz!Box, vorübergehend verwendet werden. Da aber Gateway und WLAN Sensormodule offene Netzwerke beinhalten, würde man die Datensicherheit des Heimnetzes damit aushebeln.
Ein dedizierter Modellbahn-Router, wie der mitgelieferte TPLink Router der Z21, ist immer zu empfehlen. Preisgünstig und optimal geeignet ist auch der baugleiche TPLink TL-WR840N Router. Man kann sogar eine DR5000 oder einen Raspberry Pi als Router verwenden. Weil nicht alle Router die Konfiguration einer festen IP-Adresse zulassen, steht auch DHCP zur Verfügung.
Das Sensorgateway kann genauso wie die Sensormodule mit einem Terminalprogramm beobachtet werden. Es zeigt an seinem USB-Port alle konfigurierten Daten und Information zu der verwendeten Hard- und Software. Wenn das Gateway die Verbindung mit dem Router erfolgreich aufgebaut hat, werden alle eintreffenden Z21 Nachrichten aus dem PC-Steuerprogramm und aus dem Sensornetzwerk protokolliert.
Nachbau WLAN Sensormodule und Gateway
ACHTUNG: Das Bessere ist des Guten Feind. Mit der „NextGen“ Firmware der nächsten Generation kann die hier beschriebene Hardware einfacher und mit weniger Aufwand betrieben werden. Die NextGen Firmware bietet:
- Die Reichweite wird nur bestimmt durch die WLAN-Reichweite des Routers. Erweiterbar über Repeater, Verstärker und dergleichen. Ausgedehnte, kabellose, aber automatisierte Tisch- und Teppich-Bahnen sind nun einfach realisierbar.
- Kabellose Firmware Updates, Stichwort „OTA“
- Automatische Adressvergabe für alle Sensoren und Aktoren über DHCP
- Keine Begrenzung auf 8 Sensor-/Aktormodule pro Gateway
- Simple (3 Eingaben), optional auch umfangreiche und komfortable Konfiguration über Web-Interface
- Wegfall der WLANs der Aktor- und Sensormodule. WLANs nur für die Erstinbetriebnahme neuer Hardware (weniger Elektro-Smog).
- Einheitliches, sehr informatives Web-Interface, unabhängig von der Plattform (PC, Tablet oder Smartphone)
Mehr Information zu der nächsten Generation der WLAN Rückmelder gibt es in einem separaten Blog unter https://Mobatron.4lima.de.
© 2015 – 2023 Gerard Clemens Letzter Update 29.07.2023
9. August 2022 um 13:25 Uhr
Hallo Gerard,
Ist die obige Fritzing Darstellung des „Aufbau auf einem Steckbrett eines hochohmigen Masse-Sensors mit 2 Eingängen ähnlich S88“ eine neue Schaltungsvariante? Diese unterscheidet sich doch sehr von früher publizierten Schaltungen. Was mich auch stutzig macht, ist die Schaltung des Kondensators gegen Masse, was bei Betätigung eines Tasters zur sofortigen Entladung führt.
10. August 2022 um 11:38 Uhr
Hallo Ulrich,
ja Du hast recht. Die Schaltung wurde verändert. In der ersten Variante haben die 100 kOhm und der 10 kOhm Widerstände noch einen Spannungsteiler gebildet. Dann wurde die Schaltung verbessert, indem der 10 kOhm Widerstand in Reihe mit dem Eingangsport gelegt wurde, sodass jetzt die Logikpegel am Port näher an den spezifizierten Pegel liegen. Dabei wurde der 22 nF Kondensator übersehen. Der gehört jetzt eigentlich auch an den Eingangsport des ESP8266.
An der Funktion ändert das aber nicht viel. Die kurze Zeitkonstante 10 k und 22 nF kommt beim „belegt“ Melden zum Tragen, die längere Zeitkonstante 100 k und 22 nF beim „frei“ Melden. In der abgebildeten Schaltung ist die kurze Zeitkonstante 0 und die lange Zeitkonstante sogar noch ein Ticken länger. Übrigens sind die Kondensatoren nicht mehr unbedingt nötig, weil es einen digitalen Filter in der Firmware gibt. Es geht immer nur darum, Belegtmeldungen sofort zu erkennen und Freimeldungen zu verzögern, weil sie auf Kontaktprobleme und Prellen beruhen können.
Grüße
Gerard
10. August 2022 um 18:38 Uhr
Danke, dann werde ich mich mal den Lötkolben anwerfen….
13. September 2020 um 14:36 Uhr
Hallo Gerard,
Den Artikel habe ich mit Interesse gelesen. Zufällig gefunden!
Da ich ein Projekt mit ähnlichen Zielen aber ganz anderer Technik verfolge, würde ich gern mal telefonieren.
Du könntest mir Deine Rufnummer per Email schicken, die gebe ich hier ja an.