Zitat

---

An "neuen" Märklin Decodern habe ich derzeit folgende drei Arten ..... beobachtet:
"Decoder M4 PR o.Sound (147823)"
"Decoder M4 PR m.Sound (147824)"
"Decoder M4-Sinus progr.o.Sound (121553)"

---

Deutet das "M4" nicht eher auf ESU hin?

Zitat

---

Das kann Ihnen ESU als (Mit)erfinder von mfx garantieren.

---

Also das sehe ich wie der Thomas.
--> Wenn zwei sich streiten, ist der Dritte der arme.
Ich hoffe mal, dass die "vermutete Verfeindung" der beiden "mfx-Hauptplayer" nicht auf dem Puckel der Kundschaft ausgetragen wird.
Aber allzuviel wird märklin vermutlich nicht Ändern können. Denn für all die bisherigen mfx(ESU) Decodern steht ja auch Märklin in der Pflicht.
Aber sollte doch ausarten, wäre der gemeine Märklinbahner mit DCC wirklich besser beraten gewesen.

Zitat

---

Neubesitzer einer ECOS 50200 habe ich vor ca. 3 Wochen alle meine Loks an der Station angemeldet. Darunter waren auch 8 mfx-Loks, teilweise mit ESU Dekodern, teilweise vermutlich auch welche mit Märklin-Dekodern, wer weiß das schon, ohne die Lok aufzumachen...

---

Also die Sache ob da wirklich nur ESU Produkte im Einsatz sind ist ja nach wie vor offen!
Sollte da doch noch ein Märklin Decoder auftauchen. Dann hat zumindest auch Märklin eine Erklährungsnot wesshalb sich ein Märklindecoder nach dem"Fremdgehen" nicht mehr zuhause (MS1) anmeldet.


Die Erstreaktion von ESU ist ja erstmal auch irgendwie verständlich:
zum Verständnis nochmals die Nachfrage:
Es sind zwei ECos2 betroffen
Es sind zwei MS 1 betroffen
Es sind wie viele mfx Märklin Decoder betroffen?
Es sind wie viele M4 ESU Decoder betroffen?
Es ist zumindest eine (des Händlers) CS2 im Spiel?
--> Ein Jungfräulicher mfx/M4 Decoder meldet sich an beiden MS1 an?
--> einmal an der ECos2 meldet er sich bei keiner der MS1 mehr an

Also das wird für eine Fehlersuche dann eine echte Knacknuss.
Ich schlage vor, du schickst den ganzen Krempel zu ESU
Das ist zwar Hart, anders sehe ich aber keine Chance das Problem zu lösen.


Hast du die MS schon mal resetiert?
Hast du den Decoder Schon mal resetiert
Wurde die Zentrale schon mal resetiert?

Zitat von Heinzi

---

Zitat

---

An "neuen" Märklin Decodern habe ich derzeit folgende drei Arten ..... beobachtet:
"Decoder M4 PR o.Sound (147823)"
"Decoder M4 PR m.Sound (147824)"
"Decoder M4-Sinus progr.o.Sound (121553)"

---

Deutet das "M4" nicht eher auf ESU hin?

---

Das habe ich anfangs auch geglaubt (kann man hier im Forum nachlesen), doch in der Zwischenzeit habe ich von diesen drei Typen alle CV ausgelesen und es ist TRIX(=Märklin) als Produzent statt ESU codiert.

Das war aber nur als Antwort auf Bernd's Frage gedacht und nicht als Problem erklärend. Ich habe nämlich stark das Gefühl, dass im Falle von Bernd die ECOS2 in den Decoder beim erstmaligen Anmelden etwas zurückgeschrieben hat, was den Decoder für die MS taub gemacht hat. Eine andere Erklärung wäre unlogisch, da erst die Erneuerung der Decoder Firmware (also die Entfernung dieser Spuren) den Decoder wieder hörend gemacht hat. Noch dazu handelt es sich ja um einen ESU-Decoder an einer ESU-Station.

Zum Unterschied von Andi glaube ich deshalb sehr wohl, dass man dieses Verhalten der ECOS2 anlasten muss.

Zitat von TT800

---

