THEMA: Mischbetrieb DR5000 & LDT & Decoderwerk gescheitert?

Hallo Frank,

schalte mal versuchsweise Railcom ab. Sollte zwar nach https://www.1zu160.net/scripte/forum/forum_show.php?id=1067853#aw8 funktionieren, aber Versuch macht kluch.

Grüße
Zwengelmann

Servus,



Vielleicht habe ich auch was übersehen,  aber:

Für mich klingt das eher danach,  als würden die LDTs nicht so ganz sauber arbeiten? Also zwar robust,  aber stören dann heftig?

Grüßle

MiScha

Hallo zusammen,

lieber Frank, wir standen ja im Austausch zu Deinen Experimenten. Ich möchte ein paar Sachen ergänzen.


"Das passt recht gut m. M. n. irgendwie zum Decoderwerkphänomen."

In den Decodern werden die erwähnten Optokoppler nicht eingesetzt. Auch ein Brown-Out-Effekt ist bei den eingesetzten Mikrocontrollern nicht möglich. In dem Artikel wird eine komplett andere Eigenentwicklung beschrieben die keinen Bezug zum Decoderwerk hat.


"Beim Decoderwerk muss ich das Kabel manuell drehen, bei Polartitätswechsel des DCC Eingangs / Ausgangs."

Ich hab Dir ein Video dazu geschickt, in dem zu sehen ist, das der Decoder funktioniert, egal wie rum das DCC Signal angeschlossen ist.


"Der MOTOR Vierfach verträgt kein Wechselstrom. Dann schaltet er auch im Solobetrieb nicht die Weichen."

Auch hierzu hast Du ein Video, in dem die Decoder mit Wechselstrom aus einem Conrad-Trafo problemlos schalten.


"Dann gibt es desweiteren den Knackpunkt stabile Steuerspannung für IC Schaltungen (5 Volt)."

Der Mikocontroller arbeitet gar nicht mit 5V, wie kommst Du darauf?


"Bliebe auch die Frage offen, ob sich MM und DCC in einem Decoderwerk vereint vertragen."

Ja, tun sie. Schalte einfach mal mit MM und mal mit DCC, zb an einer Z21 oder einer MS2. Geht problemlos.


"Nachtrag: die LED wird, wenn man ihn nur mal solo rein mit DCC Strom versorgt beim Schalten deutlich sichtbar etwas dunkler für einen kurzen Moment. Deutet auf Spannnungsschwankung hin. Und damit ein Nachweis eines labilen Stabilitätsfaktorelements in der Schaltung. Stichwort Stützkondensatoren und Tarnsistoren."

Ohne jetzt die Lichtstärke objektiv gemessen zu haben (ich kann da subjektiv nichts feststellen): Wenn eine Last von über 1A oder mehr geschaltet wird, eventuell über fast eine Sekunde bei einem Motorantrieb, hast Du immer eine Spannungsschwankung. Kein Decoder puffert 1A für vielleicht 16V für auch nur 200ms. Das hat auch nichts mit Transistoren zu tun.


"Ein Mischbetrieb von Decoderwerk Hardware und Littfinski Datentechnik an einer DR5000 Zentrale funktioniert leider nicht. Die Decoderwerk Hardware versagt dann den Dienst. Das DCC Bussignal schwimmt in einem sog. Signalrauschen."

Ein Decoder liest das Signal aus und verändert das Signal nicht. D.h. ein Decoder weiß nicht welche anderen Decoder noch am "Bus" lauschen. Wie sollte das dann einen anderen Decoder beeinflussen? Ich habe keinen LDT-Decoder da, werde mir aber bei Gelegenheit mal einen zum Test besorgen. Derzeit kommt mir auch theoretisch kein Grund in den Sinn, wie das von Dir dargestellte Szenario vorkommen sollte.


Ich kann nicht genau nachvollziehen, was Du wie angeschlossen hast. Aber alle Überprüfungen all Deiner Hinweise haben ergeben, das die Decoder so arbeiten, wie sie sollen, was ich Dir auch als Video zugesandt habe.

Ich danke Dir für Deine Tests und Deinen Einsatz und wünsche Euch allen noch schöne Weihnachtstage!

Gruß
Noah

Folks!
Nur zur Klarstellung ein "brown out" Problem haben die Decoder nicht sondern nur schlechten Code der, warum auch immer, den EEPROM umnietet. Die "brown out" Technik macht folgendes: der Prozessor speichert Daten im RAM. Nach dem Wideranlaufen nach einem Versorgungsaussetzer schaut der Prozessor  da nach ob Daten drin sind - im RAM! Der wird von einem Stützkondensatir gepuffert da reichen 22-47µF aus für 2-5 Sekunden. Wenn ja nimmt er diese Zustandsdaten und macht damit weiter. Man muß daher regelmäßig das was man retten will (bei Decodern Zustand der Ausgänge, Fahrtrichtung, Geschwindigkeit udglm.) abspeichern und mit einer Plausibilitätsprüfung versehen. Wenn nun ein Decoder nach einem Versorgungsaussetzer aufwacht soll er nachsehen gehen ob Daten im RAM sind und ob das plausibel ist. wenn ja diese Werte benutzen andernfalls von 0 weg starten und drauf warten was vom Gleis an Infos daher kommt. Das dauert im schlimmsten Fall einige Sekunden. In der Zeit darf der Decoder dann nix tun. Die Auswirkung einer fehlenden brown out Technik kann man an Lenz Decodern schön sehen.

Das Lesen oder gar Beschreiben des EEPROMs dauert einfach superextrem lange, allein schon deshalb ungeeignet um Betriebsdaten zu sichern. Weiters kann man einen EEPROM, als auch einen FLASH, nur wenige male verändern. Je nach Technologie 10Tausend oder 1Million mal. Wenn man das für brown out zwecke schreiben würde wäre der Speicher vermutlich nach einigen Tagen hinüber.

Bei Decodern muß man nach einem unzulässigen Absinken der Spannung halt sauber dafür sorgen daß er neu startet. Meinen Erfahrungen nach reicht aber ein klug positioniertes RC Glied am RESET Eingang aus.
-AH-

Hallo Arnold,

Jupp, das ist soweit richtig. Nur haben moderne Mikrocontroller eingebaute Under voltage und Brown Out Detektion und führen in dem Fall automatisch einen sauberen reset mit neuinitialisierung aus. Was auch von unseren Decodern so umgesetzt ist.

Gruß
Noah

Hallo,

bei mir funktioniert alles in der gleichen Kombination, wie von ELNA5 in #0 beschrieben, und zwar einwandfrei. Vielleicht hat einer seiner Littfinskis einen Defekt. Auf jeden Fall sind die meisten seiner hier getroffenen Aussagen so nicht korrekt und auf gar keinen Fall zu verallgemeinern. In meinen Augen sind das schon geschäftsschädigende Aussagen. Nur weil es bei einem nicht funktioniert...

Gruß
Kolomna