Hallo Forumleser,
mit den letzten Updates für Steuerungen, Lokprogrammer Software und Loksound V5 bzw. LokPilot V5 Firmware, hat ESU eine Geschwindigkeitsrückmeldung via RailCom implementiert. Das war für mich ein Grund, mich mit dem Thema RailCom Rückmeldungen zu befassen.
ESU Loksound V5
Nach dem Update der Lok Programmer Software auf die Version 5.2.8 und einem Update der Decoder Firmware ist zunächst einmal kein Unterschied zu sehen. Auch die ECOS zeigt mit der aktuellen Version 4.2.13 noch keine Realgeschwindigkeit an. Daher habe ich eine Lok mit einen aktuellen LokSound V5 Decoder auf meinem BiDiB System getestet. Die BiDiB Tools zeigen die RailCom Rückmeldungen des Decoders an. Für den LokSound V5 zeigen die BiDiB Tools die Aufgleisrichtung und eine Geschwindigkeitsrückmeldung mit Werten zwischen 0 und 255 an. Dabei entspricht der Wert 255 der Geschwindigkeit bei FS126. Die Werte zwischen 0 und 255 spiegeln die entsprechende Modellgeschwindigkeit wieder. Meine Testlok ist auf 105km/h Maximalgeschwindigkeit eingemessen und entsprechend entspricht bei dieser Lok der Wert 255 der Geschwindigkeit 105km/h. Folglich muss die Rückmeldung 127 der Geschwindigkeit 52km/h entsprechen. Um das zu testen habe ich die Lok auf eine expotenzielle Geschwindigkeitskurve eigestellt. Damit fährt die Lok bei FS63 etwa 25km/h. Entsprechend liefert mir der Decoder einen Wert von 63 zurück. Dann habe ich die Lok auf eine lineare Geschwindigkeitskurve umgestellt. Damit fährt die Lok bei FS63 52km/h und der Decoder meldet 127 als Wert zurück.
D&H SD22A
Mit Decoder Firmware 1.13 liefert der D&H SD22A Decoder die Aufgleisrichtung, die Signalqualität und eine Geschwindigkeitsinformation via RailCom zurück. Der Geschwindigkeitswert liegt zwischen 0 und 126 und verhält sich genauso, wie beim ESU Decoder proportional zur Modellgeschwindigkeit. Wenn man den Wert CV135 von 1 auf 2 ändert verdoppelt sich der zurückgemeldete Geschwindigkeitswert, so dass dann die Geschwindigkeitsrückmeldung wie beim ESU zwischen 0 und 255 liegt.
Zimo MX645
Für den Test eines Zimo Decoders habe ich eine BR106 DR von Roco verwendet, welche ab Werk mit einem Zimo MX645 Decoder ausgestattet ist. Diese Lok ist mit iTrain auf eine vorbildgerechte Höchstgeschwindigkeit von 60 km/h eingemessen. Mit der aktuellen Firmware 4.20 meldet der MX645 die Aufgleisrichtung, die Signalqualität und einen Geschwindigkeitswert via RailCom zurück. Die Dokumentation für die Zimo MX Decoder beschreibt das Eichen des Decoders für eine km/h Steuerung. Leider konnte ich mit diesem Eichen kein brauchbares Ergebnis erzielen. Daher habe ich den CV135 auf 0 programmiert und den Geschwindigkeitswert mithilfe von CV136 eingestellt. Indem ich den CV136 auf 90 programmiert habe, meldet mir die Lok bei FS126 einen Wert 60 zurück, was ja der eingemessenen Geschwindigkeit entspricht.
Märklin/Trix mSD3
In neueren Trix Modellen sind RailCom fähige mSD3 Decoder verbaut. Diese Decoder melden aber nur die Aufgleisrichtung via RailCom zurück.
Piko SmartDecoder 4.1
In einem ICE4 von Piko habe ich noch einen original Piko Decoder gefunden. Dieser meldet via RailCom nur die Aufgleichrichtung zurück.
Die Rückmeldung der Geschwindigkeit durch den Decoder bietet interessante Möglichkeiten. Leider legen die Decoder Hersteller die Rückmeldung der Geschwindigkeit offensichtlich unterschiedlich aus, um diese dann für eigene Zentralen nutzen zu können. Da die Geschwindigkeitsrückmeldung auch Anfahr- und Bremsverzögerungen berücksichtigen, könnte eine Steuersoftware damit eine Positionsbestimmung der Loks deutlich genauer vornehmen, als dies heute der Fall ist.
Die RailCom Rückmeldung erfolgt auf zwei Kanälen. Über Kanal 1 meldet der Decoder seine Adresse an die Zentrale. Alle anderen Rückmeldungen erfolgen über Kanal 2. Der Kanal 1 wird also nur benötigt, damit die Zentrale die Lok nach dem Aufstellen erkennt. Danach wird der Kanal 1 nicht mehr benötigt und sollte idealerweise automatisch abgeschaltet werden. Hierfür ist laut Norm die Einstellung CV28 Bit2 vorgesehen. Auch wenn in der Dokumentation von Zimo und D&H die automatische Abschaltung von Kanal 1 nicht beschrieben ist, scheinen diese Decoder diese Abschaltung zu verwenden. Sie ist wohl immer aktiv. Bei den Märklin/Trix mSD3 Decodern ist die automatische Abschaltung von Kanal 1 für CV28 Bit 2 beschrieben und kann so aktiviert und deaktiviert werden. Nur bei den ESU Decodern gibt es offensichtlich keine automatische Kanalabschaltung für Kanal 1. Hier wird empfohlen, Kanal 1 grundsätzlich abzuschalten, also CV28 Bit0 auf 0 zu programmieren. Das hat aber zur Folge, dass sich die ESU Decoder nicht automatisch mit ihrer Adresse an der Zentrale melden.
Viele Grüße
Heiko

