[hwissing]

Hallo,

seit einem knappen dreiviertel Jahr laboriere ich mit meinen beiden PIKO Loks BR 231 und BR V200 herum, die ich mit einem PIKO/ESU Loksound ausgestattet habe. Lasse ich die Loks alleine auf meiner Digital Testanlage - Märklin CS2 60214 aktuelle Software -fahren, dann ist scheinbar alles in Ordnung. Erste Probleme bemerkte ich, beim Betrieb einer weiteren Lok im DCC Format. Die reagierte nur noch sehr verzögert auf Kommandos. Es vergingen mehr als 10 Sekunden bis ein neuer Fahrbefehl übernommen wurde - Licht an/aus, Geschwindigkeitsänderung -.
Beim weiteren Austesten ergaben sich beim gleichzeitigen Betrieb der beiden Loksound Loks und weiteren Loks bzw. Steuerkommandos folgende Probleme - unvollständige Liste - :

1. Piko BR 220 - alte Form - mit EXPERT Decoder in DCC reagiert kaum, fährt plötzlich unbeeinflussbar mit Höchstgeschwindigkeit oder fährt unvermittelt aus dem Stand an, um nach einiger Zeit wieder abzubremsen.
2. Lok mit TAMS LDG32 in DCC reagiert verzögert, rast aber nicht unvermittelt los.
3. ESU LOPI 3.5 ? - DCC - in Fleischmann E 19 reagiert verzögert
4. Märklin MM2 Decoder in E 103 Insider 39579 reagiert verzögert.
5. Einige Weichenadressen lassen sich nicht oder nur zufällig ansprechen

6. Märklin MfX läuft anscheinend ungestört
7. Lok mit LOPI 4.0 läuft anscheinend ungestört

Beim Betrieb nur einer PIKO/ESU Loksound Lok sind die Probleme nicht so offensichtlich

Die Phänomene treten auch mit einer CS2 60215 im Urzustand auf.

Bahnstrom an der CS2 max. 450 mA, bei >18V Gleisspannung

PIKO verwies an ESU

ESU Service riet Railcom abzuschalten CV28 = 0, CV29 = 06 keine Änderung.

Märklin kann zu Fremddecodern keine Stellung nehmen.

Ich fühl mich .......

Meine Frage: Kann Jemand das auf seiner Anlage nachvollziehen ?

Gruß
Heimo Wissing

[Dirk Ackermann]

Hallo Heimo,

ein ähnliches Phänomen konnte ich bei der CS2 von meinem Vater feststellen, seitdem das Update für die mfx+ Decoder auf der CS ist.
Vorher gab es keinerlei Probleme mit DCC und/oder ESU Loksound Decodern.
Auch andere Loks mit DCC-Decodern reagieren ungewöhnlich, z.B. blinkende Spitzenlichter.

Anscheinend ist das mfx+ Protokoll der Störfaktor bei einigen DCC Signalen.

Auf meiner ECoS2 mit der Aktuellen Firmware sind keine Probleme erkennbar.

[od45hcwerkshop]

Hallo Heimo und Dirk
Wenn Ihr beiden mal das Format Railcom und Plus ausschaltet für CS 2 bei den ESUdecoder (V4),denn habt kein
Problem mehr.Denn die CS 2 kann kein Railcom.G. Willi

[hwissing]

Hallo Dirk und Willi,

@ Dirk,

daran hatte ich auch gedacht, da ich zeitgleich mit dem Einsatz der Decoder eines der ersten Spielewelt Updates eingespielt hatte - ß-Version nach der Messe in Sinsheim, empfohlen von Herrn Haller -. Daher hatte ich bei Märklin angefragt, ob es am Gleisprozessor-Timing Änderungen gegeben habe, die diese Phänomene erklären könnten. Dies konnte mir nicht beantwortet werden.

Deswegen habe ich mir dann eine 60215 im Urzustand beschafft, Softwareversion 1.4.0. (1), aber an der sieht es ganau so aus, wie ich dieser Tage feststellen konnte.


@ Willi,

