THEMA: JMRI Decoder Pro und Bits

Die Idee von Decoderpro ist dass du eben die Bits nicht selber suchen musst sondern im Reiter die Checkbox wählst die du brauchst.

Dann kann man noch ganze CV lesen und schreiben, aber dezimal.

Wo hättest du denn gern die Schaltfläche für einzelne Bits? In der CV Liste?

Grüße,
Harald

Es gibt z.B. bei ZIMO diverse CVs, wo man spezielle Konfigurationsbits setzen kann - oder auch CV29: kurz reinschaun, ob z.B. Railcom aktiviert ist, ohne lange Zusammenrechnerei.
In ZCS ist die bitweise Config möglich, ebenso im Freiwald TrainProgrammer mit einem kleinen Fenster, wo man sofort dezimal oder eben auch die einzelnen Bits ändern kann.

Gruß
Rainer

Hi,

Für Zimo gibt's in JMRI viele "Decoder Profiles", wo jede Einstellung Benutzerfreundlich mit Checkboxes geändert werden kann.
Wie von Harald schon gesagt, die Idee mit JMRI ist genau nicht die Bits programmieren zu müssen.

Einfach Lok einlegen dann neuen Decoder und "Decoder Erkennen" in JMRI (ich weiss nicht, wie es auf Deutsch genau heisst): dann erscheint die Interface für den richtigen Decoder bzw. Firmware version.

Das ist die "normale" Nutzung von JMRI ;)
Mehr (auf Englisch): https://www.jmri.org/help/en/html/apps/DecoderPro/Roster.shtml

LG,
Pierre

Edit: Link zu JMRI Hilfe hinzugefügt

Hallo Rainer,

wie schon Harald sagt, das Konzept von Decoder Pro ist eben, daß Du weder die CV Variablen oder gar deren Bits kennen mußt. Die CV-Variablen sind im Prinzip thematisch unter den verschiedenen Reiter einsortiert. Einfach mal die Reiter durchblättern, dann erkennt man das Konzept recht schnell.

Ich nutze Decoder Pro seit Jahren und habe seither fast keine Gedanken zu CV's und deren Bits gemacht.

Ciao, Lutz

Hallo zusammen,

ok, danke, dann bietet es JMRI also nicht an.
Ich sehe es nicht als "muß" an, mit Bits zu programmieren, es ist für mich eher eine sinnvolle Ergänzung, siehe #2.

Gruß
Rainer

Wozu muß man da etwas zusammenrechnen? Verstehe ich nicht.

Um bei Deinem Beispiel zu bleiben, ich rufe die Lok auf und da den Reiter "Railcom" das war es schon. Warum sollte ich CV Tabellen und die einzelnen Bits auswendig lernen oder zumindest in der Decoderanleitung nachschlagen, wenn ich mit 2 Mausklicks Alles in Klartext sehe? Das fände ich mehr als umständlich.



Die von frank@cb zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Rainers Wunsch ist eigentlich nicht ungewöhnlich und für die CVs deren Bits etwas schalten, also nicht die numerischen, ist das durchaus sinnvoll. Man hat zwar eine komplette CV Tabelle, aber ob ein Bit gesetzt ist, muss man sich dann doch ausrechnen.
Über ein zusätzliches Template könnte man das Abbilden, aber für alle CVs incl. aller Bänke ist das sehr mühevoll. Man müsste sich auf die wichtigsten beschränken.

Welche CVs fallen dir Rainer spontan ein?

Hallo Uli,

genau so meine ich das, wie du es geschildert hast.
Und spontan fallen mir - wie oben schon erwähnt - die ZIMO Konfigurations-CVs ein, deren einzelne Bits bestimmte Funktionen, Zustände, u.ä. bewirken.

Rainer

Ich verstehe es nicht.

Ich möchte von CV55 das Bit 2 setzen …. was muss ich bei Decoder Pro machen?

Wenn man Bit 2 in CV 55 setzen möchte muss sich doch nur den CV Wert wissen. Und der steht im Handbuch. Was soll JMRI denn noch in ehrenamtlicher Arbeit leisten?
Du kannst dann im erweiterten Programmiermodus in der Registerkarte CV Adressen den Wert ändern oder auch mit dem Einzelprogrammiertool den Wert ändern.

