THEMA: Was passiert wenn Lok aus dem refresh fliegt?

Hallo Alex,

ich habe die verschiedenen DCC-Standards schon ein paarmal durchgelesen und ich habe da noch nirgends etwas von eine Gültigkeitsdauer gelesen. Demzufolge müßte eine Lok solange mit der letzten Geschwindigkeit weiterfahren, bis der Strom ausfällt oder sie kaputtgeht Natürlich könnte ein Decoder von sich aus entscheiden, nach einer Zeit (Sekunden) stehenzubleben. Ich bin aber kein Decoder-Experte.

Klaus

Das kommt auf den Decoder an. Bei manchen gibt es einen CV wo man die Zeit einstellen kann.

Sonst hilft probieren, bei DCCEX mit <->

Grüße,
Harald.

Moin Alex,

ich denke auch, die Lok fährt so weiter. Das macht sie ja auch, wenn ich z.B. in der MultMAUS während der Fahrt eine andere Lok wähle und die steuere. Dann fährt die andere so weiter.

Gruß
Jürgen

Zentralen sollten eigentlich eine Fangfunktion haben. Heisst irgendeine andere Adresse wird "aufgegeben". Man sollte aber nicht die volle Kapazität an verwaltbaren Adressen im Arbeitsspeicher ausnutzen, sonst ist Schluß mit hin- und her schieben. Die Multimäuse können das mit Zentralen. Ergo müsste auch eine MoBa Software das können müssen. In JMRI klappt das. Was Apps und andere Handregler so können weis ich nicht.

Wenn du mit der multimaus eine andere Lok wählst fährt deine Zentrale die erste immer noch weiter. Hat mit der Originalfrage nix zu tun.

Im normalen Betrieb wird nix aufgegeben. Da hat die Zentrale eine fixe maximale Anzahl von Adressen  (DCS50 hat 10, IB1 hat 64, große Loconetzentralen 120 wenn ich mich Recht entsinne) die sie steuern kann und wenn man mehr will geht das nicht. Es gibt Zentralen die schmeißen die Lok raus aus der aktiven Liste, aber meines Wissens machen die Zentralen das nur wenn speed=0 und mehrere Minuten nicht angesteuert wurde.

Das in #4 mit hin und herschieben (warum auch) würde ich ohne weitere Fakten (wann? wie? welche Zentrale?) als Fabrikation bezeichnen.
Man kann genau so viele Loks gleichzeitig steuern wie für die Zentrale angegeben.


Grüße
Harald.

Hallo,

#2: Lt. RCN-225 gibt es eine CV 11



Was m.E. nicht klar ist, ob dabei nur der DCC Empfang oder eben an den Decoder gerichtete Pakete gemeint sind. Ich lese eher ersteres aus dem obigen Text, womit die Lok weiterfahren wuerde, wenn Sie aus dem Refresh fliegt.

Weiterfahren finde ich eine schlechte Option (=Geisterzug). Darum habe ich bei meinen Selbstbau-Decoder die CV11 folgendermassen implementiert,

Auch wenn es nicht notwendig sein sollte (wenn die Zentrale einen fahrenden Decoder aus dem Refresh wirft is das fraglich) ist deine Implementation von CV11 vernünftig. "T[ms] = CV11 * 128" Da muss man etwas (kopf)rechnen. Max 32.64 sec also.

Grüße,
Harald.

Hallo,
erst einmal Danke für die Antworten.

Mir geht es eigentlich darum, mit der schwarzen z21 soll man 119 Adressen zeitgleich im Einsatz haben können, sobald man die 120 Adresse aufruft soll die Adresse die am längsten keinen aktiven Befehl mehr bekommen hat aus dem "refresh" fallen.

Ich würde halt ganz gerne jedem Wagen mit Innenbeleuchtung eine eigene Adresse geben und da sind 119 Adressen die zeitgleich im Einsatz sind recht schnell beisammen.

Gruß Alex

Um das nicht ausufern zu lassen habe ich Wagenbeleuchtungen möglichst in Gruppen zusammen gefasst. Funzt besonders gut bei Ganzzügen wie einen IR, IC/EC oder ICE. Solo werden bleiben einzelne Kurs- und Sonderwagen. Manche beleuchtete Wagen wie Speisewagen, Rollende Landstraßenbegleitwagen und 1 "Kinderland" IR Wagen haben sogar im Moment gar keinen Decoder. Ansonsten viel Vergnügen mit deinen beleuchteten Einzelwagen.

