Hallo,
ich bin vor kurzem von einer Mobile Station 2 auf eine Central Station 3 umgestiegen.

Mit der MS2 habe ich sowohl die Loks (MM + MFX) und auch die Weichen (größtenteils MM, teilweise MFX) gesteuert. Das hat seit 2013 problemlos funktioniert und tut es auch jetzt noch.

Nun mit der CS3 laufen die Loks auch einwandfrei, bei den Weichen habe ich aber ca. ein drittel "aussortiert". Bei ein paar habe ich den Dekoder getauscht und siehe da sie funktionieren auch mit der CS3.
Die "Problemdecoder" funktionieren allein auch an der CS3, nur zusammen mit anderen bleiben sie stumm.
Ich hab schon die CS3 getauscht, leider ohne Erfolg. Die Märklin-Hotline konnte mir leider auch nicht helfen.
Die Antriebe habe ich auch schon quergetauscht, leider ohne Erfolg. Ich bin mir langsam relativ sicher das die Decoder einen Treffer haben.
Interessant wird es wenn ich den Bahnstrom belaste, d.h. Loks fahren lasse, auf einmal funktionieren die "Problemdecoder", zwar nicht zu 100% zuverlässig aber sie schalten hin und wieder mal.

Noch ein paar Daten:
Central Station 3, Hardwareversion HW:03.04, Softwareversion 2.4.0 (5), Web-Oberfläche-Version 2.0.0, Seriennummer 5214

Für alle Ideen woran es liegen könnte und Lösungsvorschläge wäre ich sehr dankbar.

Viele Grüße,
Aaron

Hallo Aaron,

siehe hier das gleiche Problem:
CS3+: Weichen schalten zum großen Teil nicht

Deine Beobachtungen würde meine Theorie sogar bestätigen.

Gruß est2fe

* Wie weit von der nächsten Einspeisung liegen die Weichendecoder denn ?
* Mit welchem Kabelquerschnitt wird eingespeist ?
* Welches Gleissystem (M,K,C) wird genutzt ?
* Wird jeweils Mittelleiter und Masse eingespeist ?

Andreas

Zitat von Andreas85 im Beitrag #3

---

* Wie weit von der nächsten Einspeisung liegen die Weichendecoder denn ?

---

Zitat von Andreas85 im Beitrag #3

---

* Mit welchem Kabelquerschnitt wird eingespeist ?

---

Zitat von Andreas85 im Beitrag #3

---

* Welches Gleissystem (M,K,C) wird genutzt ?

---

Zitat von Andreas85 im Beitrag #3

---

* Wird jeweils Mittelleiter und Masse eingespeist ?

---

Hallo Aaron,

Zitat von Aaron im Beitrag #1

---

Ich bin mir langsam relativ sicher das die Decoder einen Treffer haben.

---

Zitat von vikr im Beitrag #5

---

funktionieren sie denn in einem Vor-CS3-Umfeld auch nicht mehr so wie früher? Das heißt, Du meinst, die Decoder sind beschädigt worden? Wie kann das Deiner Meinung nach passiert sein?

---

Hallo Aaron,

versuche doch mal einfach eine zusätzliche Last mit ca. 1 - 2A dranzuhängen.
Was passiert dann?

Gruß est2fe

Zitat von Aaron im Beitrag #6

---

Sobald ein paar Loks fahren funktionieren die Problemdecoder auch mit der CS3+.
Ich denke das Signal wird gestört, eventuell durch die Problemdecoder selbst.

---

Zitat von est2fe im Beitrag #7

---

versuche doch mal einfach eine zusätzliche Last mit ca. 1 - 2A dranzuhängen.
Was passiert dann?

---

Zitat von Andreas85 im Beitrag #8

---

Das deutet für mich auf eine Abhängigkeit von Gleissignal hin.

* Welche Gleissignale sind denn aktiviert ? (MM, DCC, mfx)
* Wie viele MM-Loks sind denn in der CS3 eingetragen (DCC mfx ?)
* Ist der Punkt Loks automatisch anfahren eingeschaltet ?