Leute das ist ein reines FREIZEITPROJEKT von Privatleuten aus USA und Übersee, welches über die Jahrzehnte langsam gewachsen ist. Wenn ihr Wünsche habt, dann nur zu. Einfach mal in JAVA programmieren lernen und in der Community anmelden. Oder wenigstens mal ne Spende an das Team da lassen. Serverkosten und Webseite müssen bezahlt werden.

P.S.: ein kleines Dankeschön an ZIMO geht hier raus für deren Zuhilfe bei deren Produktpflege.

Wem das nicht so liegt, der kann das ZCS Tool austesten. Das Programm kann auch fremde Decoder handhaben.

Heißer Tipp: Dank DCC-EX Zentrale kann ich auch ZCS benutzen! Die Zentrale ist implementiert.

Hallo,

LENZ hat einen Bit-Rechenknecht hier: https://www.lenz-elektronik.de/Hilfe-Info/Bit-Rechenknecht/
Funktioniert in beide Richtungen

Vielleicht hifts
Gruß Rainer

Nach der Funktion, die dadurch Ein-/Ausgeschaltet wird, in Decoder Pro suchen und diese dann einfach per Klick de-/aktivieren ist zu schwer? Man kann natürlich auch mit der Erfindung des Rades noch einmal von vorn anfangen.

Ohne Jemande zu nahe treten zu wollen, aber man kennt es aus allen technischen Bereichen, das "ich will jedes Bit einzeln setzen" klingt oftmals nach "weil ich ja auch Ahnung habe". Aus beruflicher Erfahrung weiß ich allerdings, wer Ahnung hat, macht sich Alles so einfach wie möglich, auf das Beispiel übertragen, er nutzt grafische Tools, mit denen solche Aufgaben intuitiv und blitzschnell erledigt sind.

Die Eingangsfrage war m.E. klar formuliert. Die Antwort lautet, so wie ich es jetzt verstanden habe: Nein, das geht nicht. Die Philosophie von Decoder Pro ist eine andere … oder wie?

Hallo,

oder ein bisschen binäre Arithmetik lernen
Mit dem Windows Rechner kann man gut üben,  da kann man in der Betriebsart "Programmierer" zwischen den Zahlensystemen Dezimal, Hexadezimal und Binär umschalten.

Grüße,  Peter W

Meine Frage aus #6 ist allerdings immer noch nicht beantworten: wozu sollte man das müssen/wollen, welcher Zweck wird durch die Programmierung einzelner Bits statt Funktionen im Klartext erfüllt?

Das mag DEINE Art sein, damit umzugehen

Ich finde es allgemein Übergriffig dem User eine Art aufzuzwingen, als Beispiel nehme ich mal das FÜR MICH völlig unbrauchbare Startmenü von Windows. ICH habe einen völlig anderen Workflow.

Wo wäre es bei JMRI das Problem diese kleine Tool zu integrieren?

Da mich das Fehlen dieser BIT Berechung - Allgemein - gestört hat, habe ich mir ein eigenes Tool geschrieben, welches diverse Templates für verschiedene CVs beinhaltet. Ergo ich muss nicht überall rumnörgeln, ich bau mir ein Tool, welches MEINE Anforderung erfüllt.

Und das Thema Java
Das lernt sich nicht nebenbei, ich finde persönlich die Struktur von JMRI nicht intuitiv. Bei anderen Projekten habe ich wesentlich weniger Verständnisprobleme.

Nebenbei: Für WEN schreibst du Software? Für den User oder fürs eigene Ego?

Egal für wie sinnlos ICH manche Anforderungen halte ... der User muss es bedienen....


Viele Grüße, Franzi

Hallo Franzi,


Das wollte ich bei meinen Posts noch dazuschreiben. Ich bleibe da allerdings gelassen, denn ich bin nicht auf JMRI angewiesen.
Im Freiwald TrainProgrammer ist es integriert, ebenso im ESU Programmer, in ZIMOs ZCS und auch im Lenz CV-Editor, um diejenigen zu nennen, die ich nutze.

Um noch einmal konkrete Beispiele für meine bevorzugte bitweise CV-Bearbeitung zu nennen:
ZIMO CV158 "Diverse Spezialbits"
ZIMO CV393 + 394 "Spezielle ZIMO Konfigurationsbits"
D&H CV144 "Einstellungen"
Uns selbst in CV29 genügt ein kurzer Blick, ob die Fahrtrichtung umgekehrt ist oder ob Railcom aktiviert ist.

Rainer

