THEMA: Zimo Decoder reagieren plötzlich nicht mehr

Hallo,

also zuerst hätte mich mal interessiert, was "die üblichen Probleme mit Zimo-Decodern" sind. Die kenne ich nicht.

Dass Loks nicht mehr auf Fahrbefehle reagieren, aber Funktionsbefehle noch ausführen, klingt sehr befremdlich.
Da wäre schon sehr interessant, um welche Decoder es genau geht und welche Zentrale die nicht ausgeführten Befehle sendet. Auch Zusatzinfos wie anliegende Spannung und aktivierte Protokolle (DCC, Motorroller, SX, womöglich gar FMZ, Railcom oder nicht) wären schon auch hilfreich, um den Blick in die Glaskugel zu unterstützen.

Was den "kaum hinnehmbaren Zustand" angeht, kann ich mit so wenig Infos nur allgemein sagen, neben D&H sind meine Zimo-Decoder die zuverlässigsten überhaupt. Und das seit vielen Jahren.

Gruß,
Helmut

zurückgezogen

Wir haben da aktuell Meldungen rund um jene CVs die mit dem CV-Kurzbefehl geschrieben werden. Kontrollier bitte mal CV23, 24, 19 und 20.

Um was für Loks handelt es sich?
Ich kenne das Problem auch vereinzelt. Ganz manchmal ist der Motor kaputt. Bei Fleischmannloks habe ich gerade erfolgreich eine kuriose Hilfe entdeckt: schliess mal eine mittlere analoge Spannung direkt an den Motor an und lass ihn eine Minute laufen. Dann weisst du auch gleich, ob er defekt ist oder nicht.
Dann wieder zurück auf digital. Vielleicht ist wieder alles normal.
VG Frank

Guten morgen
Welche Zentrale hast Du?
Lg Peter

Moin,

Seit Jahren ist der Trick. Mit MX Sounddecodern habe ich auch keine Probleme. Aber ich meine hier MS Decoder. Da gibt es u.a. Probleme mit:
- Pom lesen und schreiben
- Susi Schnittstelle
- Update Probleme von Decodern, die gar nicht mehr funktionieren oder einzelne CVs verlieren.

Danke Vincent. CV 19 und 20 waren die Übeltäter. Das ist wirklich ein kritisches Problem. Welche Softwareversionen sind denn betroffen?

@Frank, damit verbrennst du ein bisschen Öl, aber um eine nachhaltige Reinigung kommt man häufig nicht drum rum.

Gruß Moritz

Ich halte es für eher unwahrscheinlich dass dies an den Decodern liegt. Der RailCom Empfang der MS/N Decoder wurde bereits von externen Personen gemessen, eine öffentlich einsehbare Variante unter anderem hier: https://www.stummiforum.de/t228345f5-Messungen-Railcom-Timings.html




Ja, die erste Implementierung war katastrophal. Aus diesem Grund hab ich den SUSI Bus für die Version 5.15 komplett neu geschrieben. Diese Version enthält sogar einen Rückwärtskompatibilitätsmodus für Module die sich nicht an die aktuelle Norm halten. (Eine Norm, die, nachträglich, wie so viele andere angepasst wurde).

Seither wurden mir keine Probleme gemeldet.




Ja, selbes Problem wie SUSI.
Im Dezember 2019 (!!!) musste ich feststellen dass der Bootloader für die Erstauslieferung der MS-Decoder massive Probleme beinhaltete und wie alles bei ZIMO unzureichend getestet wurde. Diese Probleme verfolgen uns bis heute...




Alle. Das Problem dürfte sich allerdings verschlimmert haben als ab Version 4.249.0 die DCC Timings als Workaround für Produkte anderer Hersteller gelockert wurden...

Hallo,

warum tritt das bei MX nicht auf? Wo ist da der Unterschied - dass meistens die Programmiersperre gesetzt ist?

Wäre es nicht die Lösung, die MS Decoder mit CV 15 ≠ CV 16 zu sperren, wenn das in einer konkreten Umgebung häufig auftritt?

Grüße, Peter W

Probleme mit POM (Railcom) lesen hatte ich in der Vergangenheit auch schon mit MS580-Decodern. Manchmal half es vorübergehend schon, die Lok auf dem Gleis zu drehen. Die einzige Lösung für mich war den Decoder zur Reparatur zurückzuschicken.
Als Fehlerursache habe ich den Ausfall der Railcom-Rückmeldung auf dem Decoder identifiziert. Warum, kann ich jedoch nicht sagen, der Fehler tratt nach einer Weile einfach auf. Als Zentrale verwende ich MXULFA und z21 mit ZCS.