Meine Sicht der Dinge:
aus rein technischer Sicht resp. aus der Sicht des Decoders hat der folgende (Roh-)Informationen:
die Motorreferenz als Spannung, diese entspricht auch der Motorspannung ( einigermassen bei einem PID-Regler in eingeschwungenem Zustand )
die statischen Werte aus den Geschwindigkeits-CV's, die ja entweder als lineare oder exponentielle Werte vorgegeben sind
Wenn ich jetzt mit iTrain und BiDIB die Lok erstmal mit FST 28 auf Vmax einstelle, habe ich CV 94 auf 255 und im Falle ESU CV 53 auf den Wert für passende Vmax per POM eingestellt.
Das bedeutet jetzt doch konkret, dass ich beim Einmessen per iTrain beim Hin- und Herfahren einigermassen reproduzierbare tatsächliche Werte für Vmax in iTrain erhalte.
Dem Lokdecoder ist das doch aber völlig egal !
Wenn ich jetzt die Lok einmesse, legt iTrain für jede FST in seiner Konfigdatei den tatsächlich gemessenen Wert ab und baut daraus auch zwei Kennlinien. ( Vor und Zurück )
Auch damit hat der Decoder nix zu tun, resp. bekommt davon nichts mit.
Aus Sicht des Decoders kann der natürlich anhand der Motorreferenz den prozentualen Anteil von Vmax zur aktuellen FST liefern, aber das ist doch ein relativer und kein absoluter Wert ?
Was ich meine, wie soll der Decoder die Beziehung zwischen einem gemessenen Spannungswert und der tatsächlichen Geschwindigkeit herstellen, dieses Mapping macht iTrain übers Einmessen, aber nicht der Decoder und auch nicht der BiDiB-Wizard. D.h. Railcom liefert eigentlich adaptierte Drehzahlwerte !
Ist das so richtig ?
Gruß Thomas
PS: Meine ESU Decoder sind noch nicht upgedated, ist aber kein Problem.
Wenn der Wunsch besteht, können wir gerne mal eine Messreihe aufsetzen, ich kann ESU, ZIMO und D&H beisteuern, alles Sounddecoder.
PPS: Ich fahre schon immer und grundsätzlich mit Railcom, iTrain nutzt die Infos auch, aber m.W. nicht für die Brems/Anhaltevorgänge

Zitat von mueller.heik im Beitrag #1

---

Hier wird empfohlen, Kanal 1 grundsätzlich abzuschalten, also CV28 Bit0 auf 0 zu programmieren. Das hat aber zur Folge, dass sich die ESU Decoder nicht automatisch mit ihrer Adresse an der Zentrale melden.

---

Hallo Heiko,

Zitat von mueller.heik im Beitrag #1

---