Wenn die z21 wirklich die älteste Adresse rauswirft auch wenn die Lok noch fährt finde ich das eine schlechte Entscheidung des Herstellers.

Man kann mit PoM die Wagen mit CV19 zu Zügen zusammenfassen und damit Adressen sparen.

Wegen der totalen Refreshzeit will man eigentlich gar nicht so viele Adressen aktiv haben. Auch will man Funktionen im Vergleich zu Geschwindigkeit nicht so oft refreshen. Aber oft genug. Nun, was ist oft genug? Das wird schnell komplex.


Grüße
Harald.

Hallo,

Der Refresh ist das eine, die DCC Bandbreite das andere.

Wir koennen von ca. 100 DCC Befehlen ausgehen, die pro Sekunde uebertragen werden koennen. Das bedeutet bei 100 Decodern im Refresh, dass jeder *einen* Befehl pro Sekunde bekommt. Das ist nicht viel.

Fuer fahrende Decoder sollte die Refresh-Rate deutlich hoeher liegen, damit im Falle einer kurzen Spannungsunterbrechung, die Decoder moeglichst schnell wieder mit den Geschwindigkeits- bzw. FN Informationen versorgt werden.

Es waere somit wichtig, dass die Zentrale zwischen fahrenden und stehenden Decodern unterscheidet bzw. optimiert. Ich weiss nicht ob die Z21 das tut.

Zum anderen gibt es verschiedene Befehlgruppen: [Geschwindigkeit] / [F0-F4] / [F5-F8] / [F9-F12] / ... D.h. ein einzelner Decoder benoetigt u.U. 4 (und auch mehr) Befehle um alle Funktionen F0-F12 und die Geschwindigkeit zu refreshen.

----

Lange Rede ... 120 Decoder im Refresh ist eine echte Herausforderung und erfordert intelligente Algorithmen in der Zentrale. Ich kenne den Z21 Scheduling Algorithmus nicht, aber ich wuerde Dir empfehlen testhalber mal 100 Decoder in der Zentrale anzulegen und diese "dummies" auch zu aktivieren bzw. zu fahren. Schaue dann, wie sich das System mit den realen Loks verhaelt. Gibt es beispielsweise stoerende Verzoegerungen? Diese Verzeogerungen koennen ggf. so erheblich werden, das ein Betrieb fast unmoeglich wird.

Wie gesagt, es haengt an dem DCC Scheduling Algorithmus der Zentrale. Da waere ein Benchmark mal angesagt, weil das mit zahlreichen Decodern m.M.n. ein erhebliches Qualitaetsmaerkmal darstellt.

VG, Frank

Parallell mit DCC-EX arbeiten wir auch am EX-Inspector. Den muss man noch etwas ausbauen um auch Statistik über das DCC-Signal erfassen zu können. So könnte man analysieren wie verschiedene Zentralen das Problem hantieren.

Da das DCC Scheduling der DCC-EX Zentrale noch nicht so optimiert ist (wie Frank erklärt hat) will ich unserer Software z.Z. nicht mehr als ungefähr 50 gleichzeitige Loks zumuten. Es ist open software also  man kann das natürlich auf eigene Gefahr erhöhen wenn man will. Ist auch ganz einfach, nicht an mehreren Stellen im Code  versteckt.

Grüße
Harald.

Guten Abend,,

Fremo hat aufgrund der Größe deren Anlagen Anforderungen in dieser Größenordnung. Die kann kaum ein Digital-Hersteller erfüllen. Digitrax kam wohl damals den Anforderungen am nächsten. Frank hat die Problematik in #11 sehr schön dargelegt.

Allerdings frage ich mich, ob jeder Funktionsdekoder weiterhin im Refresh-Zyklus der Zentrale sein muß, nachdem das Licht einmal eingeschaltet ist. Man schaltet das Licht nicht andauernd an und aus ... . Ggf. wären Funktionsdekoder eine Lösung, die so konfiguriert werden können, daß sie sehr schnell aus dem Refresh-Zyklus wieder rausfliegen. Dennoch ist der Vorschlag, die Dekoder entsprechend der zusammengestellten Zügen in Gruppen zusammenzufassen, sicherlich die sinnvollere Lösung.

Ciao, Lutz

Kann? Will? Ökonomisch nicht rentabel?


