Digital Uhlenbrock Bulk-Versionen 73309 lässt sich nicht lesen/programmieren

[FB.]

gefühlt der 1000ste Beitrag das der Elektronikmüll nicht das macht was man will

-schmeisst den Krempel in die Tonne und kauft alles neu-vielleicht ist es ja noch nicht veraltet wenn die Lieferung bei euch zuhause ankommt.

 

[AG_2_67]

... kann es natürlich nicht stimmen ...

Das hat ja niemand behauptet.

Aber um das nachvollziehen zu können, hätte ich gerne mal einen konkreten Fall.
Muss aber nicht hier im Bulk-Thread sein.

 

[Woodz]

Naja - das Uhlenbrock nicht so will wie man will - kann man hier ja schon oft (ge) lesen (haben).
Auch meine Erfahrung - mit DCCEX Zentrale konnte ich meinen einzigen (aus einer Tillig Lok) Uhlenbrock Decoder auch nicht verlässlich lesen und programmieren. Da werkelt jetzt ein Zimo drin...

 

[mzkay]

Mir hat das jetzt keine Ruhe gelassen und ich habe einen Uhlenbrock Decoder, welchen ich schon abgeschrieben habe vorgekramt. Lies sich auch nicht auslesen. Weder mit Klug, nicht mit ESU nicht mit Daisy2 Zentrale usw
CV8 mit 0 und 8 brachte auch keine Änderung.
Letztendlich habe ich nochmals mit der Daisy2 die Programmiersperre CV 15 und 16 mit 1 beschrieben. Plötzlich erwachte er zum Leben.
Vielleicht schaust du nochmal genauer hin? Vielleicht hast du Glück

 

[HLeske]

An die Programmiersperre hatte ich auch gedacht, aber ging auch nicht. Nur mit dem Programmer von Massoth, zum Glück, bin ich ran gekommen. Das ist auch bei allen 3 Uhlenbrock Decodern so.

 

[Per]

Spannungshöhe

Da ist keiner drauf eingegangen, ich fände das hingegen einen interessanten Ansatz. Z.B. auch, wie die sich bei den einzelnen "Zentralen" unterscheiden.

 

[HLeske]

Beide Programmer (ESU/Massoth) werden bei mir mit dem selben 18V / 2A Netzteil mit Strom versorgt.

 

[Jan]

Es geht hier um die Qualität der Antwort, die der Decoder gibt, wenn ihn die Zentrale etwas fragt.
Die Einstellung der Empfindlichkeit des Programmiergleises (oft als Erkennungsschwelle oder "Ack-Schnittstelle" bezeichnet) hängt stark von der verwendeten Digitalzentrale ab. Da Zentralen beim Auslesen oder Beschreiben von DCC- oder MM-Decodern auf die Stromquittung (den "Ack-Impuls" der Lok) angewiesen sind, kann eine zu geringe oder zu hohe Empfindlichkeit dazu führen, dass Decoder nicht erkannt werden.

 

[HLeske]

Das war bei allen fehlgeschlagenen Versuchen (lesen/Schreiben) das Problem, es gab keine Reaktion vom Dekoder auf den Motor

 

[mzkay]

Es geht hier um die Qualität der Antwort, die der Decoder gibt, wenn ihn die Zentrale etwas fragt.
Die Einstellung der Empfindlichkeit des Programmiergleises (oft als Erkennungsschwelle oder "Ack-Schnittstelle" bezeichnet) hängt stark von der verwendeten Digitalzentrale ab. Da Zentralen beim Auslesen oder Beschreiben von DCC- oder MM-Decodern auf die Stromquittung (den "Ack-Impuls" der Lok) angewiesen sind, kann eine zu geringe oder zu hohe Empfindlichkeit dazu führen, dass Decoder nicht erkannt werden.

Spinnen wir den Faden einmal weiter. Ich nehme mal an, daß es an den Zentralen keine Einstellmöglichkeiten für die Impulsstärke (ack) gibt.
Die Anschlussplatine von ESU frisst wahrscheinlich auch einiges an Übertragungsqualität weg.
Die Kabel von Zentrale, bzw. Programmiergerät sollten kurz und von guter Qualität sein
Wird auf einem Gleis programmiert, dann kein Analoggleis (Widerstand) und sauber
Keine Loks mit Pufferspeicher
Evtl. Eine alte Lokplatine zum Programmieren nutzen. Nur einen Motor und ein Lämpchen anschließen, Kabel direkt zur Zentrale bzw Programer.

Das wären erstmal meine ersten Gedanken. Es gibt mit Sicherheit noch mehr zu beachten.

 

[ateshci]