Hierfür ist laut Norm die Einstellung CV28 Bit2 vorgesehen.

---

ZIMO Decoder unterstützen die automatische Abschaltung von Kanal 1 nicht.

Hallo Vincent,

Zitat von Vincent Hamp im Beitrag #4

---

ZIMO Decoder unterstützen die automatische Abschaltung von Kanal 1 nicht.

---

Hallo Heiko,

Zitat von mueller.heik im Beitrag #1

---

mit den letzten Updates für Steuerungen, Lokprogrammer Software und Loksound V5 bzw. LokPilot V5 Firmware, hat ESU eine Geschwindigkeitsrückmeldung via RailCom implementiert. Das war für mich ein Grund, mich mit dem Thema RailCom Rückmeldungen zu befassen.

---

Zitat von vikr im Beitrag #5

---

Natürlich haben auch die Zimo-Decoder früher die automatische Abschaltung von Kanal 1 nicht unterstützt, aber mit aktuellerer Firmware seit etwa vier Jahren zunehmend.

---

Hallo Vincent,

Zitat von Vincent Hamp im Beitrag #7

---

Weder die MX- noch die MS-Decoder unterstützen die automatische Kanal 1 Abschaltung.

---

Zitat von vikr im Beitrag #8

---

Hallo Vincent,

Zitat von Vincent Hamp im Beitrag #7

---

Weder die MX- noch die MS-Decoder unterstützen die automatische Kanal 1 Abschaltung.

---

Danke für dieses klare Statement.
D. h. bei allen Zimo MX- und MS-Decodern sollte abwärtskompatibel zu einer bei Modellbahnern vorhandenen RC-Infrastruktur - mit CV28 = 3 und aktiviertem Railcom in CV29 = 8 - auf Kanal 1 ununterbrochen die eingestellte Lokadresse gemeldet werden?

MfG

vik

---

Zitat

---

Bit 2
= 0: RailCom Rückmeldung alte ZIMO Var auf Id 3
= 1: Normgerechte km/h-Rückmeldung auf Id 7

---

Bei MS-Decodern gibt es seit der letzten SW-Version eigens die CV99 um individuelle RailCom Datagramme zu deaktivieren

Zitat

---

Neue CV #99 zum Deaktivieren von RailCom ID 7-Aussendungen

Bit 0 deaktiviert Kmh
Bit 1 deaktiviert O/W
Bit 2 deaktiviert Temperatur
Bit 3 deaktiviert Gleisspannung

---

