Messungen Railcom-Timings

#1 von ukw , 01.10.2024 23:49

Liebe Stummis,

anlässlich meiner geschilderten Probleme mit Railcom und einem LD-G-42-Decoder von TAMS (nachzulesen hier: TAMS Decoder LD-G-42 - Railcom Bugs?) habe ich mir mal die Railcom-Daten diverser Lok- und Funktionsdecoder näher angeschaut. Dabei interessierte mich hauptsächlich das verwendete Timing, weil meine selbst entwickelte DCC-Steuerungszentrale nebst Railcom-Detektor (siehe Vereinfachter globaler RailCom-Detector) konkret mit dem TAMS-Decoder Railcom-Empfangsprobleme hatte. Die Empfangsprobleme äußerten sich so, dass die RailCom-Daten des TAMS-Decoders im Kanal 1 oft so spät gesandt wurden, dass sie in den Zeitbereich von Kanal 2 "hineinagten". Da RC1-Daten in der Regel immer gesendet werden, solange man sie nicht per Konfiguration ausschaltet, störten diese Daten den Empfang von Railcom-Daten anderer Decoder im Kanal 2.

Nach RCN217 sieht das Timing folgendermaßen aus:



Demnach beginnen die Daten im Kanal 1 nach TTS1=80µs (besser 75µs, siehe Bemerkung) und enden spätestens nach TTC1=177µs. Die Daten im RC-Kanal 1 bestehen immer aus 2 Bytes, die mit einer Baudrate von 250.000Bd übertragen werden. Jedes Byte besteht aus 1 Startbit, 8 Bit Daten und 1 Stoppbit. Damit ergibt sich eine minimale Dauer von 2 x 40µs = 80µs für die Übertragung.

Ich habe nun für diverse Decoder gemessen, wann sie mit der Übertragung der Daten aus Kanal 1 (TTS1) und der Übertragung der Daten aus Kanal 2 (TTS2) begannen. Gemessen habe ich für diverse Railcom-fähige Decoder folgendes:



Dabei ist die Zeitauflösung jeder Messung 2µs. Es wurden für jeden Decoder 2000 Messungen im RC1-Kanal und 200 Messungen im RC2-Kanal vorgenommen. Naturgemäß ergeben sich Schwankungen, so dass ich Minimal-, Maximal-, Durchschnitts- und Differenzwerte angegeben habe. Auffallend ist, dass die Schwankungen bei den TAMS-Decodern am größten sind.

Für die Decoder ESU Lokpilot 5, Lenz Standard+ und Zimo 630 ergibt sich, dass die Daten für Kanal 1 (RC1) spätestens nach 96µs beginnen und nach 96µs + 80µs = 176µs enden. Damit halten sie auch für die gemessenen Maximalwerte die Vorgaben von 80µs bis 177µs ein.

Anders sieht es aus für die übrigen Decoder. Dabei sind die Werte für Viessmann 5244, TAMS LD-G-42 und LD-W-42 mit maximal 104µs bzw. 100µs nur etwas über dem Zeitfenster, da hier der TTC1-Wert (Ende Kanal 1) mit 184µs bzw. 180µs knapp überschritten werden. Das lässt sich aber durch eine Korrektur der Railcom-Detector-Software leicht beheben, indem man das Zeitfenster ein paar Mikrosekunden länger offen lässt. Man ist ja tolerant .

Bei dem Funktionsdecoder FD-R Basic.3 von TAMS sind allerdings die Maximalwerte so groß, dass hier TTC1 mit 130µs + 80µs = 210µs oft in den Kanal 2 "hineinragt". Hier wird TTS2 = 193µs glatt überschritten. Die Auswirkung ist, dass die RC1-Daten, welche in der Regel in jedem Cutout gesendet werden, die RC2-Daten anderer Decoder, welche durchaus die Spezifikationen einhalten (wie z.B. ESU, Lenz und Zimo) "kaputtschreiben". Das passiert nicht jedes Mal, aber in ca. 40% aller Fälle. Das heißt: Nur in 60% aller Fälle lassen sich dann die RC2-Daten überhaupt noch auswerten, sobald nur ein FD-R Basic.3 Dekoder auf der Anlage im RC1 aktiv ist.

Fazit:

Das Problem kann man nur dadurch beheben, dass man im FD-R Basic.3 Decoder den RC1-Kanal sperrt. Dann kann dieser nicht mehr stören und die Detection-Rate für alle anderen Decoder im RC2-Kanal steigt wieder auf 100%.