Wissen wir noch nicht. Die MS Decoder setzen die interne State Machine noch nicht bei jedem einzelnen Bitfehler zurück... das könnte bei der schwachen Absicherung von DCC ein Problem sein.

Tests laufen, nur leider konnte ich den Fehler bei uns im Büro noch nicht reproduzieren.

Ist es denn sinnvoll, bzw. wer macht es, die Decoder-Programmiersperre zu aktivieren, wenn der Decoder final eingestellt ist?

PS. Ein Hinweis der einschlägigen Programmer-Software wäre dann jedoch hilfreich, wenn man dennoch versuchen sollte, gesperrte Decoder zu programmieren.

Hallo,

was genau steht denn in den beiden CV drinnen wenn das Problem besteht?

Grüße
Markus

Das spielt im Prinzip keine Rolle. CV19/20 ist die Verbundadresse, den Moment wo die gesetzt ist (>0) wird sie zur aktiven Adresse auf der die Lok gesteuert wird.

Moritz:
Zentrale?
Booster?
Leitungslängen?
Das kann alles das bit Timing ändern.

Vincent:
Während des Empfangs könnte man Qualität des Signals mitanalysieren und PoM bleiben lassen wenn zu schlecht aber Fahrbefehle weiter akzeptieren.

Viel Glück beim Reproduzieren, halt dir die Daumen.

Grüße,
Harald

Hallo,

welche Betriebs-Befehle sind dem PoM Byte Write oder Bit Write so ähnlich, dass sie bei Auskreuzung von Bitfehlern missinterpretiert werden können?

Hört die Empfangsroutine auf, wenn sie glaubt einen korrekten Befehl erkannt zu haben oder muss die eingelesene Anzahl der Bits stimmen?

Gibt es einen Unterschied in der Hardware - Spannungsteiler, GPIO Level High/Low, Hysterese?

Grüße, Peter W

Hallo,

wenn sich der Fehler reproduzieren lässt stehen dann in CV19 und CV20 immer die gleichen Werte drinnen oder jedes mal andere Werte?

Grüße
Markus

Hallo,

ich arbeite seit einiger Zeit an einer Decoder Test-Suite, die die DCC Decoder unter "Protokoll-Stress" stellt.

Was die Bit-Capture Eigenschaften angeht, erscheinen die neuen MN/MS Decoder in dieser Disziplin robuster als die MX Decoder.

VG,
Frank



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

Hallo,



Ich habe ein ähnliches Verhalten bei der ein oder anderen Lok festgestellt , kann es aber wegen Urlaub nicht direkt überprüfen.

Aber wenn ich das richtig verstehe , müsste sich ja die CV 19 und 20 im Betrieb selbständig ändern ?

Mfg
Christian

Hallo zusammen,

ja, das mit CV 19 hatten wir schonmal hier. Die CV-Werte ändern sich einfach selbständig. Bei mir tritt das Phänomen meistens während der Fahrt auf.

Vincent von Zimo hatte den betroffenen mal eine neue Software zum testen geschickt. Ich habe damit einen Decoder geupdatet und es war gut ein halbes Jahr alles in Ordnung, also keine änderung von CV19. Vor zwei Wochen, hat sich dann CV 19 aber wieder einmal selbständig geändert. Ich wollte Vincent nochmal schreiben, bin aber noch nicht dazu gekommen. Vielleicht siehst du das ja hier.

Bei mir machen aber nicht alle Firmwareversionen Probleme... Die meisten Decoder laufen stabil.

Viele Grüße!
Len

Ja servus Austria!

Oh gott oh gott! Hab mir erst letzte Woche den jüngsten Sounddecoder mit der E24 Schnittstelle für teuer Geld gegönnt und lese nun verwundert, dass die Hardware sich mit der Firmware uneins wird.

Desweiteren habe ich einen älteren MX Sounddecoder, der eigentlich soweit läuft, aber ich nun auch weiß, er wird sich trotz "jüngster" Firmware 4.22 irgendwann aufhängen.

Muss man also RailCom und POM Funktion abschalten, Consist bleiben lassen, und den Decoder quasi "zusperren", damit er sich nicht verhaspelt?
Eine Wiederinbetriebnahme durch Ausfälle kostet mich beim Service 50 Euro inkl. Porti. Ich besitze keine Hardware von ZIMO!