Edit:
Mit meinen genannten Programmen habe ich natürlich keine Not, aber ich versuche mich auch gerne an Neuem wie JMRI...

Da wo die CV Liste zu finden ist könntest du bestimmt noch per Reihe 8 kleine Köpfchen unterbringen welche auch die Bits anzeigen.

Frisch programmiert ist halb gecrasht.

Wenn eine DCCEX Zentrale dranhängt kann man übrigens <W 29 0 1> schreiben, ganz ohne GUI.

Grüße,
Harald.

Hallo,,

JMRI ist intern ein Schrott,  leider. Offenbar laufen hier das GUI und die Hardware Anbindung asynchron.  Ich habe es auf einem langsamen Rechner (Intel Atom, Win 10 32bit) getestet. Da verhält es sich so:

Man drücke CV Lesen, Pause. Keine Ahnung was da so lange rechnet. Timeout. Anschließend rattert die Lok. Wtf?

ZCS, Esu Programmer und sogar der komplexe Piko Smartprogrammer funktionieren auf der alten Kiste.
Ihr könnt Euch vorstellen,  was ich von JMRI halte.  Da brauche ich gar nicht erst über Bits vs. Bytes nachdenken. Da ist die interne Synchronisation im Eimer.

Bei Esu und Piko stehen in den Dialogen zur CV Programmierung parallel Bytes zum eingeben und die Bits zum Anklicken zur Verfügung.

Grüße,  Peter W

Ich programmiere die Decoder ausschließlich im POM Mode, da passiert das von Dir beschriebene nicht. Das Auslesen der kompletten CV Liste dauert z.B. bei Zimo Decodern genau so lange, wie in ZCS, der Status wird auch angezeigt. Das Ganze sowohl unter Windows, als auch unter Linux (auf einem Raspberry Pi) und auf dem Mac. Das Ruckeln der Lok beim Auslesen passiert nur im Programmiergleis Modus und da in jedem Programm, das ich bislang benutzt habe. Allerdings programmiere ich ausschließlich im POM Mode, selbst wenn die Lok auf meinem Programmier-/Testoval steht, da das Lesen und Schreiben um ein Vielfaches schneller abläuft, im Programmiergleis Mode ist schnell mal eine halbe bis eine Stunde weg, je nach Größe und Aufbau der CV Tabelle.

Mit wenigen Klicks findet man die Einstellungen für CV158 in den Reitern "RailCom", "Sound", "Sound-Elektrolok" und "Sound-Diesellok". Und das mit deutschsprachiger Klartext-Bezeichnung, somit einfach zu finden. Wenn man weiß, was man einrichten will, schaut man (eigentlich) automatisch bei den naheliegenden Reitern. Analog dazu auch für die anderen erwähnten CVs. Somit erübrigt sich in den meisten Fällen der Blick in die Decoderdokumentation.

Dagegen ist nichts einzuwenden.
Aber ich zitiere Franzi in #16:


😉

Das mag Alles sein, daß Manche die Fummelei mit einzelnen Bits bevorzugen, aber meine Frage, WARUM man sich das in Zeiten einfacher Klick-Lösungen antut, ist nach wie vor nicht schlüssig beantwortet. Da liegt doch (unter Anderem) die Vermutung nahe, daß man sich einfach nur vom Mainstream abheben will, oder? Wenn man es vom Job, wo Zeit Geld ist, gewohnt ist, immer den einfachsten Weg zur Lösung zu nutzen, sind unnötig komplizierte Wege schwer nachvollziehbar. Ob Andere diese Vermutung "übergriffig" finden, tangiert mich nicht, aber wenn sie sich angesprochen fühlen.
Wenn sich die Entwickler der Software entschieden haben, nur die einfachste, für Jeden realisierbare Lösung zu integrieren, ist das halt zu akzeptieren. JMRI ist ein freiwillig erstelltes und kostenlos verfügbares Projekt. Es wird Niemand gezwungen, es zu benutzen. Es gibt genügend User, die dankbar sind, daß es das Projekt gibt. Zudem gibt es die JMRI Community, wo man Ideen einbringen könnte, so man will.

... den Gedanken spare ich mir ...

Du scheinst es ja perfektioniert zu haben, alles was dir nicht in den Kram passt, zu ignorieren:

Für WEN entwickelst du Software?
Es ist völlig egal, welche Einstellung du hast!

Du hast zu akzeptieren, dass Menschen unterschiedlich sind (Bezeichnung Individuen!)

