OpenDecoder - für DCC

OpenDCC OpenDecoder - FAQ

FAQ - häufige Fragen

Der Decoder blinkt .. was bedeutet das?
Mit Hilfe der LED wird ein interner Zustand des Decoders angezeigt. Dabei wechseln sich eine Reihe schneller Pulse mit einer Pause ab. Es gibt folgende Blinkcodes:

1	----x----x----	Weiche 1 hat nicht korrekt geschaltet.
2	----x-x----x-x----	Weiche 2 hat nicht korrekt geschaltet.
3	----x-x-x----x-x-x---	Weiche 3 hat nicht korrekt geschaltet.
4	----x-x-x-x----x-x-x-x---	Weiche 4 hat nicht korrekt geschaltet.
5	----x-x-x-x-x----x-x-x-x-x---	Es wurde noch keine Adresse programmiert. Das ist der normale Zustand nach dem Laden der Firmware bzw. nach einem Decoder-Reset.
6	----x-x-x-x-x-x----	Falscher Mode, der gewählte Mode wird von der geladenen Firmware nicht unterstützt. (also z.B. wenn beim ServoDecoder DMX gewählt wird).
X	-\|-\|-\|-\|-xxxxx	sehr schnelles Blinken: es werden intern gerade Werte umkopiert, z.B. nach einem Preset oder Reset-Befehl. Dabei darf der Decoder nie stromlos geschaltet werden.

Ich habe die Adresse mit CVs eingestellt und kann den Decoder nicht mehr ansprechen.
Es gibt einen Unterschied zwischen Decoderadresse und Weichenadresse. Wenn man über Taster programmiert, dann gibt man an der Zentrale die Weichenadresse an. Bei Programmierung über CV (CV513 und CV521) wird jedoch die Decoderadresse eingestellt.
Dieser Unterschied (welcher aus der DCC Norm resultiert) ist beim Schaltdecoder erläutert.
Auf der Seite CV ist ein CV-Rechner, der das umrechnet.
Ich habe die Adresse mittels CV513 umprogrammiert, warum blinkt aber die LED trotzdem weiter (5x)?
Das liegt an einem 'versteckten' Bit in der CV521; CV521 ist der zweite Teil der Adresse, jedoch werden nicht alle Bits benötigt. In einem dieser unbenutzten Bits ist bei unprogrammiertem Decoder eine '1' hinterlegt. Wenn dieses Bit gefunden wird, dann blinkt der Decoder (5x), um anzuzeigen, dass noch keine Adressprogrammierung erfolgt ist. Wird die Adresse komplett geschrieben (entweder mit Taste oder durch Programmieren mit CV513 und CV521), dann blinkt der Decoder auch nicht mehr.
Ich verstehe das mit der Digitaladresse nicht, was ist denn nun was?
Die DCC Norm kann bis zu 511 Zubehördecoder ansprechen, von denen kann jeder 8 Ausgänge haben, diese sind ein- oder ausschaltbar. Soweit die Theorie.

Häufig werden nun zwei dieser Ausgänge paarweise gekoppelt, um z.B. eine Weiche zu schalten. Hierzu ist es erforderlich, dass sich diese beiden Ausgänge gegenseitig abschalten (sonst kracht es in der Weiche). Zudem schalten die Decoder sicherheitshalber einen aktivierten Ausgang selbständig nach einer gewissen Zeit ab, um ein Durchbrennen der Spule zu verhindern.

Dies hat zwei Folgen: Viele Bediengeräte (und auch PC-Steuerprogramme) fassen diese zwei Ausgänge zu einer neuen Adresse (Weichenadresse) zusammen. Man spricht das Ausgangspaar also nicht mehr über den Deocder und eine Untergruppe an, sondern direkt über die 'Weiche' und hat dann 2046 mögliche Adressen. Und da die Dekoder selbständig abschalten, wird auch der Abschaltbefehl stiefmütterlich behandelt - z.B. sendet die IB den Abschaltbefehl gar nicht.

