1zu160 - Forum



Anzeige:
Arnolds Modell Web

THEMA: Decoder nicht gefunden bei Zimo Decoder Update

THEMA: Decoder nicht gefunden bei Zimo Decoder Update
Startbeitrag
kochender-Eisenbahne - 01.05.20 18:24
Moin liebe N-Bahner,

benötige mal Hilfe beim Update von Zimo Decoder über das MXULFA.
Ich habe es mir ausgeliehen um mal alle meine Zimo Decoder upzudaten zm sie ABC tauglich zu machen.
Das funktioniert auch in den meisten Fällen einwandfrei und ich bin begeistert davon wie gut das funktioniert.
Nur vereinzelte Decoder weigern sich beharlich.
Der Programmer  liest und programmiert CV 29 und 144.... und beim Decoder suchen erscheint dann die Meldung : Decoder nicht gefunden. Bei einigen Decodern hat dann das Update per PC funktioniert, aber zwei Decoder weigern sich updaten zu lassen.

Hat jemand eine Idee woran das liegen könnte bzw. Tipps und Kniffe die zum Erfolg führen könnten?

Carstens Hinweise auf seiner Honepage zum Reset der Sounddecoder habe ich auch schon gelesen und es probiert.

Gruß aus Hamburg
Thorsten

Hallo Thorsten,
um welche Decoder gehts denn?

Viele Grüße
Carsten
Hallo Carsten,

geht um einen MX620 und einen MX648. Wobei der 620er in einer Lok mit einer damals auf der Zimo Honepage veröffentlichten Pufferschaltung versehen ist. Da könnte es natürlich daran liegen.

Der 648er in einer Fleischmann Taigatrommel (nachgerüstet).

Gruß aus Hamburg
Thorsten
Hi Thorsten,
hast du es via ZSP oder mit dem USB-Stick versucht? Ich hab festgestellt, dass es manchmal nötig ist, den jeweils anderen Weg zu probieren. Wenn alle Stränge reißen kannst du per ZSP auch ein Blindupdate probieren, dabei kontrolliert der MXULFA nicht, was für ein Decoder da dranhängt.

Viele Grüße
Carsten
Hallo Thorsten,

mir hat (der gleiche) Carsten auch mal einen Tipp gegeben...
nämlich eine bessere Spannungsversorgung (Schaltnetzteil anstatt dem Trafo vom ProfiBoss) zu verwenden, seitdem habe ich nie wieder Probleme beim Updaten gehabt!

Gruß
Roger
Hallo,
auf der Zimo Homepage ist was zu lesen das eine Firmwareversion (82.irgendwas) des MXULFA Probleme mit den MX Decodern verursacht.
Vielleicht liegt es auch daran.
Ich sehe gerade die Version mit der Fehlerbehebung ist raus.

http://www.zimo.at/web2010/support/UpdateMXULF.htm

Kontaktprobleme bestehen auch nicht?

Gruß Jörg
Moin,

@ Carsten:  das manchmal das Update über  ZSP geht aber nicht über den Stick hatte ich auch schon. Seltsamerweise bei recht neuen MX618. Werde mal das blind Update versuchen. Das kannte ich noch nicht.

@ Roger: habe ein Schaltnetzteil dran. Vielleicht kann ich mal eines mit 15 Volt statt 12 Volt probieren. Da das MXULFA ja aber mit 10,5 arbeitet sollte es daran nicht liegen.

@Jörg: habe aus dem Grund die letzte offizielle Software von der MXULFA Seite genommen. Aus dem Kopf irgendetwas mit 72...  
Die neue Software ist dann aber brandneu..... kann erst die letzten Tage aufgetaucht sein. Werde ich dann mal testen.

@ Alle...  Werde dieses Wochende mal alle Tips probieren und dann berichten.  

Gruß aus Hamburg
Thorsten

Hallo Thorsten,
12 V könnten wirklich etwas wenig sein, Ich füttere meins mit mehr Spannung (muss mal gucken, was das bekommt, ich glaube gar 19 V).