Warum ich so auf dem FD-R Basic.3 Decoder herumreite:

Ich benutze den FD-R Basic.3 Decoder sehr gerne in Märklin Loks, deren Original-Märklin-Decoder zwar schon DCC unterstützt, aber (noch) kein Railcom kann. Dann baue ich die kleine Platine einfach zusätzlich in die Lok, schließe einfach nur die Spannungsversorgung an und setze die Adresse gleich der Lokadresse. Schon kann ich die Lok auf der ganzen Anlage mittels RC2-Kanal lokalisieren. Sehr billig und ungeheuer praktisch.

P.S.

Zum Zeitverhalten für den Kanal 2 (RC2) kann ich nur bemerken, dass alle Decoder hier die Vorgabewerte einhalten. Das ist auch nicht weiter verwunderlich, da im RC2-Kanal bis zu 6 Bytes gesendet werden können. Die TAMS-Decoder verhalten sich zwar auch hier von den Timings sehr "großzügig", senden jedoch viel weniger Daten im Kanal 2 und reichen somit niemals bis an das Ende des Kanals 2 (TTC1=454µs) heran.


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022

zuletzt bearbeitet 01.10.2024 | Top

RE: Messungen Railcom-Timings

#2 von ukw , 09.10.2024 20:12

Hallo,

es gibt ein Update:

Ich hatte vor ein paar Tagen mal wieder bei TAMS ein paar FD-R Basic.3 bestellt. Nun sind sie angekommen. Als erstes habe ich die CV7 (Versionsnummer) ausgelesen. Die beiden älteren FD-R, die ich vor ein paar Tagen gemessen hatte, hatten hier den Wert 11 bzw. 12, die neuen FD-R haben nun die Versionsnummer 23!

Also habe ich die Railcom-Timings hier neu gemessen. Ergebnis:



Die bisherigen enormen Schwankungen sind verschwunden. TTS1 schwankt zwar immer noch um 20µs, bleibt allerdings in der oben erklärten "Toleranz". Die RC1-Daten ragen nun nicht mehr in den Kanal 2 hinein und überschreiben damit auch nicht mehr die RC2-Daten anderer Decoder. Ich kann also bei den neueren FR-R Basic.3 Modulen den Kanal 1 weiterhin aktiviert lassen.

Erfreulich ist, dass TAMS hier den Fehler behoben hat.

Viele Grüße

Frank


vikr, bertr2d2, fbstr, croc, apras, GCS88 und Sonnenbrot haben sich bedankt!
ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#3 von fschum , 14.10.2024 23:13

Hallo,

Ich kann die Timing-Probleme beim FD-R Basic.3 bestätigen. Das Minimum reicht bei TTS2 bis hinunter zu 183us, was 10us zu früh ist. Und mindestens genauso gravierend sind die vielen Railcom-Fehler (mis2). Der Decoder hätte reagieren sollen, tut es aber nicht. Auch der alte MX621 kämpft mit dem „mis2“-Problem, bei den beiden TAMS ist das Problem jedoch deutlich größer. Der FD-R hat einen CV7=20 und der LD-G-41 hat einen CV7=10.

Meine Selbstbau Zentrale logged ebenfalls das Railcom Timing im Betrieb. Hier die Statistiken von 29 Decodern nach ca. 30 Minuten Betriebszeit.


MfG,
Frank


vikr, Vincent Hamp, fbstr, Draisine, ukw, apras und Sonnenbrot haben sich bedankt!
 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#4 von Vincent Hamp , 15.10.2024 06:39

Danke für die Arbeit und das Teilen dieser Ergebnisse. Die Mitglieder der RailCommunity könnten sich hier was abschaun (ZIMO inklusive)!


zimo.at


 
Vincent Hamp
InterRegio (IR)
Beiträge: 103
Registriert am: 28.10.2022
Ort: Wien


RE: Messungen Railcom-Timings

#5 von fschum , 15.10.2024 09:27

Hallo,

Wenn ich das Kanal-2 timing vom LD-G-41 mitschneide, dann erkenne ich, dass dieser nahezu immer unterhalb des Minimums (gruene Linie) liegt. Das ist nicht so toll und stresst die Railcom Detektoren wie 'ukw' oben bereits geschrieben hatte.

Aus der Vogelperspektive sieht das alles erstmal recht gut aus.




Wenn man allerdings naeher 'rein zoome, erkennt man, dass der Decoder im Kanal-2 bis auf weniger Ausnahmen, deutlich zu frueh sendet. Der Decoder sollte oberhalb der gruenen Linie senden und nicht unterhalb.