Nachdem ich sämtliche Generationen von Uhlenbrockdecodern programmiert und eingesetzt habe, meine Erfahrungen damit. Es gab (selten) Chargen, die nicht so arbeiteten wie sie sollten. Die zu ersetzen war aber auch kein Problem. Alles was ich hatte, ließ und lässt sich immer mit der IB oder der Märklin-Gleisbox programmieren. Hartnäckige Fälle mit der IB, da man dort die ACK-Zeit und die Schwelle in den Sonderoptionen variieren kann. Diese haben aber nie ihre Ursache im Decoder, sonderen mit den elektrischen und mechanischen Konstanten der Lok. Deshalb kann ich nur unterstreichen, was @mzkay schreibt - macht Euch ein Testbrett mit einem Motor drauf, evtl noch zwei LEDs für den Beleuchtungs/Richtungstest, und programmiert dort die Grundeinstellungen. Erspart viel Frust und voreilige Schuldzuweisungen.

 

[F-Rob_S]

@HLeske

Ich hatte in der Vergangenheit auch mal 2 Uhlenbrock-Decoder (in diesem Fall Uhlenbrock IntelliDrive Comfort Mini), die sich mit einer Lenz-Compact-Zentrale nicht programmieren ließen. Ursache war wohl tatsächlich die Ausführung des Programmierausganges bzw. die Ausgangsspannung des Compact. Alle sogenannten Tipps (Widerstand parallel zum Gleis, zusätzliche Lok aufs Gleis usw. usf.) brachten keinen Erfolg.

Ich habe die Decoder dann mit anderer Hardware (also mit einer anderen Zentrale) programmiert. Mit dem Lenz Compact war nichts zu machen! Die Ursache geht vermutlich eher in die Richtung, die Jan in #20 angegeben hat!

Nimm andere Hardware zum Programmieren oder andere Decoder.

 

[AG_2_67]

Glaub es oder lass es

Was ich glaube, spielt ja keine Rolle. Mich interessieren Fakten, also konkrete Probleme bei einer der nachfolgenden Konstellationen

Z21 + ESU-Tester + Fremddecoder = Fehler oder Mist
Z21 + ZIMO-Tester + Fremddecoder = funktioniert

MXULF + ESU-Tester + Fremddecoder = Fehler oder Mist
MXULF + ZIMO-Tester + Fremddecoder = funktioniert

LokProgrammer + ESU-Tester + Fremddecoder = Mist oder Fehler beim Auslesen
LokProgrammer + ZIMO-Tester + Fremddecoder = Mist oder Fehler beim Auslesen

Und das belegt nun, dass ESU da was im Prüfstand eingebaut hat, das dies verhindert?

... oder Sound hochladen (Fehler)

Das wird ja auch nur in der "eigenen" Umgebung funktionieren. Das weißt du aber.

 

[mzkay]

Die Aufzählung von Alex kann ich aber bestätigen.
Auf den Punkt gebracht, mit etwas Übertreibung. Die Lokdecoder von Uhlenbrock lassen sich nur sicher mit Uhlenbrock Zentralen oder dem Programmer von Uhlenbrock programmieren.

 

[tokaalex]

Das wird ja auch nur in der "eigenen" Umgebung funktionieren. Das weißt du aber.

Mensch Siggi,
wie ich bereits geschrieben hatte, funzt es mit dem ZIMO-Tester auch in "fremder" Umgebung und nicht nur in der "eigenen! Den Umkehrschluss mit dem ESU-Zeugs bekommst du sicher selbst hin...

Vielleicht sollte ich zu meiner obigen Auflistung noch ergänzen:

LokProgrammer + ZIMO-Tester + ESU-Decoder = funktioniert
irgendeine Zentrale + ZIMO-Tester + irgendeinen Decoder = funktioniert

... und nu mach mit den "Fakten", was du willst. 👀

 

[HLeske]

Hallo Alex,
du schreibst
Z21 + ESU-Tester + Fremddecoder = Fehler oder Mist
Das ist definitiv falsch.
Ich kann bis auf den jetzigen Uhlenbrock alle anderen Decoder lesen und schreiben und sogar Soundprojekte auf die Deoder bringen.

Hier mal eine Liste was bei mir so Funktioniert: ESU, Massoth, Lenz, Zimo, Digitrax, Kühn, Tams, Piko und alle Onborddecoder von Piko, LGB, Märklin
Schreib hier lieber welcher Fremddecoder ärger mach.

 

[AG_2_67]

... funzt es mit dem ZIMO-Tester auch in "fremder" Umgebung ...

Es geht nicht um den Tester beim Sound.

Für ESU Sound-Projekte brauchst du den Programmer, für Zimo-Projekte das Zimo-Zeugs.

irgendeine Zentrale + ZIMO-Tester + irgendeinen Decoder = funktioniert

CV-weise ja. Soll ja auch so sein