Das kann alles sein, nur dass ich keinen Booster zum Überprüfen dieser These habe.

Zitat von rmayergfx im Beitrag #75

---

Im Nachbarforum ist zu lesen, das es im Boosterkreis nicht zu Problemen mit dieser Lok kommt. Kann es vielleicht sein, das der eingesetzte Booster das Signal "begradigt" und es somit wieder in der Norm liegt?

---

Zitat von Stahlblauberlin im Beitrag #77

---

ist ist die Ursache wohl in der Schaltung der Leistungsstufe der Z21 zu suchen.

---

Zitat von rmayergfx im Beitrag #75

---

Im Nachbarforum ist zu lesen, das es im Boosterkreis nicht zu Problemen mit dieser Lok kommt. Kann es vielleicht sein, das der eingesetzte Booster das Signal "begradigt" und es somit wieder in der Norm liegt?

mfg
Ralf

---

Schönen Sonntag da draußen. Es regnet heute und so habe ich mal in die Z21 geschaut und direkt an den Gates der Endstufen meine Messspitzen drangehalten.
Gelb ist der p-Kanal, also der obere Transistor, grün ist der n-Kanal, also der untere Transistor einer Halbbrücke.





Man sieht hier deutlich den Versatz und dass die Gates auch einigermaßen weich durchgesteuert werden, was die Störungen im Zaum hält.
Dennoch ist die Totzeit seeehr großzügig bemessen und könnte auf ein Viertel eingekürzt werden, ohne dass die Endstufen in Gefahr geraten.
Die Gates der n-Kanal-Transistoren verschwinden direkt in einem CHT02 Quad-NOR-Schaltkreis, die p-Kanal-Transistoren haben noch einen n-MOS vorgeschaltet und einen Spannungsteiler 220R auf 330R nach F+ und eine Z-Diode zum Schutz des Gates vor zu hoher Spannung. 1 ist das Gate des p-Kanal Transistors, 2 ist das Gate des n-Kanal -Transistors und x ist der HCT02. Die beiden linken Transistoren erhalten das gleiche Signal entsprechend invertiert.

Das ist ja praktisch die gleiche Schaltung wie im historischen 10764... Das geht besser, selbst ein L298 kriegt das hin, auch pre-Railcom mit 74hc14 als Inverter dazwischen...

Bedeutet das im Klartext für Nicht Technik versierte, das hier ein Software Update keine Besserung bringt, da schon die Hardware das Problem ist?

mfg
Ralf

Naja... ich weiß noch nicht, wie die Signale in die Logik-Schaltkreise kommen und inwifern diese bei der Signalgestaltung mitwirken. Im Decoder bringt ein Update auf jeden Fall was, wenn der die Nulldurchgänge etwas relaxter auswertet.

Der alte 10764 zeigt das Verhalten nicht, der Zacken im Nulldurchgang ist kaum erkennbar. Also ist vermutlich auf beiden Seiten was in Software möglich. Aus der beruflichen Praxis weiß ich zu gut das Fehlertoleranz nicht unbedingt das ist was Softwareentwickler im Auge haben, egal ob es um Gleissignale oder Anwender geht...

Welchen Einfluss haben dabei eigentlich die Weichdecoder und wahrscheinlich vor allen die Melder? Beide werden ja auch über das Gleissignal angesprochen und die Melder sind ja mit großer Wahrscheinlichkeit auch Dauerkontanke.

Gruß Andreas

Decoder, wenn in Ordnung, beeinflussen das Gleissignal nicht, schon gar nicht die Form. Ebenso Meldegleise, wobei die im DCC-Umfeld anders arbeiten als im MM-Umfeld. Wenn dann wird das Signal/die Gleisspannung durch die Stromfühler auf dem Meldegleis, und nur da, minimal kleiner. Ein Decoder hat sowas zu ignorieren solange die Gleisspannung über 8V bleibt.

Habe mit dem Kundendienst gesprochen, es wird in der nächsten Firmwareversion keine Probleme mit der Z21 (z21) mehr geben. Das Problem wurde erkannt.

Hallo,
Super, vielen Dank für deine Mühe! Ich habe von Roco Fleischmann noch keine Antwort bekommen... Melde mich, wenn etwas kommt.
Viele Grüße!
Ludmilla Fan

Hallo mal wieder,

PIKO hat die Firmware 1.8.0 für den SmartDecoder XP 5.1 herausgegeben. Damit ist u.a. das Problem mit der ohmschen Last an der Z21 (z21) behoben.

Hallo Dampfstoß,
Danke für die Information. Der Piko Service wollte, dass ich die Lok einschicken. Dann müssen die nur die Software aktualisieren, habe ich den aber in die Fehlerbeschreibung geschrieben...
Viele Grüße!

Hallo Zusammen,
Gestern habe ich von Fleischmann/Roco eine Antwort auf meine Email, in der ich die Ergebnisse von Dampfstoß zur Normgerechtigkeit der Z21 beschrieben habe, bekommen. Fleischmann/Roco schreibt dazu folgendes :