Als weitere Folge ergibt sich für Decoder, welche einen einzelnen Ausgang ein- oder ausschalten wollen, dass sie dies nicht zuverlässig über den Ausgangsschaltbefehl von DCC abbilden können. Das wird dann oft mit zwei 'Ein'schaltbefehle realisiert, die sich gegenseitig wie bei einer Weiche abschalten.
Damit ist man (als Decoder) dann über übliche Zentralen und PC Programme bedienbar.
Ich verwende 4N25 als Optokoppler, es geht nichts.
Der 4N25 ist wirklich langsam und braucht auch relativ viel Strom, um wieder abzuschalten. Hier muß der Pullup recht klein gewählt werden (etwa 1k).
Gibt es fertig programmierte Prozessoren für OpenDecoder2 und 3?
Leider nein, zumindest bei mir nicht - die SMDs kann ich nur eingelötet programmieren und das kann ich leider nicht für andere machen.
Der Decoder ist so komplex, wie kann ich den einfach konfigurieren?
Es sind i.d.R. sinnvolle Voreinstellungen vorhanden, die einfach mit Tasterdruck und Senden eines Weichenbefehls gewählt werden. Diese Voreinstellung passen im allgemeinen. Sollte es spezieller werden, so kann man mit einem der folgenden Programme ein mehr oder weniger ausgefeilte Oberfläche für die Konfiguration verwenden:
- P.F.u.Sch.: Shareware
- rocrail: Open Source, Support wird sukzessive ausgebaut.
- Trainprogrammer: Es gibt meist ein .yrc-file für die jeweilige OpenDecoder-Software, dieses File läßt sich in die Dekoderdatenbank von Trainprogrammer importieren. Damit ist dann menügeführte Programmierung möglich.
Die Servos gehen nur in einem Bereich von 0-45°. Was könnte da falsch laufen?
Das liegt an den Servos. Leider halten sich manche Hersteller nicht an die 1ms bis 2ms Ansteuerbereich. Deswegen gibt es ab der Version 0.9 in der Software ein CV-Bit 'extended range', da wird der Stellbereich auf 0.5ms bis 2.5ms ausgedehnt. (CV555 bzw. CV567).
Ich habe bei nur den Digitalstrom, keine extra Versorgung, was muß ich tun?
Hier kann man einfach zwischen DCC-Eingang und Power eine Brücke legen. Auch der Lade-Elko sollte verkleinert werden, damit der Anlaufstrom des Digitalsystems nicht so groß wird.
Das Auslesen mit der Intellibox dauert so lang!
Tja, das liegt an der IB. Die sucht nämlich bei jeder CV alle möglichen Datenworte (bis zu 256) ab und das dauert beim Lesen vieler CVs halt seine Zeit.
Die OpenDCC-Zentrale geht da intelligenter vor: Zuerst mal wird der Dekoder auf 'Bit'fähigkeit getestet und dann mit nur 8 Abfragen das Datum bestimmt. Und die Zentrale merkt sich diese Fähigkeit des Decoders für etwa 0,5s, der nächste Lesebefehl muß dann gar keine Bitfähigkeit mehr testen.
PoM Programmieren mit dem TwinCenter funktioniert nicht!
Das TwinCenter verwendet eine veraltete Form des PoM Befehles (siehe RP921, Appendix A).
Ich möchte den Code oder Teile davon für ein eigenes Projekt verwenden, was muß ich beachten?
OpenDecoder ist keine freeware, sondern unterliegt einer Lizenz (gnu). Diese erlaubt die private Nutzung, bei kommerzieller Nutzung bzw. Weiterentwicklung sind die Lizenzbedingungen zu beachten. Ich vergebe auch Lizenzen an kommerzielle Anbieter. Source Code ist entweder auf dieser Seite oder unter sourceforge.net verfügbar.
Ich habe die eagle Datei geladen, nur sind bei mir Linien in Ausdruck, die Kurzschluß verursachen!
Das ist eine Eigenheit von eagle. Masseflächen werden nur als Umriß in der Datei gespeichert und müssen nach dem Öffnen wieder neu berechnet werden. Hierzu muß man den Befehl 'Luftlinien neu berechnen' (Ratsnest) aufrufen.
Ich möchte selbst übersetzen, was ist denn nun welcher Sourcecode?
Bei OpenDecoder2 ist die Software in Module aufgeteilt, diese sind alle in einem Projekt enthalten. Durch die Compile-Switches in config.h wird dann die zu erzeugende Variante ausgewählt, man muß einfach die entsprechende Variable (z.B. SERVO_ENABLED) auf TRUE stellen. Leider passen nicht alle Softwarevarianten zugleich in den Atmega8515, man muß sich also entscheiden, ob man Standarddecoder, Servodecoder oder DMX Decoder will.
Eine Sonderposition nimmt der Signaldecoder2 ein: hier war leider eine grundlegende Änderung der Interrupts erforderlich, so dass diese Software ein eigenes Projekt ist.
Ich habe beim Programmieren der Fuses erreicht, daß der Prozessor nicht mehr erkannt wird.
Vorsicht Falle! Wenn man den Atmel auf externen Takt stellt, und da ist keine Quelle oder nur ein Quarz angeschlossen, dann geht gar nichts mehr. Lösen kann man das nur, wenn man bei XTAL1 eine (ziemlich) beliebige Frequenz von etwa 100kHz bis 10MHz einspeist. Dann lassen sich auch die Fuses wieder umprogrammieren und der Prozessor lebt wieder.
Ich habe den Prozessor falsch bestückt, wie kann ich den wieder auslöten?
Wenn man kein professionelles Werkzeug hat, kann folgender Trick angewandt werden: man fädelt dünnen Lackdraht unter den Pins einer Seite durch und fixiert ein Ende des Drahtes. Nun zieht man beginnend beim anderen Ende den Draht nach außen, wobei man gleichzeitig mit den Lötkolben die Pins erwärmt. So wird eine Anschlußseite wie ein Reißverschluß geöffnet. Der Baustein sowie die Platine nimmt dabei keinen Schaden.
Meine Roco-Weichenantriebe schalten manchmal nicht, was ist da los?
Roco Weichenantriebe sind nicht gerade berühmt für ihre Zuverlässigkeit. Zudem liegt ihr Strombedarf an der oberen Grenze der ULN2803 Treiber. Darüber hinaus streuen die Antriebs zeimlich in notwendigen Spannung zum Schalten - ich habe bei Kontrollen schon Ansprechspannungen von 7V bis zu 15V gemessen.
Abhilfen:
- eine Verdopplung des ULN2803 (einfach einen zweiten Chip Huckepack drauflöten) bringt mehr Ausgangsstrom.
- Die Sicherung auf 0,8A bis 1A erhöhen.
- Versorgung des Decoders mit 16V~ oder 18-20V=.
Die manuelle Justage am Servodecoder funktioniert irgendwie nicht richtig, nur gelegentlich kommt ein kleiner Schritt. Warum?
Die manuelle Justage verfährt bei jedem empfangenen Befehl um eine 'Justierschrittweite' (CV579). Und genau hier liegt das Dilemma: IB und Rocomaus 'fluten' beim Drücken der Weichentaste massiv Weichenstellbefehle auf das Gleis. OpenDCC schickt bloß 2 oder 3 - der Rest ist Bandbreitenverschwendung. Wenn das Increment zu groß ist, dann 'rennt' der Servo beim Stellen mit der Rocomaus, paßt aber recht gut zu TC und OpenDCC. Wenn es zu klein ist, geht es bei OpenDCC beim Stellen nur mühsam voran, man muß öfters Drücken.
Ich habe den Servodekoder nachgebaut, aber der stürzt dauernd ab!
Das ist ein Stromversorgungsproblem und kann bei bestimmten Servos auftreten. Der Einschaltstrom des Servos kann so groß sein, dass die 5V Versorgung des Prozessors in die Knie geht und damit einen Reset des Prozessors auslöst. Mögliche Abhilfen:
- Separate Stromversorgung des Servos
- Brownout-Spannung des Atmel etwas tiefer einstellen, der läuft stabil bis 2,7V runter.
- Puffer-Elko beim Servos