Es freut mich daher zu lesen, dass TAMS an dem Thema arbeitet!


MfG,
Frank


vikr und ukw haben sich bedankt!
 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#6 von ukw , 15.10.2024 10:22

Hallo Namensvetter,

Zitat von fschum im Beitrag #5
Es freut mich daher zu lesen, dass TAMS an dem Thema arbeitet!


Ich muss leider meinen obigen Satz

Zitat von ukw im Beitrag #2
Erfreulich ist, dass TAMS hier den Fehler behoben hat.


leider etwas relativieren. Auch bei der Version 23 (CV7) des FD-R Basic.3 kann ich noch vereinzelt beobachten, dass die TAMS-Daten des RC-Kanals 1 die RC2-Daten anderer Decoder "kaputtschreiben". Gerade die Lokpilot-5- und LokSound-5-Decoder von ESU werden hier in Mitleidenschaft gezogen. Hier müsste ich nochmal konkretere Messungen machen, um das zu untermauern. Da ich im Moment immer nur TTS1 messe, ich aber gar nicht weiß, wie weit Byte1 und Byte2 im RC1-Kanal zeitlich auseinanderliegen, kann ich über TTC1 schlecht Aussagen machen. Ich rechne hier einfach mit 2 x 40µs für die beiden Bytes, was aber nicht unbedingt der Wahrheit entsprechen muss. Hier müsste ich mal mit einem Logik-Analysator an die Sache, um die Daten komplett von vorn bis hinten aufzuzeichnen.

Du hast ja gerade das Railcom Kanal-2 Timing untersucht. Kannst Du auch entsprechende Aussagen über Kanal 1 machen, insbesondere über TTC1?

Viele Grüße

Frank


vikr hat sich bedankt!
ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#7 von fschum , 15.10.2024 11:41

Hallo Frank,

hier waere das Kanal-1 Timing.

Im obene Bild wieder die Vogelperspektive und unten dann 'rein gezoomed.

  • links, von 0-2500: Der Motor ist gestoppt
  • rechts, von 2500-4500: Der Motor dreht ...


Man erkennt, dass zum einen die Timing-Ausreisser bei drehendem Motor groesser werden und zum anderen im oberen Graphen auf der x-Achse zahlreiche 'Null'-Werte bei drehendem Motor. Hier 'vergisst' der Decoder die Railcom Meldungen zu senden. Die Vermutung liegt nahe, dass der Motor-Treiber CPU resourcen nicht rechtzeitig freigibt.



MfG,
Frank


ukw hat sich bedankt!
 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#8 von ukw , 15.10.2024 12:20

Hallo Frank,

Zitat von fschum im Beitrag #7
Man erkennt, dass zum einen die Timing-Ausreisser bei drehendem Motor groesser werden


super, vielen Dank! Das ist echt krass: Alle TTS1-Werte größer 97µs sind eigentlich schon außerhalb der Spezifikation, alle TTS1-Werte größer 113µs ragen auf jeden Fall in den RC2-Kanal hinein, weil sie TTS2 = 193µs überschreiten. Ist das jetzt Dein LD-G-41?

Mich würde der FD-R Basic.3-Decodern noch mehr interessieren, weil ich hier die größten Abweichungen - zumindest in den älteren Versionen - gemessen habe.

Zitat von fschum im Beitrag #7
Hier \'vergisst\' der Decoder die Railcom Meldungen zu senden.


Auch im RC-Kanal 2 oder nur RC-Kanal 1?

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#9 von vikr , 15.10.2024 12:33

Hallo,

finde das sehr interessant, bin aber gleichzeitig echt erschüttert und enttäuscht. Immerhin sind diese Basics der Railcom-Technik seit zwanzig Jahren spezifiziert. Es gab zwar immer schon auch irgendwie dokumentierte Probleme:
http://www.opendcc.de/info/railcom/railc...r_overview.html
aber diese Decoder (FD-R-Basic-3 und die LD-G-41/2 ) gibt es ja nicht erst seit gestern und führen schon immer zu Problemen, deren Ursache - weniger messtechnisch ambitionierte - Modellbahner nie zuordnen können. RailCom wurde damit ein Bärendienst erwiesen.

Kurzfristig muss man wohl alle mit diesen Produkten ausgestatteten Fahrzeuge umbauen. Wenn ein Fixen des Problems mit einem Firmware-Update überhaupt möglich ist, wird es wohl ein Weilchen dauern.
Aber wie sieht es mit den stationären Railcom fähigen Decodern und ihren Railcom-Nachrichten desselben Herstellers aus?

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