a) Je mehr MM-Loks im Zyklus sind, desto mehr "negative" Spannungsteile sind im Gleissignal
b) Wenn "Loks automatisch anfahren" ein ist, werden viele Loks bereits beim Start der CS3+ automatisch ins Gleissignal aufgenommen

---

Zitat von Aaron im Beitrag #10

---

'automatisch anfahren' ist deaktiviert.

---

Hallo Aaron,

schön, dass du einen Graf Oszillo (Oskar) hast und auch
damit umgehen kannst (sogar ein LeCroy!). Damit kann
man dem Spuck hoffentlich auf die Schliche kommen.

Frage:
Kannst du mal weiter reinzoomen bzw. höher auflösen,
so dass man einzelne Bits eines MM-Datenpaketes
erkennen kann? Das jeweils für den Gut- und den Fehlerfall
also einmal mit und einmal ohne Lastwiderstand.

Die Kür wäre dann, den Oskar so zu triggern, dass man das
an den Weichendecoder gesendete MM-Telegram aufzeichnet.

Das könnte man damit machen, dass der Triggereingang
des Oskars (aber nur den Plus, nicht/nie die Masse des
Tastkopfes anschliessen, weil der Decoder_aus_gang einen
völlig anderen GND-Bezug hat))
an den zu schaltenden Weichenausgang des Weichendecoders
dran hängt und dann die Triggerschwelle so hoch einstellt, dass
er nur dann triggert, wenn die Weiche schaltet. Dazu muss man
dann ausprobieren wie viele ms man den PreTrigger einstellen
muss, dass man den Signalverlauf vor dem Triggerereignis noch
zu sehen bekommt.
Eventuell musst du für diesen Fall den GND des Oskars an rot der
Schiene legen, um auf die negativen Pulse des Antriebs triggern zu
können.
Pass da aber auf, dass der GND vom Oskar nie an gelb oder blau
der Weichenantriebs dran kommt.
Dann ist der Decoder sofort ohne Vorwarnung hin!
Nur den Plus-Eingang des Tastkopfes da anschliessen!

Um raus zu bekommen, was man wie einstellen muss, kann man ja
zuerst mal den normalen Kanaleingang dazu hernehmen um eine
Idee zu bekommen, wie das Triggersignal aussieht. Hast du einen
2-Kanal-Oskar, nimm den 2. Kanal als Triggereingang und den
ersten Kanal für das Gleissignal.

Gruß

est2fe

Hallo,
wir haben heute noch ein paar Messungen machen können:

1. Leerlauf CS3 ohne Last (Widerstände), Peaks sehr gut erkennbar, die unsauberen Flanken könnten durchaus der Grund sein das einige Dekoder nicht reagieren:
Bild entfernt (keine Rechte)

2. Leerlauf CS3 mit Last (30 Ohm), die Flanken sind nicht perfekt aber wesentlich besser:
Bild entfernt (keine Rechte)

3. Weiche schalten ohne Last, wie bei 1 Peaks erkennbar, Flanken unsauber folglich problematisch für "Problemdekoder":
Bild entfernt (keine Rechte)

Die Erkenntnis ist im Prinzip die Gleiche wie schon bei der letzten Messung, die Signal-Qualität der CS3 mit der aktuellen Software 2.4 ist nicht perfekt.
Leider habe ich keinen direkten Vergleich zur Vorgänger-Software.

Die Tage werden wir nochmal Messungen mit der MS2 machen, wobei ich erwarte das dort die Signale besser aussehen.

Von Märklin habe ich leider bisher noch keine Antwort.

Gruß, Aaron

Zitat von Andreas85 im Beitrag #11

---

Zitat von Aaron im Beitrag #10

---

'automatisch anfahren' ist deaktiviert.

---

Das würde ich empfehlen mal einzuschalten

Ich würde auch empfahlen "versuchsweise" mal die anderen Protokolle (vor allem mfx) einzuschalten.

Noch eine Frage:

* Hat die Raumtemperatur Einfluss auf das Schaltverhalten ?
(Die Frage klingt komisch, hat aber einen entsprechenden Grund. Ein ähnliches Problem gabs mal bei den k83, und dort gibt es eine bekannte Lösung. Dort war aber zusätzlich zu den Empfangsproblemen eine Temperaturabhängigkeit vorhanden)

---

Hallo Aaron,

so was habe ich schon fast vermutet. Dass es aber so schlecht ist, hatte ich nicht erwartet.
Darüber könnte man nun recht viel diskutieren!
Ich bin mir sicher, meine CS3+ hat kein sooo schlechtes Signal, und die hat noch eine "uralt" SW-Version drauf.
Es kann aber auch an der HW selber liegen.

Leider habe ich gerade nicht so viel Zeit und mache es daher kurz:

Zum 1. Bild:
Das ist ein normales MM2-Lok-Kommando. Man könnte meinen, dass es Reflexionen sind, sind es aber nicht wirklich.
Beim Umschalten kommt irgendwas dazwischen und ein Teil (der 2. Teil) der H-Brücke schaltet nicht sauber/unverzögert
durch. Das ist aber irgendwie nicht immer gleich lang. Kommen da SW-Interrupts dazwischen, die vor dem Umschalten
nicht abgeschaltet werden? Da muss ich jetzt erst mal das Schaltbild der Endstufe/H-Brücke studieren, was da genau
vor sich geht und wie man die H-Brücke ansteuern kann/muss.
Die Peaks entstehen durch eine Längs-Induktivität, die abgeschaltet wird. Da die Höhe der Abschalt-Peaks die Höhe
des Nutzsignals erreichen und kurz darauf auch wieder den Nulldurchgang, werden die Eingänge der Decoder
2 x hintereinander getriggert. Die Signalzeiten werden hierdurch nicht eingehalten und der Decoder verwirft
_zurecht_ diese empfangenen Daten! Es kommt jetzt auf die Strategie an, mit welcher die SW nun vorgeht und die
Signalzeiten auswertet. Offensichtlich gibt es da vom gleichen Hersteller unterschiedliche Strategien, und bei einer
davon lässt sich die Signalzeitenerkennung durch diese kurze Doppeltriggerung aus dem Tritt bringen. Das empfangene
Weichenschaltkommando wird zurecht verworfen, weil das empfangene Signal die Spezifikation nicht einhält!

Zum Bild 2:
Gut, die Peaks werden nun gedämpft und die Induktivität spielt hier kaum noch eine Rolle. Es treten dann keine Flanken
mehr auf, welche den Decoder-Eingang zur falschen Zeit triggern können. Deswegen auch mein Hinweis, die Endstufen
zu belasten, was ja hier ganz eindeutig die Verbesserung bringt.

Zum 3. Bild:
Das ist ein Burst von einem Weichenschaltkommando. Das sieht man an den Signalzeiten, die nur noch halb so lang sind
wie die Lok-Kommandos. Das ergibt dann auch, dass die kurzen (also das letzte 8tel) dann so kurz wird, dass, wie im ersten
Störfall (bei ca. 106,46) dann zu sehen, die Störflanke schon nach ca. 1/5 der kurzen Signalzeit wieder umschaltet. Diese
Störung ist also rein bezogen auf die Nutz-Signalzeit her, schon recht lang (1/5tel)! Das kann, je nach Erfassungsmethode, die
Erkennung erheblich durcheinander bringen.
Was man hier aber auch sieht, ist, dass diese Übergänge beim Umschalten beim Nulldurchgang kaum noch verlängert werden.
Das ist eigentlich fast schon ein perfektes Signal, wenn da nicht diese in diesem Fall eher seltenen Störungen, doch immer
noch vorkommen. Aber ganz offensichtlich sind die Störungen der Flanken hier nicht immer bzw. eher noch selten vorhanden.

