Märklin CS3+ + Digital Decoder 74460

#26 von est2fe , 08.11.2022 17:56

Hallo Stahlblauberlin,

Zitat von Stahlblauberlin im Beitrag #24
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.

dem widersprechen aber die Aussagen einiger Kollegen hier, dass das Problem mit einer früheren CS3-Version nicht aufgetreten war.

Gruß est2fe

#27 von Eckhart , 09.11.2022 12:11

Hallo Signalanalyseexperten!

Zitat von est2fe im Beitrag #26
dem widersprechen aber die Aussagen einiger Kollegen hier, dass das Problem mit einer früheren CS3-Version nicht aufgetreten war.

Ganz genau!

Zitat von Aaron im Beitrag #13

Mal ehrlich ...seht ihr denn nicht, was hier vor sich geht? Die Spikes sind vielleicht eine unglückliche Auswirkung und vielleicht sogar CS3(+) exemplarabhängig, aber der Nukleus dessen, was überhaupt dazu führt, ist doch mehr als offensichtlich!

Mal überlegen! Bei MM, DCC (nur DCC mit nix!) und mfx brauchen wir nur Nullen und Einsen. Pegel ganz oben und Pegel ganz unten. Dazu schaltet der GFP einfach beide Seiten der Brücke gleichzeitig um. Das geht mit einem Bit! Hier sieht man aber, dass die Umschaltung nicht mehr 100% gleichzeitig stattfindet! Es scheinen also ganz offensichtlich zwei Portbefehle, bzw. Operationen im GFP am Start zu sein! Wozu macht man sowas? Warum trennt man die Ansteuerung der beiden Seiten der Brücke voneinander ab? Ich denke, das was wir in der Mitte der Flanke sehen, ist das Ziel! Diesen dritten Zustand soll der GFP können!

Und nun darf nachgedacht werden, was dieser "dritte Zustand" können könnte, wenn man es wollen würde!

Gruß, Eckhart

PS: Die Spikes, die sich vom "dritten Zustand" aus bilden, sind nur ein unbeabsichtigter Nebenkriegsschauplatz!

#28 von vikr , 09.11.2022 12:45

Hall Eckhart,

Zitat von Eckhart im Beitrag #27
Die Spikes, die sich vom "dritten Zustand" aus bilden, sind nur ein unbeabsichtigter Nebenkriegsschauplatz!

es wäre ja durchaus wünschenswert, wenn Märklin seinen Zweileiterkunden eine zeitgemäße RailCom ähnliche oder sogar kompatible Rückmeldung bieten würde. Schließlich hat Lenz auf eine Verlängerung der Patente verzichtet und es wären keine Lizenzkosten fällig. Märklin dürfte es halt nicht unter dem Namen "RailCom" vermarkten. Und natürlich muss Märklin ausgiebig testen, unter welchen Umständen eine CS3 mit dieser Option abwärtskompatibel ist. Natürlich muss man da ggf. mit Seiteneffekten rechnen.
Ungünstig ist halt bei einem solchen Test mit Seriengeräten im Feld, wenn User, die tatsächlich ein bisher nicht bekanntes Problem haben, nicht so ohne weiteres auf die frühere Firmware zurück können, mit der ihr System problemlos funktionierte. Es wird kaum die Idee von Märklin gewesen sein, dass alle CS3-Nutzer etliche ältere verbaute Weichendecoder in ihren vorbildnah eingeschottert C-Gleisen mal kurz gegen neue tauschen.
Das das ganze prinzipiell funktionieren kann, zeigt ja die ECoS.

MfG

vik

#29 von Stahlblauberlin , 09.11.2022 13:34

Zitat von Eckhart im Beitrag #27
Dazu schaltet der GFP einfach beide Seiten der Brücke gleichzeitig um. Das geht mit einem Bit!