Freetrack und ukw haben sich bedankt!
vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#10 von fschum , 15.10.2024 13:26

Hallo Frank,

Zitat von ukw im Beitrag #8
Mich würde der FD-R Basic.3-Decodern noch mehr interessieren


Ok, hier der FD-R Basic.3 im Kanal-1. Sieht erstmal garnicht so schlecht aus. Ich sehe 'nur' zwei Railcom 'misses'. Einen bei 1500 und den anderen bei ca. 3600.




Zitat von vikr im Beitrag #9
Kurzfristig muss man wohl alle mit diesen Produkten ausgestatteten Fahrzeuge umbauen.


Wenn man Railcom nicht nutzt, dann kann einem diese Diskussion hier herzlich egal sein. Aber fuer alle Railcom'er unter uns ist die Einhaltung der Norm sicher schon sehr wichtig, weil es sonst eben zu diesen Kompatibitaetsproblemen kommt, von denen 'ukw' berichtet.

Zitat von vikr im Beitrag #9
... führen schon immer zu Problemen, deren Ursache - weniger messtechnisch ambitionierte - Modellbahner nie zuordnen können. RailCom wurde damit ein Bärendienst erwiesen.


100% Zustimmung.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Messungen Railcom-Timings

#11 von ukw , 15.10.2024 13:44

Hallo Frank,

Zitat von fschum im Beitrag #10
Ok, hier der FD-R Basic.3 im Kanal-1. Sieht erstmal garnicht so schlecht aus.


Vielen Dank, da stimme ich Dir zu, auch wenn das schon arg knapp aussieht. Da sind einige mit TTS1 größer als 100µs dabei, so dass nicht unbedingt auszuschließen ist, dass sie mit dem Senden vor TTS2 = 193µs wirklich fertig sind. Die 177µs als TTC1 (Kanal 1 Ende) werden sie jedenfalls nicht mehr einhalten können. Das werde ich mir auf jeden Fall nochmal genauer anschauen.

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#12 von ukw , 15.10.2024 14:09

Hallo vik,

Zitat von vikr im Beitrag #9
RailCom wurde damit ein
Zitat von fschum im Beitrag #10
FD-R Basic.3

Bärendienst erwiesen.


Es kommt wohl immer auf die Schwerpunkte an, auf die ein Modellbahner setzt. Ich nehme mal an, dass vielen Modellbahnern erstmal RailCom vollkommen egal ist. Aber es gibt natürlich auch die technikbegeisterten, die immer nah an der Entwicklung sein möchten. Denen geht es wahrscheinlich viel zu langsam mit RailCom.

Meiner Meinung nach könnte das alles viel schneller (und besser) gehen mit der Entwicklung. Aber da die Hersteller alle eigene Interessen haben, setzen die einen auf das für die Öffentlichkeit nicht zugängliche RailCom-Plus, die anderen auf das offen dokumentierte DCC-A. So wird das nie irgendwas richtiges. Ich überlege zwar, DCC-A für meine Zentrale einzubauen, mache mir aber Gedanken, ob das zielführend ist. Wieviele Hersteller unterstützen denn DCC-A? Ich kenne nur zwei... das ist mir eigentlich zu wenig. Das "geheime" RailCom-Plus hilft mir da auch nicht weiter.

Zitat von vikr im Beitrag #9
Kurzfristig muss man wohl alle mit diesen Produkten ausgestatteten Fahrzeuge umbauen.


Oder einfach den Kanal 1 abschalten, zumindest konkret beim FD-R Basic.3. Das reicht mir, da ich den Kanal1 für den Anlagenbetrieb ziemlich uninteressant finde. Das sind einfach nur verschenkte Ressourcen, die man besser nutzen könnte.

Zitat von vikr im Beitrag #9
Wenn ein Fixen des Problems mit einem Firmware-Update überhaupt möglich ist, wird es wohl ein Weilchen dauern.


Bei so einem Billigdecoder wie dem FD-R Basic.3 lohnt sich wohl die Anschaffung eines Programmiergerätes nicht. Besser man kennt die Schwächen und weicht gegebenenfalls besser direkt auf funktionsfähige Alternativen aus. Da muss ich die Decoder von ESU, Zimo und auch Lenz schon mal loben: Die Dinger funktionieren gut und halten sich an die Regeln (RC-xxx). Wobei Lenz da in der Entwicklung ein wenig progressiver sein könnte. Aber das ist nur mein persönlicher Eindruck.