Das habe ich anfangs auch geglaubt (kann man hier im Forum nachlesen), doch in der Zwischenzeit habe ich von diesen drei Typen alle CV ausgelesen und es ist TRIX(=Märklin) als Produzent statt ESU codiert.

---

Nicht nur das, auch CS2-intern werden die mfx-Decoder als "M4" verwaltet.

Ich vermute daher, M4 war schon immer die (entwicklungs-) interne Codebezeichnung und mfx nur der Markenname.

Zitat

---

Nicht nur das, auch CS2-intern werden die mfx-Decoder als "M4" verwaltet.

---

na ich dachte eben an ein vertippen von TT800
Aber das wird ja imemr mysteriöser

Zitat von TT800

---

...Zum Unterschied von Andi glaube ich deshalb sehr wohl, dass man dieses Verhalten der ECOS2 anlasten muss.

---

Moin Stephan,

mein Stament ist unglücklich formuliert. Ich gebe dir Recht, die Zentrale spielt natürlich eine entscheidende Rolle.

Was ich eigentlich sagen wollte ist, das das ganze System bestehend aus Zentrale, Dekoder und Protokoll nicht optimal designed ist. Ich befürchte, das die Anmeldeprobleme auch in Zukunft nie ganz ausgemerzt werden können.

Hallo Andi,

da hast Du sicher Recht. War ja auch eine echte Pionierleistung damals am Beginn der ESU-Märklin Ehe, die jetzt leider getrennt weiterentwickelt wird. Ich versuche eben daher immer sachlich zu bleiben und möglichst die dargestellten Probleme zu ergründen. Die ewigen ESU vs. Märklin Dispute kommen mir wie ein Rosenkrieg nach einer Scheidung vor. Zwar hilft das niemandem wirklich, aber es ist verständlich.

Nur was ich zum Unterschied von dem im Thread "mfx Lok reagiert auf MM-Befehle" diskutierten Problem hier schockierend finde, ist die dauerhafte Veränderung (Beschädigung?) eines Decoders beim Anmelden an der ECOS2. Das darf nicht sein. Hier muss ESU schleunigst nachbessern.

Zitat von TT800

---

Nur was ich zum Unterschied von dem im Thread "mfx Lok reagiert auf MM-Befehle" diskutierten Problem hier schockierend finde, ist die dauerhafte Veränderung (Beschädigung?) eines Decoders beim Anmelden an der ECOS2. Das darf nicht sein. Hier muss ESU schleunigst nachbessern.

---

Hallo!

Bis jetzt ist noch nicht einmal klar, ob die div. Möglichkeiten eines Resets versucht wurden.

Grüße


Hp2

Hallo,

> Hast du die MS schon mal resetiert?
> Hast du den Decoder Schon mal resetiert
> Wurde die Zentrale schon mal resetiert?

Nein, ein Reset hilft hier nicht, sondern schiebt den Zeitpunkt für das Wiederanmelden an einer MS1 nur weiter nach hinten! Es geht um den Neuanmeldezähler und die Zentralen-UID!

Zudem gibt es da noch unentdeckte Features!

Ich sehe da 2 Möglichkeiten:
1.) Wenn eine ECoS2 es schafft, wie auch immer (neutrale Zentralen-UID?), einen mfx-Decoder so bei sich anzumelden, dass dessen gespeicherte Zentralen-UID nicht verändert, sondern nur der Neuanmeldezähler höher gesetzt wird, dann wird sich der Decoder so lange nicht an der MS1 anmelden, bis der Neuanmeldezähler in der MS1 den im Decoder gespeicherten Stand erreicht hat. Es kann auch mit dem Ausbleiben des Bake-Befehls vor den Anmeldung zusammenhängen.

TT800 wird das hier verstehen. Der Rest, der es nicht versteht, braucht es nicht verstehen.

Durch abwechselndes Neuanmelden zweier mfx-Loks und löschen derselben kann man es aber auch erreichen, den Neuanmeldezähler in der MS1 hochzählen zu lassen. Irgendwann wird man den Stand der ECoS2 dann erreichen, und der Decoder meldet sich auch wieder an. Durch meine weiter oben beschriebene Prozedur schafft man es aber auch, den unbekannten Neuanmeldezähler im Decoder bewusst auf einen definierten Wert zu setzen, und dann durch das Löschen eines weiteren Decoders ohne Zuhören der betroffenen Lok ihn höher zu setzen, als im unwilligen Decoder, um diesen dann zu zwingen, sich neu anmelden zu müssen.

