Das Problem

Die Kommunikation von Decoder zur Digitalzentrale nach DCC im Service Mode geschieht mit kurzen Strompulsen, die der Zentrale die progarmmierten CV Werte bestätigen. Dabei ist es nicht ungewöhnlich, dass Probleme beim Erkennen des ACK Pulses des Decoders zur Zentrale auftreten. Zum Programmieren von Decodern anwende ich zwei Zentralen: Eine Digitrax DCS 50 (Zephyr) Zentrale und einen Eigenbau mit DLL , Eigenbaubooster und eigener Ackdetectschaltung. Nach etwas Trimmung ist jetzt meine Ackdetectschaltung toleranter als die Kaufzentrale von Digitrax. Doch stellt sich die Frage: Was sagt der Standard und wie folgen die einzelnen Decoder dem Standard?

Der Standard

In RP-9.2.3 steht geschrieben: Basic acknowledgment is defined by the Digital Decoder providing an increased load (positive-delta) on the programming track of at least 60 mA for 6 ms +/-1 ms.

Alle untersuchten Decoder haben keine Probleme mit den angeschlossenen Motoren den Stromverbrauch um 60mA zu erhöhen. Der Durchgang der 60mA Schwelle wurde von mir auch zur Definition des Start- und Stopzeitpunkts verwendet.

Leider macht der Standard keinen Unterschied zwischen der Zeit für die der Decoder den Puls generieren muss und der Zeit welche die Zentrale noch als gültigen Puls akzeptiern sollte. Ist ein Puls von 4,99ms noch im gültigen Bereich oder muss er schon 5,01ms lang sein?

Die Untersuchung

Zur Untersuchung wurden mehrere Loks mit schon verbauten Decodern herangezogen. Da die Motoren dieser Loks unterschiedlich sind, möge man mir verzeihen, dass die Versuchsbedingungen nicht exakt genau gleich für alle Decoder sind. Den Aufwand, alle getesteten Decoder in die gleiche Lok einzulöten habe ich dann doch gescheut. Doch wurden keine Mühen gescheut, professionelle Messausrüstung zu benützen. Wie die Zentrale muss man auch mit dem Oszilloskop den ACK Puls erst finden. Dazu wurde die Samplingsfunktion und verschiedene Hold-off Zeiten nach dem Triggern benutzt. Nach mehrmaligem Auslesen von CV 1 kann man dann das Oszilloskop so einstellen, dass der Bereich der hohen Samplingsauflösung zeitlich richtig liegt um den ACK Puls einzufangen.

Das Oszilloskop (mit Markenfloppy) und andere nützliche Dinge:

V.l.n.r der Eigenbaubooster, die Ackdetectschaltung unter den Decoderlitzen, die Digitraxzentrale (gerade nicht am Gleis angeschlossen) und die Proben:

Digitrax

Da (nicht sehr überraschend) die Digitraxdecoder mit der Digitraxzentrale zusammen funktionieren, habe ich mit einem DZ125 in einer alten Trix F3 angefangen. Man sieht wie der Decoder 6,34ms lang den Stromverbrauch erhöht (blau) und dadurch die Spannung über das Gleis wegen des in Serie geschalteten 30 Ω Widerstands am Progarmmiergleis etwas einbricht.

Döhler & Haas

Die ganze Versuchsreihe wurde dadurch ausgelöst, dass ich Probleme hatte, eine testweise gekauften DHP160 Decoder von Döhler & Haas auszulesen. Da diese in Schweden nur sehr schwer erhältlich sind, hat mir D&H einen direkt verkauft. Da ich nur DCC Ausrüstung besitze kann ich leider aber nicht Parameter 104 der die genause Version angibt auslesen. Diese Parameter scheint als DCC CV nicht lesbar zu sein. Warum nicht alle Parameter als DCC CV lesbar gemacht wurden (es gibt ja schließlich keine Begrenzung in der Anzahl der CV) weiß ich nicht. Freundlicherweise wurde mir ein DHP160 von Heinrich O. Maile zur Untersuchung ausgeliehen, auf den die Version 7-12 aufgespielt wurde. So kann sicher gesagt werden, dass die Erkenntnisse auch für diese Softwareversion gelten. Wie man in den Screenshots erkennen kann, liegt der ACK Puls dieser Decoder sehr eng an einer Grenze des definierten Spielraums, den der RP-9.2.3 zulässt. Mit 5,02ms bzw. 5,06ms ist man so hart an der Grenze, dass die Steig- und Fallzeiten des Strompulses eine Rolle spielen, welche davon abhängen welcher Motor verwendet wird und ob gerade eine 0 oder eine 1 im DCC-Takt gesendet wird. Wenn da wirklich der Puls 5ms lang gesendet werden soll, drängt sich doch der Verdacht auf, dass da jemand den Standard missverstanden hat.

Der DHP160 in einer Arnold 111:

Der DHP160 in einer Trix F3 (gleiche Lok wie DZ125, s.o.):
So ungefähr sah es während des Versuchs aus:

Kühn

Ein anderer Decoder, der manchmal zum Auslesen funktioniert hat und manchmal nicht, ist der Kühn N025.