Blindupdate solltest du in jedem Fall nur versuchen, wenn alles andere fehlschlägt und du das Update zwingend brauchst. Schlimmstenfalls kannst du damit den Decoder unbrauchbar machen, dann muss er nach Wien, um ihn wiederzubeleben.

Viele Grüße
Carsten
Bei mir sind es jetzt 19V.

Gruß
Roger
Hallo Torsten,
wenn du von einer Pufferschaltung sprichst, dann meinst sicher irgend etwas, was mit einem Kondensator funktioniert.

Ich hatte mal eine solche solche Schaltung in Betrieb. Und bei mir war es notwendig, diese für den Programmiervorgang abzuklemmen.
Vielleicht hilft das ja auch bei dir.
Freundliche Grüße
Reinhold
Hallo,

die Pufferschaltung die am Decoder angeschlossen ist, muss zwingend abgeklemmt werden.

Irgendwo habe ich mal gelesen, das der Analogmodus augeschaltet sein sollte, und die Programmier-/Updatesperre in CV144 aufgehoben sein muss.

Mfg
Christian W.
Hallo,
bei den Pufferschaltungen ist die Drossel unbedingt erforderlich, wenn das Update funktionieren soll. Ich habe noch den MXDECUP, mit dem funktioniert es auch mit Pufferung einwandfrei, wenn die Drossel zwischen Pufferung und Decoder eingebaut ist so wie in der ZIMO Anleitung angegeben.

Viele Grüße,
Torsten
Hallo,

ja Analogbetrieb muss ausgeschaltet sein, sonst rast die Lok davon.

Grüße, Peter W
Folks!
Die MXULFA Versionen 0,8x haben den Sinn die Anwender zu verärgern, das ist das Ziel der Änderung. Wer von Euch hat schon MS Decoder und wenn gibt's Sounds die das ausnützen? Ich meine keinen der konvertierten Sounds die ohnehin keinen Unterschied machen, weil letztlich ohnehin an den Lautsprechern scheitert.

Oft hilft es dem Decoder die Signale 180° verkehrt zuzuführen. Also Kabel am Ausgang des MXULFA umdrehen.
HTH
-AH-
Hallo,
ich speise mit einem Laptopnetzteil 15 - 19 V damit  bis jetzt keine Probleme.

Wenn der Kondensator an den vom Decoder bereitgestellten Anschlüssen angeschlossen ist sollte es auch keine Probleme mit Firmware und Sound laden geben.
Eigene Erfahrung an 2 H0 Lokomotiven die mit 4700µF gepuffert werden.

Grüße Jörg
Moin,

gebe dann mal ein Update:
Erste Änderung: Laptopnetzteil mit 15 Volt... keine Änderung
Zweite Änderung: Software aktualisiert auf den neusten Stand:.... will immer noch nicht
Dritte Änderung: Schienenanschlüsse getauscht....bockt immer noch rum
Vierte Änderung: die Lok auf dem Gleis einmal umgedreht.... Update lief durch.

Daher war dann der Tip von Arnold der Richtige.
Ob das dann auch schon vorher funktoniert hätte kann ich nicht sagen, da ich mir nicht gemerkt hatte wie rum die Taigatrommel auf dem Gleis stand.

Wenn dann hier schon die geballte Digital Kompetenz versammelt ist noch zwei Frage bzw. Themen die ich bis jetzt nicht lösen konnte:

1. Bei der Taigatrommel mit Henning Sound und dem besagten MX648 schleicht die Lok bei aktivierten ABC  grundsätzlich nur noch in der Richtung in der ABC aktiviert ist. Also bei CV 27 = 3 entsprechend in beiden Richtungen. Habe schon sämtliche Einstellungen in der ABC Empfindlichkeit sprich in der CV 134. Noch einer eine Idee?

