Da wir gerade an der Automatisierung unserer Gartenbahnanlage arbeiten, kam nun die Frage auf, wie man am effektivsten und günstigsten die Belegtstatus rückmeldet und sich dabei noch alle Möglichkeiten der Rückmeldungen offen halten kann. S88 ist nicht besonders übertragungssicher, nicht besonders schnell und vor allem gänzlich unflexibel. LocoNet ist zwar gut und schön, aber die die Anzahl der Hersteller ist arg begrenzt und deshalb legt man sich schnell fest. Außerdem ist die Vorgabe durch die Netz-Infrastruktur sehr streng. Außerdem gibt es noch viele andere Rückmeldesysteme, die allerdings eher Insellösungen sind (LENZ-Bus – tolles Ding).
unser Pflichtenheft für ein Rückmeldesystem ist also etwas universeller und umfangreicher und wächst ständig.

Wenn man über den Tellerrand schaut, gibt es diverse Kommunikationsnetzwerke, die als Basis für ein Rückmeldesystem taugen. Hierbei sollte man aber schauen, wie groß der technische Aufwand ist, diese für eine Modellbahn nutzbar zu machen. Da mittlerweile schon jede elektrische Zahnbürste aus irgendeinem Grund mit dem Internet verbunden sein muss, damit man seine Facebookgemeinde am Putzerfolg teilhaben lassen kann und während des Gurgelns sich von anderen liken oder disliken oder anfeuern lassen muss, sind Netzwerkkomponenten wie Sand am Meer vorhanden. TCP ist ein tolles Protokoll, um jede Menge Daten zu übertragen und zu empfangen. Es wäre bestimmt für eine Rückmeldung am Gleis uneingeschränkt zu benutzen, und, auch wenn es hier nicht gern gehört wird, geht das auch sehr gut per Funk.
Ich bin mir sicher, dass uns eine Netzinfrastruktur (kabelgebunden oder WLAN) zum Ziel geführt hätte, allerdings wäre es doch etwas doppelmoralisch gewesen, wenn man LocoNet für zu aufwändig in Infrastruktur und Peripherie erklärt und dann eine Netzwerkverkabelung mit TCP/IP Anwendungsschicht als die Lösung präsentierte.
Außerdem: Man ahnt es bereits, ich wollte wieder irgend etwas selber bauen und, auch wenn der Aufwand überschaubar ist, sind die Ansprüche an IP Netzwerke einfach zu hoch und nicht praktisch: Zu teuer, zu komplex und viel zu groß. Man schießt mit Kanonen auf Spatzen.

CAN!

klingt lustig, aber wer ist dieser CAN? Der Freund von Barbie? – Nein, der ist nicht gemeint. CAN ist ein Industriebusstandard, der Hauptsächlich für Steuerungsaufgaben in größeren Anlagen, oder – daher auch eher bekannt – in der Automobiltechnik weit verbreitet ist. Der CAN-Bus ist ein sog. Multimaster-Bus, der sich dadurch auszeichnet, mit sehr geringem technischen Aufwand betrieben werden zu können und außerdem sehr fehlersichere Übertragungen möglich macht. Hinzu kommen vergleichsweise gute Übertragungsraten auf schier unendlichen Signalstrecken (jenseits der 100 Meter ist auch nicht schlimm). Was den CAN-Bus genau technisch ausmacht, werd ich bei Interesse später nochmal zusammentragen, aber das würde im ersten Moment hier etwas den Rahmen sprengen.
Insgesamt klingt es doch nach einem idealen System für unsere Modellbahn. Die Bauteile sind günstig, die Verkabelung ist geradezu banal (einfach nur zwei Leitungen), und die Bandbreiten sind selbst für größere Datenmengen ausreichend ( na klar, 4K Video wird man nicht streamen können).
Es haben sich schon diverse Leute Gedanken zu dem CAN-Bus auf der Modellbahnanlage gemacht, aber alle machen einen entscheidenen Fehler: Sie wollen Geld damit verdienen. Da mir die vergangenen Jahre mit den Spaßbahndecodern so viel Spaß gemacht haben, wollte ich aber lieber wieder experimentieren, und wenn es nicht funktioniert lieber daraus lernen. Daher haben wir uns zusammengesetzt und mit spitzem Bleistift gesammelt was alles möglich wäre und was gemacht werden muss, also die Kür von der Pflicht getrennt.
Mit einem kleinen Augenzwinkern ist dabei ein System heraus gekommen.

