Nachdem ich meiner Roco BR 64 jetzt auch pr. Lokprogrammer die Adresse 64 "verpassen" konnte, habe ich jetzt mit dieser Adresse grosse Probleme.
Ich fahre mit - IB (Motorola und DCC) - 4 Power 3 Booster (Uhlenbrock) - Uhlenbrock Loco-Net RM - Watchdog (Adresse 1-4) von Gerd Boll - Weichendekoder von MB-Tronic im MM Format (Flüsterantriebe mit Servos) - ESU-Mobile Control (leider ohne X-Bus Adapter, den Uhlenbrock ja immer noch nicht gebracht hat ) - WDP Version 9.2
Das Problem geht darauf hinaus, dass die BR 64 (mit Lopi 3 - auf Adresse 64 MM eingestellt) und der bis auf Weiteres auch auf die MM Adresse 64 eingestellte Packwagen mit Funktionsdekoder für die Innenbeleuchtung im Betrieb völlligen Quatsch macht: Der Lokmotor stottert und die Beleuchtung der Lok blinkt abwechselnd; Die Zugbeleuchtung blinkt.
Und dies alles, obwohl ich nur mit IB und Boostern fahre. Nun habe ich gelesen, dass WDP die Adresse 68 programmintern verwendet und dass die Mobile Control (falls seitlich an die IB gesteckt) sich nur mit Adressen von 1-64 versteht. Aber diese Fallgruben sollten ja eigentlich nicht auftreten, wenn der ganze Zubehörkrempel nicht angeschlossen ist.
Kann mir jemand einen (oder mehrere) Tipps geben, warum in der Adresse 64 der Teufel zu stecken scheint
#2 von
Peter Ploch
(
gelöscht
)
, 13.08.2006 23:25
Hallo Christof,
ich denke mal, das Problem liegt an der Vergabe einer Adresse für zwei Fahrzeuge, wenn es sich auch um einen Funktionsdecoder handelt. Gib doch Deinem Postwaggon eine andere Adresse und verbinde den dann in der Lokdatenbank von WDP als Funktionsdecoder, dann sollte das Problem erledigt sein. Die gesperrte Adresse 68 in WDP hat mit Sicherheit in Deinem Fall nichts damit zu tun.
In der Zwischenzeit habe ich weiter getestet - bin jetzt bei meinem Testkreis auf dem Schreibtisch. Die IB ist die Selbe. 2 Viessmann Weichendekoder MM-Format hängen noch dran.
Jetzt scheint Adresse 64 zu funktionieren. Die Roco BR 64 heist jetzt wieder Adresse 64 MM - der Packwagen mit dem Funktionsdekoder Adresse MM 64 auch. Hier funktioniert jetzt die letzten 20 Minuten alles wie gewollt.
Bloss: Jetzt hat sich das Ganze auf die Adresse 63 verlegt. Habe hier einen HWZ-Personenwagen mit MM-Funktionsdekoder. Und bei diesem schaltet sich die Beleuchtung und die Rückleuchten unregelmässig an und aus. Die Beleuchtung und die Rückleuchten bestehen aus LED's, die bis heute ohne Probleme funktioniert haben. Den Überlastschutz des Dekoders schliesse ich aus.
Selbes Phänomän habe ich letzte Woche bei Adresse 67 festgestellt. Weichendecoder und Software gibt es bei mir noch nicht. Auch gibt es nur eine Adresse MM67. Ich vermute, dass es durch die Multiprotokoll-Fahrerei dabei um Protokollüberschneidungen handelt, die der Decoder dann falsch interpretiert und durcheinander kommt. Bei mir war es ein Kühn, dachte schon der ist futsch, als der 2. dann das selbe Verhalten zeigte habe ich mal die Adresse gewechselt uns siehe da es geht!
Frage doch mal bei Uhlenbrock nach, woran das liegt!
Heute trat bei mir das selbe Problem auch bei Adresse 64 auf. Und zwar genau dann, sobald ich das ESU-Mobilecontrol einschalte und eben diese Adresse anwähle. Es wird dabei auch nix an die Intellibox wie bei anderen adressen übertragen. Nach einem Reset an der IB und vorherigem Ausschalten der Mobile-Control ist alles wieder bestens, bis zum nächsten Aufruf von Adresse 64 per Mobile-Control.
Denke da gibt es ein Problem zwischen Mobile und IB
Gestern hat es meine IB auf der Adresse 3 (Piko-ICE3) erwischt. Die Lampen blinkten im schnellen Takt, der Zug fuhr nur noch sehr langsam und ruckartig.
Angeschlossen war nur die IB und 3 Deltas als Booster.
Nach einer halben Stunde Zwangspause war der Effekt weg...
ich hatte/habe eine Lok die beim stellen von Weichen losfährt
Das konnte ich beliebig reproduzieren, auch mit teilweise ähnlichen Adressen an Lok und Weiche. Es lief auch immer ähnlich oder gleich ab. Die Lok fuhr langsam los und je öfter ich die Weiche schaltete desdo schneller wurde die Lok
Ich habe das auf eine Fehlinterpretation des Decoders geschoben. Die Adresse nutze ich in der Lok und mit DEM Decoder nicht mehr. Es lag im Übrigen nicht an der CU, wir haben beim Stammtisch verschiedene ausprobiert. Egal ob IB, CS oder 6021, es funktionierte immer.
Es stecken wohl reichlich Fehler(quellen) in der digitalen MoBa-Welt
Mein Tipp: Schaltet mal den analog-Modus in den Dekodern aus, wenn das geht. Es könnte daher kommen.
Es gibt Empfehlungen der hersteller, dass man den analog-Modus nur eingeschaltet lässt, wenn der auch benötigt wird. Das Motto: Wenn der an ist, schadet der nicht, das kann schief gehen.
Hallo Bernd, Dieses seltsame losfahren nach Weichenbetätigung hatte ich bei einer WLE Köf. Lok war in Göppingen, sie habe aber keinen Fehler festgestellt.
Analogmodus ist bei mir generell aus. Mit der ESU-Mobile war der Fehler immer wieder reproduzierbar. Vielleicht spiele ich mal das IB update ein. Hat das schon jemand gemacht? Kann man die alte Software sichern?
vielen Dank für eure Beiträge. Es zeigt die Probleme beim betreiben einer digitalen MoBa, m.E. Tendenz steigend Nun, solange man einen bypass findet kann/muss man damit leben
Nochmals zum Phänomen zurück, was passiert denn in so einem Decoder? Der lauscht am Gleis und sobald er meint da kommt etwas sinnvolles merkt er sich das (zum auswerten, Adresse - Befehl). Und wie merkt er das? Es ändern sich Spannungspegel (Startbit). Kommt nun so etwas wie ein Startbit schaut der Decoder auf die "Leitung" und merkt sich die Spannungspegel im Abstand der zu erwartenden Bits. Glaubt der Decoder es sind alle Bits gekommen interpretiert er das was er im Puffer gesammelt hat. Kommt ein Magnetartikelbefehl kann der Decoder das durchaus falsch interpretieren, da stimmt zwar die Paketlänge nicht aber es sind offenbar vernünftige Spannungspegel im Puffer gelandet. Und sobald der Decoder das für einen sinnvollen Loksteuerbefehl ansieht tut er wie ihm programmiert wurde.
So glaube ich kommt es zu dem Phänomen. In meiner Lok (37512) ist übrigens dieser billige PIC-Decoder drin. Die Lok war deshalb schon bei Märklin da die Lok anfänglich losraste - auch das lag am Decoder.
Hat jemand eine andere Erklärung oder sehe ich etwas falsch? Bin für jede Idee dankbar.
Die Probleme, die du da schilderst, sind ganz bestimmt nicht normal. Im Normalfall sollte der Betrieb mit allen Adressen möglich sein.
Aber es ist klar: Der Decoder muss das Digitalsignal, das auf dem Gleis daherkommt richtig interpretieren können.
Deshalb sollte man wirklich darauf achten, dass man bei allen Digitalumbauten auch dafür sorgt, dass die Entstörmittel auch eingebaut sind. Decoder, bei welcher der Hersteller den Einbauer auffordert, die Entstörmittel auszubauen, sollten gemieden werden. Auch dann, wenn der Decoderhersteller auf den Decoder einen kleinen Kondensator draufpappt. Das alleine ist ungenügend und auf dem Decoder ist es zu spät.
Ausserdem sollte darauf geachtet werden, dass die Digitalspannung an der Lok auch nicht zu tief sinkt. Also, genügend Leistung per Booster ist erforderlich. Auch genügend grosser Kabelquerschnitt für die Einspeisungen. Auch darauf achten, dass alle 1.5 bis 2m eine neue Einspeisung erfolgt.
Wenns mit diesen Massnahmen nicht funktioniert, dann liegts vielleicht wirklich am Decoder oder an der Zentrale. Wie gesagt: Es ist ein zuverlässiger Digitalbetrieb machbar.
die Lok ist so wie sie ist von Märklin geliefert worden, ich habe da nichts verändert. Bei meinen ausgiebigen Tests war diese Lok auch immer allein unterwegs.
Mit ähnlichen (benachbarten Adressen) war das Phänomen ebenfalls zu beobachten, nur musste ich dann andere Weichenadressen "bemühen"
Was man brauchen könnte um eine zu geringe Versorgungsspannung festzustellen wäre ein "Hilfswagen" mit 2 LED (rot=zu gering, grün=ausreichende Versorgungsspannung), den könnte man dann einfach die Anlage abfahren lassen. Wer hat da einen Bauplan?
Wie gesagt, wir haben meine Lok auch mal beim Stammtisch getestet, u.a. mit einer CS und einem kurzen Gleisstück. Da kann die Spannungsversorgung definitiv nicht zu gering gewesen sein.
Aber wie Martin (Meese) schon gesagt hat, wenn Märklin den Fehler in Göppingen nicht sehen kann, dann bekommt man auch keinen anderen Decoder eingebaut. Und deshalb nach Göppingen fahren?? Dann lieber eine Adresse verwenden bei der der Fehler nicht auftritt.
Hallo Bernd, Eine andere Adrese wird dann von einer anderen Weiche ausgelöst. das Problem verschwindet da nicht. War, ist so bei mir. Werde wohl bei Gelegenheit den Versuch mit Tams EC statt IB wiederholen. Vielleicht liegt es auch an der Zentrale.
IB, CS und 6021 haben wir (Michael Knop und ich) probiert, HGH und Hanno haben mit einem Auge zugeschaut
Ich glaube nicht an die CU als Verursacher, lasse mich aber gern belehren. Falls sich die Gelegenheit mal ergibt, dass einer der CU-Hersteller anwesend ist, könnte man es ihm vorführen. Solange man den Fehler alleine hat glauben ja viele man erzählt Märchen
Zitat von BerndSolange man den Fehler alleine hat glauben ja viele man erzählt Märchen
Nene, den Fehler hast du nicht alleine. Meine IB - immer noch an den Testkreis angeschlossen - oder Der Funktionsdekoder mit Adresse MM 63 spinnt immer noch
Danke an alle, die versucht haben, mir mit der Behebung des Problems zu helfen.
Die Lösung ist die, dass bei mir 2 Fehler auftraten - die IB ist unschuldig!
1) Die Adresse 64 ist wohl durch die ESU Mobile Control "verwirrt" worden. Obwohl auf der ESU FAQ zur Mobile Station steht, dass alle Adressen über 64 nicht verwendbar sind, wenn die MS seitlich an der IB angeschlossen wird. Wann bringt Uhlenbrock denn nun endlich den schon länger angekündigten X-Bus-Adapter :
Hat jemand eine Selbstbauanleitung dafür?
2) Der Grund für das Müsterium mit der Adresse 63 ist auf einen Defekten Uhlenbrock Funktionsdekoder zurückzuführen. Ich habe mit einer Anderen IB (Seriennr. 2 ) getestet - genau das selbe blinken. Jetzt ist ein neuer Funktionsdekoder im Wagen - auch auf Adresse 63 eingestellt - un funktioniert Problemlos.....