Hallo Tom,
das hört sich so an als ob entweder deine CS3 plötzlich den Befehl POM CV3 = 160 senden würde oder aber irgend ein Befehl im DCC-Protokoll, interessant wäre es zu wissen was direkt vor dem Problem du für Eingaben in die CS3 getätig hast, in diesen Decodern aufgrund eines Bugs der Software diese Umprogrammierung auslöst.
Wobei fast ein Bug auszuschliesen ist das Problem würden ja auch andere Kollegen haben.
Volker

Moin

Kann es denn sein dass einer Deiner Booster dieses Phänomen auslöst?

Bis dahin

Zitat von volkerS im Beitrag #26

---

POM CV3 = 160

---

Zitat von digitalo im Beitrag #27

---

Kann es denn sein dass einer Deiner Booster dieses Phänomen auslöst?

---

Hallo Tom,

hast Du dazu schon Kontakt mit dem ZIMO-Service gehabt? Herr Hubinger weiß fast immer Rat.

Gruß
Werner

Hallo Tom,
bei den MS Decodern die aktuell noch funktionieren: Vielleicht kann man durch setzen der Decodersperre mit CV15 und CV16 verhindern, dass ungewollt was umprogrammiert wird? Ich habe die Sperre bisher noch nicht genutzt, aber so wie ich das verstehe, setzt man die CV16 auf einen Wert, dem man sich vielleicht notieren sollte und solange die CV15 nicht den gleichen Wert hat, ist der Decoder gegen Programmierung gesperrt. Wäre zumindest einen Versuch wert, bei den MS Decodern, die noch inkl. Sound funktionieren und wo du vorher nur ggf. nach einem Reset auf dem Programmiergleis alles so einstellst, dass es passt, bevor du die Lok auf die Anlage setzt.
Bei den Decodern, wo der Sound nicht mehr funktioniert, wäre interessant, ob man die ggf. mit einem MXULFA wieder zum Leben erwecken kann, im schlimmsten Fall müsste man halt den Sound neu damit schreiben.
Vielleicht gibt es ja jemanden in deiner Nähe, der ein MXULFA hat?
Ich habe zwar eins, aber München / Maisach ist auch nicht gerade um die Ecke.
Viele Grüße
Michael

Moin

Zitat von mikomue im Beitrag #30

---

... Bei den Decodern, wo der Sound nicht mehr funktioniert, wäre interessant, ob man die ggf. mit einem MXULFA wieder zum Leben erwecken kann, im schlimmsten Fall müsste man halt den Sound neu damit schreiben ...

---

Zitat von kellerbahnsbg im Beitrag #28

---

... weil mir der Zimo-Support fast nicht geglaubt hat dass die Loks ihr Sound-Projekt "vergessen" haben. Das schien für den Support fast unmöglich ...

---

Hallo zusammen

Mir scheint, dass sich so ziemlich jeder Decoderhersteller (ausser Märklin und ESU) mit der Implementierung von "pseudeo mfx" und selbst "fits mfx" keinen gefallen erweist. Die langen reparturzeiten bei Zimo könnten eine Folge desen sein.

Zitat von kellerbahnsbg im Beitrag #24

---

Das Drama mit den MS Decodern geht weiter. Da ich wirklich von niemanden mit derartigen Problemen gehört habe, nehme ich langsam schon meine Anlage (bzw. CS3 plus) in Verdacht. Gestern, während eine 1116 mit MS450P22 fuhr, reagierte diese plötzlich nicht mehr. Hab also Gleisstrom aus, aufs Programmiergleis, und siehe da, sie hat während der Fahrt eine neue Adresse angenommen (DCC 160). Wohl angemerkt hab ich in dieser Zeit nicht am Programmiergleis rumgewerkelt, weder wird der Programmierstromkreis für irgendwas anderes verwendet als fürs Prog.-gleis. Ich fahre intzwischen nurmehr mit DCC aktiviert. Alles war auf einen der zwei Boostersegmente. Kurz darauf merkte ich, andere Loks reagierten auch nicht mehr. Also hab ich mal F2 (Hupen) auf DCC 160 aktiviert, und siehe da: Am Hauptgleis (Boostersegment, nicht Programmiergleis!) haben sich mehrere Loks auf die besagte Adresse gesetzt? Betroffen waren folgende Loks:- 2x 1116 088 (MS450P22)- 1293 Nightjet (MS450P22)- 1216 Nightjet (MS450P22)- 1142 684 (MX645P22)- 1193 WLC (MS450P22)