Wobei, wie zuvor die Universaldecoder gezeigt haben, nur eine Hardwareplattform entsteht, die zu Allem und nichts kompatibel ist. Da es einfach ist, zu nichts kompatibel zu sein, fangen wird damit an. Die genauen technischen Daten des Buses sind im Moment also noch gar nicht festgelegt; müssen sie auch nicht, denn alle Hardwarebausteine werden einen Bootloader haben, so dass man jederzeit ohne zusätzliche Hardware ein Programm auf ihnen laden kann, das mit anderen Systemen harmoniert.

Zimo baut seit geraumer Weile mit CAN-Bussen herum, allerdings überwiegend für Steuerungsaufgaben und kaum für Rückmeldungen. Roco verkauft Zentralen mit CAN-Anschluss, wobei hier nicht ganz klar ist, ob da nicht einfach jemand über einen Stecker drei Buchstaben geschrieben hat, denn weder funktioniert die Schnittstelle vernünftig, noch sagt irgendwer etwas darüber. Hier beschäftigt man sich eher damit Lokführerstände im AppStore zu verkaufen. (das ist gar keine Bitterkeit, ich rede immer so)
Sollten die Herrschaften auf die Idee kommen doch mal etwas in die Technik zu investieren, sollen die Bauteile vom SpaßCAN darauf programmierbar sein. Und dazu natürlich OpenSource.

Was gibt es denn schon?

Im Moment im Testeinsatz: Ein Interface (oder wie man bei uns im Breisgau sagt – däsch Interfatze), aus einem Bustreiber und einem Arduinomodul, womit die Daten vom CAN-Bus in den Computer gebracht werden.

Das ist natürlich noch nicht elegant, aber braucht sich auch nicht zu verstecken. Im Moment sind für das Interface zwei verschiedene Modi programmiert – im Arduinoslang spricht man von sogenannten „Sketches“, weil programmieren muss jetzt hip sein und „Sourcecode“ klingt nach irgendwelchen pickeligen Nerds mit Flaschenbodenbrillengläsern, die im Keller sitzen, eine Sonnenallergie haben und mit Mitte 30 noch Jungfrau sind. – Der erste Modus ist der generic-Modus, in dem in einem bisher nur grob umrissenen Protokoll die Daten des CAN umgesetzt werden, sortiert werden und über die USB Schnittstelle am PC ausgegeben werden. Großartige Sache, aber kein Steuerungsprogramm versteht was das Interface da redet. der zweite Modus ist der HSI-Modus. Halt, stop! HSI ist doch von LDT – So ist es. Im HSI-Modus maskiert sich das Interaface als High Speed Interface von Littfinski und sendet die Daten genau so, wie man es vom HSI erwarten würde. Allerdings liegen die Daten nicht am S88 Strang an, sondern kommen über den schnelleren CAN-Bus. Der Vorteil: Funktioniert mit allen Steuerungsprogrammen und kann ohne Probleme nahtlos integriert werden. Der Nachteil: Es funktionieren nur die klassischen Rückmeldungen, nichts anderes.

Das zweite fertige Modul: Ein S88 – CAN Konverter:

Wozu man den benötigt? Wir haben natürlich noch jede Menge S88 Melder im Keller, die wir alle einmal selbst geätzt, gebohrt und gelötet haben, kurz: Um die es einfach zu schade wäre, sie in den Ruhestand zu schicken, zumal alle wunderbar funktionierten.
Ist es nicht aber widersprüchlich, ein ordinäres Schieberegister auf dem modernen CAN-Bus zu adaptieren? Geht nicht der eigentliche Nutzen vollkommen verloren? Oder anders: Wozu muss man auf den Nürburgring, wenn man KIA Picanto fährt?
Der S88 Bus reicht bei uns allerdings nur die 10 cm vom Controller des Melders bis zum Controller des Adapters. Dahinter liegt wieder der CAN-Bus an, und es wird nur jeweils ein Melder am S88-Strang betrieben. Der Vorteil: Der S88 Bus kann mit maximaler Geschwindigkeit betrieben werden (die Ausleseintervalle des Schieberegisters wachsen proportional zur Länge des Melderstrangs). Die Fehler entstehen hauptsächlich bei langen Strängen mit vielen Modulen. Der CAN-Adapter dagegen meldet erst etwas auf den Bus, wenn es erforderlich ist, nicht permanent (wie beim s88. Der Nachteil: In einer bestehenden S88 Installation muss schon noch ein bisschen rumgewühlt werden, um einen CAN-Bus zu integrieren.

Das ist z. Zt. in Arbeit:

CAN-Melder:
Natürlich der eigentliche Rückmelder. Der muss ganz schnell her und ist auch bereits in Produktion. Auf einem Controller/Melder werden bei aktueller Hardware 16 Eingänge möglich sein (der CAN-Bus kann mehr und es wird auch nicht beschränkt, aber die Hardware muss ja untergebracht werden). Dabei ist die Rückmeldemethode egal. Die Plattform besteht aus der Busseite und einem Controller mit angeschlossenem Optokoppler auf der Eingangsseite. Hieran kann nun entweder ein beliebiger Sensor angeschlossen oder mit einer Lötbrücke eine Diodenkaskade zum Stromschnüffeln angeschlossen werden, wie bei den Rückmeldern anderer Hersteller. Viele haben ja eine natürliche Abneigung gegen das Stromschnüffeln mit dieser Technik, weil sie das Werk des Teufels sei und man schließlich 1,2 Volt verliert. Deshalb kann dieser Melder aber alles verstehen. Hallsensor, Reedkontakt, Lichtschranke, Microschalter. Entprellt wird per Software. Durch die bipolaren Optokoppler, kann der Prozessor sogar die Polarität des Signals erkennen und dank eines Software-UARTs können RailCom Signale in allen Abschnitten ausgewertet werden (sofern vorhanden). Also, eine Lok fährt in einen getrennten Versorgunsabschnitt (z.B. ein Bahnhofsgleis) und ein RailCom Broadcast gibt vor, dass der Dekoder seine Adresse zurücksenden soll. Der CAN-Melder erkennt das Signal und gibt aus, dass in das betreffende Bahnhofsgleis gerade die Adresse XYZ eingefahren ist, mit der Geschwindigkeit X.

RFID Reader:
Dank des ST95HF Chipsets für RFID und NFC Tags, kann man sehr leicht entsprechende Tags und Transponder auslesen. Diese Daten gehen dann schnurstraks auf den CAN Bus und der Computer weiß, wer gerade zur Arbeit gekommen ist. Oder vielleicht noch interessanter, welcher Transponder gerade an der Lesestelle vorbeigezogen wurde. Auf diese Art und Weise werden ganze Zugzusammenstellungen mit Länge, erlaubter Höchstgeschwindigkeit, Zugart etc eingelesen.

Das könnte man noch machen

Vieles, vieles mehr. Unsere Liste ist lang und einiges ist auch schon über das Planungsstadium hinaus, aber bevor da nicht zumindest ein lauffähiger Prototyp vorliegt, will ich nichts versprechen, was nachher nicht funktioniert.

Ich hoffe, dass der eine oder andere Leser bis hierhin gefolgt ist, da im nachhinein betrachtet der Text doch arg lang geworden ist und bestimmt nicht für jeden interessant. Im Moment bin ich aber Feuer und Flamme für das Projekt und begeistert über die ersten Erfolge und funktionierenden Bausteine unserer Rückmeldung, so dass ich einfach einmal einen kleinen Einblick in die aktuellen Entwicklungen geben möchte. Vielleicht folgt ja bald Weiteres. Vielleicht interessiert sich ja noch jemand so sehr wie ich dafür 🙂