2. Bei einer RE460 von Fleischmann auch mit Zimo Sounddecoder werden bei aktivierten Sound immer mal wieder alle möglichen Zusatzsounds per Zufall abgespielt. Und zwar die Sounds die man nicht per Zufall haben möchte wie Bremsenquitshcen, Bahnhofsansagen, Schaffnerpfiff etc.  Bin da auch schon durch eingen CV durch, bekomme das aber nicht weg. Habe auch schon den Decoder per CV 8 auf 8 zurückgesetzt. Auch hier noch jemand eine Idee?

Ansonsten muss ich sagen habe ich jetzt an die 30 Decoder upgedatet und bin recht begeistert wie gut das insgesamt funktioniert.  War eine gute Entscheidung das ich vor Jahren mich hauptsächlich auf Zimo eingeschossen hatte.

Gruß aus Hamburg,
Thorsten
Hello!
Zu den SW Versionen: Updates nur dann machen wenn durch den Update ein anzustrebendes Ziel erreicht wird. Nur des Updatens wegen das zu machen ist nicht anzuraten. Man kann sich Ärger einhandeln ohne einen Gewinn zu haben.

Firmware Revision und Sound: bei den ZIMO Decodern gibt es grundsätzlich kaum Revisionsabhängigkeiten, wenn dann als Sideeffect unbeabsichtigt. Technisch laufen die Soundprojekte ohne Ärger auf höheren Versionen. Die Soundanbieter zerfallen aus Sicht der Anwender in 2 Gruppen: jene die Interesse an einem funktionierendem Sound haben (den Decoder nicht vermurxen), und jene die bewusst, vorsätzlich, trotz vieler Hinweise das zu unterlassen die Kunden absichtlich gewaltigst ver*****. Zu letzterer Gruppe zählen die Projekte von Heinz Däppen und etwas weniger stark aber dennoch fast immer von Henning.

Das Problem ist folgendes: wenn der Sound Autor im Soundprojekt viele CVs verbiegt um den Sound auf seine persönlichen Vorlieben einzustellen (also garantiert anders als die Mehrzahl seiner Kunden das haben will weils zu viele Varianten geben kann)  dann gibt es Ärger wenn ZIMO neue Funktionen einbaut. In CVs unbenutzte Bits plötzlich eine Bedeutung bekommen und ähnliches mehr. Dieses Problem hat man im IT Umfeld seit es das gibt >100 Jahre oder noch länger, schon bei Maschinensteuerungen. Daher jeder mäßig intelligente Techniker wird das möglichst nahe an den Standardeinstellungen belassen und in der Doku beschreiben was man als Anwender seinen Vorlieben nach einstellen kann. So muß der Anwender wenn er Funktionstasten umbelegen will nicht die meist unbekannten Abweichungen des Soundautors vom Hersteller Standard rückgängig machen um danach erst dem Anwender die Neubelegung zu ermöglichen. Ja ich weiß es gibt das CV400 Eingangsmapping bei ZIMO nur das genau ist der Weg wo's völlig chaotisch wird.

Ein klassisches Beispiel: Soundprojekt hat den Kupplungswalzer vorgesehen. Kunde baut den so bespielten Decoder in eine Lok ein und legt auf die F-Taste ein Geräusch. Jedes mal wenn dieses Geräusch aufgerufen wird fährt die Lok unerwartet spazieren. Der Anwender weiß nix von Entkupplern und Kupplungswaltzer. Diese Funktion ist attraktiv gehört aber in kein Soundprojekt vorkonfiguriert. Da gibt's noch viele andre Beispiele.
Noch ein weiterer Klassiker: Lok fährt auf einer zZ21 Anlage aber auf der I-Box nicht. Auch da war im SoundProjekt sinnlos, nur weil es der Autor selbst benutzt, das ABC Bremsen eingestellt. I-Box liefert unsymmetrisches DCC daher hat die Lok gemeint sie soll anhalten und hat sich nicht bewegt. Klar der Anwender hat diverse Schäden vermutet und sich Tagelang gequält. Ich hab' das auch erst nach vielem Suchen erkannt, CV ausgebügelt und das war's.