Zitat von vikr im Beitrag #9
Aber wie sieht es mit den stationären Railcom fähigen Decodern und ihren Railcom-Nachrichten desselben Herstellers aus?


Keine Ahnung, ich habe keine stationäre Decoder. Ausnahme: Ein selbstentwickelter 8-fach RailCom-Detektor, der die Standorte der Loks an die Zentrale meldet. Da dieser aber drahtgebunden ist, macht er die RailCom-Meldungen nicht über die Schiene (da zusätzlicher Hardware-Aufwand), sondern direkt über den vorhandenen RS485-Bus. Zwei Fliegen, eine Klappe .

EDIT: Eigentlich sind es sogar 4 Fliegen: Der Detektor kann nebenbei Programm- und Ereignis-gesteuert auch noch 4 Signale und ein paar Dutzend WS2812-LEDs steuern.

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#13 von fschum , 15.10.2024 15:22

Hallo,

Zitat von ukw im Beitrag #12
Ich überlege zwar, DCC-A für meine Zentrale einzubauen, mache mir aber Gedanken, ob das zielführend ist. Wieviele Hersteller unterstützen denn DCC-A? Ich kenne nur zwei...


Ist zwar nicht das Thema hier, aber dann will ich eine Lanze fuer DCC-A brechen ...

Ich kenne derzeit auch nur zwei Firmen die das unerstuetzen: TAMS + Zimo (+ meine Eigenbau Dekoder). Vergiss Railcom+ ... ich denke DCC-A ist besser. Lok aufs Gleis setzen - 'plopp ... angemeldet ... losfahren'. Ich plane in Zukunft ausschliesslich Decoder einzusetzen, die das koennen. Aber weil DCC-A sich derzeit staendig weiterentwickelt (endlich tut sich mal was!!!) *muss* ein solcher Decoder auch Firmware update koennen - und zwar zwingend!!. Da bleibt dann momentan nur Zimo (und meine selbstbau Decoder). Ich denke das wird mittelfristig der Durchbruch fuer Railcom werden.



MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Messungen Railcom-Timings

#14 von ukw , 15.10.2024 15:50

Hallo Frank,

Zitat von fschum im Beitrag #13
aber dann will ich eine Lanze fuer DCC-A brechen ...


Hast mich überzeugt! Ich hoffe dann mal, dass die anderen Hersteller irgendwann in diesem Jahrhundert nachziehen werden...

Gibt es da zum Thema DCC-A noch weitere Quellen als RC-218?

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#15 von vikr , 15.10.2024 16:19

Hallo Frank(ukw),

Zitat von ukw im Beitrag #12
Oder einfach den Kanal 1 abschalten, zumindest konkret beim FD-R Basic.3. Das reicht mir, da ich den Kanal1 für den Anlagenbetrieb ziemlich uninteressant finde.
ich dagegen nutze vor allem Kanal 1 (auch wenn ich mir wünschen würde, dass die lange Adresse plus einer CRC in einer Kanal 1 Nachricht im Klartext übertragen werden könnte). Was es aber unbedingt in den RailCom-Detektoren braucht ist eine Kollosionsmeldung, wenn mehr als eine Adresse empfangen wird. Gelegentlich nutze ich natürlich auch das PoM-Lesen, aber die neueren Nachrichten der Railcom-Community sind aus meiner Sicht überflüssig bzw. sogar häufig irreführend, wenn man mehr als zehn Fahrzeuge im Anlagenbetrieb einsetzt...
Das von Lenz designte Railcom kann auch ohme PC bzw. Modellbahn-Steuerprogramm fast perfekt funktionieren, wenn es die Kollosionsmeldung gäbe.
Für BiDiB benötigt man aufwendige und teure Komponenten, die jederzeit komplexe Daten halten und persistent speichern. Da kann ich als Modellbahner die Steuerung meiner Anlage auch allein einem der verbreiteten Modellbahn-Steuerprogramm übertragen.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#16 von fschum , 15.10.2024 17:08

Zitat von ukw im Beitrag #14
Hast mich überzeugt!


Puh, das ging aber schnell - ich sollte ins Marketing wechseln

Ich schlage vor, wir machen fuer das DCC-A Thema einen neuen Thread auf. Da koennen wir dann alles weitere debattieren. Hier geht es um Railcom Timing ...