"Unser Test hat folgendes ergeben:
Das geschilderte Problem kann nicht reproduziert werden. Auch nicht mit Glühlämpchen.
Der Piko Decoder ist jedenfalls sehr tolerant gegenüber Abweichungen von der DCC Norm:
versuchsweise wurde er hier mit DCC-Bitzeiten von 45 bis 70µs betrieben, was einer extremen Abweichung von der DCC Norm entspricht. Trotzdem konnte unser Piko Decoder auch mit solchen starken Abweichungen stets zuverlässig betrieben werden.

Warum der Piko Decoder beim Kunden den Dienst verweigert, das können wir nicht sagen.
An einer zu kurzen oder zu langen Signallänge von der Zentrale kann es jedoch definitiv nicht liegen, das haben unsere Tests bewiesen.
Wir können daher nur raten, warum der Piko Decoder beim Kunden abstürzt.
Der Kunde möge sich daher an Piko wenden. Vielleicht gibt es ja bereits sogar schon einen Bugfix dafür in der Piko-Decoderfirmware.

Getesteter Decoder Typ: PIKO SmartDecoder XP 5.1 Sound (#56533)
CV#7 = 5
CV#8 = 162"

Aber auf die eigentliche Frage habe ich keine Antwort erhalten...

Ich finde das Komisch... Was sagt Ihr dazu?

Viele Grüße!
Ludmilla Fan

Das ist typisch für Hersteller, dass sie sich erst mal ´rauswinden. Hast Du stichhaltige Oszilloskop-Bilder von der Modellbahnunion bekommen, als Gegenbeweis?
Ich konnte das Problem ja sofort nachstellen an einer Z21, an einer anderen jedoch nicht. Es scheint also ein Grenzfall zu sein.
Im übrigen stürzte der XP 5.1 Decoder nicht ab, er erkannte einfach nicht ausreiched gültige DCC-Pakete und blieb daraufhin stehen.
Die von Fleischmann/Roco genannten Bitzeiten beziehen sich nur auf eine DCC "1" und es wird kein Wort zu den Flankensteilheiten oder zu den Treppchen im Nulldurchgang geschrieben.
Im übrigen bezweifele ich die Angaben, denn bei 45µs sollte der Decoder seinen Dienst definitiv einstellen, das ist weit außerhalb der Norm. Aber da kann ich nur raten .

Wie auch immer, mit der aktuellen Firmware 1.8.0 für den XP 5.1 Decoder tritt das Problem an keiner der in meinem Zugriff befindlichen Z21 Zentralen mehr auf.

Hallo Zusammen,
Danke Dampfstoß für deine Mühe! Die Bilder von Modellbahn Union? Die, die du hier mal im Therad gesendet hast von dem Oszilloskop habe mitgeschickt...

Herstellers geben nicht gerne Fehler zu... Da hast du definitiv recht. Hab nen Flashback zur Märklin H0 C-Gleis. Drehscheibe. 😉

Viele Grüße!
Ludmilla Fan

Hallo Ludmilla Fan,

ich meine, ob Du auch Oszilloskop-Bilder von Roco/Fleischmann bekommen hast, die beweisen, dass ihre Zentrallen einwandfrei funktionieren? Erzählen oder schreiben kann man viel...! Und nachstellen können viele Supportmitarbeiter erfahrungsgemäß auch nicht so viel, da sie außer einem Rechner und einem Telefon meist wenig Equipment auf dem Schreibtisch stehen haben. Gut, dass es Anwenderforen gibt!

Hallo Dampfstoß,
Ich habe von Roco/Fleischmann keine Bilder vom Oszilloskop bekommen... Ich denke die würde ich nicht bekommen... Auch wenn ich nachfragen. Ich kannst aber mal probieren.
Viele Grüße!
Ludmilla Fan

Bei eigenen Versuchen mit der Z21PG wo ich gezielt das Signal ähnlich wie Roco verbogen habe bin ich bei diversen Decodern auf vergleichbar tolerantes verhalten gestoßen, Das erscheint mir plausibel was Roco da schreibt. Von PIKO hatte ich allerdings nur eine V200 in N mit Werksdecoder, der hat allerdings "nur" Abweichungen im Timing von etwa 20% jenseits der DCC -Norm verkraftet. Der Zacken im Nulldurchgang wurde bis 10ys ignoriert, damit war das Timing insgesamt aber voll Verbogen.

Ist denn die PG so aufgebaut, dass sie die Nulldurchgänge ähnlich verschleifen kann wie manche Z21? Kenne die Hardware (noch) nicht.

Hallo Zusammen,
Gestern kam die Lok wieder zurück.
Mit der neuen Decoder Firmware läuft sie ohne Probleme...
Vielen Dank an alle, die mitgeholfen haben!
Viele Grüße!
Ludmilla Fan