Wegen einer unbemerkten Änderung von Bauteil-Parametern funktioniert bei einem Teil dieser Decoder das Software-Update und das Nachladen von Sound-Projekten nicht.

Abhilfe: Entfernung des Bauteiles (rot gezeichnet, "C6", ein Kondensator) laut untenstehendem Auszug des Bestückungsplanes oder Reparatur bei ZIMO (Garantiefall).

Die seit Mitte April gelieferten Magnetartikel-Decoder MX82E, MX82D, MX82V  haben zum Teil keine Funktion auf den Anschlüssen für Servos bzw. Schalteingänge. Dies ist auf einen Bestückungsfehler zurückzuführen.

Abhilfe: Reparatur bei ZIMO (Garantiefall).

Die Großbahn-Decoder MX695 in der aktuellen Bauart (ab 2012 soll dies geändert werden) haben im Vergleich zu anderen ZIMO Decodern nur eine relativ kurze Zeit des Speicher-Erhalts (Zehntel sec - Bereich) für die aktuellen Fahrdaten. Wenn also eine Kontaktunterbrechung zur Schiene länger dauert als diese Zeitspanne, kommt es zum Power-on-Reset des Decoders und zum Weideranlauf von Motor und Sound wie aus dem Stand.

Abhilfe: Anschließen eines Energiespeichers (meistens Elektrolyt-Kondensators) an den dafür vorgesehenen Schraubklemmen oder Stiften (obere Leiste, links). Um eine entsprechende Wirkung zu entfalten, sollte die Kapazität des Kondensators zumindest einige 1000 uF betragen, da ja aus diesem Kondensator auch Motor, Sound-Erzeugung, und andere Verbraucher gespeist werden. Demgemäß besteht eine starke Abhängigkeit der resultierenden Speuicherzeit vom allgemeinen Stromverbrauch.

Diese Erscheinung ist bekannt zusammen mit Zentralen von Lenz und Uhlenbrock: Durch den Ladestrom, mit dem der MX695 seine internen Kapazitäten auflädt, kann es zur Abschaltung des Programmiergleis-Ausganges kommen. OB das tatsächlich passiert, hängt von verschiedenen Umständen ab, beispielsweise von der Versorgungsspannung.

Provisorische Abhilfe: Einige Anwender berichten, dass durch Vorschalten eines 12 Ohm - Widerstandes in die Schienen-Leitung der Stromverbrauch genügend abgesenkt wird, um das unbeabsichtigte Abschalten der Zentrale zu vermeiden. Dies ist eine unter Großbahnern bewährte Methode, weil eine ähnliches Problem auch mit Decodern anderer Hersteller auftritt.

Abhilfe: Die nächste Auflage der Großbahn-Decoder ab Juli/August 2011 wird einen kleineren Strom ziehen; dies sollte das Problem beseitigen oder zumindest unwahrscheinlicher machen.

Die folgenden Probleme sind in letzter Zeit bekannt geworden:

- Auslesen von CV's im Operational Mode (PoM): Bei manchen Systemen kommt die Meldung des Wertes erst bei der zweiten Abfrage oder gar nicht. Hintergrund: Bei einer Zentrale die den DCC-Auslese-Befehl (ebenso wie Schreib-Befehle) mehrmals hintereinander sendet, z.B. bei ZIMO, ist dieser Fehler nicht feststellbar; bei einigen anderen Systemen (die einmal senden) gibt es dieses Problem.

- Adress-Erkennung und -Anzeige durch einen "lokalen RailCom-Detektor" funktioniert bisweilen unzuverlässig oder verzögert (möglicherweise besonders, wenn nur diese eine Adresse im System), festgestellt in einer Anwendung zusammen mit Tams-Produkten. Hintergrund: Ein ZIMO Decoder mit bisheriger Software hat seine eigene Adresse im sogenannten "Broadcast-Channel" nicht ausgesendet, wenn die eigene Adresse angesprochen wurde,  weil diese in Daten-Kanal sowieso quittiert wird. Wenn allerdings ein "lokaler Detektor" nur den Broadcast-Channel liest und gleichzeitig nur oder fast nur diese eine Adresse ausgesendet wird, funktioniert die Meldung nicht.

Abhilfe: SW-Update auf 30.10 oder höher.