---

Moin moin,

ich habe da auch ein ähnlich gelagertes Problem...
Ich habe eine Roco Br 120 DR mit 8 poliger Schnittstelle mit einem MS450 inkl. Jacek Sound ausgerüstet.
Nach der Abschaltung der nicht benötigten Protokolle und der Adressänderung auf 120 über das MXULFA lief die Lok auch mehrere Stunden tadellos.
Aus heiterem Himmel stotterte die Lok kurz (trotz Powerpack und sauberen Schienen) und regaierte dann nicht mehr, weder Sound noch Licht etc.
Beim schnellen auslesen über meine Ecos stellt ich dann fest, dass sich die Adresse von 120 auf 160 umgestellt hat. In den folgenden Betriebsstunden hat sich das Verhalten nicht geändert. Nach einer Laufzeit X immer wieder das gleiche. Einziger Unterschied ist, dass die verstellte Adresse variiert. Da ich noch andere Projekte für einen Bekannten umzusetzen hatte, hab ich das Problem erstmal nicht weiter verfolgt, da ich ja nun erstmal einen Workaround hatte. Die Brawa Br 111 die ich Monate später genauso umgebaut habe, zeigt den Fehler nicht. Der Decoder hat aber auch eine neuere FW. Ein Anruf bei Zimo(im Sommer 22) ergab in dieser Richtung auch nichts, da man sich den Fehler auch nicht erklären konnte. Meine Recherche im Netz ergab zu diesem Zeitpunkt leider auch keine neuen Erkentnisse. Vermutlich sollte ich den Decoder der Br 120 erstmal updaten und dann schauen ob das Problem noch existent ist. Im übrigen gibt meine Zentrale nur DCC raus und auch die Decoder sind auf only DCC programmiert.

VG André

Zitat von Heinzi im Beitrag #32

---

Das wäre ja wieder ein klarerer Fall für den Zimo-Service, wobei du Zimo dann gleich mal fragen könntest, weshalb sie in der MS-Serie die CV 144 (Programmiersperre) abgeschaft haben, und ob diese diesen Fall verhindert hätte.

---

Moin André

Nur Hypothese ... Roco verbaut auf seinen Platinen soweit ich weiß einen Kondensator zur Entstörung zwischen den Motorpolen... ähnlich wie Märklin nur halt auf der Platine und in BF SMD. Die MSxxx Zimo-Decoder scheinen aber aus irgendeinem Grund weitaus empfindlicher zu sein als die MXxxx-Reihe und bei Zimo ist die Entstörmimik bereits im Decoder integriert.
Vermutung ... das bringt die Software aus dem Tritt und es kommt zu einer Überlastung bei der ein oder mehrere CVs geändert werden.
Wie gesagt ... reine Vermutung ...

Bis dahin

Zitat von digitalo im Beitrag #35

---

Nur Hypothese ... Roco verbaut auf seinen Platinen soweit ich weiß einen Kondensator zur Entstörung zwischen den Motorpolen...

---

Moin Flo

Ich denke nicht das dies ein Alleinstellungsmerkmal von Piko ist, das C4-Problem hat ist mittlerweile auch unumstritten.
Auf unseren Ersatzplatinen für einige Fahrzeuge von Märklin, Roco oder Brawa sind zwar Lötpads für solch einen Kondensator vorgesehen, bestückt jedoch werden die nicht! Zumindest in meinen Erfahrungen mit dem Digitalisieren von Modellen jeglicher Hersteller kann ich sagen, das es dem Kondensator nicht braucht, die Modelle laufen besser ohne diesen Firleganz, der nur im Analog-Betrieb nötig ist.