das stimmt ja leider nicht ((((((((((((

Wie ich geschrieben habe, habe ich CV 28 Railcom Configuration = 0 gesetzt d.h. Kanal 1 Freigabe aus, Kanal 2 Erlaubnis aus, RailomPlus aus...... ESU Nomenklatur
CV29 = 6 d.h. normales Fahrtrichtungsverhalten, 28 bzw. 128 Fahrstufen in DCC an, analog an, Railcom aus, Motorkennlinie etc...

Merkwürdig ist nur, dass z.B. Railcom fähige Decoder, wie die TAMS Decoder, die ich sonst einsetze, derartige Probleme nicht machen, bei denen ist CV28=255, also alles an und alles läuft ganz normal!

Mir scheint, wenn die Lok fährt generieren ESU Decoder Signale, die sich nicht abstellen lassen ;(, anders ist das Verhalten der PIKO Expert Decoder nicht zu erklären. Stehen die beiden Krachmacher, dann läuft alles prächtig.

Ich wollte versuchen bei denen auch DCC abzuschalten, aber an die CV 47 kommt man unter MfX nicht dran. Ich möchte mir keinen ESU-Programmer zulegen müssen. Die Decoder sollten Normenkonform mit den gängigen Zentralen programmierbar sein.

Eigentlich möchte ich Railcom auch nicht abschalten, denn ich möchte es nutzen können. Ich gehe davon aus, dass man in Multiprotokollsysteme, auch MfX Systeme, Railcom Empfänger einbinden kann und dann die Infos im Rahmen einer PC Steuerung auswerten kann.
Leider hat ja die Rückmeldung mittels IR-Leuchtdiode und S-88 Decoder aus EDiTsPro (2001) keine Verbreitung gefunden, auch wenn sie mit Lissy nachempfunden wurde.
Railcom ist bislang das einizig genormte Rückmeldesignal.
Und ich denke, dass auch Märklin, das mit seiner Marke TRIX in die DCC-Welt hinein verkauft, früher oder später Railcom auswerten wird.

Gruß
Heimo

[digitalo]

Hallo Gemeinde

MFX und DCC am selben Gleis haben so Ihre Probleme jedenfalls wenn Zentralen von ESU und Märklin im Einsatz sind. Schau mal in der SuFu unter "Lok rast los" nach.

[Dirk Ackermann]

Hallo Willi,

Zitat von od45hcwerkshop

---

Hallo Heimo und Dirk
Wenn Ihr beiden mal das Format Railcom und Plus ausschaltet für CS 2 bei den ESUdecoder (V4),denn habt kein
Problem mehr.Denn die CS 2 kann kein Railcom.G. Willi

---

Du hast meinen Beitrag leider falsch gelesen.

Zitat

---

Auf meiner ECoS2 mit der Aktuellen Firmware sind keine Probleme erkennbar.

---

Die Probleme traten nur bei der CS2 auf jedoch nicht bei der ECoS2.
In der ECoS2 sind die Formate DCC, DCC Railcom+, Motorola und M4 (mfx) aktiviert.

Das Phänomen trat bei der CS2 auf mit den Decodern von Uhlenbrock, Tams und Zimo.
Der ESU Loksound V3.5 mit aktueller Firmware und der Loksound V4.0 mit aktueller Firmware reagierten etwas verzögert bis hin zum spontanen losfahren.

Bei einigen Decodern neuester Generation von Uhlenbrock lässt sich die Motorola Erkennung abschalten ebenso bei Zimo.
Mit dem Effekt das die Uhlis bei Motorola und mfx+ Signal am Gleis der CS2 in den Analogmodus schalten und losrasen, sofern man analog nicht deaktiviert hat. Die Zimo DEcoder reagieren da recht unterschiedlich je nach aufgespielter Firmware.
So habe ich z.B. einen Zimo MX630R mit einer älteren Firmware der sich von den Protokollen nicht beindrucken lässt, und nur auf die DCC Signale reagiert die für ihn bestimmt sind.
Um beim Beispiel MX630R zu bleiben, so habe ich einen OEM Decoder mit einer realtiv aktuellen Firmware (30.?) in einer 1141 von Roco der im Motorola Format ständig am summen und knurren ist. Daraufhin habe ich Motorola und analog im Decoder deaktiviert so das er nur noch auf DCC reagiert. Da war es sofort vorbei mit summen und knurren.

Wie schon Eingangs geschrieben alles mit der CS2 von Märklin.
Bei der ECoS2 brauche ich nur selten irgendwelche Konfigurationen der Decoder bezüglich analog oder Motorola zu ändern.
Meistens mache ich das aber bei Uhlenbrock und Zimo Decodern um bei auswärtigen Einsätzen nicht plötzlich unangenehme Überraschungen zu erleben.

[schaerra]

Hallo Heimo,

schalte mal die Analog Erkennung der Decoder aus.

Manche DCC Decoder haben mit dem Mfx Signal aus Mfx Loks so ihre Probleme. Wenn dann noch MM/mfx und DCC und ein wenig Railcom am Gleis anliegen kann es durchaus zu Verzögerungen kommen bis der Decoder ein sauberes Signal rausfiltert.
Einige Decoder interpredieren dies dann auch mal als Anlog Spannung und rasen los!
Ich kenne diese Probleme sehr gut, da ich früher auch Multikulti gefahren bin.
Um so weniger Signale gleichzeitig am Gleis sind, um so besser. Ich habe deshalb bei mir alles auf rein DCC umgestellt. Seitdem keine digitalen Verständigungsprobleme mehr.
Die Multiprotokol Zentralen funktionieren nur in der Werbung einwandfrei.
Aber mir ist klar, das die Umstellung nicht einfach und billig ist! Ist nur ein gut gemeinter Tipp!

[werner1952]

Zitat von schaerra

---

Hallo Heimo,


Die Multiprotokol Zentralen funktionieren nur in der Werbung einwandfrei.

---

und bei mir

[Peter Müller]

Zitat von hwissing

---

Märklin kann zu Fremddecodern keine Stellung nehmen.

---

Das ist doch eine klare Stellungnahme: wer Märklin mit anderen Herstellern mischt, bekommt von Märklin keine Unterstützung. Wer dennoch Service haben möchte, muss eine andere Digitalzentrale nutzen.

[werner1952]

Zitat von Peter Müller

---

Zitat von hwissing

---

Märklin kann zu Fremddecodern keine Stellung nehmen.

---

Das ist doch eine klare Stellungnahme: wer Märklin mit anderen Herstellern mischt, bekommt von Märklin keine Unterstützung. Wer dennoch Service haben möchte, muss eine andere Digitalzentrale nutzen.

---

Hallo liebe Gemeinde
die Aussage von Peter kann ich nicht so mittragen, Märklin kann aus verständlichen Gründen
keinen Support für Fremddecoder leisten.
Nebenbei: Andere Zentralenhersteller machen und können das auch nicht (wieder aus verständlichen Gründen).

[Peter Müller]

Hallo Werner,

in Bedienungsanleitungen beliebiger Nicht-Märklin-Zentralen steht dem Sinn nach "Protokoll xy nach dem Standard xyz". Und wenn man sich mit einem Problem an den Anbieter wendet, bietet dieser Hilfe an oder kennt sogar den Grund der Inkompatibilität.

Bei Märklin steht in den Bedienungsanleitungen dem Sinn nach geschrieben, das man das Märklin-Rollmaterial nur mit Märklin-Steuerungen betreiben darf. Und auf Nachfrage erfährt man, dass umgekehrt zu Fremdmaterial an Märklin-Zentralen keine Hilfestellung gegeben wird.

Du darfst mich gerne vom Gegenteil überzeugen - denn dann hätte man einen Ansatz, dass sich Märklin eben doch um Probleme mit Rollmaterial anderer Hersteller bemüht.

[hwissing]

Hallo,

besten Dank für die bisherigen Beiträge!

Ich möchte aber wieder ein wenig Systematik in die Diskussion bringen und an die Ausganslage erinnern:
Im gemischten System an der CS2 lief bislang alles problemlos, bis die PIKO/ESU Loksound Decoder zum Einsatz kamen!
Die Störungen treten nur auf, wenn die so ausgestatteten Loks fahren, die Störungen sind besonders stark, wenn 2 dieser Loks fahren. Im Stand dieser Loks sind keine Störungen erkennbar.

Zu den Ratschlägen:
In DCC werden lange Adressen verwendet. Bei den TAMS Decodern ist somit MM Erkennung aus. Analogbetrieb ist auch aus.
Beim Expert Decoder der V200 - auch als lange DCC Adresse codiert - habe ich nun MM und analog deziediert ausgeschaltet. Seither kein unkontrolliertes losrasen mehr. Jedoch Decoder reagiert praktisch nicht auf Fahrbefehle, eingestellte Geschwindigkeit wird nicht erreicht bzw. bremst nicht ab, Lichtsteuerung reagiert nicht.
MM aus und Analog aus mag ja für Multiprotokoller eine Konfigurationsmöglichkeit sein, was macht man aber mit seinen Weichen und MM2 Lokdecodern?

Schönen Sonntag
Heimo Wissing

[Peter Müller]

Zitat von hwissing

---

In DCC werden lange Adressen verwendet. Bei den TAMS Decodern ist somit MM Erkennung aus.

---

Ist das so laut Beschreibung?

Anderes Problem, aber auch eine "lange Adresse - kurze Adresse"-Geschichte: ich hatte gestern einen Uhlenbrock Decoder eingestellt auf lange DCC-Adresse. Der Decoder reagierte komisch und Licht blinkte. Ich konnte ihn auf der ehemaligen kurzen MM-Adresse ansprechen, anschließend wieder auf die lange Adresse einstellen, und alles war gut. Wieso, warum? Keine Ahnung.

Ich würde Decoderseitig alles außer purem DCC ausschalten. Auf jeden Fall gleiche Fahrstufenanzahl in Decoder und Zentrale beachten.

[hwissing]

Nochmals Danke

für die guten Ratschläge!

Aber weiterbringen würde mich und das war ja auch am Anfang die Frage, ob dies einer auf seiner Anlage nachvollziehen kann.

Gruß
Heimo Wissing

PS: @Peter: Ja das ist laut Anleitung so. Macht ja auch Sinn, da lange DCC Adressen über den MM2 Adressraum hinausgehen. TAMS ist da sehr stringent in der Logik.

[eisbaer274]

Hallo,

Piko verbaut meist Uhlenbrock Decoder. Bei gewissen MFX-Kommunikationen auf der Anlage haben diese Dekoder das Problem, dabei ein Analogsignal zu erkennen und somit rennen sie dann dank der Digitalspannung quasi mit Höchstgeschwindigkeit los. Abhilfe: Automatische Analog/Digital Erkennung im Uhlenbrock-Dekoder abschalten (d.h. in CV 29 den vorhandenen Wert um 4 reduzieren). Danach ist das Spuk vorbei... verzögerte Übernahmen von Befehlen kann ich bei meiner ECOS2 bzw. der CS1 nicht feststellen obwohl ich gemischten Betrieb mit MFX, DCC, MM und Railcom nutze - das "Losras"-Problem von Uhlenbrockdekodern habe ich jedoch mit jeder Piko-/Roco-/Brekina-Lok gehabt und mit oben genannter Umprogrammierung gelöst.

Grüße,
Markus

[hwissing]

Hallo Eisbaer,

Danke für den Hinweis, aber das ist nicht das Problem!

Gruß
Heimo Wissing

[hwissing]

Kurz zur Mitteilung von Eisbär,

ich habe ein Losrasen von Piko Loks immer nur dann beobachten können, wenn irgendwo etwas entgleist ist. Im normalen Multiprotokoll-Betrieb mit MfX nicht. Dennoch habe ich beschlossen, keine reine Softwaresteuerung zu planen, sondern Signale mit Zugbeeinflussung zu verwenden, denn Entgleisungen gehören ja zu dem, mit dem man rechnen muss.

Gruß
Heimo Wissing

PS. Mir scheint, ich bin hier der Einzige, der 2 Loksound 4 M4 Loks und ne CS2 hat :'(

[schaerra]

Hallo Heimo,

ich kenne ein losrasen nach Kurzschlüssen nur von Loks mit nachträglich eingebauten Drehstrommotoren. Dies passierte mit allen ausprobierten Decodern; Mä c90, ESU LP V3 & LS V3,5 und Khuen. Ich habe dann die DsM wieder ausgebaut und das Problem war beseitigt.

Ich weiß, das hilft Dir auch nicht weiter. Aber die Wege der Elektronik sind unergründlich! Im zusammenhang mit der CS2 (mein Kumpel hat eine und ruft mich ständig wegen CS2 trouble an), habe ich schon alles mögliche und unmögliche erlebt.

Gehen wir es noch mal durch: In den Decodern ist alles ausser DCC ausgeschalten / die Analogerkennung in AC & DC ist auch aus und die Loks rasen trotzdem nach einem Kurzschluß los!?!
Gibt es in den Loks eventuell noch irgend eine Drossel oder einen Kondensator auf der Platine welche nicht normal sind (Normal sind die Drosseln an den Motorpolen).
Bei den Chinaböllern von Piko habe ich auch schon einiges erlebt. Die löten da manchmal alles mögliche auf die Platinen, was man nicht so ohne weiteres nachvollziehen kann. Ich kenne das von meinen Ami Loks - die sind ja auch alle aus China.

[hwissing]

Hallo schaerra,

Das ist ja alles lieb und nett, aber mir geht es darum, dass einer die Phänomene, die mir meine Zeit rauben, nachvollziehen kann.

Es geht darum, dass Artikel für ein System verkauft werden und Störungen verursachen. Es muss aber gemäß den Standards des Zielsystems funktionieren. Der Standard für eine Lok die mit Wechselstromradsätzen und einem MfX kompatiblen Decoder ausgeliefert wird ist nun mal Märklin und die CS2. Funktioniert der Artikel nicht im Standardumfeld, dann ist er nicht kompatibel und somit mängelbehaftet.

Gruß
Heimo Wissing

[hwissing]

Hallo schaerra,

und Nein, Loks mit Piko Expert Decodern im Auslieferzustand rasen nicht nach Kurzschluss los, sondern dann, wenn man gleichzeitig zwei Loks mit Piko/ESU Loksound Decodern betreibt. 2 Märklin MfX machen keine Störungen. Wie geschrieben, nach Abschalten von Analog, rasen sie nicht mehr los, nehmen aber im Fahrbetrieb die Steuerkommandos nicht mehr an.

Gruß
H. Wissing

[Peter Müller]

Zitat von hwissing

---

PS. Mir scheint, ich bin hier der Einzige, der 2 Loksound 4 M4 Loks und ne CS2 hat :'(

---

Im Moment noch, scheint so. Aber sicherlich nicht mehr lange. Und dann wird das Phänomen bestimmt öfters Thema sein. Eigentlich müsste Piko ein Interesse haben, sich der Sache anzunehmen. Schließlich wollen sie im nächsten Jahr weitere "Loksound 4 M4"-Loks verkaufen.

Du kannst die Loks zurückgeben, oder Dich für Piko als Beta-Tester anbieten. Vorher müsste Piko mit ESU klären, dass ESU sich als Decoder-Lieferant der Sache annimmt.

[hwissing]

Ja, das sollte man meinen, Peter!

Als meine ROCO 150er mit TAMS LDG-32 Prbleme gemacht hat, hab ich mich gleich an Piko gewandt. Da kam zügig die Antwort, das sei wohl eher ein Problem von TAMS und ESU.
Dann hab ich nach und nach ein paar andere Decoder getestet, bis ich ne 2. CS2 hatte hat's bis kurz vor Weihnachten gedauert.

Ich bin schon froh, dass gerade die PIKO EXPERT Decoder die größten Probleme haben. So hat PIKO mit sich ein Problem

Gruß
Heimo Wissing

[Peter Müller]

Willst Du weiter nach einer Lösung suchen oder gibst Du die Lokomotiven wieder ab?

Wenn Du nach einer Lösung suchen willst - heißt ja zunächst, dass Problem einzukreisen - fällt mir auf, dass bisher immer geraten wurde, nur DCC auszuwählen. Das ist ja eigentlich suboptimal, Du solltest als CentralStation-II-Fan nur M4/Mfx auswählen und analog, DCC und RailCom ausschalten. Vielleicht sogar auch MM ausschalten.

Oder vielleicht klappt auch dieser Ansatz: es findet sich jemand mit CentralStation II, der experimentierfreudig ist und für Dich den Fall lösen will? Weil mich die Lösung interessiert, würde ich das Paketporto hin und her spendieren.

[hwissing]

2 CS2 hab ich ja schon, 60214 mit aktueller Software und 60215 im Auslieferzustand von vor Ca. 3 Jahren, mit Software 1.4.0. also der erster CS2 Software mit DCC. Also an der Spelewelt liegt's nicht.

Wenn's mich zu sehr juckt, hätte ich auch noch ein 200 MHz digitales Speicheroszilloskop mit 2 Mb Speichertiefe. Aber dazu muss ich wissen, ob es nur mein Problem ist. Bin noch nicht der Freak in Gleissignalanalyse.

Bis zum Erscheinen dieser Decoder auf meiner Anlage habe ich alles Fremdmaterial in DCC gefahren, ohne jegliches Problem und dachte in hätte mit Railcom die Option auf ein Rückmeldesysrem. Aber die edlen ESU Teile machen da nicht mit, obwohl das Abschalten von Railcom keine Besserung bringt. Das wird's nicht sein.


Gruß
Heimo Wissing

[Peter Müller]

Klar, die Hoffnung war, Du bist nicht der erste mit diesem Phänomen und jemand anderes hat es schon gelöst. Aber im Moment findet sich kein anderer. Deshalb wäre zuerst zu testen, ob in einer anderen Umgebung der gleiche Fehler auftritt.