Ich werde mich nicht dafür Rechtfertigen, dass ICH eine andere Herangehensweise habe, als sie Dir genehm ist!

Nochmal: Deine Aussage zeigt, dass du Software fürs eigene Ego schreibst, aber nicht für den Anwender

Es spielt überhaupt keine Rolle, ob DU es nachvollziehen kannst!

Ach nee, da ist aber wieder Jemand angep***. Immer noch sauer, daß ich Dich der Unkenntnis/Lüge überführt habe, von Brawa gäbe es keine Loks mit D&H ab Werk? Daß Du gern absichtlich Äußerungen fehlinterpretierst und Dinge unterstellst, keinen Widerspruch duldest?

Wenn Du den Sinn hinter freiwillig erstellter, nichtkommerzieller Software, davon reden wir hier und nicht von einem Produkt, das xxx€ kostet, nicht verstehst oder akzeptierst, solltest Du Dir einen anderen Sandkasten suchen.

Du könntest ja einfach meine mehrfach gestellte Frage beantworten. Keine Argumente parat?

Ganz so radikal würd ichs vielleicht nicht ausdrücken, aber ich kenne eigentlich niemanden der sich den Source Code von JMRI angesehen hat und dann viel gutes darüber zu berichten hatte. Für die Programmierung von ein paar CVs mag das egal sein.... ich hab selbst mal kurz mit dem Gedanken gespielt die .xml Decoder Definitionen zu parsen bevor ich gesehen hab was für ein Chaos dort herrscht. Aber niemals, niemals nie würd ich JMRI an eine Anlage lassen.

Ich habe JMRI einmal vor vielen Jahren (es muss Anfang der 2000er gewesen sein) mit Lenz getestet, da gab es noch kein PoM/Railcom auslesen. Und manche Hersteller wollen es auch heute noch immer nicht können, wie ich bei aktuellen MTX Loks mit hauseigenen Decodern leider feststellen musste: Railcom geht bei MTX nicht mehr. Dazu vielleicht ein eigener Threads.

Damals war das Verhalten so:
Bei jeder CV wurde in den Programmiermodus umgeschaltet (Relais klackte), CV wurde ausgelesen, Programmiermodus wurde wieder verlassen (Relais klackte erneut). Ein Auslesen eines ganzen Decoders (trotz der damals geringen Anzahl von CVs) dauerte ewig. Klick - ratter ratter ratter - klack, Pause, klick - ratter ratter ratter - klack ....

Ich kann mir schon vorstellen dass das Programm auf modernen CPUs und aktuellem Java mit parallel Threading gut läuft.
Allerdings wenn die GUI aufgibt bevor der Treiber fertig ist, einmal "nichts" liefert, einmal der Wert vom vorhergehenden Auslesen und einmal den richtigen Wert kann nicht richtig sein. Das ist kein Bug, deutet auf ein konzeptuelles Problem der Synchronisierung in der Parallelverarbeitung hin. Wenn die CPU keinen zweiten Kern hat, fährt die Software an die Wand? Dann gehört das als Mindestanforderung dokumentiert. Dabei ist es mir egal, ob es sich um eine kommerzielle oder eine freie Software handelt.

Da kommt bei mir ebenfalls die Frage auf, für wen wurde das programmiert: Für den Modellbahner, der gerne ausrangierte PCs nutzt (eventuell mit Linux wenn Windows nicht mehr unterstützt wird) oder ftden PC-Nerd der immer das aktuellste vom aktuellen nutzt?

Grüße, Peter W

habe Mindestanforderungen nicht direkt auf der JMRI-Seite gefunden, aber für die aktuelle JMRI-Version (>5.15.1) wird Java 21 empfohlen. Java 21 benötigt Windows 11. Windows 10 wird nicht mehr unterstützt und Windows 11 benötigt einen Prozessor mit Minimum 1 Gigahertz (GHz) und 2 oder mehr Kernen, mindestens 4 GByte RAM etc.....

Dies sollte eingehalten werden. Alles klar?
Rainer

Hallo zusammen,

ich habe vor allem deshalb mit JMRI Decoder Pro experimentiert, weil mich die Funktion interessiert hat, Decoder herstellerübergreifend zu identifizieren.



Danke für diese Info. Ich dachte es liegt am Rechner (Win11/64) oder an der USB-Verbindung, nachdem ich genau diesen Effekt mit mehreren Zentralen hatte, es ohne PC aber ging.