So sehen die Zeiten des N025 in einer Arnold 211 aus (5,34ms):
N025_in_Arnond_221.png

Zimo

Ein Decoder, der immer recht gut funktioniert, ist der Zimo MX620. In diesem Test zeigt er in einem Kato 515, dass er mit 6,08ms ganz dicht an der vorgegebeben Zeit liegt:

Besondere Erwähnung verdienen die genau definierten Flanken.

CT Elektronik (Tran)

Die Decoder von CT-Elektronik sind wegen ihrer Winzigkeit sehr beliebt. Auch funktioniert das Auslesen für mich recht zuverlässig. Wie gut folgen sie dem Standard?

DCX75 in Arnold V65:

Hoppla, was sind denn das für Stromspitzen? Und auch noch im Leerlauf? Sieht ganz so aus als wäre da ein Kondensator verbaut. Bin mir aber recht sicher, dass da keiner ist, Platz ist ja auch keiner dafür da. Es hat zwar die Triggerung des Oszilloskops etwas erschwert, aber dennoch gibt es einen deutlichen Puls von 7,56ms. Zum Vergleich habe ich auch noch eine andere Lok mit DCX75 herangezogen.

DCX75 in Ibertren V80:

Hier sind die Störungen nicht vorhanden, also muss es die Arnoldlok sein, die irgendwie diese verursacht. Das werden ich später noch untersuchen. Doch zurück zum ACK Puls. Auch hier hat er eine Länge von 7,56ms. Eine standardkonforme Zentrale müsste eigentlich einen solchen Puls als ungültig verwerfen. Doch scheint es mit den meisten Zentralen zu funktionieren. Wahrscheinlich wird die Längenüberschreitung nicht so genau kontrolliert. Bei Tran ist der ACK Puls einstellbar mit CV 111. Der gemessene Puls der auserhalb des Standards liegt wurde mit den Werkseinstellungen des Decoders erzeugt (CV 111 = 255). Die Dokumentation des Decoders gibt einen Einstellungsbereich von 0-255 an. Exakt wie sich der Puls bei anderen Werten von CV 111 verändert, wurde nicht getestet und ist auch in der Anleitung nicht angegeben. "Intensität der Quittierungsimpulse (ACK): verbessert die Programmierbarkeit, 128 = ca. 50% des max. Quittierungsstromes" Eine andere Anomalie ist, dass der Quittierungspuls ungefähr in der Mitte schwächer wird, um dann wieder zuzunehmen.

TCS

Digitrax ist der größte, aber nicht der einzige Decoderhersteller in den USA. Zum Vergleich tritt hier ein Decoder der Firma TCS, die innovative Lösungen mit zweigeteilten Decodern für die älteren USA-Diesel von Kato anbietet, an.

Hier kann man sehen, dass auch TCS mit 6,24ms wie Digitrax sich im Breich "gut 6ms" hällt.

Hier das CN Modell in einer Atlas U25B:

Fazit

Offenbar folgen weder alle Hersteller von Decodern noch die Hersteller von Zentralen in allen Aspekten dem Standard. Die Digitraxzentrale sollte mit dem ACK Puls von Kühn klarkommen und der Tran Decoder sollte sich unter 7ms halten. Auch wäre es löblich, wenn die Decoder mit einer Einstellung ausgeliefert würden, bei der der ACK Puls so nah wie möglich an 6ms angenähert ist. Ich zweifle nach dieser Versuchsreihe aber, dass dieses von der Firmware bei allen oben genannten Produkten versucht wird.

Auch lässt die Standardisierungsarbeit der NMRA, die oft in Zusammenarbeit mit den Herstellern erfolgt, noch zu wünschen übrig. Unzulänglichkeiten im Standard wie dieselbe Definition des ACK Pulses für Sender und Empfänger wären eigentlich vermeidbar. Bei Radsatz und Gleis geht es ja auch. Beim Gleis ist allerdings die Einhaltung des Standards leicht zu überprüfen, eine Radsatzlehre ist billiger als ein Oszilloskop. Da dem Konsumenten eine Überprüfung nicht zugemutet werden kann, ist die Verantwortung des Herstellers recht groß, wenn er seine Produkte mit dem DCC Logo oder Bezeichnungen wie "Voll NMRA-kompatibel" anbietet.

Da das Verhalten des Decoders zu einem großen Teil von der Softwareversion abhängt, wäre es den Decoderherstellern zu empfehlen, die Versionsinformation inklusive aller Unterversionen gut lesbar auszuführen. Entweder durch die Verwendung des dafür genormten CV, oder wenn die Auflösung von 255 Versionen nicht reicht, durch die Anwendung einer anderen firmenspezifischen CV. Auch ein Aufkleber mit der Versionsnummer (entweder auf dem Decoder oder dessen Verpackung) wäre zu begrüßen. Dies wäre sicherlich auch in der Kommunikation zwischen Endverbraucher und Support des Herstellers anwendbar.

Diskussion

Im Forum 1zu160 kann man hier einen Kommentar abgeben

Dank

... Heinrich O. Maile für den Testkandidaten DHP160.

... Magnus D. für Oszilloskop und Knöpfchendrücken auf demselben:

Document version $Id: index.html,v 1.5 2010/10/15 15:36:40 haba Exp $