Hallo Zusammen,
das Thema RailCom Rückmeldungen ist für mich interessant, um die Anläufe auf unserer Clubanlage zu optimieren. Diese wird mit iTrain automatisch gesteuert. Hierfür ist ein sehr aufweniges Einmessen jeder einzelnen Lok erforderlich. Dazu kommt, dass die Anfahr- und Bremsverzögerungen angepasst und zusätzlich eine Reaktionsverzögerung eingestellt werden muss. Ich habe dafür einige Testfahrten erstellt, welche die Loks mal kurz vor Blockende und mal direkt am Blockanfang anhalten. Außerdem gibt es eine Aktion, welche die Lok nach dem Stopp am Blockanfang um 50cm weiter rangiert. Erst wenn alle Stopppositionen und auch die 50cm rangierte Strecke stimmen, wird die Lok auf der Anlage gefahren. Trotzdem sind immer wieder mal unterschiedliche Stopppositionen von Loks in verschiedenen Blocks der Anlage zu sehen. Kritisch ist hier vor allem die Drehscheibe, da diese bei manchen Modellen nur 1cm länger ist und daher eine sehr exakte Positionierung erfordert. Meine Hoffnng ist hier, dass die Rückmeldungen des Decoders das Einmessen und Anpassen des Decoders an iTrain vereinfachen, wenn z.B. die Geschwindigkeitsrückmeldung des Decoders der iTrain Software beim Erkennen des Beschleunigungs- und Bremsverhaltens hilft.
Das Thema der RailCom Kanäle ist dann relevant, wenn man sehr viele Modelle hat und auch mehrere Modelle im gleichen Meldeabschnitt stehen können. Bei opendcc.de ist nachzulesen, dass sich die Adressmeldungen via Kanal 1 bei mehrerer Modelle in einem Meldeabschnitt gegenseitig stören. Daher wird die automatische Abschaltung von Kanal 1 empfohlen. Ich habe heute Test mit ESU und Zimo Decodern durchgeführt, um dieses Verhalten zu testen. Dazu habe ich bei zwei Modellen mit ESU LokSound V5 jeweils den CV28 auf 131 programmiert und somit beide RailCom Kanäle aktiviert. Dann habe ich beide Modelle in einen Meldeabschnitt gestellt und die Versorgungsspannung eingeschaltet. Der BiDiB Wizard zeigt mir diesen Block als belegt an, kann aber die Adressen der Modelle nicht lesen. Bewege ich die Modelle in unterschiedliche Meldeabschnitte, dann kommt sofort eine Adressmeldung. Den gleichen Test habe ich mit zwei Modellen mit Zimo MX645 durchgeführt. Auch hier erfolgt keine Adressmeldung, wenn die Modelle bei Einschalten der Versorgungsspannung im gleichen Meldeabschnitt stehen. Das Bestätigt die Aussage von vik, wonach Zimo Decoder keine automatische Abschaltung von RailCom Kanal 1 haben. Natürlich kann man nun wieder iTrain zu Hilfe nehmen. iTrain initialisiert beim Starten alle angelegten Modelle, so dass die RailCom Kommunikation auf Kanal 2 für diese Modelle aktiv wird. Dadurch werden dann auch die Adressen der Modelle gelesen, die im gleichen Meldeabschnitt stehen oder bei denen Kanal 1 abgeschaltet ist. Das Initialisieren aller aktiven Modelle durch iTrain hat aber auch einen Nachteil. Je mehr Modelle in iTrain angelegt und aktiv sind, desto langsamer wird die Kommunikation. Das merkt man daran, dass z.B. ein Rangierspiff nicht kommt, wie er soll, weil einfach die Verzögerung länger ist, als die Funktion aktiv ist. Auf einer Clubanlage können schon mal über 100 Modelle in iTrain angelegt sein. Davon fahren bei uns aber immer nur max. 20 Modelle gleichzeitig auf der Anlage. Im muss also immer die nicht auf der Anlage benötigten Modelle in iTrain auf inaktiv setzen, damit die Kommunikationsverzögerung nicht zu groß wird. Wenn also alle Deocder Hersteller eine automatische Abschaltung von RailCom Kanal 1 in ihre Decopder implementieren würden, dann könnte iTrain die initialisierung weg lassen und jedes Modell würde sich selbst an iTrain anmelden, sobald es auf dem Gleis steht. iTrain könnte dann die Kommunikation auf die gemeldeten Modelle beschränken, ohne dass man Modelle manuell deaktivieren müsste.
Wenn ich die im Netz verfügbaren Informationen zu DCC-A richtig verstanden habe, dann soll DCC-A das RailComPlus ersetzen. RailComPlus habe ich in allen meinen ESU Decodern aktiv. Damit melden sich die ESU Decoder bei meiner ECOS an und senden die Belegung der Funktionstasten an die ECOS. Bei nicht RailComPlus fähigen Zentralen, wie BiDiB funktioniert das Anmelden via RailComPlus nicht. Aktuell habe ich keine Zentrale und keine Deoder mit DCC-A Unterstützung.
Viele Grüße
Heiko

Hallo Heiko,

Zitat von mueller.heik im Beitrag #10

---

das Thema RailCom Rückmeldungen ist für mich interessant, um die Anläufe auf unserer Clubanlage zu optimieren. Diese wird mit iTrain automatisch gesteuert. Hierfür ist ein sehr aufweniges Einmessen jeder einzelnen Lok erforderlich.

---

Zitat von mueller.heik im Beitrag #10

---

Dazu kommt, dass die Anfahr- und Bremsverzögerungen angepasst und zusätzlich eine Reaktionsverzögerung eingestellt werden muss.

---

Zitat von mueller.heik im Beitrag #10

---

Ich habe dafür einige Testfahrten erstell,.... Trotzdem sind immer wieder mal unterschiedliche Stopppositionen von Loks in verschiedenen Blocks der Anlage zu sehen. Kritisch ist hier vor allem die Drehscheibe, da diese bei manchen Modellen nur 1cm länger ist und daher eine sehr exakte Positionierung erfordert.

---

Zitat von mueller.heik im Beitrag #10