Ja, damit hatte ich auch begonnen. Aber die Zeit, die Zeit... Allein alle Varianten bei Zimo und D&H anhand verschiedener CVs zu erkennen, ist schon eine Menge Holz. Dazu habe ich noch mit der Idee herumgesponnen, bei älteren Decodern vielleicht eine Kennung in CV105/6 zu schreiben, um wenigstens beim nächsten Mal die Lok nicht mehr aufmachen zu müssen. War mal so eine Selbstlernübung, als ich beruflich von .NET/C++ auf Java umsteigen musste, ist dann aber irgendwie hängengeblieben. Und bei JMRI hab ich eben gedacht, wenn sich ein anderer die Arbeit schon gemacht hat, muss ich nicht das Rad neu erfinden.


Richtig. Trotzdem kurz Danke auch für diese Info. Dann bleibt der Bann bestehen, egal wie interessant das Fahrzeug sein könnte.

Gruß,
Helmut

Normal gibst du gescheite Kommentare ab, doch hier? Ohne zu wissen mit welchem Protokoll du mit welcher Zentrale arbeitest sagt das erst mal gar nix, weil es könnte ja auch die Zentrale sein die JMRI ignoriert, oder? Also den Monitor und/oder debug aufmachen und dann nachgucken was los ist. Oder den Machern von JMRI einen guten Rapport schicken. Der wird nämlich normalerweise GELESEN und es wird auch versucht Fehler zu beheben. Auf Veränderungswünsche ist man allerdings nicht immer so erpicht aber Bugreports werden immer angenommen.

Der Quellcode von JMRI ist alt, bloated und stellenweise sehr verschwurbelt. Vor allem wenn man nicht neu nachgedacht hat sondern den Code von Zentrale X erstellt hat indem man von Zentrale Y ausgegangen ist und dann so lange programmiert hat bis sich das Problem nicht mehr rühren konnte. Doch das Resultat ist erstaunlich stabil.



So man braucht eientlich keine Angst haben dass JMRI Mist baut und plötzlich alle Loks mit Vmax über die Anlage jagt oder so. Von sowas hätte ich gehört.

Es wäre schön wenn man aus dem XML das sehr viel Information enthällt was gescheites machen könnte. Es ist ja auch keinem Hersteller verweht bessere XML-Definitionen für ihre Decoder zu publizieren oder? Welche andere Alternativen gibt es denn? Also wenn man das lesbar und portabel zwischen verschiedenen Programmen machen will.

Zu den Anforderungen: JMRI/Java frisst RAM. So 1 bis 2GB. WIe mir scheint noch mehr unter Windows als unter Linux. Auf meinen über 5 Jahre alten Laptop läuft es recht anständig. Ist halt auch ein leichtes XFCE Desktop und nix wo halbdurchsichtige Fenster beim Auf- und Zumachen rumwackeln und Schwusch machen.  So wenn ihr einen etwas älteren Rechner habt, installiert eine der mehr genügsamen Linux-distros und gönnt euch eine SSD fürs System. Es gibt doch jetzt genug abgelegte Computer nachdem Win11 ins Land gezogen ist und viele gute Hardware aufs Abstellgleis geschoben hat. Ein Schelm wer böses dabei denkt.

Doch: Auf einem Intel Atom von - tja 2012 vielleicht  -  geht ein neues Java wahrscheinlich eher schlecht als recht. Doch mit einem JMRI von 2012 mit einem Java von 2012 sollte wieder alles passen

Da zwichen den Entwicklern von JMRI und DCC-EX ein Austausch besteht kann es auch sein, dass gerade die Kombination nicht die Schlechteste ist.

Um die geliebte Darstellung in Binär oder als Bits in die CV Tabelle zu bekommen - habt ihr denn den Wunsch als Git Issue geäußert oder ist das zu schwer?

Grüße,
Harald.

Hallo,

Wenn Du das auch hast, dann liegt es nicht an meinem alten Rechner.

Die Spezifikation für JMRI lautet,  es wird Java 21 empfohlen aber die Mindestvoraussetzung ist Java 11 oder höher. Und für Java 17 LTS gibt es noch 32bit Builds.
Die Spezifikation für Java 21 ist übrigens Win 10 oder Win 11, in jedem Fall 64bit.

So habe ich JMRI 5 15 4 mit Java 17 unter Win 10 32bit am Laufen.