Bis dahin

Zitat von digitalo im Beitrag #35

---

Moin André

Nur Hypothese ... Roco verbaut auf seinen Platinen soweit ich weiß einen Kondensator zur Entstörung zwischen den Motorpolen...

Bis dahin

---

Moin André

Doch doch ... da ist einer und zwar wird der von den violetten Kabeln zwischen den Drosseln verdeckt ... schieb die Kabel mal beiseite, dan siehst Du den kleinen hellbraunen Würfel in BF SMD ... das ist ein Keramik-Kondensator und der soll im Analog-Betrieb das Bürstenfeuer des Motors kompensieren.

Bis dahin

Hallo André,

Stephan hat Recht, alle Roco-Loks haben einen Entstörkondensator zwischen den Motorpolen und alle anderen mir bekannten Hersteller ebenso (Funkentstörung).
Und auch wenn hier immer wieder von Problemen mit den Kondensatoren speziell bei Piko (C4) berichtet wird, ich konnte noch keine feststellen, egal welcher Decoderhersteller. Ich habe genau ein Mal den Piko C4 ausgelötet, das Ergebnis war keinerlei Veränderung, weder beim betroffenen Modell noch bei anderen.
Ich bezweifle auch, dass sich ZIMO MS-Decoder mit aktueller Firmware seltsam verhalten, denn ich habe inzwischen einige ZIMO MN-Decoder eingebaut, die den MS bis auf den Soundteil entsprechen, und auch damit keinerlei Probleme feststellen können.

Gruß
Werner

Zitat von drum58 im Beitrag #40

---

Hallo André,

Stephan hat Recht, alle Roco-Loks haben einen Entstörkondensator zwischen den Motorpolen …

---

Zitat von Kretsche im Beitrag #33

---

dass sich die Adresse von 120 auf 160 umgestellt hat

---

Du könntest mal testen ob das Problem auch dann auftritt wenn in der Piko 1044er ein anderer Decoder drin ist.

Moin Tom

ich empfehle Dir mal dieses "Machwerk" ... RE: Probleme PIKO/ESU Loksound M4 mit DCC / MM Decodern ... von Heimo Wissing. Bislang 12 Seiten schwer und teils recht wissenschaftlich gehalten. Darin wurde auf das Piko-C4 Problem glasklar hingewiesen und ich hab es "durchgeackert" ... bei mir fliegt dieser Unrat, der auf den Brückenstecker gehört und nicht auf die Board-Platine des Modells seither sang und klanglos raus.
Das 1. was ich bei einer neuen Piko-Lok im BW tue, ist den C4 zu entfernen ... ich habe mehr als 25 Stück davon im BW.

Moin Werner

Kann ja sein, das Du auch keine Probleme mit dem C zwischen den Motorpolen hast, ich denke das ist auch von der verwendeten Zentrale abhängig wie ausgeprägt dieses Phänomen auftritt.
Beim Commander von Viessmann war es so, dass bei mir die Decoder von UB ein sehr unangenehmes zirpen des Motors verursachten und Kollegen mit einer IB aus gleichem Hause dies nicht hatten.
Meine Ludmilla von Roco bekam vor Jahren eine Austauschplatine von Hr. Huebsch und einem Zimo MX645P22 mit Henning-Sound spendiert ... die Lok fuhr super, der Sound war ein Gedicht. Irgendwann musste ich das Gehäuse der Lok abnehmen und bekam es fast nicht runter ... schließlich griff ich beherzter zu. Auf der Decoderseite waren die Lichtleiter durch die hohe Wärmeentwicklung des Decoders total mit der Platine verschmolzen. Das war zu der Zeit, als das C4-Problem von Piko hochkochte ... auch die Huebsch-Platine hatte einen C zwischen den Motorpolen ... nun aber nicht mehr und der Decoder bleibt seither kalt.
Jeder hat so seine Erfahrungen, ich höre immer das der ein oder andere kein Problem mit dem C zwischen den Motorpolen hat ... bei den märklinschen Gussklumpen, da ja aus "wertigem Metall" ... ist ein heißer Decoder vermutlich auch kein Problem, aber wenns ein wenig originalgetreuer sein soll und Kunststoff ins Spiel kommt, kann die Hitzeentwicklung des Decoders zum Totoialverlust des Modells führen ... daher ... für Experimente ala "abwarten und Tee trinken" sind mir meine Modelle zu teuer gewesen.