Geht es leider nicht, wenn z.B. Railcom unterstützt werden soll muss auch die Möglichkeit bestehen beide Zweige der H-Brücke niederohmig auf LOW zu schalten. Auch lässt die Schaltung es nicht zu ohne ein zusätzliches Gatter (Inverter) zu verwenden, damit wäre aber zum Beispiel Railcom schon in Hardware ausgeschlossen. Wie MFX die Kommunikation Lok -> Zentrale auf elektrischer Ebene abwickelt weiß ich nicht, aber ich kann mir vorstellen das das ähnlich wie bei Railcom läuft.
Das Ruckeln im Nulldurchgang ist unschön, die Deadtime ist sehr großzügig. Da kann die Software durchaus eine Rolle spielen, Decoder sollte das aber nicht wirklich kratzen. Bei der üblichen Eingangsbeschaltung werten die eh nur eine Halbwelle des Signals aus. Haarig könnte es nur sein wenn der Siebkondensator auf dem Decoder nach dem Gleichrichter so winzig ist das die sich aus der Deadtime ergebenden Unterbrechungen der Stromzufuhr auf die Betriebsspannung des Controllers im Decoder durchschlagen.
Ganz vermeiden lässt sich die Deadtime nicht, sie sollte aber im Bereich von unter einer µsec machbar sein. Meine Arduino-basierte Zentrale schafft etwa 0,3 µsec bei 16 MHz Takt. Da kommt noch die Verzögerung des L298 zu. Die ESP8266-Zentrale mit 160 MHz ist da mit meinem 20MHz-Oszilloskop nicht mehr zu erfassen, da schlägt die Deadtime der Treiber als einziges rein. Die ist für mich nicht mehr messbar, eine gerade zu erahnende Stufe auf dem Oszi.. Die Deadtime ist auch notwendig weil niemals obere und untere Hälfte einer (Halb)Brücke gleichzeitig leitend sein dürfen.
Wenn also Softwareproblem dann in der Ansteuerung. Im Quelltext meiner Zentralen sind das zwei Zeilen die die entsprechenden Pins auf den Status des DCC-Signals setzen, einmal nichtinvertiert, einmal invertiert. Weiß nicht was für ein Prozessor in der CS3 das Signal generiert, mehr Dampf als ein Arduino hat er mit Sicherheit.

#30 von Michael Knop , 09.11.2022 15:00

Hi zusammen,

Da hier (oben) auch wieder von railcom die Rede ist:

Railcom und die genannten Dekoder 74460 schließen sich zusammen aus - wenn railcom im Gleis ist, schalten die Dekoder nicht (mehr richtig/zuverlässig).
Das selbe gilt für die mehrfach Wichen- Dekoder aus der „Frühzeit“ der Digitalisierung.

Gleiches gilt für Fahrzeuge mit Dekoder (vom Märklin) mit Dip Schaltern zu Adresse codieren - mit railcom im Gleis laufen diese Loks nicht mehr (vernünftig). Ggf. Sind c90/2 Dekoder noch brauchbar, aber Delta, c80 und c90 sind bei railcom nicht mehr nutzbar.

Viele Grüße, Michael

#31 von vikr , 09.11.2022 15:18

Hallo Stahlblauberlin,

Zitat von Stahlblauberlin im Beitrag #29
Wenn also Softwareproblem dann in der Ansteuerung.

was genau das nicht die These von estefe und anderen in diesem Thread im Gegensatz zu Deiner Idee?

Zitat von Stahlblauberlin im Beitrag #24
Das einige Decoder es doch tun bzw. bei ausreichend elektrischer Last und damit saubererem Signal alle schließt ein generelles Softwareproblem aus.

MfG

vik

#32 von vikr , 09.11.2022 15:31

Hallo Michael,

Zitat von Michael Knop im Beitrag #30
Da hier (oben) auch wieder von railcom die Rede ist:

Railcom und die genannten Dekoder 74460 schließen sich zusammen aus - wenn railcom im Gleis ist, schalten die Dekoder nicht (mehr richtig/zuverlässig).
Das selbe gilt für die mehrfach Wichen- Dekoder aus der „Frühzeit“ der Digitalisierung.

Gleiches gilt für Fahrzeuge mit Dekoder (vom Märklin) mit Dip Schaltern zu Adresse codieren - mit railcom im Gleis laufen diese Loks nicht mehr (vernünftig). Ggf. Sind c90/2 Dekoder noch brauchbar, aber Delta, c80 und c90 sind bei railcom nicht mehr nutzbar.

stimmt, ich halte es aber eher für ein Problem der Asymmetrie des Motorola-Gleis-Formats in Verbindung mit der Polung. Bei den Weichenspulen kommt hinter einem Motoroladecoder einfach zuwenig Leistung an, wenn versucht wird, das gesamte Gleissignal dauerhaft symmetrisch zu verbiegen.

MfG

vik

#33 von Eckhart , 11.11.2022 13:24

Hallo Stahlblauberlin!