Zitat von vikr im Beitrag #15
aber die neueren Nachrichten der Railcom-Community sind aus meiner Sicht überflüssig bzw. sogar häufig irreführend, wenn man mehr als zehn Fahrzeuge im Anlagenbetrieb einsetzt...


Das wuerde mich interessieren wo bzw. was irrefuehrend ist. Sollte das so sein, muss man das verbessern.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Messungen Railcom-Timings

#17 von vikr , 15.10.2024 17:22

Hallo Frank,

Zitat von fschum im Beitrag #16
ich sollte ins Marketing wechseln [quote="vikr"|p2729524]
Zitat von fschum im Beitrag #16
Das wuerde mich interessieren wo bzw. was irrefuehrend ist. Sollte das so sein, muss man das verbessern.
"ins Marketing gehen" und (technisch) "das verbessern" passt eigentlich nicht zusammen.
Zitat von fschum im Beitrag #16
Das wuerde mich interessieren wo bzw. was irrefuehrend ist. Sollte das so sein, muss man das verbessern.
das passt aber inhaltlich auch nicht mehr richtig in diesen Lücken-Timing-Test!

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#18 von ukw , 15.10.2024 17:26

Hallo vik,

Zitat von vikr im Beitrag #15
ich dagegen nutze vor allem Kanal 1 (auch wenn ich mir wünschen würde, dass die lange Adresse plus einer CRC in einer Kanal 1 Nachricht im Klartext übertragen werden könnte).


Wofür? Um den Ort einer Lok zu bestimmen oder um eine neu aufs Gleis gestellte Lok zu erkennen?

Ich selbst interessiere mich beim globalen RailCom-Detektor nur für den Kanal 2, da im Kanal 1 ab zwei Loks auf dem Gleis nur noch Quark ankommt. Die Ortsbestimmung mache ich über lokale 8-fach RalCom-Detektoren, die einfach nur schauen, ob sich gerade lokal etwas im Kanal 2 tut. So kann ich beliebig viele(!) Loks innerhalb eines lokalen Abschnitts erkennen und melden: "Die Lok ist hier!". Die Information, ob eine Kollision im Kanal 1 stattfand, brauche ich daher nicht.

Zitat von vikr im Beitrag #15
Was es aber unbedingt in den RailCom-Detektoren braucht ist eine Kollosionsmeldung, wenn mehr als eine Adresse empfangen wird.


Das ist einfach. Wenn der Hamming-Code einen Fehler meldet, dann ist die Wahrscheinlichkeit einer Kollision sehr groß. Das kann meine Zentrale detektieren und damit automatisch die Daten im Kanal 1 verwerfen. Leider kommt es in seltenen Fällen trotz Kollision vor, dass der Hamming-Code gültig ist. Der Hamming-Code ist nur ein notwendiges, aber leider kein hinreichendes Kriterium für die Gültigkeit der Daten.

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022


RE: Messungen Railcom-Timings

#19 von ukw , 15.10.2024 17:33

Hallo vik,

Zitat von vikr im Beitrag #17
das passt aber inhaltlich auch nicht mehr richtig in diesen Lücken-Timing-Test!


Machst Du einen neuen Thread "Railcom Kanal 1 vs Kanal 2" dafür auf? Die Weiterführung der Diskussion bzgl. Sinn und Unsinn von RailCom Kanal 1 vs Kanal 2 würde mich schon interessieren.

Hallo Frank

Zitat von fschum im Beitrag #16
Ich schlage vor, wir machen fuer das DCC-A Thema einen neuen Thread auf.


Gute Idee! Machst Du einen Thread für DCC-A auf oder soll ich das? Ich komme aber wohl heute erst spätabends dazu.

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#20 von vikr , 15.10.2024 19:19

Hallo Frank,

Zitat von ukw im Beitrag #18
Zitat von vikr im Beitrag #15
ich dagegen nutze vor allem Kanal 1
Wofür? Um den Ort einer Lok zu bestimmen...
ja, vor allem, um jederzeit eine Meldung zu bekommen, welches Fahrzeug gerade auf einem bestimmten Abschnitt ankommt und ggf. davon abhängig zu entscheiden (zu lassen), ob sofort! eine von mehreren - bereits vorab geplanten Aktionen - eingeleitet werden kann/soll etc.
Ich bin übrigens auch als Teppich, Tisch und Parkettbahner unterwegs.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#21 von ukw , 15.10.2024 22:05

Hallo vik,

