[SRCP] OpenDCC und SRCP, ein erster Erfahrungsbericht
Guido Scholz
nach einigen Wochen Vorplanung war es gestern endlich so weit: Die
Zusammenarbeit dieser beiden Open-Source-Projekte kam auf den Prüfstand.
Der Test selbst fand im »Prüflabor« von Wolfgang Kufer statt, der
glücklicherweise nur rund 20 km von mir entfernt wohnt.
OpenDCC (http://www.opendcc.de/)
--------------------------------
Zum Einsatz kam ein Modell (Seriennummer 3, Software-Version 0.13) mit
Kommunikations-Software für das Intellibox-Protokoll. Der Anschluß an den
PC wurde mit seriellem Kabel (RS-232) vorgenommen.
SRCP (http://www.der-moba.de/index.php/Digitalprojekt)
------------------------------------------------------
Auf der SRCP-Seite kam ein Laptop (IBM A22p) mit Ubuntu 6.06 und srcpd
2.0.10 zum Einsatz. Die Ansteuerung der Lokomotive fand über dtcltiny
0.8.4 statt. Zur Ansteuerung eines Weichendecoders und zur Überprüfung der
Rückmeldungen wurde spdrs60 0.5.2 genutzt.
Ergebnisse
----------
Der srcpd konnte mittels dem per Konfigurationsdatei eingestellten
Intellibox-Protokoll problemlos mit der openDCC-Zentrale verbinden und
fand automatisch die dort eingestellte Datentransferrate von 19200 Baud.
Ein- und Ausschalten des Digitalstromes funktionierten problemlos.
Die Ansteuerung der auf einem Rollenprüfstand aufgebauten Lok
(ZIMO-Decoder, Modell ?, 28 Geschwindigkeitsstufen, kurze Adressen)
funktionierte ebenfalls problemlos. Getestet wurden verschiedene
Geschwindigkeitseinstellungen sowie das Schalten zweier eingebauter
Lichtfunktionen F1 und F2.
Der DCC-Weichendecoder (OpenDecoder, Selbstbau W. Kufer) wurde ebenfalls
vollkommen problemlos angesteuert. Sowohl die Programmierung der Adresse
als auch das Umschalten aller Ausgänge wurden getestet. Da der Decoder
auch eine programmierbare Ampelschaltung für ein Faller-Car-System hat,
wurde auch deren Programmierung und Einstellung geprüft.
Problematisch wurde es erst beim Testen der Rückmeldungen. Hier wurden
zwei Module in unterschiedlicher Hardware-Ausführung und auch zwei
Versionen der Zentrale ohne Erfolg ausgeprüft. Wolfgang wird sich der
Sache aber nochmal annehmen, zumal das Phänomen auch auf dem zeitgleich
verfügbaren, proprietäten Vergleichsystem »MS-Windows/Railroad&Co«
nachstellbar war. Mittlerweile ist der Fehler erkannt und behoben (?),
wie Wolfgang mir per E-Mail mitteilte.
Nicht ausgetestet wurde eine Anbindung der Zentrale per USB, da das
verfügbare OpenDCC-Modell nicht lief. Ebenfalls nicht getestet wurde eine
Kommunikation von srcpd mit OpenDCC per Lenz-Protokoll, da eine Zentrale
mit fertiger Software-Konfiguration nicht zur Verfügung stand. Weiterhin
fehlt noch ein Test zur Programmierung von Lokdecodern, der aus
Zeitgründen nicht vorgenommen werden konnte.
Alles in Allem kein allzuschlechtes Ergebnis für einen ersten Test. Wenn
die Rückmeldungen ans Laufen kommen, bekommt der Anwender hiermit ein sehr
preiswertes und leistungsfähiges System in die Hände.
Gruß
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
Guido Scholz
> Problematisch wurde es erst beim Testen der Rückmeldungen. Hier wurden
> zwei Module in unterschiedlicher Hardware-Ausführung und auch zwei
> Versionen der Zentrale ohne Erfolg ausgeprüft. Wolfgang wird sich der
> Sache aber nochmal annehmen, zumal das Phänomen auch auf dem zeitgleich
> verfügbaren, proprietäten Vergleichsystem »MS-Windows/Railroad&Co«
> nachstellbar war. Mittlerweile ist der Fehler erkannt und behoben (?),
> wie Wolfgang mir per E-Mail mitteilte.
hierzu gibt es nun einen Nachtrag, da wir nach einer längeren
Schönwetterpause gestern einen zweiten Testtermin veranstalten konnten.
Unter im Prinzip identischen Software- und Hardware-Testbedingungen wurde
ein S88-Modul von C* an die OpenDCC-Zentrale (V 1.13, Intellibox-Protokoll,
RS-232-Anbindung) angeschlossen und problemlos betrieben. Die Auswertung
der Rückmeldungen erfolge über spdrs60. Beim letzten Mal war das Modul
falsch angeschlossen, und hatte von daher seinen Betrieb verweigert.
Als nächstes wurde der HSI-S88-Modus getestet, den sowohl srcpd als auch
die OpenDCC-Zentrale unterstützen. Auch hier gab es keine Verbindungs-
probleme. Das oben schon erwähnte S88-Modul wurde an den drei
Anschlußkanälen (L, M, R) der Zentrale getestet. Zwei Kanäle liefen
erfolgreich, beim Dritten hatte sich offenbar ein Hardwarefehler beim
Verlöten eingeschlichen. Dessen Nichtbetriebsfähigkeit ließ sich
problemlos unter der proprietären Konkurrenz (M$-Win/Freiwald)
nachstellen.
> Nicht ausgetestet wurde eine Anbindung der Zentrale per USB, da das
> verfügbare OpenDCC-Modell nicht lief. Ebenfalls nicht getestet wurde eine
> Kommunikation von srcpd mit OpenDCC per Lenz-Protokoll, da eine Zentrale
> mit fertiger Software-Konfiguration nicht zur Verfügung stand. Weiterhin
> fehlt noch ein Test zur Programmierung von Lokdecodern, der aus
> Zeitgründen nicht vorgenommen werden konnte.
Eine Zeit lang haben wir uns dann noch vergeblich mit dem Anschluß über
USB beschäftig, der aber mangels Fachkenntnis nicht im zur Verfügung
stehenden Zeitrahmen ans Laufen kam. Der USB-Baustein der Zentrale ist
per »lsusb« ohne Weiteres sichtbar, er wird aber nicht standardmäßig als
serielles Gerät erkannt und automatisch eingebunden. Hier ist noch etwas
Lektüre notwendig.
Ein Test der Verständigung über das Lenz-Protokoll fand ebenfalls nicht
statt. Wolfgang hatte auch dieses Mal keine entprechend ausgestattete
Zentrale vorrätig. Das Programmieren von Lokdecodern fand aus zeitlichen
Gründen ebenfalls nicht mehr statt.
Matthias Trute
>
> Eine Zeit lang haben wir uns dann noch vergeblich mit dem Anschluß über
> USB beschäftig, der aber mangels Fachkenntnis nicht im zur Verfügung
> stehenden Zeitrahmen ans Laufen kam. Der USB-Baustein der Zentrale ist
> per »lsusb« ohne Weiteres sichtbar, er wird aber nicht standardmäßig als
> serielles Gerät erkannt und automatisch eingebunden.
Das liegt an der "falschen" Vendor/Product-ID. IIRC hat Wolfgang
"seine" Kombination dafür, da springt der usbserial Treiber nicht
drauf an.
> Hier ist noch etwas Lektüre notwendig.
libusb hat eine sehr karge Dokumentation, nach der die Identifikation
eines USB Bausteines über die Vendor-ID/Product-ID geht und dann die
Enumeration der solcherart identischen Busteilnehmer erfolgt. Ohne
jetzt nachgeschaut zu haben, sollte entweder nur eine opendcc Zentrale
am USB hängen oder es muß ein weiteres Kriterium durch Auswerten
von USB Konfigurationsvariablen (aka Seriennummer) herangezogen
werden. Im srcpd wird dann auf diese zwei/drei Werte Bezug genommen
um das USB Gerät ansprechen zu können. Das zieht aber einiges
nach sich. Stichwort Hotplug usw. Derzeit ist auch kein USB relevanter
Code im srcpd, opendcc wäre das erste wirkliche USB Gerät (usb2serial
zählt da nicht)!
Gruß
Matthias
Guido Scholz
Hallo Matthias,
> Guido Scholz schrieb:
>> Eine Zeit lang haben wir uns dann noch vergeblich mit dem Anschluß über
>> USB beschäftig, der aber mangels Fachkenntnis nicht im zur Verfügung
>> stehenden Zeitrahmen ans Laufen kam. Der USB-Baustein der Zentrale ist
>> per »lsusb« ohne Weiteres sichtbar, er wird aber nicht standardmäßig als
>> serielles Gerät erkannt und automatisch eingebunden.
> Das liegt an der "falschen" Vendor/Product-ID. IIRC hat Wolfgang
> "seine" Kombination dafür, da springt der usbserial Treiber nicht
> drauf an.
ich habe jetzt schon eine ganze Zeit »herumgegoogelt« und verschiedene
Hinweise gefunden. Vermutlich würde ein händisches
modprobe ftdi_sio vendor=0x0403 product=0xbfd8"
helfen. Ich kann es aber im Augenblick mangels Hardware nicht testen.
Diese Art von »Handstart« wäre auch nicht wirklich benutzerfreundlich.
>> Hier ist noch etwas Lektüre notwendig.
> libusb hat eine sehr karge Dokumentation, nach der die Identifikation
> eines USB Bausteines über die Vendor-ID/Product-ID geht und dann die
> Enumeration der solcherart identischen Busteilnehmer erfolgt. Ohne
> jetzt nachgeschaut zu haben, sollte entweder nur eine opendcc Zentrale
> am USB hängen oder es muß ein weiteres Kriterium durch Auswerten
> von USB Konfigurationsvariablen (aka Seriennummer) herangezogen
> werden. Im srcpd wird dann auf diese zwei/drei Werte Bezug genommen
> um das USB Gerät ansprechen zu können. Das zieht aber einiges
> nach sich. Stichwort Hotplug usw.
Mit udev müßte folgende Regel funktionieren:
BUS=="usb" SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bfd8",
MODE="660", GROUP="dialout", NAME="opendcc"
Damit würde dann beim Einstecken gleich ein »/dev/opendcc« resultieren.
Natürlich kann man damit erstmal nur eine OpenDCC-Zentrale anschließen.
> Derzeit ist auch kein USB relevanter
> Code im srcpd, opendcc wäre das erste wirkliche USB Gerät (usb2serial
> zählt da nicht)!
Wie die USB-Schnittstelle auf die Geschwindigkeitsparametereinstellungen
reagiert ist mir auch nicht klar. Ich würde das einfach mal probieren
und mich auf den Kerneltreiber verlassen.
Guido Scholz
> Mit udev müßte folgende Regel funktionieren:
> BUS=="usb" SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bfd8",
> MODE="660", GROUP="dialout", NAME="opendcc"
> Damit würde dann beim Einstecken gleich ein »/dev/opendcc« resultieren.
> Natürlich kann man damit erstmal nur eine OpenDCC-Zentrale anschließen.
Gleich ein Nachtrag hierzu: Wie ich gerade gelesen habe, sollte jeder
USB-Chip auch noch eine Seriennummer haben, dann kann man einfach für
jede anzuschließende Zentrale ein eigenes Device erzeugen:
SYSFS{serial}=="CHIP-ID1", NAME="opendcc0"
SYSFS{serial}=="CHIP-ID2", NAME="opendcc1"
usw., damit wäre das Thema dann auch erledigt.
Guido Scholz
> Eine Zeit lang haben wir uns dann noch vergeblich mit dem Anschluß über
> USB beschäftig, der aber mangels Fachkenntnis nicht im zur Verfügung
> stehenden Zeitrahmen ans Laufen kam. Der USB-Baustein der Zentrale ist
> per »lsusb« ohne Weiteres sichtbar, er wird aber nicht standardmäßig als
> serielles Gerät erkannt und automatisch eingebunden. Hier ist noch etwas
> Lektüre notwendig.
Hallo zusammen,
bevor dieser Diskussionsfaden mit seinen noch offenen Fragestellungen aus
meiner Programmhistorie verschwindet, sei noch kurz eine Aktualisierung
des derzeitigen Standes veröffentlicht.
Die Frage, ob sich die OpenDCC-Zentrale unter Linux mit USB betreiben
läßt, ist kurz mit »Ja« zu beantworten. Wie geht man nun vor, damit
OpenDCC als serielles Gerät am USB-Bus erkannt wird? Hier gibt es mehrere
Möglichkeiten.
1)
Vor einigen Wochen habe ich einen Kernel-Patch eingereicht, der die
Product-ID für OpenDCC (0xbfd8) bei dem zugehörigen Kerneltreiber
(ftdi_sio) registriert. Dieser wurde mittlerweile angenommen und ist sogar
schon im Kernel 2.6.22 enthalten. Man könnte jetzt also warten, bis eine
Distribution mit diesem oder einem noch neueren Kernel herauskommt.
Alternativ könnte man den aktuellen Kernel selbst kompilieren oder auch
nur den Patch [1] beim ftdi_sio-Treiber einspielen, um dann nur das
Modul mit einem beliebigen älteren 2.6er Kernel neu zu kompilieren. Die
Wahl sei den interessierten Fachleuten überlassen.
2)
Eine wesentlich einfachere und sofort nutzbare Methode sei aber auch
noch erwähnt und als Übergangslösung in erster Linie empfohlen.
Vorrausgesetz man besitzt eine halbwegs aktuelle Distribution mit
»udev«-Unterstützung, dann läßt sich eine zuverlässige
»Einsteck-und-Spiel«-Lösung durch die Erstellung einer geeigneten
udev-Filterregel erreichen. Unter Ubuntu 6.10 geht man beispielsweise so
vor:
Im Verzeichnis
/etc/udev/rules.d/
legt man eine Datei mit dem Namen
10-opendcc.rules
an (der Name ist natürlich weitgehend frei). Diese Datei soll folgende
Textzeile (hier umgebrochen) enthalten:
SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bfd8",
RUN+="/sbin/modprobe -q ftdi_sio vendor=0x0403 product=0xbfd8"
Das ist schon alles. Diese Zeile sorgt dafür, dass der ftdi-sio-Treiber
geladen wird, wenn sich der Chip mit der OpenDCC-Kennung am USB-System
anmeldet. Beim Einstecken wird dann eine Datei /dev/ttyUSB0 erzeugt, die
man als Schnittstelle in der srcpd.conf einträgt. Beim gleichzeitigen
Betrieb mehrerer USB/Seriell-Konvertierer kann statt mit »0« die
Schnittstelle natürlich auch mit einer anderen Ziffer benannt sein. Beim
Abziehen des Steckers verschwindet diese Datei anwendungsgemäß wieder.
Nachdem ich erst seit Mitte letzter Woche Besitzer einer eingenen
OpenDCC-Zentrale bin und mir noch Hardware zur Anbindung der
Modellbahnperipherie fehlt, gibt es derzeit noch keine großartigen
weiteren Testergebnisse. Die Kontaktaufnahme per Intellibox-Protokoll
funktioniert im Prinzip wie beim RS232-Betrieb (automatisches Finden der
voreingestellten 19200 Baud), und der Digitalstrom läßt sich per SRCP ein-
und ausschalten. Es gibt zur Zeit in der Initialisierungsphase noch einen
Hänger beim Umschalten auf den _nur P50xb_-Modus; dieser Schritt wird
schließlich per Timeout überwunden. Der Grund dafür liegt in einer
fehlenden Antwort durch die in meiner Zentrale werkelnde (Beta-)
OpenDCC-Version, wie mittlerweile klar geworden ist. Wolfgang hat schon
Nachbesserung gelobt.
Gruß
Guido
[1]: usb-ftdi_sio-add-usb-product-id-for-opendcc.patch