Zitat von Stahlblauberlin im Beitrag #29
Wie MFX die Kommunikation Lok -> Zentrale auf elektrischer Ebene abwickelt weiß ich nicht, aber ich kann mir vorstellen das das ähnlich wie bei Railcom läuft.

Die mfx Rückmeldung ist mit dem RDS ("Radio Daten System") Verfahren, nur mit einer etwas anderen Frequenz als RDS und natürlich anderem Content, auf das Gleissignal aufmoduliert. Das hat mit RailCom nichts zu tun und benötigt auch keinen CutOut!

Zitat von Stahlblauberlin im Beitrag #29
Im Quelltext meiner Zentralen sind das zwei Zeilen die die entsprechenden Pins auf den Status des DCC-Signals setzen, einmal nichtinvertiert, einmal invertiert. Weiß nicht was für ein Prozessor in der CS3 das Signal generiert, mehr Dampf als ein Arduino hat er mit Sicherheit.

Das ist eine viel zu einfache Sicht auf die Mä CS2/3 Gleissignal und Booster Welt! Bei der CS2/3 generiert nicht der Main uC (der für GUI, Internet, etc.) das Gleissignal, sondern der Gleisformatprozessor ist ein eigener uC! Dieser hängt einerseits (u.A. via CAN) am Main uC und generiert sein Gleissignal für eine in Hardware gegossene Switching-Matrix. An dieser Switchíng-Matrix hängen, der interne Booster für das Hauptgleis, der kleine Zusatzbooster für das Programmiergleis und das im CAN-Kabel mitgeführte native Gleissignal für die externen Booster! Außerdem kann diese Switching-Matrix den eigenen GFP abkoppeln und statt dessen das im rückführenden CAN Kabel mitgeführte Gleissignal in den Booster einspeisen. ("Slave Betrieb" der 3/4/5 und 6+)

Zumindest die OUT und IN in den CAN-Kabeln mitgeführten Gleissignale bestehen nur aus EINER Leitung! Im Slave Betrieb generiert die Switching-Matrix die beiden Brückenhälften des Booster daher quasi-simultan! imho hat das eine frühere Firmware genauso vom GFP, via Switching-Matrix, zum Booster getan! Hier scheint, in der neuen CS3 Firmware, etwas aufgespalten worden zu sein! Dass es Seiteneffekte auf bestimmte Decoder hat, war wohl nicht klar.

Ich hoffe, dass Mä einen kompatiblen Weg findet und nicht einfach alles zurücknimmt und das "Projekt" vorläufig begräbt!

Gruß, Eckhart

#34 von vikr , 11.11.2022 15:17

Hallo Eckhart,

Zitat von Eckhart im Beitrag #33
..... Dass es Seiteneffekte auf bestimmte Decoder hat, war wohl nicht klar.

Hhm, muss man den gewünschten Umfang der Abwärtskompatibilit nicht schon vor der Entwicklung festlegen und dann während der Entwicklung kontinuierlich überprüfen?

Zitat von Eckhart im Beitrag #33
.....
Ich hoffe, dass Mä einen kompatiblen Weg findet und nicht einfach alles zurücknimmt und das "Projekt" vorläufig begräbt!

Ja, hoffen wir mal... Die Entwicklung und Weiterentwicklung der CS3 stand Märklin bisher nicht wirklich unter einem guten Stern. Vielleicht hat Märklin im verflixten siebenten Jahr letztlich doch noch eine glücklichere Hand.

MfG

vik

Beiträge:	1.451
Registriert am:	07.06.2007
Gleise	C + M
Spurweite	H0
Steuerung	6021 IB1 MS1 MS2 CS2 CS3
Stromart	Digital

Beiträge:	608
Registriert am:	28.01.2022
Gleise	K-Gleis
Spurweite	H0
Steuerung	CS3+
Stromart	AC, Digital

Beiträge:	6.367
Registriert am:	23.10.2011
Gleise	M, C u. K.
Spurweite	H0, N
Stromart	Digital, Analog

Beiträge:	3.458
Registriert am:	07.03.2022
Ort:	Berlin
Spurweite	H0, Z, G
Steuerung	Roco digital, Z21-Nachbau
Stromart	DC, Digital, Analog

Beiträge:	7.329
Registriert am:	28.04.2005
Ort:	Ruhrpott
Gleise	C-Gleis
Spurweite	H0
Steuerung	IB / IB2
Stromart	AC, Digital

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

RE: Märklin CS3+ + Digital Decoder 74460

Bitte geben Sie einen Grund für die Verwarnung an