Zudem sehe ich, dass dieser Burst von Weichen-Schaltkommando insgesamt 4 x gesendet wird. Rein theoretisch würde da
schon ein Doppel-Signal reichen. Offensichtlich sendet es die CS3 hier zur Sicherheit, dass es der Decoder auf jeden Fall
nicht missversteht, gleich 4 mal raus. Somit dauert so ein Weichenschaltkommando also fast 30ms incl. der obligatorischen
Pausen! Ich kann da also auf der Schiene nur max. 30 Weichenschaltbefehle pro Sekunde übertragen, ohne einen Lokbefehl
dazwischen! Mehr geht da einfach rein physikalisch nicht! Da sieht man die Grenzen sehr gut! So ein Weichenschaltbefehl
der CS3 dauert dadurch also fast die doppelte Zeit wie ein Lokbefehl, obwohl er doppelt so schnell gesendet wird!

Diese 3. deiner Aufzeichnungen ist (für mich) sehr aufschlussreich, da ich schon vor einiger Zeit behauptete, dass da was
nicht ganz ok sei, es aber nie bewiesen habe/bzw. mangels Zeit beweisen konnte. Deine Aufzeichnung liefert mir jetzt den
Beweis. Danke.

Gruß est2fe

Hallo!

Ich habe diese Antwort noch nicht gefunden. Darum hier meine Lösung.

Bitte einfach einmal die Anschlüsse von B und 0 am Weichen-Decoder vertauschen. Bei mir hat das funktioniert.

Der Tipp stammt von Märklin.

Hallo,
die Anschlüsse hatte ich auch getauscht, das Problem wurde dadurch aber nicht behoben.
Meine CS3+ und ein paar Dekoder mit denen das Problem sehr gut nachvollziehbar ist sind seit Mai bei Märklin.
Telefonisch hat man mir auch bestätigt das man das Problem nachvollziehen kann, eine Lösung hat Märklin aber leider noch nicht.

Ich habe mittlerweile auch mit anderen Märklin-Freunden gesprochen, ganz unbekannt scheint das Problem nicht zu sein. Durch den Einsatz von Boostern soll die Signalqualität wohl besser sein und sich das Problem umschiffen lassen.

Ich bin gespannt ob Märklin mir eine Lösung anbieten kann, ansonsten werde ich wohl die Problemdekoder rauswerfen müssen und neue kaufen.

Viele Grüße,
Aaron

Nach anderen Quellen hier im Forum entspricht die Endstufe der CS3 ja der des 60175. Da ist eigentlich ein Netzwerk am Ausgang verbaut das solche Unsauberkeiten im Sinne der EMV unterdrücken sollte. Die Drosseln dämpfen zusammen mit dem Boucherot-Glied bei korrekter Abstimmung Überschwinger zuverlässig. Bei der Abstimmung ist aber auch der Lastwiderstand relevant, das erklärt die Tatsache das bei genug Last die Decoder wieder funktionieren. Eventuell lassen sich die Decoder mit einem kleinen Kondensator am Signaleingang störresistenter machen, dafür müsste man aber die Schaltung des Decoders genau auseinanderpflücken. Typischerweise ist am Eingang erstmal ein Brückengleichrichter verbaut, am Gleichrichter vorbei wird über einen Widerstand von 10-47K das rohe Gleissignal an einen Pin des Microcontrollers geleitet. Die eigentlich als ESD-Schutz gedachten Dioden des Pins sorgen geschützt durch den Widerstand für eine Einweggleichrichtung so das der Decoder das Gleissignal sieht. Fiese Spikes bringen den Controller aber ggf. aus dem Takt oder sorgen sogar für sogenannte Latchup-Efekte durch die EMV-Schutzdioden. Dann hängt der Eingang fest und der Decoder ist blind. Ein winziger Kondensator im Bereich einiger pF vom Pin des Controllers nach GND würde diese Spikes ziemlich plätten. GND ist in diesem Fall das Decoder-GND, nicht die berühmte Märklin-Masse.
Die Endstufe des 60175 ist ziemlich schnell verglichen mit früheren Treibern, das fördert solche Überschwinger. Der bei DCC-Selbstlötern beliebte L298 als Treiber ist in sich so langsam das da kaum Überschwinger entstehen, beim BTS7960 (IBT2-Modul) gibt es einen Widerstand mit dem man die Anstiegsgeschwindigkeit beeinflussen kann um Störungen zu minimieren.

