Hallo zusammen,
ich habe mal unter
www.nmra.org dies aktuellen Spezifikationen zur biderektionalen Datenübertragung übers Gleis laut NMRA gelesen. Der elektrische Teil des Verfahrens ist bereits verabschiedet und kommt laut eigenen Angaben im Handbuch bereits im Lenz LV102 und ECos und evtl auch weiteren Systemen zum Einsatz. Das Verfahrungen wird üblicherweise meist "RailCom" (Warenzeichen der Lenz-Elektronik GmbH) genannt.
Ob und und unter welchen Voraussetzungen diese biderektionalen Booster einen gemeinsame Nutzung mit "herkömmlichen" Boostern zum Fahren auf derselben Gleisanlage ermöglichen geht aus der Patent enthaltenden Norm nicht hervor. Das hängt wohl von der jeweilgen elektrischen Implementierung der jeweilgen Geräte ab, und ich selbst würde mich hier deswegen streng an die jeweiligen Empfehlungen des Herstellers halten.
Ersichtlich für den Hobby-Elekroniker ist aber schon, das eine Brückung eines bidirektionalen Boosters mit einem herkömmlichen Booster durch einen die Trennstelle überfahrenden Zug sofort die Übertragung der Daten von Lok nach Booster abschalten muss. Zumindest solange die Boosterkreise der unterschiedlichen Booster gebrückt sind wird der herkömmliche Booster als Fremdspannung erkannt, und es kann und darf kein "Railcom" funktionieren bzw. stattfinden.
Eine darüber hinaus gehende negative Auswirkung einer gemeinsamen Masse mit "herkömmlichen Booster" sind hier nicht erörtert und bleiben für mich weiter ungewiss.
Das Bidirektionale Verfahren nach NMRA funktioniert in etwa so: Der Booster erstellt für bis zu zwei kurze Augenblicke (2 oder 4 logische '1'-DCC-Bits zwischen 2 Befehlen) ein elektrische Verbindung der beiden Schienenstränge unter Abschaltung des DCC-Signals. Der Decoder generiert aus gespeicherter Ladung währende dieses "Cutout" recht hochfrequent (256kBits/s) 2 oder 4 kurze reduntant kodierte Datenbytes (12 oder 24 logische bits) in Form von im Lok-Decoder erzeugten Stromimpulsen (z.B. 30mA über 4us). Diese können dann vom Detector (im Booster integriert oder als externes Gerät ) ausgewertet werden und z.B. mittels Systembus zur Zentrale übersendet werden. Der am Detector anfallende Spannungsabfall soll bei ca 2V liegen.
Das Software-Protokol zur Nutzung der Datenübertragung befindet sich im Entwurfs-Modus, ist im Gegensatz zur elektrischen Schicht also noch nicht endgültig festgelegt. Er erschien mir dennoch vollständig und konkret. Erwähnt werden formale Funktionalitäten wie Quittierung von Befehlen (z.B. zur Protokoll-Sicherung), von der Lok ungefragt gesendete Info (z.B. Adresse), lokspezifische Daten (von der Lok unmitellbar nach einem an sie Adressierten Befehl zu senden).
www.nmra.org/standards/DCC/standards_rps/RP-931%202007%20Jan.pdfwww.nmra.org/standards/DCC/standards_rps/RP-9.3.2%20draft%202005-04-14.pdfDiese Informationen sind auch bereits kategorisiert, z.B. CV-Inhalte, Fahr-Route, Geschwindigkeitsinformationen, Aufenthaltsort, Lok-Temperatur, Wasser und Ölstand, sowie natürlich vom Decoder-Hersteller beliebig nutzbare Daten.
Die erwähnten Funktionen sind natürlich nicht verbindlich vorgeschrieben, so dass man nicht davon ausgehen kann, das ein "RailCom"-Gerät alle die erwähnten Funktionionen beherrscht. Vielmehr sagen diese Normen nur, welche Spezifaktionenn ein Hersteller einhalten sollte bzw.muss, um eine kompatible biderektionale Datenübertragung zu erstellen, bzw. um diesbezüglich Kompabilität von der NMRA zugesprochen zu bekommen. Auch wenn er keine oder nur geringe der genannten Funktionalitäten bereitstellt.
Lange Rede kurzer Sinn: Man muss wohl davon ausgehen das auch bei "RailCom" nur mir "RailCom-Boostern" (z.B. LV102, ECosBoost) funktioniert, und eine gemischte Nutzung mit traditionellen Boostern im Fahrstrom zumindest zu Einschränkungen führen wird. Den ECosBoost empfiehlt ESU auch für die Central-Station als mfx-Booster.
Viele Grüße
Frank