Die Platzhirsche gehen da einfach nach dem Gleichrichter und vor dem LDO ran, was elektronisch größter Schwachsinn ist. Die Pufferkondensatoren sollen nicht den Spannungsregler "stützen", sondern den Mikrocontroller bei Stromausfall am Leben halten und verhindern, dass dieser in den Brownout oder Reset geht.
Naja, so komplett schwachsinnig find ich das nicht. Vor dem LDO hängen meist auch die verstärkten Ausgänge für die Beleuchtung. Und ich will, dass diese beim Fahren nicht flackert. Weiterhin hängt an dieser Versorgungsspannung auch manchmal ein SUSI-Modul. Und bei diesem soll der µC ebenfalls vor einem Spannungsabfall geschützt werden. Besonders bei Soundmodulen klingt das nicht schön.
Und fast noch wichtiger, der Speicher dient auch als elektronische Schwungmasse. Was bringt es mir, wenn der µC noch lebt, aber der Motor das Fahrzeug nicht vom Kunststoffherzstück herrunterfahren kann? (Stichwort ASF)
Gerade diese dämliche Bitschubbserei in den CV's ist bei dem C-Digitalsystem wesentlich besser gelöst. Für die Standardfunktionen brauche ich keinerlei "CV's" zu bearbeiten. Auch für die Motorenansteuerungsoptimierung gibt es ein Einmessprogramm, was die notwendigen Variablen selbst setzt. Also genau das, was ein "Einsteiger" sucht.
Es wirkt auf mich "besser" gelöst, weil es sehr viel weniger Einstellmöglichkeiten gibt. Bei wenigen Dutzend CV/ Registern mit entsprechend wenig Optionen ist es naturgemäß übersichtlicher. Mit CV-Nummern und CV-Werten darf man sich trotzdem herumschlagen, nur die Addition der Bits entfällt. Eine automatische Einmessfunktion haben meines Wissens ESU-Decoder.
Wenn aus den "Einsteigern" später "Fortgeschrittene" werden, kann man sich immer noch mit den vielfältigen und tiefergehenden Decoderoptionen, so fern vorhanden, beschäftigen. Ich schalte gerne das Schlußlicht zwischen Lok und
Wagen ab. Rangierlicht ist auch eine schöne Spielerei.
Ich nutze Decoder Pro von JMRI um meine Decoder via PC zu konfigurieren. Ich habe tatsächlich auch keine Lust auf Bitschubsen. Tastatur, Maus und Monitor sind doch entspannter als ein Mäusekino.
Ich sehe nicht den Anwendungszweck, ein ASF, welches sich zu 99,9% im BW bewegt, zu digitalisieren.
Gut, das ASF-Beispiel war zugegebenermaßen etwas gemein. Ich hatte gelesen, dass ASF nicht nur in BWs, sondern auch auf
Gleisanschlüssen anzutreffen waren.
Eine Kö war dann schon im gesamten
Bahnhof unterwegs und eine preußische T3 durfte auch auf die Strecke.
es spart die Kosten für eine Traincontroller-Lizenz oder ähnliche Software, die total unrealistische Fahrszenarien per Zufallsprinzip generiert, wenn man nicht 1000 Stunden Konfiguration der Software investiert.
Soweit ich es nicht übersehen habe, scheint mir das C-Digitalsystem nicht digital schalten zu können, weshalb der Vergleich mit Traincontroller etwas hinkt.
Zeit frisst am Ende jeder Aufbau einer (Voll-)Automatisierung, egal welches System.
Was ich gut finde, der Begriff wird im Plural verwendet. Und das ist der große Vorteil von DCC, die Herstellervielfalt. Wenn ein Hersteller verschwindet, gibt es noch andere, mit deren Produkten ich mein (Decoder-)Investment weiter betreiben kann. Aktuell macht der Hersteller Massoth
Schlagzeilen.
Die
Liste der Hersteller, die sich um eine Weiterentwicklung des DCC-Protokolls bemühen, umfasst nicht nur Platzhirsche. Da sind auch einige kleinere dabei.
Wenn ich mir das C-Digitalsystem-Decoder so anschaue, sind die Entwickler ziemlich stolz auf ihre Motoransteuerung. Interessant wäre, wenn es eine Decodervariante mit DCC-Interface und ABC-Fähigkeit geben würde. Da wäre sicherlich der ein oder andere Bissen vom DCC-Kuchen dabei.
Wer mit seinem vorhandenen System zufrieden ist und dafür Komponenten bekommt, der braucht nicht wechseln. Neueinsteiger sollten bei einer Entscheidung für System X, Y oder Z auch die Verfügbarkeit in Zukunft im Blick haben. Da ist DCC mit der Normung durch die Modellbahnverbände und die Herstellervielfalt gut aufgestellt. Auch wenn das Protokoll sicherlich seine Schwächen hat. Aber Kompromisse sind des Modellbahners täglich Brot
Beste Grüße
