OpenDCC - Eine Zentrale für DCC - FAQ und Change Log

FAQ - häufige Fragen

    Es tauchen immer wieder gleiche Fragen zu OpenDCC auf, diese versuche ich hier zu sammeln und zu beantworten.

  • Was kostet OpenDCC?
    Mut und Nerven ;-)
    Im Ernst: die Platine kostet 25,90, die Bauteile etwa 30-40 Euro.
    Ich kann leider keine fertigen Zentralen bzw. Bausätze anbieten.
    Norbert Martsch hat sich bereit erklärt, Stückliste und ev. Bausätze zusammen zu stellen. Bei ihm gibt es eine ladbare Bestellliste für reichelt.de.
    Platinen gibt es entweder bei mir oder bei modellautos-h0.de.
  • Wie viele Loks kann ich mit OpenDCC fahren?
    Der integrierte Booster ist nur für 2-3 Loks ausgelegt, die Steuerlogik für max. 64 gleichzeitig fahrende Loks. Mehr ist für DCC wirklich nicht sinnvoll. Es können aber beliebig viele Loks an der Zentrale aufgerufen werden (das wird dynamisch verwaltet) - fahren tun die letzten 64. Natürlich ist diese Grenze im Sourcecode änderbar, wer will, kann auch 200 Loks fahren.
  • OpenDCC wäre ja ganz schön, aber ich wünsche mir einen Handregler!
    Es gibt eine Erweiterung für Xpressnet-Handregler (z.B. Roco® Multimaus®). Dafür wird auch eine bessere CPU benötigt: Statt Atmega32 wird Atmega644P verwendet, wichtig ist der Suffix P, nur diese CPU hat die zweite serielle Schnittstelle. Atmega644-20PU paßt nicht, es muß Atmega644P-20PU sein. (siehe auch: AVR DIL40 TQPF44 Adapter)
    Mittlerweile gibt es auch einen OpenDCC Handregler, der meiner bescheidenen Meinung nach nicht schlecht ist.
  • Ich habe eine vorhandene OpenDCC Zentrale, wie kann ich diese für Handregler aufrüsten?
    Die Erweiterung (für google: Migration, Upgrade, Aufrüstung, Tuning) ist recht einfach:
    • Ersatz der CPU Atmega32 durch eine Atmega644P (der Suffix P ist wichtig), die sonstige Hardware bleibt gleich.
    • Einbau des Xpressnet-Adapters
  • PC-Port: Kann ich mit der Option "USB+RS232 eingelötet" wahlweise eine der beiden PC-Schnittstellen durch einfaches Umjumpern nutzen?
    Ja.
  • Kann ich auch mit p50x meine Multimaus (über den Xpressnet-Adapter) weiter verwenden?
    Ja. Und man kann sogar die Lokdatenbank der Multimaus vom PC aus mit Hilfe des Configtools befüllen. Auch Funktionen der Multimaus F12 bis F20 werden unterstützt.
  • Wie kann ich meine Loks in den Handregler laden?
    Die Roco® Multimaus® bietet die Auswahl der Loks per Namen an. Dies unterstützt OpenDCC mit einer Lok-Datenbank.
  • Welches Schnittstellenprotokoll muß ich am PC wählen?
    Die verschiedenen Baugruppen einer Modellbahn-Steuerung kommunizieren mit Datenverbindungen miteinander. OpenDCC Z1 hat zwei solche Verbindungsmöglichkeiten:
    • Schnittstelle zu Handreglern: Diese Schnittstelle wird mit Xpressnet betrieben und erfordert Atmega644P und die Erweiterungsplatine.
    • Schnittstelle zum PC: Hier wird eine serielle Verbindung unterstützt (oder eine USB-Verbindung, auf der dann eine virtuelle serielle Verbindung aufgebaut wird). Auf dieser Verbindung sind zwei verschiedene logische Protokollemulationen möglich, das ist aber unabhängig von der Schnittstelle zum Handregler:
      Diese Emulation wird per geladener Software bestimmt und sowohl beim Atmega32 als auch beim Atmega644P mit [b]p50x[/b] vorbelegt. Man wählt also am PC entweder IB oder besser Tams EC. Wenn man an dieser Stelle eine Lenz-Emulation haben will, so muß man in config.h eine Variable ändern, neu übersetzen und die Box neu laden. Beide Emulationen lassen sich nicht zugleich laden.
  • Unterstützt OpenDCC Märklin®?
    Nein. Braucht der "Marktführer" Unterstützung?
    Ein Vermischen von DCC und MM würde die excellente Performance von OpenDCC beeinträchtigen.
    (Im Module dccout.c ist allerdings eine bisher nicht getestete Implementierung des MM1 und MM2 Protokolls enthalten, diese wird aber nicht vom ORGANIZER angesteuert.)
  • Unterstützt OpenDCC BiDi (railcom®)?
    Ja. Hierzu gibt es Konfigurationsvariablen:
    Mit CV25=1 wird die Austastlücke erzeugt; Zudem sind die Befehle für CV-Lesen über BiDi implementiert. Der Rückweg ist dabei nicht in OpenDCC implementiert, sondern wird über ein externes System wie z.B. den GBM16 oder Tams RC erledigt.
  • Ich habe meine s88 Rückmelder angeschlossen, aber die Anzeige flackert. Was ist falsch?
    Vermutlich ist in der Zentrale nicht die richtige Anzahl an Module je Strang eingestellt. Eine andere Ursache kann ein zu schnelles Lesetiming von OpenDCC sein - auch das ist per CV einstellbar. Alle Anbieter von S88-N Modulen sind verpflichtet, das Timing zu veröffentlichen. Bitte sprechen Sie den Anbieter darauf an.
  • Wie kann ich die Zahl der S88-Rückmeldemodule je Strang einstellen?
    Entweder beim Übersetzen, oder durch Einstellen von Spezial-Optionen. Und es gibt auch spezielle IB-Befehle. Die Zuordnung ist wie folgt:
       S88-1 = X10 / X22, "left", von vorn gesehen
       S88-2 = X8 / X23, "middle"
       S88-3 = X9 / X24, "right", von vorn gesehen
  • Wie kann man Loks programmieren?
    OpenDCC unterstützt normales Programmieren und Programmieren auf dem Hauptgleis. Zur leichteren Bedienung kann eines der folgenden Programme verwendet werden:
  • Wie kann ich zwischen Programmiergleis und Hauptgleis umschalten?
    Man kann beide Ausgänge parallel schalten (auf Polarität achten - gleiche Polung verbinden) dann kann man auf einem Gleis sowohl programmieren als auch probefahren. Hierzu bitte M- und P- verbinden, zwischen M+ und P+ (Pins 2 und 4 von X5) einen Widerstand von 10 Ohm zwischenschalten. Das Gleis wird dann an M+ und M- angeschlossen. (Der Widerstand ist nur nötig, damit die Kurzschlußerkennung nicht verfrüht anspricht).
    Achtung: nicht mit angeschlossener Anlage machen, das gibt dann ziemlich viele gleich programmierte Lokomotiven :-)
  • Warum ist OpenDCC beim Auslesen von CVs so viel schneller als meine bisherige Zentrale?
    OpenDCC hat einen recht intelligenten Algorithmus zum CV lesen und fährt auch die Programmierbefehle mit dem Minimaltiming der NMRA. Fallweise muß das verlängert werden, s.u.
  • Ich kann die Lok programmieren und auslesen, aber die Werte sind falsch und es ist auch nichts in der Lok?
    Offenbar ist die Zentrale auf Programmierung der internen CVs eingestellt. Da erfolgt normalerweise durch Tastendruck auf GO beim Einschalten. Wenn die (eigentlich nicht bestückten) Kondensatoren C37 und C38 vorhanden sind, dauert es beim Einschalten zu lange, bis die Leitung auf High geht und es wird fälschlicherweise ein Tastendruck angenommen. C37 und C38 entfernen!
  • Ich kann die Lok zwar programmieren aber nicht auslesen, was ist falsch?
    Wenn beim Lesen Timeout kommt, dann erkennt OpenDCC den ACK-Puls von der Lok nicht. Bitte folgendes kontrollieren:
    • Ist die Lok am Programmierausgang angeschlossen (Ausgang P)?
    • Ist die Stromzuführung zur Lok absolut einwandfrei?
      (Grund: Der Quittungspuls für das Lesen wird durch eine Stromerhöhung von mind. 60mA gemacht - die Decoder erzeugen diese Stromerhöhung durch 6ms langes Einschalten des Motors. Dadurch bewegt sich die Lok auch ein wenig und kann fallweise Kontaktprobleme haben.)
    • Ist die Lok mit einem Faulhabermotor ausgerüstet? Diese brauchen sehr wenig Strom, so dass die notwendige Stromerhöhung nicht zustande kommt. Hier kann eine Verkleinerung des Widerstandes R22 von 13k auf 12k die Empfindlichkeit erhöhen. Diese Empfindlichkeitserhöhung ist auch sinnvoll bei Spur N. Ansonsten muß in der Lok ein Lastwiderstand parallel zum Motor (während des Programmierens) eingebaut werden.
    • Kann der Decoder die gewählte Programmierart?
      Hier kann es speziell bei älteren Decodern Probleme geben, diese können manchmal noch nicht 'DCC byteweise' oder Bitbefehle. Bitte bei solchen Decodern (z.B. Lenz LE200) auch darauf achten, dass das Hostprogramm entsprechend konfiguriert ist und 'Register'-Befehle absetzt.
    • Hilft fallweise ein langsameres Lesetiming?
      Mittels zweier Sonderoptionen (18 und 19) kann die Zugriffsgeschwindigkeit von OpenDCC auf CV's reduziert werden.
    • Ist die u.g. Hardwareänderung durchgeführt? (nur für alte Platinen)
  • Wie muss ich OpenDCC anschließen?
    Auf der Seite Anlagenverdrahtung habe ich wichtige Hinweise und Schaltbilder für den Anschluß bereitgestellt.
  • Brauche ich die Optokoppler?
    Hängt von der Applikation ab: OK1 ist ein allgemeiner Ausgang, OK2 ist ein allgemeiner Eingang. Es gibt bis jetzt zwei Anwendungen:
      - OK2 wird für die echte Rückmeldung der Weichenlage verwendet.
      - Beide OK werden bei externem Halt verwendet.
    Wenn man das nicht will, kann man die OC problemlos weglassen.
  • Mit welchen Programmen funktioniert OpenDCC?
    OpenDCC unterstützt Lenz und Intellibox bzw. Tams EC-Emulation. Dies ist weitgehend kompatibel, kann und will aber nicht alle Fälle abdecken. Z.B. sind Multitraktionsbefehle nicht vorhanden, da bisher kein PC-Progamm diese nutzt.

    Da kommerzielle Softwarehersteller sich am Markt orientieren (da spielen Selbstbausysteme nur eine geringe Rolle), nehmen sie naturgemäß auch keine Rücksicht auf diese Systeme. Es kann daher sein, dass eine neue Version eines Steuerprogramms ev. neue Befehle verwendet, welche in OpenDCC (noch) nicht implementiert sind. Daher gelten die Tests logischerweise immer nur für den status quo der angesprochenen Software. Aus den erfolgten Tests ist auch keine Präferenz für eine bestimmte Steuersoftware abzuleiten.

    Die Abneigung gegen ev. missliebige Zentralen geht sogar so weit, dass man sich explizit vorbehält, ohne nachvollziehbare Gründe nicht näher genannte Digitalsysteme zu blockieren (wer kann eigentlich als Käufer so eine AGB guten Gewissens unterschreiben?). Umgekehrt behalte ich mir vor, die Steuerung durch bestimmte Softwaresysteme zu unterbinden. Auch kann mein Support für eine bestimmte PC-Software wegen eventueller problematischer Lizenzbedingungen oder mangelnder Zusammenarbeit mit dem Programmanbieter eingestellt werden.

    Bisher wurde OpenDCC mit folgenden Programmen erfolgreich getestet:
    • srcpd und spdrs60 (Open Source)
    • TrackOne (Open Source)
    • Rocrail (Open Source)
    • Traincontroller 5.8 (Support für TC 7.0 nur teilweise, wegen fehlender Informationen vom Programmanbieter) (Kommerziell)
    • railware (Kommerziell)
    • Umgekehrt bietet OpenDCC auch schon viele Eigenschaften, welche über die Fähigkeiten käuflicher Zentralen hinausgehen (z.B. Lokdaten-Download, Lokbilderzuordnung, Modellbahn-Uhrzeit, Weichenrückmeldung, erweiterte Zubehörbefehle, Remote-Konfiguration). Dies wird z.Z. am besten von rocrail unterstützt. Besonders gut ist die Konfiguration von OpenDCC in rocrail gelöst, dort gibt es direkte Einstellmenüs für OpenDCC.
  • Meine Loks beschleunigen und bremsen unter Traincontroller 8 sprunghaft!
    Wenn über OpenDCC und das Protokoll p50x Rückmelder in Traincontroller eingelesen werden, kann es ab einer bestimmten Menge an Rückmeldern Probleme bei der internen Verarbeitung in Traincontroller geben. Als Folge werden Fahrbefehle nur verzögert an das Digitalsystem übermittelt. Das gilt auch, wenn 'Fahren' und 'Melden' auf zwei verschiedenen Digitalsystemen implementiert sind. TC8 kommt offenbar nicht mit schnellen Reaktionszeiten des Digitalsystems zurecht. Abhilfe schafft eine künstliche Verlangsamung der OpenDCC-Zentrale Z1. Für näherere Einzelheiten siehe Forum.
  • Ich möchte den Code oder Teile davon für ein eigenes Projekt verwenden, was muß ich beachten?
    OpenDCC ist keine freeware, sondern unterliegt einer Lizenz (gnu). Diese erlaubt die private Nutzung, bei kommerzieller Nutzung bzw. Weiterentwicklung sind die Lizenzbedingungen zu beachten. Source Code ist entweder auf dieser Seite oder unter sourceforge.net verfügbar. Wenn ein Passwort erforderlich ist, bitte ich dieses unter Angabe des Namens und der Adresse per mail zu erfragen.
  • Ich möchte nachbauen, habe aber ein bestimmtes Bauelement nicht?
    • Frage zu IC7: Vorgabe: 74AC244N. Diesen hat Reichelt nicht, ist auch 74HC244 möglich?
      An dieser Stelle geht im Prinzip jeder 244er; AC habe wegen der brachialen Treiberleistung genommen, der HC ist aber auch nicht schlecht; um die Pegel möglichst in der Mitte zu treffen, sollte es ein HC oder AC (kein ACT oder HCT) sein.
    • L6206N (Zweifacher H-Brücken-Treiber im PDIP24 Gehäuse) habe ich nicht.
      Der L6203 paßt nicht; Zur Not kann man den Booster mit L6203 extra aufbauen und nur die DCC-Leitung vom Prozessor adaptieren.
      Offenbar ist der L6206 nicht ganz leicht zu bekommen - fallweise per mail bei mir melden. (Ich habe einen kleinen Vorrat.)
  • Ich kann den Bootloader nicht laden.
    Zuerst in ponyprog den richtigen Prozessor einstellen, dann das File laden. Der Bootloader beginnt erst bei Hex 7800, es schaut daher im ersten Moment so aus, als wenn nichts passiert wäre - aber einfach mal auf 7800 runterscrollen, dann sieht man den Bootloader.
    Leider unterstützt ponyprog bis jetzt (Sept. 2008) den Atmega644P nicht. (Ich habe eine gepatchte Version von Ponyprog, welche den 644P unterstützt, bitte per mail anfragen).
      Es geht auch mit dem Ponyprog-Seriell Adapter und AVRDUDE (auch unter Linux):
    • Setzen der Fuses mit avrdude:
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U lfuse:w:0xD7:m
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U hfuse:w:0x9C:m
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -u -U efuse:w:0xFC:m
    • Kontrollieren der Fuses mit avrdude:
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U lfuse:r:-:i
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U hfuse:r:-:i
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U efuse:r:-:i
    • Dann den Bootloader einspielen (nur flash):
         avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:bootloader.hex:i
    • Optional: OpenDCC einspielen (flash und eeprom):
         avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:OpenDCC_XP.hex:i -U eeprom:w:OpenDCC_XP.eep:i

    • Für das Microsoft Betriebssystem muss man nur /dev/ttyS0 mit comX ersetzen.
      Alle späteren Updates sind dann über USB mit avrosp.exe möglich (bzw. mit der update_opendcc.bat).
  • Was muß ich bei AVRDUDE beachten?
    AVRDUDE kann mit einem seriellen Ponyprog-Adapter zusammenarbeiten. Der auf lancos.com gezeichnete Adapter invertiert Reset. Sollte der verwendete Adapter die Resetleitung nicht invertieren, wie es z.B. der 'Notadapter' auf der OpenDCC-Platine macht, dann ist vorher folgende Änderung in avrdude.conf durchzuführen:
    orginal:programmer
      id = "ponyser";
      desc = "design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts";
      type = serbb;
      reset = ~3;
      sck = 7;
      mosi = 4;
      miso = 8;
    geändert:programmer
      id = "ponyser2";
      desc = "design ponyprog serial, reset=txd sck=rts mosi=dtr miso=cts";
      type = serbb;
      reset = 3;
      sck = 7;
      mosi = 4;
      miso = 8;
    Der Aufruf erfolgt dann natürlich mit "-c ponyser2" .
  • Ich erhalte die Fehlermeldung 'Closing tag not found! Opening tag <?xml> found, but not closing </?xml>.
    Leider hat Atmel ab dem Studio 4.14 die partfiles nicht mehr kompatibel zum AVROSP gehalten. Also muß man bei neuem Studio entweder entweder AVROSP frisch installieren, die partfiles aus dem altem Studio für den Download entnehmen oder auf ein besseres Bootprogramm umsteigen, wie z.B. AvrOspII.
  • Wie kann ich mich aktiv an dem Projekt beteiligen?
    Mithilfe beim Programmieren, Testen und Übersetzen ist gerne gesehen. Es gibt auch eine (anmeldepflichtige) Yahoo Group, wo man weiteres erfahren kann: http://groups.yahoo.com/group/opendcc/
  • Mein S88 geht nicht, warum?
    Vermutlich ist die Lötbrücke SJ2 auf der Unterseite der S88-Platine nicht geschlossen.
  • Mir gefällt der S88-Bus nicht, ich hätte lieber RS-Bus oder Loconet.
    S88 ist leicht abspaltbar (die Adapterplatine weglassen und den #define Schalter S88_ENABLED ausschalten). Meine eigenen Rückmelder sind S88, daher habe ich kein anderes Protokoll implementiert - aber ein Entwurf für den RS-Bus geistert schon irgendwo bei mir rum. Zudem ist der S88 gar nicht so schecht, wie er oft gemacht wird: Mit OpenDCC ist er durchaus schnell und die Übertragungprobleme lassen sich lösen.
  • Die Kurzschlußüberwachung schaltet zu schnell ab, was kann ich tun?
    Die Verdrahtung und der Ausgangsfilter belastet die Ausgangsstufe mit einer Kapazität. Daher zieht die Kurzschlußüberwachung prinzipbedingt bei jedem Polaritätswechsel kurz an.
    Deshalb sind Sind R19 und R20 auf 2k2 geändert worden und zusätzlich wird in der Software (status.c) ein Filter gerechnet. Dieses Filter könnte man eventuell weniger aggressiv machen:
    statt main_short_mean += 4; z.B. main_short_mean += 2; verwenden.
    SHORT_TURNOFF_TIME ist die Zeitdauer, in der abgeschaltet wird; diese ist z.Z. auf 15ms eingestellt. (Ab V0.15 gibt es die CVs 34 und 35 für diese Einstellung).

    Ein weitere Ursache können Servodekoder sein: Servos ziehen bei der Lageregelung (auch in der jeweiligen Endstellung) ziemlich kräftige Strompulse von bis 1,5A. Diese können die Kurzschlußsicherung zum Ansprechen bringen.
  • Bei mir funktioniert der Bootloader nicht, es gibt timeout!
    Wenn sich der Bootloader normal einspielen ließ und anschließend die Verbindung zu Bootloader nicht klappt, könnte es auch an mangelnden Windows-Rechten liegen. Windows stellt sich an der seriellen Schnittstelle ohne Admin-Rechte bockig an. In diesem Fall als Administrator den Update durchführen.
  • Ich will mit dem Lenz-Protokoll steuern, geht das?
    Die Entwicklung von OpenDCC startete mit dem Lenz Protokoll; Da aber dort u.a. die CV's und die maximal möglichen Adressen beschränkt waren, habe ich dann auf IB-Protokoll umgestellt. Alle Tests der letzten Zeit wurden mit dem IB-Protokoll gefahren.
    Lenz ist nach wie vor vorhanden (und wird auch von manchen Anwendern benutzt) und kann per Compile-Switch wieder reaktiviert werden. Bitte hierzu per mail nachfragen (ab V0.14)
  • Wie kann ich PoM-Read machen?
    Nach dem Absetzen eines PoM-read-Befehls muß die Antwort von einem Gleisbesetztmelder erfaßt werden und per Xpressnet an die Zentrale geliefert werden. Dort wird das entweder an den Handregler geschickt oder an den Host weitergeleitet.
    In Xevent (0xC8) wird bei einem eintreffenden BiDi-CV-Ergebnis das Bit 5 (Maske 0x20) im Byte 3 gesetzt. Das Bit bleibt so lange stehen, bis XEvtPT gerufen wird. (Es schadet also nicht, wenn man vor dem PoM-Read einmal XEvtPT aufruft, um 'alte Leichen' wegzuräumen.)
    Die Abfrage des Dateninhalts erfolgt dann mit XEvtPT, dort liegt wie sonst auch das Ergebnis vor. Intern merkt sich die Zentrale beim Ausführen eines beliebigen PoM-Befehls (via p50x Parser) ein Flag, den Zeitpunkt und die angefragte CV. Bei der XevtPT Abfrage wird das Flag und die Differenz (aktuelle Zeit - obiger Zeitpunkt) ausgewertet:
      a) ein Result für die CV liegt vor: es wird 0x02,0x00,DATA gemeldet.
      b) ein Result liegt nicht vor: es wird 0xF5 (=Busy) gemeldet.
      c) die Timeout ist abgelaufen: es wird 0x01,0xFE (=no ACK from Decoder) gemeldet.

    Leider kennen die Hostprotokolle keinen 'Eigentümer' eines PoM-Befehls, die Antwort wird von der Zentrale ähnlich wie beim normalen Programmieren systemweit globalisiert. Wenn da also ein PoM von einem Handregler und dem PC parallel erfolgt, dann ist die Antwort nicht eindeutig. Vernünftig wird sich das erst in zukünftigen Protokollen lösen lassen.

    Hinweis für Benutzer von Trainprogrammer der Firma Freiwald: Trainprogrammer muß als Schnittstellenprotokoll Tams EasyControl benutzen und damit Trainprogrammer PoM-Lesen aktiviert, muß in der Datei railroad.ini die Option
       [Connections]
       EnablePOMRead=1
    gesetzt sein.
  • Die Dioden blinkern, was ist da kaputt?
    Prog, Stop und Go gleichzeitig schnell blinkend bedeutet, dass die Software keine Daten (oder veraltete Daten)im EEPROM gefunden hat. Es wird nichts gestartet. Abhilfe: Abstecken, roten Knopf drücken, anstecken, Daten einspielen (mit update_opendcc_eeprom.bat).
  • Die Zentrale 'spinnt', (=schaltet ab, irrtümliche Kurzschlußerkennung, usw.), was ist die Ursache?
    Hier hat sich bereits mehrmals das verwendete Netzteil als Ursache herausgestellt. Da gibt es offenbar Typen, welche Spikes und Dropouts am Ausgang haben. Dies irritiert fallweise die Kurzschlußerkennung bzw. die Spannungsüberwachung des Prozessors. Auch wurde mir schon ein Fall berichtet, wo das Netzteil keine vollständige Potentialtrennung hatte. Offenbar interpretieren manche Anbieter das CE-Zeichen als Abkürzung für China Export.
  • Ich brauche mehr/weniger Spannung, z.B. für LGB (24V).
    Im Prinzip ist eine Änderung möglich, aber bitte folgende Dinge beachten:
    • Kondensatoren / Dioden / Gleichrichter müssen dafür ausgelegt sein - die Kondensatoren müssen mind. 40V haben.
    • Der L6206 kann bis 50V und bis 2,5A, aber die Strombegrenzung der H-Brücke ist hardwaremseitig auf 1,5A und die Abschaltroutine dahinter 'pingelig' ausgelegt. Hier muß man für LGB fallweise mehr Strom zulassen (siehe Datenblatt). Thermisch ist das normalerweise kein Problem.
    • Die 5V für den Prozessor können noch mit dem 7805 erzeugt werden (ev. kühlen), jedoch für den S88 Kreis rate ich zu einem Schaltregler bzw. separater Versorgung.
    • Ein Anlage mit mehrerer Loks oder Weichendekodern sollte immer über Booster versorgt werden: die Kondensatoren der Dekoder verursachen einen Stromspitze beim Einschalten, welche die Kurzschlußabschaltung ansprechen lassen kann.
    • Ich rate von der Verwendung von alten PC-Netzteilen ab: dort funktioniert die 12V-Regelung oft nicht richtig, wenn die 5V nicht mit einer Mindestlast belegt sind.
  • Welcher Booster ist verwendbar?
    Erst einmal muß man die Sicherheit beachten: Modellbahn muß gemäß VDE schutzgetrennt sein (die Zentrale ist über die PC-Verbindung geerdet), also muß der Booster die Schutztrennung mit einem Optokoppler gewährleisten.

    Rein von der schaltungstechnischen Seite her ist folgendes zu betrachten:
    Es gibt im Prinzip zwei verschiedene Boosterkonzepte: H-Brücke (so wie der OpenDCC-Booster) oder NF-Verstärker (so wie oft im MM-Umfeld verwendet).

    H-Brücke ist recht simpel im Aufbau und billig, hat aber den Nachteil, dass das Gleis hinten gegen Masse der Zentrale 'tanzt'. Das ist nicht weiter schlimm, wenn optogekoppelte Rückmelder verwendet werden. Cutout-Erzeugung geht mit H-Brücke sehr einfach, da muß man nur beide Low-Quadranten gleichzeitig enablen.
    NF-Verstärker ist mehr Aufwand, teueres Netzteil, fette Elkos, Schaltungsaufwand mit Levelshiftern und Brimborium. Hat aber den Vorteil, dass hinten eine Seite auf Masse der Zentrale liegt. Mit NF-Verstärkern ist auch die Cutout-Erzeugung mit mehr Aufwand verbunden. Damit lassen sich dann Rückmelder wunderbar billigst massebezogen bauen und man braucht keine weiteren Optokoppler mehr. Aber damit besteht auch die Gefahr, dass ein Teil des Gleisstromes über die Rückmelder abfließt und dort Störungen verursacht (Das hat dem S88 seinen schlechten Ruf eingebracht).

    Wenn wirklich solche massebezogenen Booster verwendet werden sollen, dann würde ich in der Zentrale beim DCC Signal vom Prozessor andocken. Der Ausgang kann bis zu 10mA locker verkraften, d.h. bei üblichen 10k Eingangswiderstand lassen sich 10 Booster ansteuern. (Nochmal: Schutztrennung ist dann weg - die Anlage ist indirekt über den PC geerdet.)
  • Der Spannungsregler 7805 wird recht warm, was soll ich tun?
      Die internen 5V und die externe Versorgung der S88-Module werden aus der angelegten Primärspannung erzeugt. Je größer diese ist, umso höher die Verlustleistung.
    • Ein Kühlkörper hilft sehr viel, auch ein kleiner bringt schon was. Das Gehäuse sollte unbedingt belüftet sein.
    • Schaltreglern ist klar der Vorzug zu geben. Es gibt neben dem auf der Platine bestückbaren Schaltregler von TI auch 7805-Ersatz Typen (R-7805) oder Selbstbaulösungen. Ein PTH08080 geht bis 18V= Eingang und hat 86% Wirkungsgrad, ein 7805 hat nur 30%.
  • Was ist der Unterschied zwischen den Layoutversionen 1.3, 1.4 und 1.5?
    Nahezu kein Unterschied, elektrisch ist alles beim alten geblieben. Ich habe wegen notorischer Unzuverlässigkeit den Leiterplattenhersteller gewechselt und mußte deshalb Fräsmarken ins Layout einbringen.
  • Wie kann ich ein Logging erzeugen?
    Bei hartnäckigen Problemen brauche ich zur Analyse ein Logging der Schnittstelle, d.h. eine Mitschrift des Datenverkehrs vom PC zur Zentrale und zurück. Dies wird wie folgt erzeugt:
    • Das entsprechende Programm (portmon.exe) kann von der Microsoft-Webseite geladen werden.
    • Dieses muß man einfach *vor* der Modellbahnsoftware starten.
    • Im Programm muß man folgende Einstellungen vornehmen:
      Auswahl des Ports, welcher überwacht werden soll (kann auch USB sein)
      Filter setzen (das ist der Trichter); bei Exclude: IOCTL_SERIAL_GET_COMMSTATUS mit dazu nehmen (dann wird das das Log kleiner)
      bei Options: Show Time und Show Hex dazu.
    • Jetzt das Zielprogramm starten.
  • Was besser: OpenDCC oder DiCoStation?
    Das ist natürlich schwer objektiv zu beantworten - jeder Meister lobt seinen Kleister!
    Einfach zu vergleichen ist die Ausstattung: DiCo hat keinen Nothalttaster, keinen Booster, keinen Programmiergleisanschluß.
    Zur Leistung: ich halte meinen Algorithmus für den Lokstack von DCC für das Optimum an Performance, was aus DCC herauszuholen ist, die Latenzzeiten sind geringer als bei SX! Und diese Performance bleibt auch bei vielen Loks und 128 Fahrstufen erhalten! Beim Protokoll P50x verursacht die die DiCo erhebliche CPU-Last auf dem Host, OpenDCC nicht. Die S88-Implementierung von OpenDCC ist deutlich flotter und störsicherer unterwegs.
    Die DiCo kann Märklin Motorola, was ich nicht einbauen wollte. Die DiCo braucht zum Betrieb eine PC-Software (nur für Windows verfügbar), diese wird mittels einer Key-CD geschützt. Die CD wird laut Handbuch alle 15 Tage abgefragt.

