[DDL-ML] Re: [DDL-ML] rufo, loconet, rückmeldebus, bushardware, ddl-treffen

["Andy" <Andy_P@gmx.de>]

Hallo Puesch,

----- Original Message -----
From: "puesch" <puesch@yahoo.de>


> hi ddler,
>
> rückmeldebus:
> ansätze loconet in ddl zu implementieren gibt es ja schon. warum wird es
> nicht so intensiv weitergeführt wie srcp, da scheint die zusammenarbeit
> gut zu klappen.
Hierfür gibt's denke ich mehrere Gründe:
- Aufgrund des kritischen Timings kommt kein normaler User-Prozeß in Frage,
und mit Device Drivern spielt nicht jeder Linuxer freiwillig rum.
- Loconet ist "proprietär" und "nicht völlig lizenzfrei", und damit für
etliche Leute per se disqualifiziert.
- DDL scheint eher von Leuten mit kleineren Anlagen verwendet zu werden, und
da ist der Leidensdruck vernünftige Infrastruktur einzusetzen eben nicht
groß genug. Wer nur zwei Loks steuern will, kann das auch per Joystick oder
etwas Gebastel am S88.

> z.b. aktiver rückmeldebus (z.b. loconet):
Es scheint mir in der Tat derzeit keine Alternative zu existieren. Ethernet
kommt dafür denke ich nicht in Frage, die Verkabelung ist einfach nicht
"anlagenkompatibel" (vergleichsweise dicke Kabel und Stecker, immer ein Hub
erforderlich, man kann nicht einfach Klingelleitung zur Verdrahtung nehmen).
Andere serielle Lösungen skalieren nicht vernünftig.

Weiß eigentlich jemand wie das Digitrax Transponding funktioniert? Die
Patentschrift ist etwas zäh zu lesen... Vielleicht lassen sich daraus ja
weitere Ideen entwickeln. Ich halte allerdings normale Transponder, wie sie
für Warenkennzeichnung etc im Einsatz sind, für den zukunftsträchtigeren Weg
zur Wagenlokalisierung.


> öfter wurde schon diskutiert an welcher hardwareschnittstelle denn ddl
> zukünftig laufen sollte, wenn die serielle an den neueren pcs evtl.
> wegfallen sollte und vielleicht auch irgend wann mal die parallele.

Da gibt's irgend wann wohl tatsächlich ein Problem. Solange aber noch alle
handelsüblichen Mainboards mit 2xSeriell ausgestattet sind, haben wir da
wohl noch etwas Zeit. Im Übrigen will ein DDLer ja wohl eh keine topaktuelle
Kiste verwenden...
srcpd anders als seriell mit dem Booster zu verbinden macht solange wenig
Sinn, wie die Impulserzeugung im PC erfolgt. srcpd ist darauf angewiesen,
die mehr oder weniger kompatibel berechneten Signale praktisch direkt auf
eine "klappernde" Leitung zu legen. Denkbar wäre es, den Bitmustergenerator
komplett auszulagern, dieses externe Kästchen bekäme dann über irgend eine
Schnittstelle den auf die Schiene zu schickenden Command String. Das wäre
allerdings eine recht proprietäre Angelegenheit, was so nicht im Sinne von
DDL sein kann. Der nächste Schritt, srcpd gleich in Hardware zu gießen,
läuft darauf hinaus einen Single Board PC mit Minimal-Linux zu betreiben,
und das geht prinzipiell jetzt ja auch schon. Wir können uns wohl drauf
verlassen, daß auch in 20 Jahren noch Single Board PCs auch die eine oder
andere serielle Schnittstelle dranhaben.

Für einen Loconet Controller kann ich mir auch eine Lösung vorstellen die
kleiner ist als ein SBPC. Ein Atmel (PIC ist vermutlich zu klein) mit
Ethernet-Controller, der die Loconet Daten aufbereitet zur Verfügung stellt,
dürfte als Feierabendprojekt realisierbar sein. Damit wäre auch das
Timing/Device Driver Problem vom Tisch.


> hat den schon mal jemand in die loconet url
> http://groups.yahoo.com/group/loconet_hackers/files/
> hinengeschaut????

Jo, hab ich (schon früher und jetzt noch mal). Hilft uns aber nicht bei DDL
weiter, da offenbar alle Hacker eine Zentrale haben. Der LocoBuffer ist im
Prinzip 'ne schöne Angelegenheit, da er das Timing vereinfacht: innerhalb
von 20 ms sollte es jede alte Gurke schaffen die Daten abzuholen. Leider
reicht das nicht für die Registrierung der Slots: hier muß die Antwort
innerhalb kürzester Frist zurückgeschickt werden, und das macht LocoBuffer
eben nicht selber und Linux nicht zuverlässig schnell (bei normaler
tty-Programmierung). LocoBuffer ist also nur etwas für eine
"Zweit-Zentrale". LocoIO zeigt den Aufwand für ein
Rückmelde/Steuer/Schaltmodul: etwa 20,-? zuzügl. eventuelle Treiber; auf die
Portanzahl umgerechnet billiger als Motorola-Schaltdecoder.

Andreas