Mit dem MXULFA funktioniert das CV Auslesen jedenfalls nur mit dem o.g. Fehlerbild.
Vielleicht ist nur der Zimo Treiber buggy.
Möglicherweise funktioniert es mit der z21 via LAN.

Grüße,  Peter W

Das CV-Lesen mit dem MXULFA wird von DecoderPro in den aktuellen Versionen nicht mehr unterstützt. Es gibt bereits einen Issue auf Github "Reading CVs from Zimo MXULF #14050", der aber wegen "nicht Aktivität" geschlossen wurde. Es gibt wohl keinen Programmierer, der sich dem Problem annehmen kann.

auf der JMRI Webseite gibt es dazu nur den folgenden Hinweis:
MXULF - Binary Protocol Up to Software 0.61.05
(Zimo hat da wohl mal etwas geändert...)

Mit einer DCC-EX Zentrale oder einer Z(z)21 funktioniert DecoderPro jedoch problemlos. Mein Favorit ist jedoch die z21, da DCC-EX wegen fehlender RailCom Rückmeldung nur im Programmiergleismodus funktioniert.

Uli

Die Mehrzahl der Anwender, global, ist an RailCom nicht die Bohne interessiert.

Wir würden es aber gern unterstützen wenn es denn einen richtig preiswerten Rückmelder geben würde, den man einfach an die Zentrale anschließen kann. Ohne die HW dafür selber machen zu müssen, weil dann dauert es leider immer etwas länger.

Zur z21 ist auch noch ein Preisunterschied und trotzdem kann sie nicht Service und Hauptgleis gleichzeitig, oder?

Gruß,
Harald

Hallo Harald,

wie meinst Du Service und Hauptgleis gleichzeitig? Die weiße z21 hat nur einen Gleisausgang, wo sowohl Service als auch Betriebsbefehle (PoM). ausgegeben werden. Es wird also nichts umgeschaltet. Allerdings kann man, wenn die Zentrale im Service Mode ist, keine Betriebsbefehle ausgeben. Also gleichzeitig darf es nicht gehen, aber hintereinander.

Grüße, Peter W

Märklin/Trix hat sich seit 2026 bei mir komplett bei den Loks und Triebwagen aus dem Sortiment verabschiedet, weil sie anfangen bei der Decodertechnik die Kundschaft bevomunden zu müssen. Modelle mit Analogplatinen zukünftig Fehlanzeige. Es werden digitale Vollplatinen nur noch mit hauseigenem Soundmodul und hauseigenem Motordecoder verkauft. RaiCom gibt es nicht mehr nur noch mfx Hausmannskost. Beim nächstbesten Kurzschluß kannste die Lok als####billig verkaufen odre ins Regal stellen, da man derzeit für alle Neumodelle keine Ersatzplatinen bekommt und das Soundmodul fest auf der Plaine verlötet ist. Bei wenigen Platinen ist immerhin der Decoder in einer Steckschnittstelle verbaut, jedoch ohne Hinweise, was es für einer sein könnte und welche Schnittstelle. Offenbar ist der Lieferant aber nicht mehr Doehler und Haass, denn ich hab noch keinen Hinweis gesehen, dass D&H auch mfx statt RC für Großkunden anbieten würde. Märklin verweigert sich offensichtlich seit neustem Sounddecoder zuzulassen / zu verbauen?

Hinweis: JMRI ist in Kooperation mit ZIMO auf KLUG für das DecoderPro Modul umgestiegen! Der läuft in der neuen Version 5.16 jetzt soweit, ich benutze ihn nämlich.

Dann sollte es auch relativ einfach möglich sein den MXULFA mit der aktuellen Firmware wieder ans laufen zu bekommen und zwar auch mit Unterstützung von POM/RailCom.

Hihi, soweit zum Chaos Code...

Ich hab das vor Jahren mal als Issue aufgemacht. Nachdem das bis heute keine Beachtung fand würd ich ehrlich gesagt nicht mehr damit rechnen.

Dazu braucht es halt jemand der programmieren kann und den es juckt, entweder für sich oder für Geld. Billigere Hardware senkt die Schwelle, ein MXULFA ist das nicht.

Genauso wie ein preiswerter railcom detector  für dccex hilfreich wäre.

Wenn man das issue wieder aufmacht hat man ne Chance. Doch wie gesagt, es braucht halt jemand mit der Hardware und etwas Zeit zum debuggen.

Grüße,
Harald.