Change Log bzw. Release Notes (allgemein)

    Hier findet sich die Änderungsgeschichte. OpenDCC ist ein nicht kommerzielles Projekt (ich mache das in meiner Freizeit) - daher bitte ich um Nachsicht, wenn noch nicht alle Facetten getestet sind und vielleicht der eine oder andere Bug enthalten ist. Aber ich hoffe auf Unterstützung beim Test und auf möglichst konstruktive Kritik. Danke all jenen, die bisher zum Projekt beigetragen haben.

Change Log bzw. Release Notes (Xpressnetversion, Atmega644P)

  • OpenDCC_XP_V0.23.11
    • 04.12.2013 Bugfix bei der Adressierung von extended Accessory > 63. (Dank an R.Blank)
    • 27.03.2015: Bugfix Fehlerhaftes Progshort bei Cutout on, deswegen dort ein Debouncer hinzu.
    • 27.03.2015: Ergänzung Dummy Lokbefehl wenn noch nie eine Lok aufgerufen wurde.
    • 26.08.2015: Bugfix im DCC Optimizer: unter bestimmten Randbedingungen konnte ein Funktionsbefehl der Funktionen F21-F28 falsch zugeordnet werden.
  • OpenDCC_XP_V0.23.9
    • 27.01.2012: Bugfix bei exerner Abschaltung: diese konnte ev. für einen zu lange Zeitraum nicht detektiert werden.
    • 27.10.2011: Nach XSensOff werden alle Xpressnet-Clients aufgefordert, die Belegtmeldung erneut abzuschicken. Hierfür gibt es ein neues Kommando 0x61 0x23 am Xpressnet. (Wichtig bei reconnect von Hostprogrammen)
  • OpenDCC_XP_V0.23.8
    • 16.07.2011: Initprobleme im Zusammenspiel mit Koploper und railware beseitigt.
    • 25.07.2011: p50x-Emulation: F17 bis F28 neu dazu, Binary States neu dazu. Xlimit wandert dafür nach 0x8F
  • OpenDCC_XP_V0.23.7
    • 10.03.2011: X@@ für Kaltstart hinzu.
    • 10.03.2011: Wenn keine Lok aktiviert ist, so wird anstatt ein Lokbefehl auf Adresse 3 mit Speed 0 ausgegeben. Dadurch eröffnet sich ein Anmeldefenster für BiDi-Loks. Sobald irgendeine Lok aktiviert ist, entfällt dieser DCC-Befehl.
    • 28.02.2011: Bugfix: in der 0.23.6 hatte sich eine falsche Antwort auf XNop eingeschlichen.
  • OpenDCC_XP_V0.23.6
    • 17.06.2010: Lenz-Emulation: Befehle für PoM read / write für accessory und extended accessory dazu.
    • 18.07.2010: Paged Mode wird nicht mehr auf Direct-Mode abgebildet, sondern als Page-Mode ausgeführt.
    • 19.07.2010: Lenz-Emulation: Prog_mode Broadcast wird nur noch gesendet, wenn der Mode gewechselt wird (JMRI).
    • 24.11.2010: Neue XP-Befehle für Feedback und PoM Read Daten. Damit kann zusammen mit dem GBM16 ein PoM-Read durchgeführt werden und Belegtmeldung erfolgen. Neu auch PoM-Read Support für das p50x-Protokoll.
    • 27.11.2010: neues p50x-Command: XEvtBiDi und Flags in Xevent: man kann über Intellibox-Syntax die Position der Loks abfragen.
    • 20.12.2010: neues p50x-Command: XBiDiQuery liefert zu einer Detektor-ID die fallweise dort stehende Lok zurück. Bei XEvtBiDi wird jetzt auch gemeldet, wenn eine Lok den Abschnitt verläßt.
    • 07.02.2011: nach einem PoM-Read per p50x kann über die XevtPT das Ergebnis direkt abgefragt werden. Sollte sich der Dekoder nicht melden, wird nach einer Zeit von 500ms ein Time-Out gemeldet.
  • OpenDCC_XP_V0.23.5
    • 10.11.2009: Hinzufügen von Extended Accessory Commands (bei p50xb: XTrntX und TX, bei Xpressnet 0x1*)
    • 21.11.2009: Bugfix POM Accessory Command, das 3. Byte begann irrtümlich mit 0x7 statt korrekt mit 0xE
    • 07.01.2010: kleinere Korrekturen in den Antworten bei p50xa und bei Lokbefehlen (im Falle von stopped oder halted)
    • 15.02.2010: Transfer der Lokdatenbank kann auch über einen Redirekt eines Accessory Commands angestoßen werden.
    • 15.02.2010: Hinzufügen von Restricted Speed Commands (bei p50xb: XLimit, XLimitSts, bei Xpressnet 0xE6 0x30 ...)
    • 19.02.2010: Hinzufügen von BiDi-Read Befehl (XPDR) und XLokX (Tams EC Kompatibilität)
    • V0.23.1: 01.03.2010: Fehlerbehebung (CV Adresse wurde fälschlicherweise um ein dekrementiert) bei PoM über Xpressnet
    • V0.23.2: 03.03.2010: Fehlerbehebung in XevtLok bei Funktionen
    • V0.23.3: 16.03.2010: Fehlerbehebung bei Extended Accessory
    • V0.23.4: 02.04.2010: PoM-Read Command for Xpressnet added
    • V0.23.5: 29.04.2010: BiDi: start gap für cutout leicht verlängert von 30µs auf 38µs
    • V0.23.5: 01.06.2010: Lenz-Emulation: Baud Problem behoben.
    • Ende DMX-Unterstützung in der Zentrale (nur noch per Dekoder)
  • OpenDCC_XP_V0.22.0
    • 23.10.2009: bei rückgemeldeten Weichen wird nach dem Schalten die echte Stellung nur noch als Broadcast am XPressnet übertragen, die direkte Rückmeldung an den auslösenden Regler entfällt; damit kommt dann ein LH100 auch damit zurecht.
    • Neu eingeführt: CV2 gibt die Optionsausstattung von Hardware und Software an. CV26 den Beschleunigungsfaktor der Uhr
    • 23.06.2009: Erweiterung um Uhrzeitkommando; damit wird eine Modellbahnzeit mit einstellbarer Beschleunigung über DCC übertragen. Das ist momentan mit Faktor 8 als default freigegeben.
    • 15.05.2009: bei rückgemeldeten Weichen wird nach dem Schalten die echte Stelle als Broadcast am XPressnet übertragen.
  • OpenDCC_XP_V0.21.0
    • 15.03.2009: Externes Abschalten nach Systemstart kann für eine bestimmte Zeit (CV37) unterbunden werden - damit haben z.B. Booster etwas Zeit, die Abschaltanforderung nach dem Einschalten zurückzunehmen.
    • 11.03.2009: Lokdatenbank auf 10 Zeichen erweitert, Datenbanktransfer sowohl für Multimaus als auch für OpenDCC Handregler.
  • OpenDCC_XP_V0.20beta
    • 24.02.2009: Version 0.20.9 (release candidate 3) Bugfix für Xpressnet command 0x92 (Nothalt einer Lok)
      Hinweis: Wertänderung auf R3 und R4 auf dem Xpressnet-Adapter von 4k7 auf 1k5 um im Bus-Idle eine fehlerhafte Startbiterkennung zu unterbinden.
    • 01.12.2008: Version 0.20.7 (release candidate 2) Neu dazu: command tunnel, added feedback info for Xpressnet, Lenz V3.6
    • 06.09.2008: Version 0.20.5 (release candidate) Neu dazu: Programmierbefehle, railcom
    • 28.08.2008: Zweite beta: neu dazu LOCO DATA BASE, bisher getestet: Einträge hinzufügen, Ausgeben, Übergabe an multiMaus.
    • 23.08.2008 Erste Release, bisher getestet: Fahren, Schalten, Mehrfachhandregler, PC-Übergabe (beide Richtungen).
      offen: Programmierinterface

