Meine Versuche fanden mit der schwarzen Z21 statt und es waren satte 5µs, was den positiven Puls auf 64µs und den negativen auf 54µs verlängerte, respektive verkürzte. Der Nulldurchgang spielt dabei insofern eine Rolle, dass er in der Mitte der beiden Spannungsmaxima platt wird. Damit werden die für den Decoder sichtbaren Flanken versetzt. Der Decoder sieht also nicht die gewohnten 58µs +-3, sondern 58µs +-5. Und das ist an der Grenze der Norm. Selbige Verzerrung passiert am Nullbit, wobei hier nur die untere Grenze problematisch ist. Nach oben darf eine Null ja länger sein.

1-Bit ohne Ohmschen Verbraucher:


1-Bit mit 300mA ohmscher Last direkt am Gleis

Hallo Zusammen,
Kann ich etwas gegen die Spannungs Schwankungen tun, die durch die Glühbirnen ausgelöst werden?
Viele Grüße!
Ludmilla Fan

Naja, die Glühlampen dürfen nicht direkt an´s Gleis. Davor muss ein schneller Vollbrückengleichrichter und ggf. ein Ladekondensator. Bei der Glühlampe ist der Kondensator eher sinnlos, die leitet ja ohnehin immer.

Rein ohmsche Lasten dürfen auch direkt ans Gleis, ob da ein Gleichrichter vor ist oder in China fällt ein Reissack um. Solange der Maximalstrom nicht überschritten wird darf man da ne'n kompletten Weihnachtsbaum ranhängen. Alles andere ist elektrotechnisch Quatsch. Ohmsche Lasten stören nicht mal das Lesen von CVs, die Zentrale wertet die Quittungsimpulse anhand von Laständerungen aus, sprich: ob der Strom bei Senden einer Quittung um mindestens 60 mA durch Einschalten des Motors ansteigt. Ob da ein A Grundlast auf dem Gleis liegt kratzt dabei nicht. Auch wenn nach NMRA und NEM im Service-Modus der Gleisstrom auf 200/400 mA begrenzt sein sollte, die meisten Zentralen begrenzen da nicht.
Auch darf sich ein Decoder eigentlich durch solche Verzerrungen nicht aus dem Takt bringen lassen, ansonsten ist die Firmware und/oder die HW besch..en. Sinnvollerweise muss ein Decoder ein Signal verwerten können das die doppelten erlaubten Abweichungen aufweist. Da beim DCC-Signal immer die ganze Periode zählt (also von Low-High-Flanke zu Low-High-Flanke) ist die Gesamt-Periodenlänge mit 118µSec sauber im Rahmen des erlaubten. 116µSec wären das Optimum, 2 µSec sind nicht mal 2 %. Bei eigenen Experimenten in anderem Zusammenhang habe ich Decoder mit Abweichungen von 20% im Timing noch problemlos ansprechen können, in beide Richtungen, sprich: zu schnell und zu langsam. Freie Arduino-Bibliotheken zur DCC-Auswertung erlauben für eine 1 eine Preiodenlänge von 70-150 µs und eine Null alles ab 150 µs. Gibt ja noch die "Streched Zeros" mit der man noch eine analoge Lok nutzen konnte...
Ist der Decoder mal auf Werkseinstellungen zurückgesetzt worden? (Wert 8 in CV8) Nicht das da irgendwas zerspielt worden ist.

Hallo Zusammen,
Habe die Lok schon zurückgesetzt, aber ohne Erfolg... Die Br 101 hat sich trotzdem wieder abgeschaltet...
Viele Grüße!

Dann vermute ich einen Defekt am Decoder bzw. die Firmware hat einen Bug. Wenn eine andere Zentrale, gerne was ganz einfaches, zur Verfügung steht würde ich damit mal testen. Für solche Fälle hab ich immer noch eine LM2 und den 10764 liegen.

Hallo BR 132 Fan,

da ich das Problem nachstellen konnte, ist es bestätigt, dass z21 und Decoder sich unter den gegebenen Umständen nicht mögen. Woher die Ursachen für die Verzerrungen kommen, können wir nur raten. Ich habe habe die Z21 mit 30 Loks auf meiner Anlage, da gibt es keine Probleme. Die Decoder sind alle PluX22 XP-5.1, zum großen Teil mit Sound.