Wenn er sich den Zustand auch über Stromausfälle behält, dann nicht. Legt die Lichtfunktion doch auf F32 (kann der Decoder das?) dann sollte es keinen refresh geben sofern nie eine Geschwindigkeit eingegeben wurde. Kann die Zentrale das?

Es gibt  da einen Spruch: Scratch your own  itch. Also kratz dich da wo es bei dir juckt. Erwarte also auch nicht dass jemand da kratzt wo es dich juckt.  Deswegen mach ich meine Zentrale selber und mit Open source sind auch andere eingeladen da wo es dich  juckt mitzumachen.

Grüße
Harald

Hallo,



Das mache ich genauso, allerdings nicht mit DCC-ex sondern mit einem eigenen Projekt. Ich habe in den letzten Jahren viel bzgl. DCC Scheduling experimentiert. Ein wenig davon habe ich hier dokumentiert: https://rtb4dcc.de/protocols/dcc/

Aber all die Modellbahner, die nicht programmieren koennen oder wollen, sind auf kommerziellen Produkte angewiesen.



Ich hatte mich aus diesen Skalierungsgruenden entschieden, den DCC Generator auf den PC zu verlagern. Dort stehen nahezu unbegrenzte Resourcen zur Verfuegung und die Algorithmen koennen in deutlich kuerzeren Entwicklungszyklen vorangetrieben werden. Im Ergebnis skaliert meine Zentrale weit ueber das uebliche Mass. Das DCC Scheduling ist dynamisch und zeigt bei steigender Decoderzahl eine nahezu konstante Antwortzeit. Allerdings setzt die DCC Bandbreite auch diesem Ansatz irgendwann Grenzen. Um diese zu ueberwinden, arbeitet meine Architektur mit multiplen unabhaengigen DCC Generatoren.



Sowas hatte ich mir vor einigen Jahren gebaut, um besser zu verstehen, was unten auf dem Gleis eigentlich los ist.

https://rtb4dcc.de/blog/dcc_logger/

Ich verwende diesen Logger aber nicht mehr so oft, weil meine RTB Infrastruktur ein viel leistungsfaehigeres Loggin/Tracing bereits integriert hat. Aber um einer Fremd-Zentrale auf den Zahn zu fuehlen, da leistet der DPM immer noch gute Dienste.

VG, Frank

Ich weiss jetzt nicht wie du deine Algoritmen schreibst aber ich mach das in sowieso in C++ und das spielt es jetzt keine Rolle ob das auf einem PC oder Mikrokontoller läuft. Es ist allerdings korrekt dass man auf einem PC sehr viel mehr per Zeiteinheit machen kann und sehr sehr viel mehr RAM hat als auf einem AVR. Doch beim ESP32 oder STM32 ist das gar nicht so übel. Der Vorteil mit dem Mikroprozessor nah am Gleis zu sitzen ist dass wenn z.B. ein Notstop reinkommt der dann als nächstes DCC Paket rausgehen kann. Auch funkt kein OS dazwischen das gerade nach Updates sucht. Wir haben auch viele Anwender die sehr dagegen sind einen "Computer" hochzufahren, auch wenn es nur ein Raspi wäre. Auch ist der Mikrokontroller immer noch etwas kleiner als ein PC. Die CSB-1 Zentrale wiegt 30 Gramm ohne Gehäuse.


Ich sehe da eine  "will haben/kaufen, ohne Risiko und gern billig" Mentalität von vorzugsweise deutschen Modellbahnern. Es kommen deutlich mehr Beiträge (*) an DCC=EX aus anderen Ländern obwohl es da weniger Modellbahner gibt. Könnte auch sein die deutschen Tüftler machen es nur für sich selber im stillen Kämmerlein und haben Angst sich zu zeigen? Kann man nicht wissen. Ich glaube nicht dass in D weniger Modellbahner die Kompetenz haben als z.B. in UK oder AU.


Manchmal muss man auch seine eigene Arbeit kontrollieren - wir haben da kürzlich entdeckt dass wir unnötigerweise zu viel <idle> rausgeschickt haben, also Bandbreite verschwendet. Der Bug ist aber jetzt eingefangen und vernichtet.

Die Frage ist, wer würde kommerzielle Zentralen testen und die Resultate veröffentlichen? Von der Mobapresse erwarte ich da z.B. nichts..

Grüße,
Harald.

(*) Nicht nur Programmcode sondern auch Dokumentation, Test, Videos etc.