bis dahin

Morgen!

Ich hab mich gestern mit einem Kollegen intensiv mit dem Problem auseinandergesetzt. Dass die Piko-Lok das verursacht konnten wir mehr oder weniger ausschließen.
Eine Vermutung konnten wir dafür aufstellen:
Ich habe auf meiner CS3 nur DCC aktiviert. Also MM und MFX ist deaktiviert. Trotzdem spreche ich die Märklin m83 Decoder für die Weichen via. Windigipet mit MM an. Dass das geht wundert mich eigentlich?
Vielleicht vertragen die MS-Decoder das aus welchem Grund auch immer nicht, denn MM ist ja eigentlich deaktiviert.

Die 160 in den CV-Werten lieben die MS-Decoder dafür. Diese Zahl wurde bei meinen Loks schon zig mal von selber gesetzt. Ich werde heute oder morgen mal alle m83 auf DCC umstellen und schauen ob das Problem besteht.

Gruß,
Tom

Hallo Zusammen,
ich habe in letzter Zeit zwei AC Roco Loks gekauft. Einen Vectron vor ca. 9 Monaten und die Aktuelle 218 Press.
Ich Fahre mit Traincontroller mit einer Ecos2 zum Fahren und einer CS2 zum Schalten.
Das Dillemma bei Märklin ist, daß es MM und mfx gibt. D.h. ich verwende MM, mfx und DCC, wobei die moderneren Märklin Loks mit DCC gesteuert werden, soll heißen, daß mehrheitlich DCC verwendet wird.

Jetzt zu meiner Beobachtung.
Vorab: Bei beiden Loks ist nur das DCC Protokoll aktiv.
Die 218 hat nach weniger als zwei Betriebsstunden keinen Mux mehr gemacht, d.h. weder ging irgend ein Sound, noch ließ sich die Lok fahren.
Folglich die Lok über den Händler zur Reparatur zu Roco geschickt.

Vor zwei Tagen nun das gleiche Problem mir dem Vectron (ca. 11 Betriebsstunden).
Mit der Ecos konnte ich keine CV auslesen es kam immer eine Fehlermeldung. Der Dekoder machte wie oben beschrieben keinen Mux mehr. Auch in diesem Fall haben alle in diesem Thread beschriebenen Maßnahmen nicht geholfen.

Ich habe dann die Lok auf das Programmiergleis der CS2 gestellt, hier konnte ich unter DCC alle CV's lesen / schreiben und die Lok fahren etc..
Anschließend habe ich die Lok wieder auf das Programmiergleis der Ecos gestellt.
Nix ging, weder konnte ich die Lok fahren, noch konnte ich CV's auslesen.

Ich habe die Lok in der Ecos gelöscht und neu angelegt, nix ging.

Nächster Versuch: Ich habe die gespeicherten Konfigurationsdaten welche diese Lok enthielt auf die Ecos geladen und siehe da! Die Lok konnte vollumfänglich angesprochen werden.

Da Frage ich mich wie ist das zu erklären?

Zunächst liegt der Verdacht nah, daß es an der Ecos liegt.
Was aber dagegen spricht, das die Probleme auch mit anderen Zentralen wie z.B. der CS3+ beschrieben wurden.