Change Log bzw. Release Notes (Normalversion, Atmega32)

  • V0.17.0, 22.02.2010
    • Erweiterung mit restricted speed command.
    • Erweiterung mit DCC FAST CLOCK; hierbei ist auch die interne Interruptstruktur für das Timing umgestellt worden, jedoch ohne weitere Auswirkungen auf die Funktion (hoffentlich:-). Siehe auch CV26
    • Neu eingeführt: CV2 gibt die Optionsausstattung von Hardware und Software an.
    • Neue OpenDCC.yrc
    • 21.11.2009: Bugfix POM Accessory Command, third byte started with 0x7 instead 0xE
    • 07.01.2010: kleinere Korrekturen in den Antworten bei p50xa und bei Lokbefehlen (im Falle von stopped oder halted), Bugfix in der Implementierung von HALT
    • 19.02.2010: Hinzufügen von BiDi-Read Befehl (XPDR) und XLokX (Tams EC Kompatibilität)
  • V0.16, 10.10.2008
    • Bugfix: Die Versionsabfrage beim p50xa lieferte zusätzlich noch extra char mit.
    • Bugfix: Der Meldewert beim IB-Parser für Zubehörbefehle zeigt fäschlicherweise 'Queue fast voll' an.
    • Bugfix: Default Baudrate konnte nicht umgestellt werden.
  • V0.15, 12.08.2008
      Bitte bei jedem Update auf V0.15beta sowohl Flash und EEPROM neu einspielen.
    • Die jeweiligen Wiederholungen für Geschwindigkeit, Function und PoM sind per CV einstellbar. Die default-Werte sind allerdings sinnvoll und erprobt, da braucht man nichts verstellen.
    • Die defaultmäßig verwendete Fahrstufenzahl (28) ist per CV veränderbar.
    • Externer Nothalteingang (Konfigurierbar per CV36)
    • Die Abschaltzeit bei Kurzschluß jetzt einfach per CV änderbar. (Voreinstellung: 15ms für das Hauptgleis, 40ms für das Programmiergleis)
    • Es ist eine CV als Seriennummer beschreibbar - damit lassen sich verschiedene Boxen leichter indentifizieren.
    • Das Timing am S88 ist per CV programmierbar. Zusätzlich wird bei aktivierten Programmiergleis das s88-Lesen abgeschaltet, um keine Unterbrechungen im DCC Signal zu riskieren. Des weiteren habe ich die S88-Task auf Bitebene runtergebrochen - somit kann auch bei langer Einstellung der S88-CV kein Timingproblem auftreten.
    • Es gibt eine neue Configdatei für TC.
    • Bugfix: Bei heftigem Datenverkehr und vielen Lokkommandos konnte es passieren, dass ein Richtungswechsel nicht rechtzeitig die bisherigen Richtungsinformation ersetzt hat. Die entsprechende Lok fährt dadurch in falscher Richtung los. Jetzt wird ein Richtungswechsel mit hoher Priorität behandelt und kann nicht mehr von normalen Geschwindigkeitskommandos überholt werden.
    • Bugfix: Adressierungsfehler bei Rückmeldebits und aktivierter Weichenlagemeldung (nur bei entsprechend gesetztem compile-switch). Zusätzlich gibt zwei weitere CVs, mit denen man die Anzahl der rückgemeldeten Weichen einstellen kann.
    • 17.04.08: Bugfix: Baudrate 57600 und 115200 sind falsch initialisiert. das ist behoben, aber noch nicht im download.
    • 18.07.08: Bugfix: HEX Eingabe im p50xa-Befehlen hatte Fehler.
    • 10.08.08: In Vorbereitung der Xpressnetschnittstelle wurde Optimierungen und Codeänderungen am Organizer vorgenommen. Die S88 Task ist auf Timer umgestellt.
    • PT-Event wird jetzt im Falle eines Abbruchs vom Host erzeugt.
  • Neue Platinenversion V1.4, lieferbar ab Jan 2008
      Bei der Nachbesellung von Platinen habe ich die Gelegenheit benutzt, einige kleinere Änderungen einfließen zu lassen. Änderungen von V1.3 auf V1.4:
    • Die RJ45 Anschlüsse haben jetzt eine Pinbelegung gemäß dem neuen Standard S88-N.
    • Dieser Standard unterstützt auch die Übertragung von RAILDATA - dafür wird in der V1.4 das DCC Ausgangssignal mittels eines Single Gate Buffers (74AHC1G125) zu den S88 Leitungen übertragen. Für den normalen S88-Betrieb braucht man das nicht und kann es einfach weglassen.
    • Um zukünftig auch mal CVs über diesen Weg lesen zu können, kann die Reset-Leitung tristate geschaltet und zurückgelesen werden.
    • Das Umschalten zwischen USB und RS232 erfolgt jetzt über einfache Jumper (JP5 und JP6) auf Bergstiften.
    • SJ4 ist jetzt auf der Bauteilseite
    • Viele Texte und Markierungen im Kupfer hinzugefügt, um den Nachbau zu erleichtern.
  • V0.14, 20.10.2007
      Bitte beim Update auf V0.14 sowohl Flash und EEPROM neu einspielen (auch für bisherige 0.14beta-Inhaber).
    • neu: echte Weichenrückmeldung
    • Programmierbefehle funktionieren unter Lenz-Emulation - danke an Rainer für die Logs!
    • Erweiterung um P50Xa-Programmierbefehle und Stop und Go (0x60 bzw. 0x61) der 6050 Syntax. Diese Befehle werden u.a. auch von WinDigipet gebraucht.
    • Nach dem Programmierende wird wieder der Zustand vor dem Programmieren einschaltet - war vorher 'running', ist es danach auch wieder.
    • Der default-Startmode im Intellibox-Mode ist jetzt P50/P50X-Mixed (war vorher P50X-only), damit funktioniert auch Rocrail. Bei TC hat es keine Auswirkung.
    • Bessere Aufteilung des Sourcecode in Module, um zukünftige andere Hardwareplattformen besser integrieren zu können.
    • Beim Befehl XZzA1 wurde kein String zurückgegeben, das ist jetzt korrigiert.
    • Beim Programmieren wird das Einlesen der ACK-Leitung mit einer Filterfunktion bewertet, damit können 'Problemloks' besser behandelt werden. Während OpenDCC auf den ACK wartet, wird die gelbe LED (PROG) kurz ausgeschaltet - damit sieht man die Leseaktivität recht gut.
    • Der Programmieralgorithmus kann im Timing per Konfiguration langsamer gemacht werden:
      - Die Zahl der Resetpakete vor einem Lesebefehl kann erhöht werden.
      - Die Zahl der Lesekommandos kann erhöht werden, damit hat der Decoder mehr Zeit für die Antwort. (siehe Sonderoptionen 18 und 19)
    • Einfachere Konfiguration durch Programmierbefehle: Wenn beim Einschalten die GO-Taste gedrückt ist, dann werden die Programmierbefehle auf die internen Konfigurationsvariablen umgeleitet. Die Parameter der Zentrale sind dann über einen Programmer (z.B. Trainprogrammer) les- und schreibbar. Natürlich kann man dann keine normalen Loks mehr programmieren. Für Trainprogrammer gibt es auch ein yrc-file: OpenDCC_V17.yrc
  • V0.13, 15.03.2007
      Alle Optimierungen der V0.13 gelten nur für den IB-Mode!
    • Bugfix im Programmer bei Intellibox-Emulation.
      Hintergrund: der Programmer war in den älteren Versionen "busy waiting" implementiert und wurde wegen des IB-Parsers in den normalen Queuemanager einordnet ("multi tasking"). Leider hat der Queuemanager den bereits vorgegebenen Repeatcount der Programmierbefehle mit 1 überschrieben, so daß nicht mehr die normgerechte Anzahl an page-presets o.ä. rausgegangen ist.
    • Der ACK-Puls bei Programmieren wird zusätzlich mit einer Software-Entprellschleife von 500µs gewertet. Bitte auch die Hardwareänderungen bachten: C44 - 10nF, R19 - 2k2, R20 - 2k2
    • Neu dazu: Programmieren auf dem Hauptgleis - POM Hinweis: das geht logischerweise nur write-only.
    • Falls OpenDCC im Programmiermodus steht, werden auch die Lok-Kommandos, Accessory und POM auf das Programmiergleis ausgegeben, aber nur, wenn nicht gerade eine Programmieraktion läuft. Diese Kommandos werden nicht zyklisch wiederholt oder im Lokspeicher abgelegt.
    • Beschleunigung des DCC Direktmodes durch vorhergehenden Test auf Bit-Fähigkeit. Diese Decoderfähigkeit merkt sich OpenDCC für eine kurze Zeit (#define TIME_REMEMBER_BIT_OP). Damit dauert dann das Auslesen einer kompletten Geschwindigkeitskennlinie 20s, obwohl die Vorgaben der NMRA im Gegensatz zu einer käuflichen Zentrale eingehalten werden.
    • Zurückgemeldete Fehlercodes beim Programmieren sind jetzt konform zur IB.
  • V0.12, 05.02.2007
    • EEPROM-Routinen und mehrere Sonderoptionen der IB implementiert.
      Hintergrund: Railware fragt eine Menge von IB-SO's ab - diese werden bestmöglichst beantwortet.
    • Compiler-Umstellung auf gcc 4.1.1 und AVR-Studio 4.13 (wichtig).
  • V0.11, 28.01.2007
    • Bugfix im Zusammenspiel Intellibox und TC.
      Hintergrund: TC initialisiert mit 2 Stopbits. Wenn OpenDCC mit einem Stopbit sendet, kann es bei USB-to-Serial Konvertern Probleme geben
    • DCC Accessory repeat count ist im EEROM einstellbar.
    • Bei der Lenz-Emulation werden die Accessory Commands invertiert.
      Hintergrund: hier unterscheiden sich IB und Lenz in Ihrer Interpretation von DCC (!)
    • Bugfix im Zusammenspiel mit DMX
    • Hardwareänderung: um allzu hektisches Abschalten der Ausgangsstufe bei kapazitiven Lasten zu vermeiden, muß die Erholzeit der Ausgangsstufe verkleinert werden: R19 und R20 ändert sich von 10k auf 2k2.
  • V0.10, 22.01.2007
      OpenDCC hat heute mit der Intellibox-Emulation Verbindung zum Traincontroller aufgenommen. Lok ist gefahren, Funktionen wurden übermittelt und Weichen konnte ich schalten!
      Stop-Go wird in beide Richtungen übermittelt. Das etwas verzwickte Initialisierungsschema "BABI" inkl. der Abfrage vom Sonderoptionen (wie z.B. Baudrate) funktioniert auch.

ChangeLog Configtool

  • V0.18, 22.01.2007
    • Fenstergröße für die Hauptform ist jetzt fix und kann nicht mehr maximiert werden-
    • das Meldefenster für die Aktualisierung der Firmware kann nun nicht mehr beschrieben werden
    • das Einfrieren des Bildschirms beim Update konnte ich noch nicht lösen
    • die Programmierung auf dem Hauptgleis über P50Xa- Kommandos

Geplante Erweiterungen

    Das sind nur Ideen, ob ich es mache, steht in den Sternen!
  • Konfiguration von OpenDCC über einen virtuellen Lokdecoder - ab V0.14 enthalten
  • Rückmeldung der Weichenlage mittels rückmeldefähiger Decoder und virtueller Melder - ab V0.14 enthalten.
  • POM - Programming on the main auch im ASCII Mode
  • Handregler: dieser wird Xpressnet basiert sein, z.B. geeignet für Roco® Multimaus®
  • Befehlserweiterungen:
    0x82 XLokSpd echte Speed
    Pom read
    Pom accessory
    Pom read accessory
    0xC0 XClockSet (implementiert ab V0.22)
    0xC1 XClockGet (implementiert ab V0.22)
  • XLokSpd (0x82) (nur zusammen mit Railcom)
    Antwort: 1 Byte, Speed gemäß der BiDi-Kodierung (siehe XEvtLokSpd)
    
     Melden von Istgeschwindigkeit, Pushdienst:
    
     In XEvent (0xC8) wird Bit 6 (=0x40) gesetzt, wenn eine neue
     Geschwindigkeitsrückmeldung vorliegt.
     Mit XEvtLokSpd kann das dann abgefragt werden.
  • XEvtLokSpd (0xCC)NEU - NOCH NICHT VERABSCHIEDET Länge = 1 Byte
    Antwort (nur bei OpenDCC_XP mit railcom):
          Es werden alle seit der letzten Abfrage eingegangenen Geschwindigkeit-Datagramme gemeldet.
          Die Meldung erfolgt als verkettete Liste:
          1. Byte: 0x00 - 0xFE: Speed gemäß der BiDi-Kodierung
                       0..63:    speed = byte1 / 2;
                       64..127:  speed = byte1 - 32;
                       128..254: speed = byte1 * 4;
                       255:      Listenende
          2. Byte: low byte of Lok# (A7..A0)
          3. Byte: high byte of Lok#, plus Dir and Light status, coded as follows:
                         bit#   7     6     5     4     3     2     1     0
                             +-----+-----+-----+-----+-----+-----+-----+-----+
                             | Dir |  FL | A13 | A12 | A11 | A10 | A9  | A8  |
                             +-----+-----+-----+-----+-----+-----+-----+-----+
          

Märklin ist das eingetragene und geschützte Warenzeichen der Firma Gebr. Märklin & Cie. GmbH, Göppingen , Deutschland.
Intellibox ist das eingetragene und geschützte Warenzeichen der Fa. Uhlenbrock
DiCoStation ist das eingetragene und geschützte Warenzeichen von Littfinski Daten Technik
Xpressnet und railcom sind das eingetragene und geschützte Warenzeichen von Fa. Lenz