@ Stahlblauberlin:
Du magst komplett richtig liegen, wenn Du Dich am Gleis alleine um DCC sorgen musst. Der Decoder ist ein aber Multiprotokoll-Decoder und der muss DCC von anderen sehr ähnlichen Protokollen, etwa mfx, unterscheiden können. Die Toleranzfenster daher um 20% aufzuweiten, ist nicht sinnvoll, da daduch mehr Störungen durchkommen können. Beide Pulse in Folge auszuwerten und daraus einen zu machen ist ebenfalls nicht sinnvoll, wenn Zusatzfunktionen, wie ABC-Bremsstecken mit Langsamfahrt, detektiert werden müssen oder gar HLU. Da müssen nämlich auch Einzelpulse und deren Spannung gelesen werden. Auch für die RailCom-Austastlücke kann ein beidphasiges Lesen der Pulse sinnvoll sein, um das Timing für die RailCom-Antwort genau hinzubekommen. Das hängt von der Gestaltung der Hardware und Firmware ab. Im Übrigern gibt es die RCN-210, die klar regelt, was ein Decoder erkennen können muss und was nicht. Da kannst Du nun hineininterpretieren was Du willst. Wenn Du Arduinos programmierst, kannst Du das alles so stricken wie Du es willst, aber für Modellbahnhersteller gelten im Allgemeinen Normen.

Hallo Zusammen,
Ich denke ich werde mich mal mit Piko in Kontakt setzten... Im Notfall reklamieren ich die Br 101 und kauf sie mir analog und Bau einen ESU Sounddecoder ein... Schade... Der Piko Sound hat mir gut gefallen...
Vielen Dank für eure Bemühungen...
Viele Grüße!
Ludmilla Fan

Hallo Ludmilla Fan, wenn Du genau beschreibst, was Dir aufgefallen ist, kann Dir beim Kundendienst vielleicht geholfen werden. Halte uns mal auf dem Laufenden. Ich werde mal die Z21 an meiner Anlage mit den H0-Loks quälen und schauen, ob ich das auch dort reproduzieren kann.

Mache ich!
Bis dahin!

Ach so, der Vollständigkeit halber: ESU LoPi4 Next18-Decoder haben auf der SUSI-Schnittstelle Clock/Daten vertauscht. Daher werden bei der BR101 die Führerstände und das Fernlicht nicht funktionieren, insofern man diesen Decoder einsetzen will.

Fan nehme ich Zimo...
Danke für den Hinweis!

@Dampfstoß Zitat aus RCN210:
2.1 Das "1"-Bit, Einsbit
 In einem Einsbit müssen die erste und die zweite Hälfte eine Dauer von 58 µs ± 3 µs
haben.
 Die Dauer eines Einsbits beträgt somit 116 µs ± 6 µs.
 Beide Bithälften müssen gleich lang sein mit einer Toleranz von ± 3 µs.
 Ein Decoder muss eine Toleranz für ein Bithälfte vom ± 6 µs akzeptieren.
 Das bedeutet, ein Decoder muss solche empfangenen Bits als gültige Einsbits erkennen,
deren beide Teile je eine Dauer zwischen 52 µs und 64 µs haben.

Damit liegt die Z21 noch in der Norm, der Decoder muß es also verdauen. Das man eigene Software da beliebig tolerant auslegen kann ist eine andere Geschichte, erst recht wenn man sich auf ein Protokoll festlegt.
Bei ABC-Strecken ist das Timing irrelevant, bei den auf Basis von Asymmetrien im Pegel arbeitenden Bremsstrecken müssen die Pegel in Abhängigkeit von der Polarität erfasst werden, das Timing ist für diesen Zweck irrelevant. Die Railcom-Lücke ist wiederum was ganz anderes, da muss der Decoder in erster Linie die Austastlücke erkennen, und zwar folgend auf ein gültiges DCC-Paket. Multiprotokollfähigkeit wiederum ist richtig spannend, aber auch da wird in erster Linie die Struktur ausgewertet, basierend auf den Signalflanken. Mehrere Protokolle am Gleis sind aber auch ein Quell von bizarrsten Fehlern. Zumindest decoderseitig nicht benötigte Protokolle zu deaktivieren hat schon einige Probleme gelöst.

Zitat von Stahlblauberlin im Beitrag #38

---

Damit liegt die Z21 noch in der Norm, der Decoder muß es also verdauen.

---

@Dampfstoß Interessant wäre warum die Z21 sowas mit übersichtlicher Last macht, z.B. ein Fehler am konkreten Gerät. Um den Effekt nachzubauen muss man das schon bewusst machen, 5µs Totzeit sind heftig. Mit irgendwelchen Schaltverzögerungen der Bauteile selbst bekommt man da nicht hin, es sei denn es werden Treiber mit einstellbarer Totzeit verwendet und hier gibt's einen Bestückungsfehler. Meist ist das ein Widerstand oder ein RC-Glied.