Habe ich mich umsonst gegen ESU beim Sound entschieden? Bewusst in Kauf genommen die Garantie zu opfern um die neue Sudexpress Eurodual Lok zu manipulieren, damit die Schlußlichter wieder leuchten. Nicht ganz billig das Investment.

Dabei sind die Soundprojekte von LeoLab und Henning gut für ZIMO Sound. Und ausfahren der Lok tut der Decoder auch gut.

Für die MX658N18 Serie gibt's keine FW update nach 4.22 mehr oder?

Bei den reinen Fahrdecodern bin ich bei D&H jedenfalls wirklich in guten Händen. (Konkurrenz belebt das Geschäft).

Ich hoffe Hardware- und Softwaretrupp bekommen die Kurve. Drücke jedenfalls die Daumen. Man wächst mit den Herausforderungen! Auf den Gipfel hinauf des Olymps ist halt ein steiler Anstieg. Aber das sollten die Ösis packen.

Schönes WE.

Hallo,


Au weh, zur Erläuterung:
- Railcom hat damit nichts zu tun, dabei handelt es sich um den Rückkanal.
- PoM Befehle kann man nicht ausklammern. Die sind schon lange Teil des DCC Standards.

Die Programmiersperre setzen ist die einzige sinnvolle Lösung, Dadurch wird aktiv verhindert, dass CV geändert werden können - weder absichtlich noch unabsichtlich.


Vincent.


Kenn wa nicht, Piefke

Grüße, Peter W.

Sind nur CV19 und CV20 verstellt?

Adresse der betroffenen Lok?

Welche Werte findet man dann in den beiden CV?

Waren die Loks mit 14/28 Fahrstufen unterwegs? Rückwärts?

Welche Zentrale?

Multiprotokoll an oder aus?

Ich hab einen Verdacht. Bei dem müsste nur in der state machine das end packet bit verpasst und dann 0000 0000 als Prüfsumme aufgefasst werden. Oder das ist Teil von anderen multiprotokoll Daten.

Grüße,
Harald.


EDIT: HAB MICH WAHRSCHEINLICH UM 4 BITS VERRECHNET. DOCH NIX

Hallo Harald,

irgend sowas sagt mein Bauchgefühl auch, welches Datagramm meinst Du genau?

Grüße, Peter W.

Lieber Peter.

Wenn ich zusperre, dann ist POM mit gesperrt. Ich lese heraus, dass die Decoder signaltechnisch irritiert werden können und auch ein Programmierbefehlsproblem im Consistmode haben können. Lassen wir mal RC beiseite benützt ja nicht Jeder.

Der ZIMO Sounddecoder hat 3 Optionen zum Zusperren um vor unbeabsichtigtem Handeln sich zu schützen. Hauptsache der Decoder fährt mit der Lok bis dato dann betriebssicher weiter.

Warte nun auf positive Signale aus Wien. Und die werden sicherlich kommen.

lg

Hallo,

ja dann ist alles gesperrt und es kann somit zu keiner Fehl-Pommung kommen. Eine Mehrfachtraktion sollte man damit auch nicht bilden können. Andere Sperren sind mir bei MS nicht bekannt, Bei MX gibt es verschiedene Sperren, aber um die geht es nicht.

Die MS Decoder unterstützen die genormte Programmiersperre über CVs 15/16.  Die MX nicht.

Zu Esu: Die kochen auch nur mit reinem Wasser, wenngleich wir Wiener unser Hochquellenwasser haben. Vielleicht ist deswegen die Motorregelung bei Zimo so gut

Grüße, Peter W.

Moin Vincent,

ich nutze eine Z21. Das ist keine unübliche Zentrale. Wenn da POM nur bei MS Decodern nicht funktioniert, ist für mich erstmal der Decoderhersteller im Verdacht. Da lasse ich mich gerne eines besseren belehren.

Deine Susi Bemühung ist schön, aber update ich jetzt meine Loks, damit ich sie spontan nicht mehr steuern kann, weil sich spontan die Consist Adresse ändert? Und zumindest den Part mit den Susimodulen von Piko kann ich mit der neuen Version bestätigen, das klappt erheblich besser (wenn man nicht per POM programmiert). Allerdings kann ich das bei der Nutzung der Susiausgänge als Funktionsausgänge noch nicht bestätigen.