Daher meine Aussage es gibt gute Soundautoren und welche die es besonders schlecht mit ihren Kunden meinen. Das Vorbelegen der Tasten, gut gemeint, scheitert schon beim ersten Überlegen es gibt Tausende Varianten wenn man nur alle Möglichkeiten durchspielt die bei 12 Tasten möglich werden. Da kann kein Soundautor das richtige wählen. Beginnt bei der Frage ob Sound ein/aus auf der prominenten Taste 1 liegen soll oder eher weiter hinten da man die Taste eher selten benutzt und die leicht erreichbare Taste 1 nicht besser für was anderes zu benutzen ist. Da gibt es kein richtig oder falsch sondern nur persönliche Vorlieben. Wenn ein Soundautor das offensichtlich nicht verstehen will sondern den Kunden die an sich belastende Aufgabe der Konfiguration besonders schwer macht, dann benenne ich solche Projekte als schlechte Soundprojekte.

Es gibt einen undokumentierten Ausweg bei den ZIMO Decodern: CV8=0 das radiert den Mist aus dem Soundprojekt aus und stellt die ZIMO Standard CVs wieder her. Im Gegensatz dazu CV8=8 das macht die CV Einstellungen des SoundAutors.
-AH-
Hallo Herr Hübsch,

vielen Dank für die ausführliche Erläuterung.

In meinem Fall war das Updaten schon recht sinnvoll da Zimo die ABC Erkennung verbessert hat und auch das langsam Fahren schon recht cool ist.
Die beiden beschriebenen "Macken" waren schon vor den Updates da.
Werde dann mal CV8 =0 probieren.

Gruß aus Hamburg,
Thorsten

P.S. Das mit dem verzweifelten Suchen kenne ich, hatte ich bei ihrer 5047er Platine. Nicht nur das eine LED der Innenbeleuchtung fehlte, sondern habe dann auch noch entdeckt das die LED auf der einen Seite der Spitzenbeleuchtung falsch herum eingelötet war. Auf die Idee beim Suchen warum die Spitzenbeleuchtung auf einer Seite nicht ging bin ich auch erst sehr....sehr spät gekommen.

Hallo,

ich hänge mich mal hier mit ran.

Ich habe jetzt schon bei einem zweiten Zimo MX618N18 das Problem, das dieser sich nicht updaten lässt.

"Dieser Decodertyp wird vom Update nicht unterstützt"

Ich versuche es gerade mit der schwarzen Z21 (Netzteil 10851 20V) und dem ESU Decodertester.