@Br 132 Fan

Hast du mal probiert in der CV12 alle ungenutzten Betriebsarten abzuschalten?
Aktuell sollte da CV12=117 drinstehen, somit sind alle Betriebsarten aktiv. Wenn du DCC fährst stell doch die CV12=4 ein, damit ist nur noch DCC aktiv.

mfg
Ralf

Hallo Ralf,
Habe ich noch nicht probiert...
Mache ich heute Abend mal...
Viele Grüße!

Andere Protokolle abschalten bringt nix. DCC wird nicht erkannt, fertig.

@Stahlblauberlin Ich habe noch eine zweite Z21 im Zugriff, die guck ich mir heute Abend an.
Wenn ich DCC-Signale selber erzeuge, lasse ich die Timer im Controller entscheiden, welcher der Brückentransistoren wann schalten darf. Da kommen in der Regel Zeiten um 1µs zum Einsatz. Das kann man dann frei einstellen und muss sich nicht auf R/C-Kombinationen verlassen. Ist auch nett, wenn man die Endstufen mangels Material gegen andere austauschen muss und diese eine andere Charakteristik haben oder eine andere Gate-Kapazität.

@Dampfstoß Bei mir kommen aktuell zwei Versionen der Z21 PG zum Einsatz, bei beiden wird vom Arduino das DCC bzw. ein invertiertes DCC-Signal durch schalten der jeweiligen Pins in Software erledigt, damit dann direkt die H-Brücke (L298 bzw. BTS7960) angesteuert. Die Kombination Arduino Nano mit L298 schafft schon unter 500ns, die mit ESP8266 und BTS7960 liegt bei ~20 ns, das löst mein Oszi kaum noch auf. Das Timing selbst halten beide auf ca. 1µs sicher ein, es sei denn ein Interrupt haut mal blöde dazwischen. Beim Nano gibt es dann halt mal ein ungültiges Paket, der ESP ist schnell genug um selbst dann das Timing zu halten. Unter Last wird allerdings speziell beim L298 das Signal leicht trapezförmig, die Verzerrung im Nulldurchgang bleibt konstant. Der L298 ist allerdings auch nicht gerade State-of-the-Art.

Nee, der L298 ist schon etwas älter und ziemlich analog mit reichlich Leistungsverlust. Es geht ja auch nicht darum, die steilsten Nulldurchgänge hinzubekommen, sondern saubere mit gleichen Bitlängen. Ich nehm diskrete MOSFETS mit ausreichend schnellen Treibern. Die Totzeit soll halt nur das Durchschlagen eines Transistorpärchens verhindern. Mehr nicht. Ich stelle das so steil wie nötig ein, so dass der Ruhestrom in der Endstufe durch Schaltverluste minimal ist und andererseits keine Treppen im Signal auftauchen. Aber das wird jetzt schon recht fachlich .

Hallo zusammen,

ich sehe das hier zufällig...

Schnelle Flanken sind schön, aber nur, wenn sie auf dem Gleis nicht zu drastischen Verzerrungen führen und man nicht eine Sendeanlage baut. Die Dekoder stecken Überschwinger nicht gut weg, wenn sie daraus Taktflanken restaurieren sollen.
Der bipolare L298 ist nicht zu schnell, wird heiß und steckt Kurzschlüsse nicht so ganz toll weg. Sein Trapez ist aber nicht schlecht.
Besser, man baut mit FETs, aber zusätzlich folgendes ein:
1. Eine Slope Kontrolle, im einfachsten Fall ein RC Glied zum Gleisspannungs-Ausgang
2. Eine Strombegrenzung, die auch nicht zu früh abschaltet.

Gruß,
Joachim

Der Snubber am Ausgang ist Pflicht. Kostet etwas Strom, aber macht "runde Ecken" und erfreut die Bundesnetzagentur

@rmayergfx
Bei CV 12 ist bei mir Wert 53... Was heißt das denn?
Viele Grüße!

Zitat von Br 132 Fan im Beitrag #48

---

@rmayergfx
Bei CV 12 ist bei mir Wert 53... Was heißt das denn?
Viele Grüße!

---

Danke für deine Antwort!
In meiner Anleitung ist der Wert nicht aufgeführt...
Viele Grüße!