Zum Bootloader, es sind tatsächlich eher ältere Decoder betroffen. Gibt es dafür eine Lösung oder muss man einfach vorher alle CVs sichern und dann nach dem Update erneut aufspielen? Sofern die Lok nach dem Update noch reagiert.

@Uli, das ist ein interessanter Hinweis, aber dann schicke ich statt 20 50 Sounddecoder zu Zimo ein. Die werden sich auch bedanken :D
Und ausbauen möchte ich die auch eigentlich nicht

@DCC Ex-Freund


Nein, lieber 5 Probleme mit Zimo Deocdern, als 1 mit Esu. Aber das ist leider auch die Quote

Wenn für MX Decoder ein Update nötig wird, dann wird auch eins kommen.

@Harald, Peter und Markus
Verwendet wird ne Z21 mit mehreren verschiedenen Uhlenbrock Boostern. Kabellängen sind vorhanden. 20 Meter werden die aber nicht überschreiten.
Mal wird CV 19 und mal CV 20 geändert und bisher verschiedene Werte.
Die Adressen liegen im Bereich 600-799 und 85xx. Aktuell schwer (oft) getroffen hat es 732 in beide Fahrtrichtungen (ist aktuell eine Doppeltraktion mit gleicher Adresse). 28 Fahrstufen. Die genauen Werte kann ich nicht mehr benennen.
Die Z21 spricht nur noch DCC. Worauf die Decoder lauschen habe ich bisher nicht geprüft.


Nochmal zu Esu: Das sind fürs Hobby leidenschaftslose Techniker. Kürzlich fanden Soundaufnahmen statt mit Mitarbeitern von Esu, Dekas, ASM und Hobbytrain statt. Die letzteren waren von den Fahrzeugen schwer begeistert. Erstere wollten den Job schnell erledigen.

Gruß Moritz

Wenn etwas nicht geht bitte melde den Fehler in einer Weise dass ich ihn beheben kann. Mit "SUSI Ausgänge funktionieren nicht" fang ich leider nicht viel an. Welche CVs hast du wie eingestellt?

Die ganzen restlichen Spekulationen sind auch nicht zielführend. Ich hab in meinem ersten Post beschrieben woran es liegt...

Und nochmal, MX Decoder sind NICHT betroffen.

Zumindest CV19 / CV20 im Kurzbefehl dürfen ja laut Norm erst nach 2 identischen Nachrichten gesetzt werden (ich hab die gerade noch sehr vor Augen durch eigene Implementierung), da muss dann ja schon sehr Richtung wiederholter falscher Signalaufnahme liegen.

Hast du eine Vermutung, was eigentlich als Fahrbefehl kommen soll und falsch interpretiert wird? Oder zumindest ne Richtung?

Ich hab hier und da auch Probleme mit POM lesen und Susi als Funktionsausgang aber das ist erstmal zweitrangig.

Loks im Automatikbetrieb die nicht mehr auf ihre Adresse reagieren machen sehr viel mehr aua als eine LED die nicht angeht.

Gruß
Hannes

Hier is der Code:
https://github.com/ZIMO-Elektronik/DCC

Da können alle Experten reinschaun.

Hallo

Meine Fleischmann 210 mit ZIMO-MS-Decoder wollte jetzt gerade nicht mehr fahren.
CV 19 stand auf 224. Zurückgesetzt auf 0 --> fährt wieder.
Zur Sicherheit habe ich jetzt CV 16 ungleich CV 15 gesetzt.

Dietrich

Hallo Dietrich. Hast Du eine Programmiersperre jetzt mal gesetzt? lg

Hallo,

Danke für die Info, da bin ich gespannt ob die Programmiersperre den Vorgang blockiert.
Wenn ja -> eindeutig Fehler in der DCC Decodierung
Wenn nicht -> anderes Problem beim Zugriff auf CV Speicher

Grüße, Peter W

Hallo.
Der MoBa Freund 'spurneun' hat 12 MS Decoder und nur 1 spinnt jetzt. Vielleicht doch eine Hardwarequalitätsstreuung statt Firmwarethematik? Bitte mal von den Experten durchlesen. Grüße.

https://www.1zu160.net/scripte/forum/forum_show.php?id=1463591

Moin,
ganz interessant, bei mir sind auch bisher nur MS Decoder mit Goldcaps betroffen und bei Jemandandres/Moritz auch.

Gruß
Hannes

Hallo zusammen,

leider hab ich jetzt keine Zeit (Arbeit)
ich muss mir das in Ruhe mal ansehen und werden berichten