Die BR 218 ist nach acht Wochen auf dem Weg zu mir.

Da bin ich mal gespannt ob Rocko eine Beschreibung beigelegt hat, was oder ob überhaupt was defekt war.

Fazit für mich: Vorerst keine Zimo Dekoder mehr.

Hallo zusammen,

meine BR03.10 von Roco mit MS450P16 und Sound ab Werk als DC-Version (70031) hat es gestern auch etwas schwerer erwischt. Die Lok stand mehrere Wochen unberührt im Lokschuppen und sollte mal wieder eine Testrunde drehen. Dabei war ihr kein Ton zu entlocken. Als ich sie zuletzt gefahren hatte, war mit dem Sound noch alles bestens. Die Lokadresse ist aber unverändert und die Lok sonst hinsichtlich Fahren / Licht ok.

Ich fahre mit einem Fleischmann Twincenter (nur DCC) in Verbindung mit Rocrail und bei mir sind ca. 40 Loks dauerhaft auf der Anlage, die meisten mit ESU oder Zimo-Decodern, vereinzelt ein paar Märklin/Trix Sounddecoder und Piko 4.1 Sound-Decoder.

Die sonst bei mir üblichen Schritte (kurzer Betrieb DC analog oder CV's auf dem Programmiergleis lesen / schreiben) haben leider auch nicht geholfen. Auch ein Reset CV8=8 brachte keine Besserung, außer dass dann die Funktionsausgänge auch noch durcheinander waren.

Letztendlich habe ich mit dem MXULFA die neueste Firmware-Version für den MS-Decoder (4.241) auf den Decoder aufgespielt und siehe da, der Sound war wieder in Ordnung. Auch die Funktionszuordnung der Sounds war dann wieder wie ab Werk zurück. Was leider immernoch durcheinander war, waren alle Funktionen, die nichts direkt mit den Soundslots zu tun haben. Das ließ sich aber mit ZCS wieder leicht korrigieren.

Für alle, die einen MXULFA haben und wo der Sound verschwunden ist bei MS-Decodern - vielleicht ist es ja einen Versuch wert, mal eine neue Firmware auf den Decoder zu spielen?

Ich denke, dass die Probleme nicht nur was mit MM / MFX zu tun haben, sonst müssten ja alle, die nur DCC verwenden, verschont bleiben.

MS-Decoder in min. 10 anderen Loks, die dauerhaft auf der Anlage sind, funktionieren weiterhin ohne Probleme.

PS: Ich habe in keiner meiner Loks irgendwelche Kondensatoren entfernt. Bisher sind auch in gut zwanzig Jahren digital erst zwei Decoder gestorben (beide ESU, jeweils plötzlich nach jahrelangem problemlosen Betrieb).

Viele Grüße

Michael

Zitat von Georg Tanzer im Beitrag #46

---

Vorab: Bei beiden Loks ist nur das DCC Protokoll aktiv.

---

Zitat von Georg Tanzer im Beitrag #46

---

Ich habe dann die Lok auf das Programmiergleis der CS2 gestellt, hier konnte ich unter DCC alle CV's lesen / schreiben und die Lok fahren etc..
Anschließend habe ich die Lok wieder auf das Programmiergleis der Ecos gestellt.
Nix ging, weder konnte ich die Lok fahren, noch konnte ich CV's auslesen.

---

Hallo Flo Danke für die Antwort,
be der BR 218 war nur das DCC Protokoll aktiviert, diese hatte aber einen kapitalen Motorschaden (nicht mal zwei Betriebsstunden ), der bei Roco durch Motortausch behoben wurde.

Zitat von Flo_85 im Beitrag #48

---

.. klingt als würde der Decoder auf mfx oder MM Modus gehen. Denn sobald der Decoder ein MFX oder MM Signal bekommt (er muss da gar nicht direkt angesprochen werden) und es nicht über CV12 deaktiviert ist will er damit angesprochen werden und nimmt keine DCC Signal mehr an.

---