Hallo Aaron,

Zitat von Aaron im Beitrag #17

---

die Anschlüsse hatte ich auch getauscht, das Problem wurde dadurch aber nicht behoben.
Meine CS3+ und ein paar Dekoder mit denen das Problem sehr gut nachvollziehbar ist sind seit Mai bei Märklin.
Telefonisch hat man mir auch bestätigt das man das Problem nachvollziehen kann, eine Lösung hat Märklin aber leider noch nicht.

Ich habe mittlerweile auch mit anderen Märklin-Freunden gesprochen, ganz unbekannt scheint das Problem nicht zu sein. Durch den Einsatz von Boostern soll die Signalqualität wohl besser sein und sich das Problem umschiffen lassen.

Ich bin gespannt ob Märklin mir eine Lösung anbieten kann, ansonsten werde ich wohl die Problemdekoder rauswerfen müssen und neue kaufen.

---

Ist das jetzt ein 74460, ein 74461 oder 74462 ? (Die sind wirklich nicht gleich )

Hallo Andreas,

Zitat von Andreas85 im Beitrag #20

---

Ist das jetzt ein 74460, ein 74461 oder 74462 ? (Die sind wirklich nicht gleich )

---

Zitat von Aaron im Beitrag #10

---

Ich hab DCC und mfx deaktiviert, leider kein spürbarer Einfluss.

---

Zitat von vikr im Beitrag #21

---

Hallo Andreas,

Zitat von Andreas85 im Beitrag #20

---

Ist das jetzt ein 74460, ein 74461 oder 74462 ? (Die sind wirklich nicht gleich )

---

bisher stand im Titel immer 74460 und auch im Text wurde bisher m.W. nie ein anderer erwähnt. Warum zweifelt Du da?

Zitat von Aaron im Beitrag #10

---

Ich hab DCC und mfx deaktiviert, leider kein spürbarer Einfluss.

---

Es geht um Motoroladecoder hinter der CS3plus.

MfG

vik

---

Bei mir funktionieren auch einzelne 74462-Decoder nicht mit meiner (neuen) CS3+.

Und ich schalte mit MM.


Gruß Thomas

Nach dem was da schon mit dem Oszilloskop dokumentiert wurde dürfte das Problem, so es an der Signalqualität bzw. der Empfindlichkeit der Dekoder liegt, nicht durch Software zu lösen sein. Die Überschwinger bzw. die daraus resultierenden Spikes sind nur in Hardware in den Griff zu bekommen, da ist mit Software wortwörtlich nichts zu löten, auch nichts mit irgendwelchen Einstellungen. Das Fehlerbild deutet darauf hin das die Decoder blind sind, sprich: die Spikes die Signalauswertung blockieren. Das ist jetzt nichts wirklich ungewöhnliches, ist aber mit passender Eingangsbeschaltung der Decoder in den Griff zu bekommen. Seitens der CS3 ausgangsseitig Filter zu verbauen ist haarig, die internen sind eigentlich schon ordentlich. Leider müssen solche Filter auf eine definierte Last ausgelegt werden, links und rechts von diesem Lastpunkt ist die Güte der Filter schlechter. Zu wenig Last und das Signal wird zu eckig, zu viel und es wird immer runder, salopp ausgedrückt. Das einige Decoder es doch tun bzw. bei ausreichend elektrischer Last und damit saubererem Signal alle schließt ein generelles Softwareproblem aus.

Hallo Eckhart,

Zitat von Eckhart im Beitrag #22

---

mit der letzten CS3(+) Firmware, die im Gleissignal Merkmale aufweist, die darauf hindeuten, dass Märklin mit DCC etwas vorhaben "könnte".

---

Zitat von Eckhart im Beitrag #22

---

Vielleicht gibt es aber auch zwei Probleme; eines, das sich auf den 74460 mit Motorola bezieht und eines, das 74461 mit "neuem CS3(+) DCC" betrifft.

---