Zitat von vikr im Beitrag #20
ja, vor allem, um jederzeit eine Meldung zu bekommen, welches Fahrzeug gerade auf einem bestimmten Abschnitt ankommt und ggf. davon abhängig zu entscheiden (zu lassen), ob sofort! eine von mehreren - bereits vorab geplanten Aktionen - eingeleitet werden kann/soll etc.


Ja, aber das geht doch auch über den Kanal 2. Die Zentrale sendet zyklisch Kommandos an alle auf der Anlage befindlichen Decoder und bekommt (hoffentlich) von allen auch auf dem Kanal 2 ein ACK (oder andere dynamische Infos) zurück. Zack, hat der lokale RailCom-Detektor den Decoder an der Angel und kann den Ort an die Zentrale melden.

So sieht das mit Aktionen auf meiner Zentrale aus - wahlweise für Einfahrt oder Ausfahrt auf einem Streckenabschnitt, der von einem lokalen RailCom-Detector überwacht wird:



Der RailCom-Kanal 1 ist dabei nicht vonnöten.

Viele Grüße

Frank


fschum hat sich bedankt!
ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022

zuletzt bearbeitet 15.10.2024 | Top

RE: Messungen Railcom-Timings

#22 von vikr , 15.10.2024 23:48

Hallo Frank,

Zitat von ukw im Beitrag #21
Ja, aber das geht doch auch über den Kanal 2. Die Zentrale sendet zyklisch Kommandos an alle auf der Anlage befindlichen Decoder und bekommt (hoffentlich) von allen auch auf dem Kanal 2 ein ACK (oder andere dynamische Infos) zurück. Zack, hat der lokale RailCom-Detektor den Decoder an der Angel und kann den Ort an die Zentrale melden.
ja, wenn es nur eine handvoll Fahrzeuge gibt, funktioniert das einigermaßen mit entsprechender Hard/Software, die den ACK des Decoders dem richtigen DCC-Paket und dem richtigen Abschnitt zuordnet. Aber bei mehr als ein paar adressierten Fahrzeugen im Zyklus, kann man ein ziemliches Delay haben, bis der aufrufende DCC-Befehl überhaupt aufs Gleis abgesetzt wird und vor allem einen völlig unkontrollierbaren Jitter.
Die Kanal-1 Meldung kommt dagegen in dem Detektor-Abschnitt im der nächsten Lücke, d.h. praktisch sofort.

Melde in Deiner Zentrale mal einfach fünfzig oder sechszig Loks an. Mit einer z21 geht das ganz einfach (Maximum ist 99) und dort kannst Du auch leicht in den Protokollen nachsehen, wann der ACK - als Antwort auf den nächsten adressierten Befehl an den Decoder ankommt, der gerade in den interessierenden Abschitt einfährt. Aber auch bei zwei Dutzend Loks kann das schon zu lange dauern, um z.B. eine notwendige Vollbremsung auszulösen...

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


Karst Drenth hat sich bedankt!
vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 16.10.2024 | Top

RE: Messungen Railcom-Timings

#23 von vikr , 16.10.2024 09:45

Hallo Frank,

Zitat von ukw im Beitrag #1
Warum ich so auf dem FD-R Basic.3 Decoder herumreite:

Ich benutze den FD-R Basic.3 Decoder sehr gerne in Märklin Loks, deren Original-Märklin-Decoder zwar schon DCC unterstützt, aber (noch) kein Railcom kann.
ist übrigens genau derselbe Grund, warum ich die Tams FD-R Basic gern eingesetzt habe, allerdings um eine Kanal-1 Rückmeldung zu bekommen. Mit der alten Tamszemtrale "MC1" klappte das seit 2008 bei mir meist ganz gut.
RE: Testbericht Tams FD-R Basic (RailCom fuer DCC und MM)
Jetzt wird vielleicht auch klar, warum das mit dem FD-R Basic3 nicht immer so gut klappt.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
Trans Europ Express (TEE)
Beiträge: 7.738
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 16.10.2024 | Top

RE: Messungen Railcom-Timings

#24 von ukw , 16.10.2024 10:41

Hallo vik,

Zitat von vikr im Beitrag #22
Melde in Deiner Zentrale mal einfach fünfzig oder sechszig Loks an.


Ich habe nur 15 Loks . Aber klar, ich könnte einfach mal weitere fiktive 50 Loks anmelden. Ich werde das mit meiner Zentrale testen. Bei dieser ist die theoretische Obergrenze 65535. Soviele DCC-Adressen gibt es gar nicht. Praktisch ist die Obergrenze wohl auch nicht.