mke

Hallo

CV 15 ≠ CV 16 IST die Programmiersperre!

Dietrich

Eine Korrelation mit Goldcaps oder STACO konnte ich bislang nicht feststellen. Im Gegenteil, das einzige Mal als ich den Fehler bislang nachstellen konnte war mit einem blanken MS450 (bzw. sogar schlechterer Pufferung, weil ich den Datenlogger mit versorgen muss). Leider hat sich der Windows Laptop der die Daten mitloggte dann entschieden neu zu starten.... Anschließend lief die Testlok mehr als 48h durch.

Servus Vincent,

solange die Lok läuft passiert das auch nicht
sondern wenn die Lok aufgrund mangelnder Stromversorgung stehenbleibt
oder beim Abschalten der Anlage nach Ende Fahrbetrieb

mke

Hallo,

eine Idee dazu: Wenn man die Gleisspannung mit einem Arduino und Relais zufallsgesteuert unterbricht, müsste sich der Effekt doch zeigen.

Grüße, Peter W.

Mit DCC-EX brauchst du kein Relais. Auch kann man sehr kurz aus/anschalten. Dann einfach den Decoder in den Decodertester stecken, den Decodertester an DCC-EX und dann in EXRAIL folgendes definieren:

SEQUENCE(1)
   SET_POWER(A, ON)
   DELAYRANDOM(100,10000)  // 0.1 bis 10sec
   SET_POWER(A, OFF)
   DELAYRANDOM(100,10000)  // 0.1 bis 10sec
   FOLLOW(1)

Mit einer anderen Sequenz kann man auch den Decoder "fahren".

Dann die Störsequenz manuell starten (oder AUTOSTART) und es es wird stotterig am Gleisausgang A.

Bei der CSB-1 kann das auch im Booster-modus sein.

Grüße,
Harald.

Um einen sinnvollen Simulator zu bauen müsste man die Unterbrechungen vorher wohl erst studieren. Das wäre sicherlich eine nette Masterarbeit.

Ich gehe davon aus dass ich das Problem heute nach >60 Milliarden DCC Paketen wohl erschlagen habe. Es handelte sich aller Voraussicht nach um eine Kombination mehrerer unglücklicher Umstände.
- Ein bestehender Workaround für Fremdzentralen der die Vorgabe ignorierte das zw. zwei Programmierpaketen der Decoder nicht adressiert werden darf wurde entfernt
- Fehlende Längenprüfungen für alle DCC Pakete wurden hinzugefügt
- Eine fehlende Überlaufprüfung bei CV23 ließ die Beschleunigung negativ werden (ähnliche Symptome wie wenn sich CV19 ändert)
- Der Standard wird nun an zwei Stellen bewusst ignoriert. Sowohl die Kurzform für CV23/24 Schreiben als auch der Mehrfachtraktionssteuerungsbefehl ist in meinen Augen nicht sicher genug. (Nutzer der DCC Bibliothek werden die Standardkonformität mit einer CMake Option wiederherstellen können)

Servus.
Herzlichen Glückwunsch! Bedeutet also es wird demnächst ein offizielles Firmware update für MS und MN Decoder geben?
LG

Hallo Vincent,

gratuliere, das sind gute Nachrichten.

Grüße, Peter W

Nein natürlich nicht, ich behalte den Fix jetzt bis zum Hitzetod des Universums bei mir! [insert evil laugh]

Ja wird aber noch ein wenig dauern. Urlaubszeit usw.

Servus zusammen,

das hört sich plausibel an
UND auch noch sehr gut, wenn das mit einem Firmware Update behoben werden kann.
Auch wenn das vielleicht noch etwas dauert, kann man sich doch auf die MS-Dekoder verlassen und weitere Soundprojekte damit angehen.

mke

Hallo Vincent Hamp.
Ich wollte mal fragen, ob schon ein konkretes Zeitfenster für die Veröffentlichung des von Dir genannten FW updates um den Bug bei MS und MN Decodern zu beheben seitens ZIMO besteht? Bisher halte ich den Einbau meines Sounddecoders zurück, da ein Upgrade des Decoders ohne Lok für den Händler und mich bzgl. Kosten und Aufwand einfacher ist.
Grüße nach Wien.
Frank

Hallo Frank,

eine neue Version wird derzeit getestet. Wahrscheinlich wird noch in laufe dieses Monats das Update verfügbar sein.

LG
Markus