Mir ist bisher aber leider unklar, warum sich der Decoder an verschiedenen MS1 nicht anmelden will, sondern nur an einer ECoS2.

2.)
Offensichtlich gibt es eine Möglichkeit, dem Decoder abzugewöhnen, dass er auf die Zentralen-UID hört. Das hat auch Vorteile, wenn man zum Beispiel die Lok über mehrere verschiedene Zentralen steuern will, ohne dass sie sich beim Bereichsübergang neu anmelden muss, bedingt aber, dass jede Zentrale die SID des Decoders kennt. Man sollte diesen Modus jedoch auch wieder ausschalten können. Das wurde aber bisher nicht kommuniziert, wie das geht. Das steht sicherlich in irgend einer CV drin.

Wenn man das nachstellen kann, würde mich ein Schienen-Log-File interessieren.

Eigentlich müsste dieses Verhalten auch bei einer CS1 reload und der ECoS1 zu beobachten sein, wenn der Quellcode übernommen wurde!

Welche UID hat denn die böse ECoS2? Kann das sein, dass diese die UID 0x00000 oder 0xFFFFFF hat?

Eventuell kann man an deiner CS2 das mit Hilfe von gekonnt eingestreuten Befehlen an den GFP auch mal nachstellen, in dem man so tut, wie wenn man eine Zentrale mit diesen UID vorgaukelt und den Decoder dann mit dieser UID (vielleicht ungültigen oder neutralen) UID anmeldet. Dann könnte es ja sein, dass er sich hinfort nicht mehr so ohne weiteres zum Anmelden meldet!

Gruss

est2fe

Hallo est2fe,

eigentlich habe ich mich nicht so tief in diese Problematik hineindenken wollen, weil ich gerechnet habe, dass Du die Ursache ohnehin aufklären kannst. Aber Deine Denkmodelle 1 und 2 kreisen nur um Zentralen-UID und NAZ. Und das halte ich für eine Sackgasse. Und Bernd konnte Deinen 2LokLöschTest noch nicht durchführen.

Zitat

---

Ach ja, noch etwas: Am Samstag durfte ich eine meiner "entführten" Loks an der CS2 meines Händlers anmelden. Mit der fuhr sie, aber meine MS1 zuhause mochte sie nachher immer noch nicht.

---

Also wird eine geänderte Zentralen-UID vom Decoder als Neuanmeldegrund gesehen. Und die Zentralen-UID der CS2 wurde sicher eingetragen. Also müßte auch bei der MS1 dieser Neuanmeldegrund gelten.

Dieselben Überlegungen gelten auch für den NAZ.

Nachdem aber auch nach dem Zwischendurch-Anmelden bei der CS2 die MS1 (oder eigentlich der Decoder) für diese Kommunikation taub ist, muss noch etwas anderes, Dauerhaftes (= die Zwischendurchanmeldung bei der CS2 Überstehendes) beim ersten Anmelden an die ECOS2 passiert sein.

Leider kenne ich die MS1 zuwenig, um zu wissen, was im Vergleich zur ECOS2 (oder CS2) beim Anmelden oder Wiedererkennen unterschiedlich ist. Was läuft in der MS1 einfacher ab als in den Zentralen? Dort muss der Schlüssel liegen. Der Decoder glaubt, er ist zu Hause; die MS1 bekommt überhaupt nicht mit, dass ein neuer da ist. Quasi ein Trojaner, der gar nicht abgefragt wird; aber auch nicht reagiert, weil ja die SID nicht stimmen wird.

Zitat von TT800

---

...Nur was ich zum Unterschied von dem im Thread "mfx Lok reagiert auf MM-Befehle" diskutierten Problem hier schockierend finde, ist die dauerhafte Veränderung (Beschädigung?) eines Decoders beim Anmelden an der ECOS2. Das darf nicht sein. Hier muss ESU schleunigst nachbessern.

---

Moin Stephan,