Vertauschen der "Gleisanschlüsse" hat nicht geholfen. Spannung auch schon variiert (15-19V) , CV( reset hilft auch nicht

Beide Probanden haben

CV7 = 37
CV8 = 145 (Zimo)
CV65 = 22
CV144 = 0
CV250 = 181 (ID)

Softwarezip ist 201217/Roco_Z21_201217.zsu, auch die eine ältere geht nicht, noch ältere kennen die ID=181 nicht

Z21 Version 1.14

Ideen ?

VG wassi

PS: eines ist ein "orginal" Zimo, einer kommt aus einer Fleischmann 685101 Umverpackung, wo ja dann auch wieder nur ein MX618N18 drin ist mit Zimo-Kurzanleitung Stand 10.5.2020


Moin,

Bei mir hat am MXULFA bei einigen Decodern das Firmware Update weder mit der Windows Software, noch am Programmer selber geklappt.
Bei mir hat nur geholfen die Update-Sperre des Decoders per Hand aufzuheben.
(Originale Werte vorher auslesen, anschließend zurückspielen)

Auszug aus der Anleitung zum MXULFA:
Zitat

Im Rahmen des Update- oder Sound-Lade-Vorganges wird durch das MXULF automatisch die Update-Sperre des Decoders aufgehoben (durch Programmierung der CV # 144 = 0) und der Analogbetrieb ausgeschaltet (CV # 29, Bit 2 = 0). Nach dem Update- oder Ladevorgang versucht MXULF, diese CVs wieder auf die ursprünglichen Werte zu setzen.
Falls diese automatischen CV-Programmierungen durch das MXULF aus irgendeinem Grund nicht gelingen sollten (entsprechender Hinweis am Display oder Verdacht, z.B. Decoder ohne Verbraucher, und daher keine Programmier-Quittung), können ersatzweise bereits vor dem Update-Vorgang auf je-dem Digitalsystem die Programmierungen C # 144 = 0 und CV # 29, Bit 2 = 0 vorgenommen werden.



Wobei ja bei dir die CV144 schon "entsperrt" ist.
In CV29 die Analogerkennung sollte laut Anleitung ausgeschaltet sein.

Viele Grüße, Franzi
Hallo Franzi,

sorry ich vergass

CV29=10

auch schon ausprobiert, hilft bei mir leider auch nicht weiter.

VG wassi

PS: einen anderen (älteren) MX618N18 (mit ID=243) konnte ich ohne Probleme auf 40.1 updaten

Hallo!

Ich habe gerade dasselbe Problem mit einem MS500. CV lesen / schreiben funktioniert, Update von FW 4..97 auf 4.107 stoppt mit Fehlermeldung "Decoder nicht gefunden", nachdem CV 29 und 144 gelesen und geschrieben(!) wurden. Ich frage mich ja, wie kann ein Decoder nach lesen und schreiben von CVs verlustig gehen? Beim lesen und schreiben war er ja noch da, da kam keine Fehlermeldung, dass dies nicht funktioniert hätte. Weiters würde mich interessieren: lt. Anleitung wird CV 144 bei MS-Decodern nicht mehr benötigt, warum wird die CV dann noch gelesen und geschrieben?

Beste Grüße

Boris
Hallo Boris,

ich nehme an, Du hast schon probiert die Lok umzudrehen? Vor dem Update prüft das Programm ja nochmals welcher Decodertyp es ist damit das richtige File geladen werden kann zumindest beim MXDECUP und MX Decodern war das so.

Grüße, Peter W
Hallo Peter!

Ja, die Aufstellrichtung der Lok habe ich gedreht, auf's Dach habe ich sie aber nicht gelegt. Und mehr Spannung auf der Eingangsseite des MXULFA habe ich auch gelegt, bringt aber nix, VOUT ist trotzdem nur 11,7.

Versuch über ZSP schlug auch fehl, jetzt grade probiere ich es mit "ohne Rückmeldung Programmieren". Das ist aber auch verwirrend. Obwohl ich MS500 ausgewählt hatte, wird MS440C_4_107 programmiert (inkl. Tippfehler).

Dieses Bild
ist nur für eingeloggte User sichtbar: Login
  

Beste Grüße

Boris


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

Hallo Boris,

mit ZSP ist es (momentan noch) nicht möglich Updates auf MS-Decoder zu laden. Das geht nur mit den USB Stick am MXULF. Über ZSP ist es nur möglich Updates auf MX-Decoder zu laden.

Dein Problem die SW des MS500 von der 4.97 auf 4.107 zu updaten, konnte ich bei manchen MS500 nachstellen. Alternativ kannst du das Softwareupdate über MS SW Power Cycle machen. Dafür musst du nur die R Taste am MXULF lang drücken, zum Punkt MS SW PowCycle runterscrollen und diesen Punkt auswählen.

LG
Markus
Hallo Markus!

Danke für die Info, konnte ich bisher nirgends lesen. Wollte grad fragen, wie lange das noch dauert, weil das Bild, das ich vorher gepostet habe, ist schon 1 Stunde alt. OK dann breche ich mal ab, hoffe, das schadet nicht!

Nachtrag: MS SW PowCycle hat super geklappt! DANKE für den Tipp!

Beste Grüße

Boris



Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->

Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account





Zum Seitenanfang

© by 1zu160.net;