Dies ist kein eigentlicher Entwicklungs- oder Produktionsfehler, sondern eher eine Fehleinschätzung der Anwenderwünsche: aus Speicherplatzgründen (wegen Miniaturisierung kleinerer Prozessor als andere ZIMO Decoder) sind einige der sonst üblichen Software-Features im MX621 nicht implementiert. Dies betrifft u.a. das MM-Format (nicht vorhanden), die Servo-Ansteuerung (nicht vorhanden), Lichteffekte, und eben auch einen großen Teil des über das NMRA-konforme hinausgehende Function mapping (CV 61 = ... Fälle, darunter auch die Prozedur CV # 61 = 98).

Während der größte Teil der dadurch verursachten Einschränkungen für die Anwendungen eines Miniatur-Decoders belanglos sind, gibt es eine Betriebsvariante, die jetzt fehlt und doch vielfach genwünscht wird: der "einseitige Lichtwechsel", bisher entweder über die CV # 61 = 98 Prozedur oder über die Effekte programmierbar.

Wegen des großen Bedarfs werden wahrscheinlich in der nächsten SW-Version die bisher unbenützten CV's 47, 48 dafür herangezogen, um zumindest den "einseitigen Lichtwechsel" möglich zu machen.

Abhilfe: SW-Update auf zukünftige Version, wo der beschriebene Mangel behoben ist (also die CV's # 47, 48 eingebaut sind.

Wegen eines Bestückungsfehlers arbeitet die Rückmeldung (CV-Auslesen, Geschwindigkeits-Meldung, Adress-Rückmeldung) über RailCom nicht.

Fehler verifizieren: CV # 29, Bit 3 einschalten (also z.B. CV # 29 = 14) und CV # 28 = 3. Fahrbetrieb mit RailCom-fähigem Digitalsystem, z.B. ZIMO MX31ZL. Wenn dann keine Geschwindigkeitsmeldung (kmh ...) im Display aufscheint, ist der betreffende Decoder bezüglich RailComdefekt.

Abhilfe: In diesem Fall ist zu Behebung nur eine Hardware-Reparatur bei ZIMO möglich.

Die beiden genannten Betriebsarten (siehe CV's # 135, 136 bzw. # 140 .. 143) sind anscheinend durch Software-Modifikationen in der Vergangenheit beschädigt worden. Die gewünschte Funktion ist daher mit der aktuellen Software nicht oder nicht vollständig gegeben.

Abhilfe: SW-Update auf zukünftige Version, wo dieser Fehler behoben ist.

Bei Verwendung der sogenannte "Märklin-Bremsstrecke" und gleichzeitiger Verwendung des MM-Formates (Motorola, meistens Märklin-Zentrale) Fährt der Zug nach Aufhebung der Bremsstrecke nicht selbsttätig wieder an.

Hingegen: bei DCC Format und "Märklin-Bremsstrecke" (ist praktisch gleich der Gleichstrom-Bremsstrecke) tritt dieser Fehler nicht auf.

Abhilfe: SW-Update auf 28.25 oder höher

Durch einen Bauteil-Bruch am Decoder, der beim routinemäßigen Produktionstest nicht erkennbar ist, kommt es zu einem Fehlstrom in der Motor-Endstufe des Decoders, der den Stromverbrauch, und damit die Erwärmung des Decoders erhöht. Im Allgemeinen tritt dieser Effekt jedoch nur auf, wenn die Fahrspannung höher als ca. 20 V ist. Dies ist vor allem bei Digitalzentralen ohne Spannungsregelung der Fall, daher (auf den ersten Blick paradoxer Weise) bei besonders kleinen, preisgünstigen Produkten und geringer Belastung.

Es ist derzeit nicht wirklich bekannt, wie viele der gelieferten Decoder diesen Fahler aufweisen; es könnten bis 20 % sein.

Erkennung des Problems: Fahrverhalten beim Rückwärtsfahren ist schlechter als im Vorwärtsbetrieb, Geräusche beim Rückwärtsfahren, manchmal schaltet die Digitalzentrale ab (was natürlich nur bei relativ "schwachen" Zentralen passiert), ev. kann der Decoder beschädigt werden, d.h. die Endstufe zerstört (eine Fahrtrichtung fällt aus oder beide).

Abhilfe: Reparatur bei ZIMO

Der Typ MX645 wird seit Dezember 2010 ausgeliefert.

Es kommt (je nach SW-Version leicht unterschiedlich) zu verzögertem Einschalten der FA5 bis FA8, Nicht-Funktion der FA7 - FA8, und Nicht-Wirkung der Dimm-Maske 2 für die FA's ab FA7.

Abhilfe: SW-Update auf 28.15 oder höher

Durch einen Software-Fehler bezüglich der Überstrom-Abschaltung für Funktions-Ausgänge kommt es ohne Anlass zum Abschalten der Lichter (besonders wenn es sich um Glühbirnchen handelt und nicht nur um LEDs); nach einigen sec schaltet sich das Licht wieder automatisch ein.

Abhilfe: SW-Update auf 28.10 oder höher

Bei Durchführung des SW-Updates mit dem Update-Gerät MXDECUP kommt die Fehler-Meldung "Framing error" - Das Update wird aber trotzdem durchgeführt !!!     Ursache ist ein Fehler im Boot-Loader der Decoder; dieser wird nicht durch ein Software-Update beseitigt (obwohl dieses - siehe oben - an sich funktioniert) !

Abhilfe: Fehler-Meldung ignorieren ... besser: sobald erhältlich auf das neue Update-Gerät MXULF wechseln !

Dies betrifft (wahrscheinlich) Decoder mit Software-Versionen 27.7 bis 28.9.

Der Decoder spricht nicht an auf die MAN-Taste des ZIMO Fahrpultes (MN beim MX32), sowohl was das Aufheben der ZIMO Zugbeeinflussung (HLU) betrifft) als auch, wenn MAN in Verwendung als Rangiertaste.

Abhilfe: SW-Update auf aktuelle Version durchführen.

Das Zeitverhalten im Programmiermodus (am Programmiergleis, "service mode") eines Fertigungsloses der ZIMO (Nicht-Sound-) Decoder MX630, MX631 weicht leicht von der Norm ab, was bei Digitalsystemen, die diesbezüglich  wenig Toleranz aufweisen, dazu führt, dass das Programmieren/Auslesen der CV's sowie das Adressieren (Zuteilung einer neuen Fahrzeugadresse) am Programmiergleis (im SERVICE MODE) nicht funktioniert.

Bekannt ist derzeit, dass das Programmieren/Auslesen mit Lenz Digitalsystemen sowie Uhlenbrock Digitalsystemen (Intellibox I, wahrscheinlich auch II) davon betroffen ist.  Über Probleme mit anderen Systemen ist (derzeit) nichts bekannt.

Abhilfe im Falle eines Lenz-Systems: es kann das "Quittungsverfahren durch Hochfrequenz-Hochstromimpulse" verwendet werden, welches an sich für andere Aufgaben geschaffen wurde, aber "zufällig" hier auch hilft. Dafür ist folgende CV-Programmierung notwendig:

  CV # 112, Bit 1 = 1,    also z.B.  CV # 112 = 5

Besser ist natürlich ein SW-Update auf die aktuelle Version.

Abhilfe im Falle eines Uhlenbrock-Systems: das obige Verfahren (wie für Lenz) hilft nicht; CV-Programmieren kann also nur unbestätigt durchgeführt werden; CV-Auslesen ist nicht möglich.

Im Falle des Adressieren ist auch keine unbestätigte Durchführung möglich, weil bei Adressieren das Auslesen der CV # 29 unumgänglich ist. Ersatzweise kann/span> das eigentliche Adressieren durch direktes (unbestätigtes) CV-Programmieren ersetzt werden:

Im Falle einer "kurzen" Adresse (1 bis 127): die gewünschte Adresse einschreiben in CV # 1,
im Falle einer "langen" Adresse (ab 128): gewünschte Adresse in CV # 17 und 18
(die Art der Codierung der langen Adresse kann man erfahren, indem man versuchsweise einen
Decoder mit funktionierendem Auslesen regulär adressiert und dort das Ergebnis aus CV # 17 und 18 ausliest)

Bei Wechsel zwischen kurzer und langer Adresse: CV # 29 neu programmieren
(mit Bit 5 = 0 für kurze Adresse, Bit 5 = 1 für lange Adresse)

Besser ist natürlich ein SW-Update auf die aktuelle Version./span>

ZIMO Decoder, die werksseitig in Fahrzeuge der Fa. Roco, Fleischmann, HAG, und anderer Hersteller eingesetzt werden, sind häufig gegen ein SW-Update gesperrt; dies geschieht aus Sicherheitsgründen, damit der Decoder (insbesondere im Analogbetrieb) nicht versehentlich in den Update-Modus geraten kann (wo er dann nicht mehr fahrbar wäre).

Wenn ein solcher Decoder bzw. eine Lok, die einen solchen ZIMO Decoder enthält, mit einer neuen SW-Version versehen werden soll, wird der Decoder von der Update-Software (ZSP, ZIRC, ..) als "nicht gefunden" gemeldet !

Abhilfe: vor dem SW-Update: 

  CV # 144 = 0

setzen ! Damit wird in der CV # 144 auch das Bit 7 gelöscht, welches für die Update-Sperr zuständig ist. Danach kann die neue Software geladen werden (wie üblich mit MXDECUP oder MX31ZL und Software ZSP, ZIRC, ..)

Zusatzhinweis: In manchen Fällen wird das SW-Update auch behindert, wenn Analogbetrieb eingeschaltet ist, was bei werksseitig eingebauten Decodern meistens der Fall ist. Wenn dies der Fall ist - oder gleich vorbeugend - kann der Analogbetrieb dieser ausgeschaltet werden durch

CV # 29, Bit 2 = 0,    also z.B.  CV # 29 = 10 (anstelle 14, was oft vorgegeben ist)

Nach erfolgtem Update können natürlich Analogbetrieb und/oder Update-Sperre bei Bedarf wieder aktiviert werden: CV # 29 = 14, CV # 144 = 128.

HiHinweis: ein neues - besonders komfortables Decoder-Update-Gerät - MXULF - ist in Entwicklung und wird das vorhandene MXDECUP ablösen ! Dieses kann auch offline arbeiten ("Decoder-SW-Update" aus dem USB-Stick), wird Testfahrten möglich machen, und wird natürlich auch das Sperr-Bit in CV # 144 selbsttätig löschen ...

Diese Problem kann auftreten, wenn in CV # 155 und/oder CV1 # 156 eine Funktion als Rangiertaste zugeordnet ist, und die Digitalzentrale den aktuellen Zustand der betreffenden Funktion (z.B. F6) -dass sie nämlich ausgeschaltet ist - nicht aussendet, weil das Digitalsystem die betreffende Funktion (z.B. F6) gar nicht kennt, weil z.B. nur die Funktionen F0 bis F4 bedient werden.

Dies ist vor allem bei älteren Digitalsystemen der Fall (altes Märklin System, altes Roco Lokmaus System, ... deswegen wurde das Problem auch nicht vor Auslieferung erkannt.

Der Decoder nimmt dann zufällig einen Zustand (ein/aus) für diese Funktion (z.B. F6) an, und schaltet damit den Rangiergang manchmal ein. Dies macht sich vor allem dadurch bemerkbar, das die Lok nicht mit normaler Geschwindigkeit fährt, sondern schleicht. Die Lok verhält sich aber meistens nicht dauerhaft so, sondern das Problem kann nach Power-on verschwinden oder wieder-auftreten, bzw. auch nach verschiedenen Bedienungsschritten.

Eventuell betroffene Fahrzeuge mit einem ZIMO Decoder als Erstausstattung sind:

ROCO, FLEISCHMANN:
E10/BR110  (F9 als Rangiertaste)
DA-SJ (F6 als Rangiertaste)
BRBR44 (F6 als Rangiertaste)
Railjet (F6 als Rangiertaste)
BR43 (F6 als Rangiertaste)span>

HAG:
MX631, 631C (F4 als Rangiertaste)

NICHT betroffen: ICN, S231, S60, BR18.201, 1245

Abhilfe: N Null-Setzen der Rangiertasten-CV's, also 

 CV # 155 = 0   und CV # 156 = 0

Damit ist die Rangierfunktions beseitigt, was keinen Verlust darstellt, weil sie vom betreffenden Digitalsystem ohnedies nicht bedient werden könnte.

Da hauptsächlich Motorola-Fahrer betroffen sind (altes Märklin System ...), hier eine kurze Beschreibung, wie diese Programmierung von einem Märklin 6021 aus durchzuführen ist:

Um in den Programmiermodus einsteigen:
- die Adresse der zu programmierenden Lok anwählen
- "STOP"-Taste auf der Zentrale drücken und einige Sekunden warten
- Geschwindigkeitsregler über den linken Anschlag hinaus drehen, halten (Richtungsumkehr)
- "START"-Taste auf der Zentrale drücken
- Geschwindigkeitsregler loslassen

Der Decoder sollte nun im Programmiermodus sein und das Frontlicht im Abstand von einer Sekunde blinken. Nun folgende Adressen eingeben und danach. Richtungsumkehr betätigen (RU=Richtungsumkehr):
- Adr. 80, RU, RU  (wechselt in den Modus zum programmieren von CV's > 79)
- Adr. 15, RUr> - Adr. 5, RU
- Adr. 80, RU, RU
- Adr. 15, RU
- Adr. 6, RU
- Adr. 80, RU, RU

DaDas Anhalten in einer Gleichstrom-Bremsstrecke (auch "Märklin" - Bremsabschnitt) funktioniert zwar planmäßig, jedoch fährt die Lok span> nach dem Aufheben einer Gleichstrom-Bremsstrecke (wenn also wieder ein DCC-Signal angelegt wird) nicht selbsttätig wieder an.

Das Problem tritt nicht bei Betrieb mit einem ZIMO Digitalsystem auf !

Abhilfe: F Folgende CV-Programmierungen machen den Fehler unwirksam (obwohl diese CV's eigentlich nichts mit DC-Abschnitten zu tun haben, sondern mit ABC):

 CV # 27 = 3   und CV # 134 = 150span>

Allerdings funktioniert dann ABC nicht mehr (aber dieses wird selten zusammenmit DC-Bremsabschnitten verwendet). Besser ist natürlich ein SW-Update auf die aktuelle Version.

Hinweis: ein neues - besonders komfortables Decoder-Update-Gerät - MXULF - ist in Entwicklung und wird das vorhandene MXDECUP ablösen !

Versehentlich wurden in den letzten Monaten ein Teil der Sound-Decoder ohne bzw. mit unvollständiger ID in den CV's # 250 - 253 ausgeliefert; hauptsächlich solche, die werksseitig in Fahrzeuge der Fa. Roco eingebaut wurden.

Im Normalfall macht das kein Problem, da bereits das passende Sound-Projekt geladen ist. Falls aber in einen solchen Sound-Decoder ein anderes Sound-Projekt geladen werden soll, und dieses andere Sound Projekt ein kostenpflichtiges ist, müsste dafür ein Lade-Code angefordert werden, was aber ohne Decoder-ID nicht möglich ist.span>

Abhilfe: Auslesen der CV # 250 von einem Fahrgerät aus (nicht vom Computer); das Ergebnis des Auslesens ist in diesem Zusammenhang belanglos (es handelt sich um einen Code für den Decoder-Typ), aber es führt dazu, dass eine automatische ID (Zufallszahl) gebildet wird. Diese kann dann auch vom Computer ausgelesen werden, und für die Anforderung eines Lade-Codes verwendet werden.

Beim Laden eines Sound-Projektes über das Decoder-Update-Gerät MXDECUP kommt es zum Abbruch, obwohl der Decoder zunächst erfolgreich gefunden wird, und auch ein eventuelles Software-Update durchgeführt werden kann. Ursache für das Problem dürfte ein elektrisches Übersprechen zwischen nahe-liegenden Leiterbahnen auf der Decoder-Platine sein.

Bei den selben Decodern kann es übrigens auch zu Sound-Verzerrungen kommen, wenn die Schienenspannung größer als ca. 20 V ist.

Abhilfe: Decoder in umgekehrter Polarität am MXDECUP anschließen; Software-Update auf Version 27.6 oder höher.

Bei einem Teil der etwa im Juli, August 2010 produzierten Sound-Decoder MX642 funktioniert bei angeschlossenem Energiespeicher-Kondensator das CV-Auslesen am Programmiergleis nicht.

Abhilfe: abgesehen von der provisorischen Lösung des Abtrennen des Kondensators kann das Problem nur durch eine Reparatur in der ZIMO Werkstätte behoben werden.

Durch einen Fehler innerhalb der verwendeten Microcontroller funktionieren viele der Sound-Decoder, welche im Jahr 2010 ausgeliefert worden sind, nicht stabil bei höheren Temperaturen. D.h. ab eíner Decoder-Temperatur von ca. 80 C kann es zum "Absturz" der Software kommen, wodurch der Decoder nicht mehr ansprechbar ist.

Abhilfe: Der defekte Microcontroller muss ausgetauscht werden; diese Reparatur ist nur in der ZIMO Werkstätte möglich; sie erfolgt natürlich auf Garantie.

In den letzten SW-Versionen (etwa ab 25.0) und mit einigen Antriebsarten tritt ruckeliges Fahrverhalten (eher bei MX640 gesehen) auf bzw.  "Bocksprünge" (gelegentliches Hochlaufen des Motors, gesehen beim MX630).

Abhilfe: Update des Decoders auf die Version 26.4 oder höher..

Bei Verwendung der Decoder zusammen mit Lenz-Systemen wird bisweilen der "Signalhalt durch asymmetrisches DCC-Signal" (Lenz ABC) eingesetzt. Kundenberichte sprechen davon, dass diese Funktion mit den aktuellen SW-Versionen der ZIMO Decoder nicht sicher funktioniert.

 Abhilfe: Neue SW-Version ab Juli 2010

Durch Pseudo-Programmieren der CV # 7 können höher CV's und höhere CV-Werte (jeweils > 99) mit Geräten erreicht werden, welche nur einen Wertebereich 0 - 99 beherrschen, wie Lokmau-2. Durch Software-Modifikationen im Decoder (wahrscheinlich mit Version 25.0) ist dies Funktion versehentlich gestört worden.

Abhilfe: Update des Decoders auf die Version 25.4 oder höher. 

Diese Prozedur dient zur richtungsabhängigen Zuordnung von Funktionsausgängen zu Funktionen, was mit dem "normalen" Function mapping" nach NMRA nicht möglich ist. Durch Software-Modifikationen im Decoder (wahrscheinlich mit Version 25.0) ist dies Funktion versehentlich gestört worden.

Abhilfe: Update des Decoders auf die Version 25.4 oder höher. 

Januar 2009Die SW-Version 20.19 bewirkt beim Sound-Projekt für den "roten Brummer" VT98 nach einiger Zeit (jeweils nach Power-on) normaler Funktionsweise, einen immer rascheres Abspielen einer Funktions-Sounds. Diese SW-Version ist an sich eine Spezial-Ausgabe für ein anderes Hersteller-Projekt und wurde versehentlich in eine größere Serie Decoder geladen.

Abhilfe: Update des Decoders auf die "ältere" Version 20.18 bzw.

Endgültige Abhilfe: neue SW-Version 25.0 ab Juli 2009.

Das MX31ZL kann bekanntlich sowohl als Zentrale als auch als "normales" Fahrpult angeschlossen an einem Basisgerät MX1, ... oder auch an einem anderen MX31ZL, verwendet wird. Wenn ein MX31ZL als Fahrpult an eine bereits laufende Konfiguration angeschlossen wird, kommt es zum Zwangs-Resewt aller Geräte am CAN-Bus, d.h. die Züge bleien stehen, usw. Dieser Effekt hat sich als SW-Fehler vor einigen Moanten "eingeschlichen".

Abhilfe: Entweder: MX31ZL anschließen vor dem Einschalten des Basisgerätes, oder (besser) Update auf die korrigierte Software-Version ab 3.08 (Februar 2009).

Mit bestimmten Motoren (typ. Fleischmann) treten mit neueren SW-Versionen (z.B. beim MX640 höher als 4.0) Regelungsfehler auf, meistens bemerkbar durch plötzliches unerwünschtes Beschleunigen ("Bocksprünge").

Betroffen sind nur bestimmte Motortypen, besonders häufig dürften dies Fleischmann-Motor sein. Auch Faulhaber-Motore könnten gelegentlich betroffen sein.

Abhilfe: Update auf die korrigierte Software-Version (ab ca. 28. Jan. 2009)

MX620, MX64D:  9.10
MX69, MX690: 20.16
MX640:   4.16