---

Meine Hoffnng ist hier, dass die Rückmeldungen des Decoders das Einmessen und Anpassen des Decoders an iTrain vereinfachen, wenn z.B. die Geschwindigkeitsrückmeldung des Decoders der iTrain Software beim Erkennen des Beschleunigungs- und Bremsverhaltens hilft.

---

Zitat von mueller.heik im Beitrag #10

---

Das Thema der RailCom Kanäle ist dann relevant, wenn man sehr viele Modelle hat und auch mehrere Modelle im gleichen Meldeabschnitt stehen können. Bei opendcc.de ist nachzulesen, dass sich die Adressmeldungen via Kanal 1 bei mehrerer Modelle in einem Meldeabschnitt gegenseitig stören. Daher wird die automatische Abschaltung von Kanal 1 empfohlen.

---

Zitat von mueller.heik im Beitrag #10

---

Je mehr Modelle in iTrain angelegt und aktiv sind, desto langsamer wird die Kommunikation.

---

Zitat von mueller.heik im Beitrag #10

---

Wenn ich die im Netz verfügbaren Informationen zu DCC-A richtig verstanden habe, dann soll DCC-A das RailComPlus ersetzen.

---

Hallo Heiko,

Ich interessiere mich schon seit Jahren leidenschaftlich für das Thema Railcom, da ich enormes Potenzial zur Optimierung der Steuerung sehe. Im Prinzip entsteht durch die Rückkopplung ein Regelkreis. Im einfachsten Fall weiß die Zentrale, dass ein Decoder einen Befehl erhalten hat und muss diesen daher nicht wiederholen. Der DCC-Refresh-Stack, der das Grundübel der DCC-Skalierbarkeit darstellt, kann entrümpelt werden. Ergebnis: 80 Decoder im System sind kein Problem mehr bei nahezu konstanten Reaktionszeiten auf Befehle.

Aber Railcom bietet, wie Du es so schön beschrieben hast, noch weitere nette Annehmlichkeiten: Decoder können sich automatisch registrieren, Telemetriedaten senden und schnell programmiert werden. Selbst Firmware-Updates auf der Hauptstreckeoder, oder irgendwo im SBH, sind kein Problem mehr.

Hier sind einige Beispiele für die tollen Dinge, die ich mit Railcom mache:

Automatische Anmeldung (Decoder-Erkennung)

Hier wurden automatisch 32 Decoder auf meinem System erkannt, mit Produktname, Hersteller und, falls vorhanden, Firmware-Version. Die Registrierung dieser 32 Decodern mit DCC-A dauert nur wenige Sekunden. Ich muss nichts mehr tippen, keine Adressen verwalten usw. Ich stelle die Loks auf Gleis und los geht's. Ich will nix anderes mehr haben.




Railcom live Daten

Hier sehen wir, was für schöne Dinge meine 32 Decoder senden. Viele senden Geschwindigkeit und QoS, einige senden dann Temperatur oder die Gleis Spannung. Die Zimos senden Ost-West-Informationen ... das ist neu. Meine Decoder senden Motorstrom, CPU-Auslastung und noch vieles mehr. Ich kann mich für so etwas wirklich begeistern.




DCC Stack entruempelt

Noch ein paar Worte zum DCC-Repeater-Stack. Schaut man sich meinen DCC/Railcom-Trace an, sieht man deutlich, wie „leer“ dieser Stack mit 32 Decodern noch ist. Die Befehle „ff00ff“ in der Spalte 'dcc' bedeuten IDLE, die Zentrale hat hier also nichts zu tun. Dazwischen liegen verstreut die Befehle an die Decoder, die sofort mit Railcom quittiert werden (Spalte = ch2). So weiß meine Zentrale, dass der Befehl verstanden wurde und nicht mehr wiederholt werden muss.




Wenn Sie mich fragen, ist Railcom die Zukunft. Es eröffnet definitiv neue Möglichkeiten. Deshalb würde ich auf Railcom-kompatible HW/SW achten.

Hallo Frank,

vielen Dank für Deine detaillierten Erläuterungen

Zitat von fschum im Beitrag #12

---

Wenn Sie mich fragen, ist Railcom die Zukunft. Es eröffnet definitiv neue Möglichkeiten. Deshalb würde ich auf Railcom-kompatible HW/SW achten.

---