hier bin ich mir noch nicht sicher, ob das ein spezifisches durch die ECoS2 ausgelöstes Problem ist oder ob hier noch ein bisher nicht entdeckter (Design?) Fehler schlummert. Soweit ich mich erinnern kann, wurde schon zweimal darüber berichtet, das sich eine mfx-Lok nicht mehr ansprechen ließ, nachdem der Kollege seine mit der MS gesteuerte Anlage längere Zeit nicht mehr in Betrieb hatte.

Die Lok (= Dekoder) wurde einfach nur längere Zeit nicht benutzt. Es hat kein Zentralenwechsel stattgefunden, der Dekoder reagierte einfach nicht mehr an der Zentrale an der er sich vor geraumer Zeit mal angemeldet hatte (und meldete sich auch nicht neu an).

Hallo TT800,

> Nachdem aber auch nach dem Zwischendurch-Anmelden bei der CS2
> die MS1 (oder eigentlich der Decoder) für diese Kommunikation taub
> ist, muss noch etwas anderes, Dauerhaftes (= die
> Zwischendurchanmeldung bei der CS2 Überstehendes) beim ersten
> Anmelden an die ECOS2 passiert sein.

ja, das sehe ich auch so.
Ich gebe allerdings auch zu, dass ich _nur_ die Anmeldung der MS1 und einer alten CS1 (V < 2.0.4) kenne, und nicht die der C2 /ECoS.

Ja, es stimmt, dass da noch was bisher unentdecktes schlummert. Um das aber jetzt rauszubekommen, bedarf es wohl doch mehr Aufwand, den der Betroffene aber sicher nicht leisten kann.

Also die Fakten nochmal im einzelnen:

Die MS1sen sind wohl nicht hinüber und hören auch noch gut genug, weil sich ja der eine Decoder nach dem Flashen wieder brav an der MS1 anmeldet.

An einer ECoS / CS2 melden sich die gestörten Decoder trotzdem an.

An den MS1 melden sich die einmal an einer ECoS angemeldeten Decoder nicht mehr an.

Ein Flashen, selbst mit gleicher Firmware behebt das Problem wohl so lange, bis der Decoder wieder an einer ECoS angemeldet wird.

Mehr Fakten haben wir bisher nicht.

Mir stellt sich nun die Frage, was ein Decoder als Zentralen-UID abspeichert, wenn die Zentrale selbst ihre Zentralen-UID vor der Anmeldung noch nie versendet hat.

Meines Wissens versenden die neueren Zentralen das Bake anders als die MS1. Nachmessen konnte ich noch nicht, weil mir dazu das Equipment fehlt.

Gruss

est2fe

Hallo est2fe,

Deiner Zusammenfassung der Fakten stimme ich zu.

Zitat

---

Mir stellt sich nun die Frage, was ein Decoder als Zentralen-UID abspeichert, wenn die Zentrale selbst ihre Zentralen-UID vor der Anmeldung noch nie versendet hat.

---

Von der CS2 kann ich nur berichten, dass der GFP alle 10 sec. meldet, dass er ein Rückmeldefenster für eine 1-Bit Rückmeldung auf der Schiene öffnet. Da wird vermutlich die Zentralen-UID mitgeschickt, denn in der CAN-Meldung ist sie inkludiert. Kurz vor dem Auslesen einer Decoder-mfx-UID als Beginn des Neuanmeldevorgangs gibt es mehrere kurz hintereinanderliegende gleichartige GFP-Meldungen (das Rückmeldefenster betreffend) am CAN zu beobachten.
Spekulation:
Vielleicht hat jetzt die ECOS2 diese Prozedur kopiert?
Was aber noch nicht erklären würde, was noch an der ECOS2 passiert und dabei den Decoder so verändert, dass er mit der MS nicht mehr zurechtkommt.

Zitat

---

Meines Wissens versenden die neueren Zentralen das Bake anders als die MS1. Nachmessen konnte ich noch nicht, weil mir dazu das Equipment fehlt.

---

So geht es mir leider auch. Ich fürchte, dieses Thema kommt in meine Lade der nicht geklärten Fälle.

Zitat von Andi

---

... ob hier noch ein bisher nicht entdeckter (Design?) Fehler schlummert ...

---

Nicht auszuschließen, aber das kann man auch erst beantworten, wenn jemand den Datenverkehr auf der Schiene analysieren konnte.