Hallo Mike und die anderen Vorausdenker,
klar, ich bin mir bewusst, dass ein bidirektionaler schneller Funkverkehr das Optimum wäre. Aber sinnieren wir doch einfach mal, ob wir mit dem bereits vorhandenen die Situation wesentlich verbessern könnten.
Eigentlich haben wir schon fast alles, was wir benötigen. Man muss es nur sinnvoll kombinieren.
Was stört uns am derzeitigen DCC?
- Viel Schienenbandbreite für wenig Information (Viele Präambelbits, 4-Byte-Befehle, XOR als Checksumme).
- Die CV-Struktur ist suboptimal.
Was stört uns am derzeitigen RailCom?
- Der Rückmeldung mangelt es an Energie. Die Speed wäre aber da.
Wenn wir jetzt die Vorteile von mfx mit der RDS-Strom-Rückmeldung und DCC (RailCom-Rückmeldung) + Protokollerweiterungen sinnvoll kombinieren würden, hätten wir doch schon fast alles was wir benötigen.
- Als schnelles Protokoll von der Zentrale zur Schiene bietet ein erweitertes mfx mit ständiger Rückmeldung gem. RailCom, aber nicht in spannungslosen Datenpausen, sondern unter Dampf wie beim mfx-RDS, nur eben mit der Speed von RailCom, eigentlich alles bisher Benötigte.
Das mfx-Protokoll ist, vereinfacht betrachtet, ein sinnvoll abgespecktes DCC. Dagegen ist nichts einzuwenden. Framegrenzen werden, wie weiter oben schon gefordert, durch eine gezielte Protokollverletzung angezeigt. Weiterhin gibt es eine richtige CRC-Checksumme. Es sind sinnvolle Befehle für eine objektorientierte CV-Struktur vorhanden. Was fehlt ist eine kontinuierliche Befehlsquittierung/Rückmeldung wie bei RailCom. Das könnte man aber problemlos einbauen.
Was bei mfx aber nicht so ideal ist, das ist die langsame RDS-Rückmeldung. Dafür liegt bei der Rückmeldung aber Versorgungsspannung am Gleis. Und genau da würde ich ansetzen. Statt nun mit der langsamen RDS-Speed rückzumelden, würde ich jetzt die Spannung eingeschaltet lassen und mit 200mA oder sogar noch größeren 250kBit RS232-Strom-Pulsen (gem. RailCom-Spec) bei eingeschalteter Versorgungsspannung zurücksenden, und da auch wieder mind. 2 Kanäle und ein/mehrere Strom-Status-Bit(s). Das bringt eine wesentlich bessere Rückmeldesicherheit.
RailCom krankt ein wenig an der Empfindlichkeit. Mit 45mA bei einer größeren Anlage vom hintersten Winkel aus senden, ist einfach fast nicht mehr machbar, besonders bei der elektrischen Verschmutzung durch die PWM der Lokmotoren. Und dafür kurzzeitig alles Abschalten ist ein Aufwand, der vermeidbar wäre.
Zusätzlich wird vereinbart, dass jeder Schienenbefehl direkt per RailCom, oder sogar noch einfacher, nur durch ein (Strom-)Bit quittiert wird. Man kann daher die Bandbreite fressenden sinnlosen Befehls-Wiederholungen drastisch zurückfahren und dadurch richtig viel Schienenbandbreite sparen.
Als weitere Massnahme würde ich Befehle einführen wie z. B. mit der im Decoder eingestellten ABV und/oder eingestelltem konstantem Bremsweg abbremsen. Auch dieser Befehl wird quittiert. Damit versende ich von der Zentrale aus nur einen einzigen kurzen Schienen-Befehl und kann mich dann darauf verlassen, dass der Decoder das verstanden hat und das auch tut, was er soll, sofern er ordentlich versorgt wird. Ebenso für das Anfahren. Ein Befehl genügt und nicht für die ansteigenden Fahrstufen einen ganzen Blumenstrauss von Fahrbefehlen. Das ist unnötig, auch heute schon.
Weiterhin würde ich noch so was wie diese assymetrische Betriebsspannung für Bremsstrecken einbauen, damit man Blockbetrieb auch ohne Zentralen-Befehle dezentral nur vom Signal ausgelöst, steuern kann.
Wie die Rückmeldung einer Weichenlage oder Belegtmeldung über das Gleis ohne viel Latenz (= Verzögerung) gemacht werden kann, da habe ich momentan noch keine brauchbare Idee. Das gebe ich ganz offen zu.
Was man mit den o. g. Kombinationen aber schon erschlagen kann ist folgendes:
- Schnelles Gleisprotokoll
- Lokpositionsrückmeldung (zumindest Abschnittsweise) durch in die Zuleitung eingeschleifte Stromsensoren möglich (weil jeder Fahrbefehl durch einen Hochstrom-Impuls von dem angesprochenen Decoder quittiert wird).
- Halbwegs sicheres schnelles Rückmelden über Hochstrom-RailCom-Datenpakete zwischen den Datenframes, wobei ein CutOut nicht nötig ist, weil in der Zeit, wie bei RDS, Spannung anliegt.
Alle diese bisher angeführten Verbesserungen beruhen nur auf einer Kombination von den guten Eigenschaften von den bisher auch schon vorhandenen Protokollen und HW und sind zu dem bisherigen DCC/MM/mfx vollkommen kompatibel.
Gruss
est2fe