Aber mal eine Frage dazu: Wieviele Loks fahren denn tatsächlich gleichzeitig? Ein guter Scheduler gibt den fahrenden Loks eine höhere Priorität als den stehenden, denn letztere stehen nur dumm rum und können überhaupt keine Ereignisse auslösen. Man kann das im Scheduler sogar noch weiter auf die Spitze treiben: Je schneller die Lok, desto höher die Priorität und desto öfter die DCC-Wiederholungsrate gegenüber langsam fahrenden Loks. Der schnelle TGV bei Höchstgeschwindigkeit meldet dann 3 bis 4 mal häufiger seinen Standort als eine müde dahinzuckelnde Dampflok.

Eine weitere Optimierung: Jeder mit einem ACK beantwortete Befehl braucht nicht mehr wiederholt zu werden. Eigentlich muss man dann nur noch Befehle schicken, wenn sich etwas ändern soll, wie zum Beispiel die Geschwindigkeit. Um die Lok jedoch nicht "verhungern" zu lassen und ihr überhaupt noch eine Cance zu geben, sich im RC2-Kanal zu melden, muss man ihr natürlich zyklisch irgendetwas schicken. Deshalb halte ich die Idee, dann nur noch IDLE-Frames zu senden, wie es Frank (fschum) hier RailCom Rückmeldung bei Sound Decodern äußert, für nicht so gelungen. Stattdessen sollte man die Loks mit dem kurzen Befehl "Decoderquittungsanforderung" (RCN-212 Kapitel 2.1.) bei Lust und Laune halten.

All diese Maßnahmen erhöhen den Durchsatz signifikant. Welche davon die Z21 umsetzt (falls überhaupt) weiß ich nicht.

Zur Notbremsung: In diesem Fall sende ich einfach einen Broadcast an alle Loks: Stopp mit Geschwindigkeit 1. Wirkt sofort - egal wieviele Loks angemeldet sind. Und ich muss als Bediener nicht lange überlegen, welche Lok ich denn jetzt konkret stoppen muss. Okay, vielleicht ist das nicht das, was Du bezwecken möchtest

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 83
Registriert am: 06.01.2022

zuletzt bearbeitet 16.10.2024 | Top

RE: Messungen Railcom-Timings

#25 von fschum , 16.10.2024 11:28

Hallo Frank,

Zitat von ukw im Beitrag #24
Deshalb halte ich die Idee, dann nur noch IDLE-Frames zu senden, wie es Frank (fschum) hier RailCom Rückmeldung bei Sound Decodern äußert, für nicht so gelungen.


Das hast Du teilweise missverstanden, bzw. es gibt Gruende fuer IDLE.

Mein Scheduling: Zum einen spreche alle Decoder auf der Anlage zyklisch an, unterscheide aber zwischen fahrenden und stehenden. Fahrende Decoder werden alle 125ms angesprochen. So habe ich eine (nahezu) garantierte Reaktionszeit. Stehende Decoder werden seltener angesprochen, und zwar abhaengig davon wie lange sie stehen. D.h. der Scheduler incrementiert das Intervall zwischen zwei Befehlen successsive fuer stehende Decoder. Minimal wird jeder stehende Decoder alle 2 Sekunden angesprochen. Ereignisse, beispielsweise das Druecken einer Funktionstaste, werden aynchron eingeschoben und haben hoechste Prio. Befehle die keinen Kanal-2 ACK liefern werden sofort wierderholt. Dieses Scheduling skaliert sehr gut. 100 Decoder in einer DCC Domain sind kein Problem.

IDLE: Warum fuelle ich mit IDLE auf. Es gibt zwei Gruende. Erstens ist der IDLE Befehl der 'schnellste' Befehl und dauert nur ca. 6ms. Das ergibt eine kleinstmoegliche 'Totzeit' im Scheduling. Das verbessert die Reaktionszeit speziell auf asynchrone Ereignisse. Ich koennte auch mit Fahrbefehlen auffuellen, aber dann waere die Reaktionszeit wieder abhaengig von der Systemlast - genau das will ich nicht. Das System soll lastunabhaengig immer das Gleiche Verhalten zeigen. Egal ob 1 Lok, 10 Loks oder 100 Loks.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 118
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


   

CV Programmierung CS2 - Frage zum Wertebereich
Dekoder-Umbau bei Roco-Kran

  • Ähnliche Themen
    Antworten
    Zugriffe
    Letzter Beitrag
Xobor Einfach ein eigenes Forum erstellen
Datenschutz