OpenDCC Z1 - Zentrale für DCC - Befehle im Intellibox-Mode

Überblick

    Beim Projekt OpenDCC kann das zum Host hin emulierte Schittstellenprotokoll verschiedene Zentralen emulieren. Nachfolgend ist die Kommandoübersicht für den Intellibox-Mode ® aufgelistet. Entdeckte Fehler oder Unklarheiten bitte ich per mail mitzuteilen. Verwendete allgemein übliche Bezeichungen für andere Zentralen sind fallweise registrierte Marken der jeweiligen Eigner.

Allgemeine Eigenschaften

  • Schnittstelle:
    OpenDCC arbeitet mit einer Default Baudrate von 19200. Einstellbar sind jedoch auch 2400, 4800, 9600, 19200, 38400 und 57600 Baud. Das Datenformat ist immer 8 Datenbits, kein Parity, 2 Stopbit (8N2), wobei es beim Empfang egal ist, ob 1 oder 2 Stopbits empfangen werden. Beim Senden werden immer 2 Stopbits gesendet, damit unter Traincontroller auch USB-to-Serial Konverter funktionieren.
    Bei der Kommunikation über USB wird eine serielle Schnittstelle emuliert, hier liegt die empfohlene Einstellung bei 38400 Baud.
    OpenDCC unterstützt die automatische Baudratenerkennung BABI wie die Intellibox. Die Implementation ist etwas anders, funktionierte jedoch bei einem Test mit Traincontroller.
      HINWEIS: Nach Neustart von OpenDCC (z.B. durch Aus- und Einschalten) oder abziehen des USB-Kabels ist die benutzte serielle Schnittstelle über USB nicht mehr gültig, da sich OpenDCC über USB nach dem Einschalten neu am System anmeldet. In diesem Fall ist das Filehandle (des Steuerprogramms) für die geöffnete Schnittstelle unbrauchbar (es können keine Zeichen mehr versandt werden und es wird natürlich nichts mehr empfangen). Das kann je nach Qualität der Hostsoftware zum "Hängenbleiben" des Steuerprogramms führen.

    Es wird voller Duplexbetrieb mit Hardwarehandshake unterstützt, die Transmit- und Receive-Fifos sind 64 Bytes tief, 10 Byte vor dem Vollwerden wird CTS = High zurückgemeldet.
  • Protokoll:
    Bei der Intellibox gibt es drei Protokolle:
    • Märklin 6050 binäre Interfacebefehle (bei der Intellibox [IB] P50-Kommandos genannt).
    • ASCII Kommando-Erweiterung (bei der IB P50Xa-Kommandos genannt).
    • Binär Kommando-Erweiterung (bei der IB P50Xb-Kommandos genannt).
    Wenn im P50-Mode das erste Zeichen ein X ist, dann wird auf die erweiterte Kommandoebene umgeschaltet; Ist das zweite Zeichen ein ASCII Zeichen (<0x80), so wird die ASCII Erweiterung angesprochen, ansonsten die Binärerweiterung.

    OpenDCC unterstützt den P50-Mode gar nicht (Ausnahmen: Power On/Off und 0xc4 für Autobaudumschaltung), den ASCII-Mode und den Binärmode weitgehend. Im ASCII Mode wird jede Antwort mit der Zeichenfolge <cr> + ']' abgeschlossen.
  • Lokprotokoll, Lokstack:
    OpenDCC arbeitet nicht mit einen Lokstack oder Slots, welche zyklisch arbgearbeitet wird, sondern mit dynamisch priorisierten Listen, welche von einer Organisationseinheit gefüllt werden. Dadurch wird eine extrem schnelle Reaktion auf Fahrbefehle vom PC erreicht. Diese Organisationseinheit kann 64 gleichzeitig *fahrende* Loks verwalten. Loks, welche längere Zeit nicht mehr bewegt wurden, werden beim Aufrufen weiterer Loks automatisch von der Organisationseinheit nicht mehr betrachtet, es ist kein An- oder Abmelden erforderlich. Ein weiterer Vorteil dieser dynamischen Listen ist gleichbleibende Performance auch bei längerem Fahrbetrieb.
    Diese Grenze von 64 fahrenden Loks kann durch eine entsprechende #define-Einstellungen beim Übersetzen auch anders liegen. Allerdings macht es kaum Sinn, mit DCC mehr als 40 Lok gleichzeitig fahren zu lassen. Da stößt das Timing am Gleis an die Grenzen.

    OpenDCC erlaubt Lok-Adressen von 1 .. 10239. (gesamter DCC Adressraum). Der Bereich von 10239 bis 16384 bleibt reserviert. Die Adresse Null ist grundsätzlich ungültig und wird nicht in einen entsprechenden Broadcast umgesetzt.

    Das Lokformat von OpenDCC wird (per Compileeinstellung) auf eine Voreinstellung festgelegt. Alle Loks werden in diesem Format (z.B. DCC28) angesprochen. Da das orginale Intellibox-Protokoll keinen Befehl zum Festlegen des Formats kennt, wurde ein neues Kommando Lok_Cfg_Set (LS) eingeführt, das es erlaubt, Lokomotiven mit einem anderen Format anzusprechen. (Dieses ist auch kompatibel in der TamsMC enthalten).
    Per Lok_Cfg_Set definierte Ausnahmen vom Defaultprotokoll werden permanent im EEPROM gespeichert; es gibt 64 Speicherplätze für Ausnahmen. Mit Hilfe des Programms OpenDCC_configtool lassen sich diese Listen leicht verwalten.

    Geschwindigkeitseinstellung:
    Die Geschwindigkeit am Interface ist unabhängig vom Format der Lok 0 bis 127 und wird intern auf die jeweils verfügbaren Geschwindigkeitsstufen umgerechnet. Die Geschwindigkeitsstufe 1 bedeutet dabei immer Not-Halt (Emergency-Stop).

    Unterstützte Funktionen:
    OpenDCC kann die Funktionen F1 bis F28, sowie F0 (bzw. FL / Licht).
  • Rückmelden (S88):
    OpenDCC macht grundsätzlich s88-Autoreset, d.h. das Auslesen eines s88-Moduls liefert den aufsummierten Zustand (Oder-Verknüpfung) seit dem letzten Reset. Diese Bits werden nach dem Auslesen wieder auf Null gesetzt.

    Über das S88 Interface können auch die Weichenrückmeldungen eingelesen werden, dies muß entsprechend mit Spezial-Optionen eingestellt werden.

P50-Kommandos (Märklin 6050)

    OpenDCC unterstützt dieses Format nicht - nur die beiden Kommandos 'x' (oder 'X') und 0xC4 (liefert als Antwort immer 0x00 bzw. 0x00 0x00, je nach Mode) werden unterstützt, damit die Baudratenerkennung funktioniert und auf einen der P50X Befehlsätze umgeschaltet werden kann.
    Auch der Märklin MM1 und MM2-Mode wird bis auf weiteres nicht freigegeben.

P50Xa-Kommandos (ASCII-Commands):

    Allgemeine Regeln:
    P50Xa Befehle beginnen immer mit einem X (es sei denn, man ist bereits permanent im P50X-Modus).
    Ein Befehl darf bis zu 63 Zeichen lang sein und wird mit (=0x0D) abgeschlossen.
    Die Antwort wird immer mit "]<cr>" abgeschlossen.
    kennzeichnet neue Befehle, die nicht in der IB enthalten sind (aber fallweise in der Tams MC).
    kennzeichnet geplante neue Befehle zur Funktionserweiterung.
    Im Gegensatz zur IB kann nicht mit "<delete>" ein Zeichen gelöscht werden, welches bereits an OpenDCC abgesendet wurde.
    Hinweise:
      Mit dem P50Xa-Kommando ZZA kann zwischen dem P50X-Only und P50/P50X-Mixed Modus umgeschaltet werden. Die Defaultbelegung ist P50/P50X-Mixed Modus, diese kann permanent im EEProm mittels SO#15 modifiziert werden.
      Im folgenden sind optionale Parameter mit [..] eingeklammert. Wird ein Befehl ohne Parameter übergeben, so wird dieser Befehl als Abfragebefehl ausgeführt.
  • ? oder H: Hilfe
    Aktion: keine
    Antwort: "Help cmds: HL, HF, HT"
  • HF: Hilfe für Funktionskommandos
    Aktion: keine
    Antwort: "F {Lok#, [F1], [F2], [F3], [F4], [F5], [F6], [F7], [F8]}"
  • HL: Hilfe für Lok-Befehle
    Aktion: keine
    Antwort: "L {Lok#, [Speed], [FL], [Dir], [F1], [F2], [F3], [F4]}"
  • HT: Hilfe für Turnout-Commands (Weichen)
    Aktion: keine
    Antwort: "T {Trnt#, [Color], [Status]}"
  • . oder STOP: Stop
    Aktion: Führt einen STOP aus (selbe Aktion wie zweimaliges Drücken der roten STOP-Taste). Die Gleissignale werden abgeschaltet.
    Antwort: "Pwr off"
  • ! oder GO: Go
    Aktion: Führt einen GO aus (selbe Aktion wie Drücken der grünen GO-Taste). Die Gleissignale werden eingeschaltet.
    Antwort: "Pwr on"
  • HALT: Halt
    Aktion: Die Funktion hält alle Loks an (per Emergency-Stop), schaltet die Gleis- signale jedoch nicht ab. Weichen können nach wie vor geschaltet werden.
    Antwort: "Halted!"
  • L: Lok Befehl
    Syntax: L {Lok#, [Speed], [FL], [Dir], [F1], [F2], [F3], [F4]}
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
            Speed: Geschwindigkeit (0 .. 127: 0 = Stop, 1 = Em.Stop)
            FL: Front-Light (0 = aus, 1 = ein)
            Dir: Direction (0 oder r = rückwärts, 1 oder f = vorwärts)
            Fn: Funktionsausgang n (0 = aus, 1 = ein)
    Antwort: "L 'Lok#' 'Speed' 'Dir' 'FL' 'F4_F1' 'Speed_internes_Format'"
    Unabhängig vom Lokformat wird die Geschwindigkeit immer im Bereich von 0 bis 127 angegeben. OpenDCC rechnet diese Geschwindigkeit intern auf die jeweiligen Fahrstufen der Lok um. Es gilt folgender Algorithmus (dieser ist indentisch zu Tams EasyControl und Intellibox; es wird jeweils als integer gerechnet):
    1. Geschwindigkeit 0 bleibt 0.
    2. DCC, 14 Fahrstufen: V = (Speed - 2) / 9 + 1;
    3. DCC, 28 Fahrstufen: V = (Speed - 2) * 2 / 9 + 1;
    4. DCC, 128 Fahrstufen: V = (Speed - 1);
    27 Fahrstufen werden nicht unterstützt. Die höchste Fahrstufe am Gleis liegt damit je nach Protokoll bei folgender Eingabe an:
      
    Lokformat Maximum bei
    DCC14 119
    DCC28 124
    DCC128 127

      Hinweise zum Lokbefehl:
    • Wird der Befehl ohne Parameter (z.B. L 3) gesendet, wird der Status der Lok angezeigt. Voraussetzung dabei ist allerdings, dass die Lok schon einmal angesprochen wurde, ansonsten wird 'No lok data' geantwortet.
    • Ist die Zentrale im HALT-Zustand, wird ein Ändern der Lok-Geschwindigkeit verweigert und mit 'Halted!' retourniert. Ein Abfragen des Lok-Status ist jedoch moeglich.
    • Die Funktionen F1 .. F4 sind zwar in der IB Syntax enthalten, werden hier aber nicht unterstützt und liefern im Antwort-String immer 0. Für Funktionen bitte den Befehl 'F' verwenden.
  • LC: Lok Protokoll Konfiguration ausgeben
    Syntax: LC {Lok#}
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
    Antwort: "DCC" und Zahl der Fahrstufen
    War die Lok bisher noch nie benutzt und ist sie auch nicht als Ausnahme von der Voreinstellung in OpenDCC hinterlegt, so wird das voreingestellte Lokformat zurückgemeldet.
  • LS: Lok Protokoll einstellen (neu in OpenDCC!)
    Syntax: LS {Lok#, [Format], [Steps]}
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
            Format: MM1, MM2 or DCC, codiert als 0,1,2; bei OpenDCC ist nur DCC erlaubt.
            Steps: 14, 28, 126
    Aktion: Falls Format von der Voreinstellung abweicht, wird dies Lok als Ausnahme gespeichert.
  • F: Function
    Syntax: F {Lok#, [F1], [F2], [F3], [F4], [F5], [F6], [F7], [F8]}
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
            Fn: Funktionsausgang n (0 = aus, 1 = ein)
    Aktion: Wenn mindestens ein Parameter vorhanden ist, so werden die Funktionsbits entsprechend gesetzt.
    Antwort: Ausgabe der Funktionsbits, z.B. "F 1 2 4 8" (String wird ev. noch auf 0 / 1 geändert)
  • FX: Function (eXtended)
    Syntax: FX {Lok#, [F9], [F10], [F11], [F12]}
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
            Fn: Funktionsausgang n (0 = aus, 1 = ein)
    Aktion: Wenn mindestens ein Parameter vorhanden ist, so werden die Funktionsbits entsprechend gesetzt.
    Antwort: Ausgabe der Funktionsbits, z.B. "F 1 2 4 8" (String wird ev. noch auf 0 / 1 geändert)
  • LOCADD: Lok zu Datenbank hinzufügen
    Syntax: LOCADD Lok#, SPEEDSTEPS, FORMAT, NAME
    Parameter:
            Lok#: Lokadresse (1 .. 10239)
            SPEEDSTEPS: Anzahl der Fahrstufen, moegliche Auswahl: 14, 28, 126
            FORMAT: Lokformat, mögliche Auswahl: hier nur DCC
            NAME: max. 10 Zeichen (ASCII); (bis Version 0.20: 6 Zeichen)
    Aktion: Die Lok wird in die interne Datenbank aufgenommen und permanent gespeichert. Diese Datenbank ist _nicht_ der Lokstack - d.h. es können auch Loks gefahren werden, die nicht in der Datenbank enthalten sind. Umgekehrt sind Loks nicht in der Gleisausgabe enthalten, wenn Sie zwar in der Datenbank enthalten sind, aber noch nicht aufgerufen wurden.
    Die Namen werden beginnend mit dem ersten Zeichen nach dem Komma nach FORMAT in die Lokdatenbank kopiert. Es wird bis zum nächsten Leerzeichen kopiert. Wenn das erste Zeichen ein " oder ein ' ist, dann wird dieses Zeichen übersprungen und von dieser Stelle an bis zu Auftreten des gleichen Zeichens oder bis zur maximalen Zeichenlänge kopiert. Wenn also ein Lokname ein Leerzeichen enthalten soll, so ist er einfache oder doppelte Hochkommata einzuschließen.
    Wenn eine Lok mit gleicher Adresse in der Datenbank bereits vorhanden ist, dann wird diese ersetzt. Nur verfügbar bei OpenDCC_XP
  • LOCDUMP: Lok-Datenbank ausgeben
    Syntax: LOCDUMP
    Aktion: Es wird eine Liste mit einem Datensatz pro Zeile ausgegeben. Der Aufbau jeder Zeile ist wie folgt:
      Lok#, SPEEDSTEPS, FORMAT, NAME
    SPEEDSTEPS, FORMAT, NAME sind wie bei LOCADD formatiert. Die Liste wird mit einer Zeile "*END*" abgeschlossen.
    Nur verfügbar bei OpenDCC_XP
  • LOCXMT: Lok-Datenbank an eine angeschlossene multiMaus® ausgeben
    Syntax: LOCXMT
    Aktion: Es wird die Lokdatenbank auf dem Xpressnet ausgegeben. Die Ausgabe erfolgt jeweils zweimal je Lok in Abständen von je 100ms. Je nach Umfang der Lokdatenbank kann dies also etwas dauern. Ab Version 0.21 erfolgt die Ausgabe viermal ke Lok in Abständen von 50ms und zwar in der Reihefolge: M-C-M-C; M bezeichnet eine Xpressnet-Mastermessage, C eine Clientmessage; Die Rocomäuse verstehen nur die Clientmessage.
    Nur verfügbar bei OpenDCC_XP
  • LOCCLEAR: Lok-Datenbank komplett löschen
    Syntax: LOCCLEAR
    Aktion: Antwort: 'ok'; Die Datenbank wird gelöscht - und weg ist sie! (keine Nachfrage) Ein PC-Programm (Configtool) kann mit LOCDUMP alle Loks einlesen (oder bei Null beginnen) und eine interne Liste von Loks aufbauen (z.B. durch den Anwender editieren lassen). Anschließend löscht es die Lok-DB mit LOCCLEAR und sendet eine komplett neue Liste mit LOCADD an OpenDCC. Nach dem Übertragen der List kann diese dann mit LOCXMT an die Handregler verteilt werden.
    Nur verfügbar bei OpenDCC_XP
  • T: Turnout (Weiche oder Signalschaltbefehl)
    Syntax: T {Trnt#, [Color], [Status]}
    Parameter:
            Trnt#: Weichen-Nummer (1 .. 2040)
            Color: 0 oder 'r' = Rot / Abzweig, 1 oder 'g' = Grün / gerade aus
            Status: 1 = ein, 0 oder nicht angegeben = aus
    Aktion: OpenDCC sendet z.Z. sowohl den Status on als auch den Status off Befehl auf den Ausgang.
      Bei aktiver Weichenrückmeldung passiert folgendes: Bei Status on wird der Befehl durchgereicht; bei Status Off wird auch der Befehl durchgereicht, allerdings wird danach der Acknowledge-Eingang abgefragt. Ein rückmeldefähiger Weichendecoder quittiert damit den vorangegangen Schaltbefehl und zeigt durch den ACK-Puls an, dass die Weiche in korrekter Lage liegt. Fehlt dieser Rückmeldepuls, so wird ein S88-Event generiert.
      Hinweis: Die IB sendet den Weichenbefehl 1 als Decoder 1, Output 0 ab. Das ist m.E. eine falsche Interpretation der NMRA, die Decoder beginnen bei 0. Broadcast ist hier 511.
    Aktion: Schaltet die Weiche entsprechend oder gibt den Status der Weiche aus.
    Beispiel: "T 5 g 0"
    Antwort bei Abfragebefehl: (z.B. "T 1"): "T 'Trnt#' 'Status'". Status ist hier immer der Soll-Status (also die letzte bekannte Schaltposition, eine ev. Rückmeldung von der Weiche wird hier nicht verarbeitet. Diese wird als S88-Event direkt an den PC weitergereicht. (Dieses Verhalten wurde so von PC-Programmherstellern gewünscht, diese wollen die Auswertung und Reaktion selbst durchführen.)
  • TX: Extended Accessory
    Signalschaltbefehl mit Aspect
    Syntax: TX {Dec#, Aspect}
    Parameter:
            Dec#: Decodernummer (0 .. 2043)
            Aspect: der darzustellende Signalbegriff (0 .. 31)
    Aktion: OpenDCC sendet einmalig (ohne Wiederholung) den Extended Accessory Befehl aus. Keine Abfrage möglich.
    (ab V0.23, nur in OpenDCC_XP)
  • RC: Railcom
    Syntax: RC {[Mode]}
    Parameter: Bitfeld
    ParameterBedeutung
    ohneDer aktuelle Zustand wird ausgegeben. Antwort: "BiDi on" oder "BiDi off"
    0=000bDie Erzeugung von cutouts ist abgeschaltet.
    1=001bIm DCC Strom wird nach jedem Befehl für die Länge von 434us ein Cutout eingefügt.
    3=011b* In Abständen wird der IdNotify Befehl zum Anmelden von Loks gesendet.
    5=101b* In Abständen wird ein AccQuery Befehl für RailCom Rückmeldung von Accessory-Decodern gesendet.
    * = not yet implemented, coming soon
  • Y: Status
    Aktion: Gibt den momentanen Systemstatus aus.
    Antwort: "Pwr off", "Halted!", "Pwr on", "DCC program" oder "RESET"
  • V: Version
    Syntax: V
    Gibt die Versionsnummer von OpenDCC aus: "OpenDCC V0.15"
  • MT: Magnetartikel Timer
    In OpenDCC nicht implementiert
  • SR: s88-Autoreset
    Syntax: SR {[Flag]}
    Flag: 0 (aus) oder 1 (ein)
    In OpenDCC nicht implementiert, es wird immer die automatische Einstellung verwendet.
  • SS: s88-Modul auslesen
    Syntax: SS {Modulnummer}
    Modulnummer: 1..32
    In OpenDCC nicht implementiert, alle Rückmeldungen laufen über XEVSens.
  • SE: Anzahl s88-Module definieren
    Syntax: SE {[AnzModul]}
    AnzModul: Anzahl der s88-Halbmodule (0..64)
    In OpenDCC nicht implementiert, da drei Strings vorhanden sind. Diese werden akteulle über EEPROM Konstanten eingestellt.
    Die Anzahl der automatisch einzulesenden Module ist die angegebene Anzahl dividiert durch 2 (die IB rechnet hier in 'Halbmodulen', entsprechend Bytes). Ungerade Anzahlen werden nach oben gerundet. Eine Angabe von 0 als Anzahl zu lesender Halbmodule führt zum Abschalten des s88-Bus (es werden keine Daten eingelesen). Antwort: tbd.
  • ZZA: Umschalten zwischen P50X-Only und P50/P50X-Mixed Modus
    Syntax: ZZA [Wert]
    Wert: 0 (mixed mode) oder 1 (P50X-only mode)

    Schaltet OpenDCC in den P50X-only mode (nur P50X Kommandos erlaubt) oder wieder zurück in den mixed mode (P50 und P50X Kommandos erlaubt).
    Antwortstrings:
        ZZA0: 'Mixed P50/P50X mode'
        ZZA1: 'P50X only mode (P50 is disabled)'

    Hinweis 1: Dieser Befehl ist im Gegensatz zur IB nicht case-sensitiv.
    Hinweis 2: Der Startmode kann mit einer Compileoption festgelegt werden. (default ab 0.14: Mixed Mode)
  • @@: Kaltstart:
    Syntax: @@
    Um nach einer Konfiguration diese auch wirksam werden zu lassen, ist ein Kaltstart erforderlich. Hierzu kann man entweder aus-einschalten oder dieses Kommando verwenden. (enthalten ab V0.23.8)
  • B: Baudrate
    Syntax: B [Baud]
    Parameter: Baud: Baudrate (2400, 4800, 9600, 19200, 38400, 57600)
    Die Baudrate wird auf den angegebenen Wert gesetzt, wobei die Antwort dieses Befehls noch vollständig mit der alten Baudrate gesendet wird, sofort danach wird umgeschaltet. Sollte ein falscher Wert für Baud angegeben werden, so wird DEFAULT_BAUD (normalerweise 19200) eingestellt. Fehlt der Parameter, so wird die aktuelle Baudrate zurückgemeldet.
    Diese Einstellung wirkt nur temporär, nach einem Neustart oder Framefehler ist wieder die default-Einstellung gültig.
  • SO: EEPROM-Variable auslesen oder schreiben
    Syntax: SO Adresse [Wert]
    Adresse: Die Adresse einer EEPROM-Variablen. Die IB ermöglicht Adressen von 0..999. OpenDCC hat eine andere Belegung der Adressen (siehe Sourcecode). Ein Ausnahme gilt für SO 1: hier wird bei einer Abfrage der interne ENUM für die BAUDRATE (welcher normalerweise der Lenz-Zählweise entspricht) auf die Intellibox Syntax umgesetzt. Damit funktionieren dann auch das pseudointelligente Verfahren von TC, bei bereits bestehender Verbindung nochmal anhand von SO 1 die Baudrate umzustellen.
    Zur weitestgehenden Kompatibilität mit railware sind die von Railware nachgefragten Sonderoptionen mit möglichst sinnvollen Werten vorbelegt.
  • PT: Einschalten oder Ausschalten Programmier-Modus
    Syntax: PT [0|1]
    0 schaltet Programmiermode aus, 1 schaltet ein. kein Parameter: aktueller Zustand wird angezeigt.
  • PTRD: Lesen DCC-CV per Bytebefehle
    Syntax: PTRD [CV]
    Parameter: CV: 1..1024
    Antwort: Okay, gefolgt vom Inhalt der CV oder failed
      Hinweise:
    • Das Lesen erfolgt auf dem Programmiergleis-Ausgang.
    • Ist das Lesen nicht möglich (Ack kommt nicht), geht die Zentrale in ein Timeout (gelbe Prog-Led blinkt).
    • Manche Dekoder verhalten sich nicht normgerecht, hier müssen fallweise mehr Resetpakete oder längere Pausen eingefügt werden, näheres hierzu siehe bei den Konfigurations-Optionen. (Die Defaulteinstellung paßt in der Regel.)
    • Ein Lesen der internen CVs ist möglich, wenn beim Einschalten der Zentrale die GO-Taste gedrückt wird.
  • PTWD: Schreiben DCC-CV per Bytebefehle
    Syntax: PTRD [CV, Byte]
    Parameter: CV: 1..1024, Byte: das wird geschrieben
    Antwort: Okay oder failed
  • PA: Schreiben DCC-CV per Programming on the main, für Accessory Decoder
    Syntax: PA [Addr, CV, Byte]
    Parameter: Addr 0..510 Decoderadresse (nicht Weichenadressen)
          CV: 1..1024: zu beschreibende Config Variable
          Byte: Dateninhalt Antwort: Okay oder failed
  • PAR: Lesen DCC-CV per Programming on the main und BiDi, für Accessory Decoder
    Syntax: PAR [Addr, CV]
    Parameter: Addr 0..510 Decoderadresse (nicht Weichenadressen)
    Parameter: CV: 1..1024
    Antwort: gelesenes Byte (z.B. 0xAB) oder failed
    Enthalten ab V0.23.6; CV wird ab 1 beginnend gezählt.
  • PAWX: Schreiben DCC-CV per Programming on the main, für Extended Accessory Decoder
    Syntax: PA [Addr, CV, Byte]
    Parameter: Addr 0..2039 Adresse (beginnend bei 0)
          CV: 1..1024: zu beschreibende Config Variable
          Byte: Dateninhalt Antwort: Okay oder failed
    Enthalten ab V0.23.8; CV wird ab 1 beginnend gezählt.
  • PARX: Lesen DCC-CV per Programming on the main und BiDi, für Accessory Decoder
    Syntax: PARX [Addr, CV]
    Parameter: Addr 0..2039 Adresse (beginnend bei 0)
    Parameter: CV: 1..1024
    Antwort: gelesenes Byte (z.B. 0xAB) oder failed
    Enthalten ab V0.23.8; CV wird ab 1 beginnend gezählt.
  • PD: Schreiben DCC-CV per Programming on the main, für Lok Decoder
    Syntax: PD [Addr, CV, Byte]
    Parameter: Addr 1..10239 Lokadresse
          CV: 1..1024
          Byte: Dateninhalt Antwort: Okay oder failed
  • PDR: Lesen DCC-CV per Programming on the main und BiDi, für Lokomotiv Decoder
    Syntax: PDR [Addr, CV]
    Parameter: Addr 1..10239 Lokadresse
    Parameter: CV: 1..1024
    Antwort: Okay oder failed
    Die Unterscheidung, ob eine Lok mit kurzer oder langer Adresse angesprochen wird erfolgt automatisch. Das Rücklesen der CV ist zur Zeit noch nicht möglich, dies muß (noch) extern erfolgen, es wird nur der Befehl ausgesendet. Hier kann sich in Zukunft die Antwort noch ändern.
    Enthalten ab V0.23; Die Tams-EC hat dieses Kommando als RCR bezeichnet, OpenDCC unterstützt das auch.

P50Xb-Kommandos (Binary-Commands):

    Wenn nach dem einleitenden 'X' ein Zeichen mit einer Binärcodierung >0x80 kommt, so wird das Binärprotokoll angesprochen. Wenn OpenDCC auf *nur* P50Xb eingestellt ist, so ist das führende 'X' wegzulassen.

    Das erste Zeichen (Byte) ist das Kommandobyte und legt fest, wieviele Parameter-Bytes folgen. Diese Kommando wird in jedem Fall sofort quittiert (Returncode). Wenn mit dem Kommando eine längere Aktion verbunden war (z.B. ein Programmierbefehl) so ist das Ergebnis dieses Befehls mit einem Abfragebefehl zu holen.

    Die jeweilige Antwort kann auch eine längere Liste (fallweise verkettet) von einzelnen Bytes sein. Hierbei verwendet das IB-Protokoll unterschiedliche Techniken:
    1. Mit einem MSB (Erweiterungsbit) wird eine weiteres Antwort-Byte angekündigt.
    2. Die erste Antwort enhält eine Kodierung, ob weitere Antworten folgen. Diese Antworten können auch jeweils Pakete von Bytes sein.
    3. Die Antwort beginnt mit der Zahl, wie viele Antwortpakete übermittelt werden.
    Offenbar ist das IB-Protokoll ziemlich historisch gewachsen und von verschiedenen Entwicklern im Freestyle entworfen worden :-(

    Kommandoliste:
  • XLok (0x80) - Länge = 1+4 bytes
    Befehlsbytes:
            0: 0x80 XLok
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Speed (0 .. 127). (unabhängig von Lokformat)
            4: Funktion- und Statusbits:
                bit#   7     6     5     4     3     2     1     0
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    |Chg-F| Forc| Dir | F0  | F4  | F3  | F2  | F1  |
                    +-----+-----+-----+-----+-----+-----+-----+-----+
               Chg-F:     wenn 1: die Bits F4 .. F1 als Funktionsbits übernehmen, bei 0 ignorieren.
               Force:     wird von OpenDCC ignoriert, ein Lokcommand gilt immer.
               Dir:       Fahrtrichtung: 1 = vorwärts, 0 = rückwärts
               F0:        Frontlicht (FL): 1 = an, 0 = aus
               F4..F1:    Status der Funktionen F1 .. F4 (nur wenn Bit F-Valid gesetzt)
    Antwort: 1 Byte:  0 oder Error-Code
    Mögliche Error-Codes: OK - OK, Befehl ausgeführt XBADPRM - Lokadresse außerhalb des Bereichs (1 .. 10239) XNOSLOT - Z.Zt. kann die Lok nicht in die Queues aufgenommen werden (zu viele Befehle) Befehl später wiederholen. XLKHALT - OpenDCC ist im HALT-Modus. Der Befehl wurde akzeptiert (bezüglich der Funktionen und der Fahrtrichtung) aber mit V=0 in die Buffer aufgenommen. XLKPOFF - OpenDCC ist im STOP-Modus. Der Befehl wurde akzeptiert (bezüglich der Funktionen und der Fahrtrichtung) aber mit V=0 in die Buffer aufgenommen und nicht ans Gleis gesendet.
  • XLokX (0x81) - Länge = 1+4 bytes
    Dies ist eine Erweiterung von TAMS. Ist fast identisch zu XLok, jedoch mit echter Decoderspeed. Wird von OpenDCC_XP ab V0.23 unterstützt.
    Befehlsbytes:
            0: 0x81 XLokX
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Speed (0 .. 127). (abhängig von Lokformat, echte Decoderspeed:  0..14/28/126) (1 bedeutet fahren)
            4: Funktion- und Statusbits:
                bit#   7     6     5     4     3     2     1     0
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    |Chg-F| Forc| Dir | F0  | F4  | F3  | F2  | F1  |
                    +-----+-----+-----+-----+-----+-----+-----+-----+
               Chg-F:     wenn 1: die Bits F4 .. F1 als Funktionsbits übernehmen, bei 0 ignorieren.
               Force:     wird von OpenDCC ignoriert, ein Lokcommand gilt immer.
               Dir:       Fahrtrichtung: 1 = vorwärts, 0 = rückwärts
               F0:        Frontlicht (FL): 1 = an, 0 = aus
               F4..F1:    Status der Funktionen F1 .. F4 (nur wenn Bit F-Valid gesetzt)
    Antwort: 1 Byte:  0 oder Error-Code
    Mögliche Error-Codes: OK - OK, Befehl ausgeführt XBADPRM - Lokadresse außerhalb des Bereichs (1 .. 10239) XNOSLOT - Z.Zt. kann die Lok nicht in die Queues aufgenommen werden (zu viele Befehle) Befehl später wiederholen. NOSLOT wird auch gemeldet, wenn die Lok noch nicht (oder nicht mehr) im Lokstack ist. Ausnahme: Die übergebene Speed ist 0, dann wird die Lok neu in den Stack aufgenommen. XLKHALT - OpenDCC ist im HALT-Modus. Der Befehl wurde akzeptiert (bezüglich der Funktionen und der Fahrtrichtung) aber mit V=0 in die Buffer aufgenommen. XLKPOFF - OpenDCC ist im STOP-Modus. Der Befehl wurde akzeptiert (bezüglich der Funktionen und der Fahrtrichtung) aber mit V=0 in die Buffer aufgenommen und nicht ans Gleis gesendet.
    Hier wird die Speed in tatsächlicher Fahrstufe des Dekoders übergeben, wobei die Nothaltstufe nicht mit verwendet wird. Zum Nothalt muß der Befehl XLok verwendet werden. Damit OpenDCC weiß, wie die Lok anzusteuern ist, muß sie vorher einmal in den Lokstack aufgenommen werden. Das erfolgt normalerweise mit Xlok, ausnahmeweise auch mit XLokX und Fahrstufe 0. (Bedingt durch die Fähigkeit von OpenDCC_XP, zwei Interfaces parallel zu bedienen, kann der theorische Fall eintreten, dass eine Lok trotz anders lautenden Datenbankeintrag in einem unbekannten Format gesteuert wird; um in so einem Fall das doppelte Durchsuchen von Lokstack und Datenbank zu vermeiden, ist diese Einschränkung getroffen worden.)
  • XLkDisp (0x83)
    Dispatchstatus; wird von OpenDCC nicht unterstützt.
  • XLokSts (0x84) - Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x84 XLokSts
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
    
    Antwort: 1 / 4 Bytes
            0: Error-Code. Wenn OK (0x00), dann folgend die weiteren Antwort-Bytes
            1: Speed (0 .. 127). 1 bedeutet Emergency-Stop.
            2: Funktionen und Richtung (wie bei XLok):
               bit#   7     6     5     4     3     2     1     0
                   +-----+-----+-----+-----+-----+-----+-----+-----+
                   |  0  |  0  | Dir | F0  | F4  | F3  | F2  | F1  |
                   +-----+-----+-----+-----+-----+-----+-----+-----+
    
               Dir     Fahrtrichtung wie beim XLOK-Command: 1 = vorwärts, 0 = rückwärts
               F0      Frontlicht (FL): 1 = an, 0 = aus
               F4..F1  Status der Funktionen F1 .. F4
            3: Echte Lok-Geschwindigkeit wie sie am Gleis ausgegben wird (je nach Lokformat)
               0 = Stop, 1 .. 15/29/127 (das MSB ist ab Version 0.23.8 maskiert)
    
       Mögliche Error-Codes:
            OK       - OK, Befehl ausgeführt
            XBADPRM  - Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA  - Es liegen keine Lokdaten vor (Lok nicht in Refresh-Queue)
    
  • XLokCfg (0x85) - Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x85 XLokCfg
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
    
    Antwort: 1 / 5 Bytes
            0: Error-Code. Wenn OK (0x00), dann folgen vier weitere Antwort-Bytes
            1: Lok-Format: bei OpenDCC immer 2, bedeutet DCC
            2: Anzahl Geschwindigkeitsstufen (ohne Stop): 14, 28 oder 126
            3: 0xFF (bei IB zur Kennzeichnung virtueller Loks -> gibt es hier nicht)
            4: 0xFF (bei IB zur Kennzeichnung virtueller Loks -> gibt es hier nicht)
    
    Mögliche Error-Codes:
            OK        - OK, Befehl ausgeführt
            XBADPRM        - Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA - Es liegen keine Lokdaten vor (Lok nicht in Refresh-Queue)
    
  • XLokCfgSet (0x86) - Länge = 1+4 bytes
    Diese Kommando gibt es bei der IBox nicht, Tams hat es dankenswerterweise
    kompatibel übernommen.
    Befehlsbytes:
            0: 0x86 XLokCfg
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Lok-Format: wird von OpenDCC ignoriert (wir sprechen nur DCC ;-)
            4: Anzahl Geschwindigkeitsstufen (ohne Stop): 14, 28 oder 126
    
    Antwort: 1 Byte
            0: Error-Code
    
    Mögliche Error-Codes:
            OK        - OK, Befehl ausgeführt
            XBADPRM   - Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNOSLOT   - Zu viele Loks mit extra Format (vielleicht sollte ein solcher Anwender
                        das default-Format umstellen).
    
    Erläuterung: Die Lok wird durch dieses Kommando *nicht* aufgerufen, sondern es wird nur
    das Format festgelegt. Wenn das Format dem voreingestelltem Format entspricht,
    so passiert nichts weiter. Wenn es nicht der Voreinstellung entspricht, so wird diese
    Lokadresse als Ausnahme permanent im EEPROM gespeichert;
    es gibt 64 Speicherplätze für solche Ausnahmen.
    
  • XFunc (0x88)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0x88 XFunc
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Status: F1 (bit #0) .. F8 (bit #7)
    
    Antwort: 1 Byte 0 oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNOSLOT   - 0x0B: Queues sind voll, Kommando wurde verworfen.
    
  • XFunc2 (0x89)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0x89 XFuncX
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Status: F9 (bit #0) .. F16 (bit #7)
    
    Antwort: 1 Byte 0 oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNOSLOT   - 0x0B: Queues sind voll, Kommando wurde verworfen.
    
    Hinweis: OpenDCC unterstützt nur F1 bis F12, F13 bis F16 wird nicht ausgeführt; OpenDCC_XP unterstützt bis F16.
    
  • XFunc34 (0x8A)- Länge = 1+4 bytes
    Befehlsbytes:
            0: 0x8A XFunc34
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: F24..F17
            4: xxxx.F28..F25 (oberes nibble ist nicht benutzt)
    
    Antwort: 0 oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA   - 0x0A: Die Lok ist nicht im Refreshbuffer
    
    Hinweis: OpenDCC unterstützt nur F1 bis F12.
             OpenDCC_XP unterstützt bis F28
    
  • XFuncSts (0x8C)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x8C XFuncSts
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
    
    Antwort: 0 (gefolgt von einem Byte) oder Error-Code
            Status: F1 (bit #0) .. F8 (bit #7)
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA   - 0x0A: Die Lok ist nicht im Refreshbuffer
    
  • XFuncXSts (0x8D)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x8D XFuncXSts
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
    
    Antwort: 0 (gefolgt von einem Byte) oder Error-Code
            Status: F9 (bit #0) .. F16 (bit #7)
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA   - 0x0A: Die Lok ist nicht im Refreshbuffer
    
    Hinweis: OpenDCC unterstützt nur F1 bis F12, für F13 bis F16 wird 0 zurückgeliefert.
             OpenDCC_XP unterstützt bis F28
    
  • XFunc34Sts (0x8E)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x8E XFunc34Sts
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
    
    Antwort: 0 (gefolgt von zwei Bytes) oder Error-Code
            Status: F17 (bit #0) .. F23 (bit #7)  und F25 .. F28; die oberen 4 Bit bleiben frei.
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNODATA   - 0x0A: Die Lok ist nicht im Refreshbuffer
    
    Hinweis: OpenDCC unterstützt nur F1 bis F12, für F13 bis F16 wird 0 zurückgeliefert.
             OpenDCC_XP unterstützt bis F28
    
  • XLimit (0x8F)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0x8A XLimit
            1: LSB der Lokadresse
            2: MSB der Lokadresse (Adresse im Bereich 1 .. 10239)
            3: Limitbyte
               enable restricted speed (bit #7 = 1) or disable it (bit #7 = 0)
            value for restricted speed (bit #0 .. bit #5)
    
    Antwort: 1 Byte 0 oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XBADPRM   - 0x02: Lokadresse außerhalb des Bereichs (1 .. 10239)
            XNOSLOT   - 0x0B: Queues sind voll, Kommando wurde verworfen.
    
    Hinweise:
    Dieser Befehl sendet auf dem Gleis die "Restricted Speed Step Instruction" gemäß NMRA 9.2.1.
    Dieser Befehl ist nur in der Xpressnetversion (OpenDCC_XP) verfügbar. Bis Version 0.23.8 war dieser Befehl auf 0x8A kodiert, mit Erscheinen der Version 2 der IB gab es auf 0x8A Kollisionsgefahr.
  • XTrnt (0x90)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x90 XTrnt (= turnout bzw. Schaltbefehl)
            1: LSB der Weichenadresse (A7 ... A0)
            2: MSB der Weichenadresse und Statusbits (Farbe und Spuleaktivierung)
               (Adresse im Bereich 1 .. 2043)
                bit#   7     6     5     4     3     2     1     0
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    |Color| Sts | Res |NoCmd| A11 | A10 |  A9 |  A8 |
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                Bedeutung:
                  A10..A0: Addr of Turnout -> max. 2043 (A11 = reserved). beginnend bei 1.
                           (die IB erlaubt hier weniger)
                           Hinweis: Es können zwar alle Adressen angesteuert werden,
                           jedoch nur die Lage der untersten 512 wird im OpenDCC
                           gespeichert. (siehe SIZE_TURNOUTBUFFER).
                  Color:   1 = closed (grün), 0 = thrown (rot)
                           (Hinweis: wird bei Lenz anders herum interpretiert)
                  Sts:     Spulenzustand: (1 = ein, 0 = aus)
                  Res:     Hier könnte man eine Weiche verriegeln - macht OpenDCC nicht
                           (und offenbar auch die Intellibox nicht)
                  NoCmd:   wird ingoriert.
    
    Antwort: 0  oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XPWOFF    - 0x06: abgeschaltet!
            XBADPRM   - 0x02: Weichenadresse außerhalb des Bereichs (1 .. 4095)
            XLOWTSP   - 0x40: Die Queue ist fast voll
    
    Hinweis: die IB weicht hier unnötig von der DCC Spec ab: Weiche 1 wird intern auf Ausgang 0 abgebildet. Das ist bei Lenz immer direkt gelöst.
  • XTrntX (0x91)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0x91 XTrntX (= turnout bzw. Schaltbefehl)
            1: LSB Dekoderadresse (A7 ... A0)
            2: MSB der Dekoderadresse und Signal-Begriff
               (Adresse im Bereich 0 .. 2043)
                bit#   7     6     5     4     3     2     1     0
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    | B4  | B3  | B2  | B1  | B0  | A10 | A9  | A8  |
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                Bedeutung:
                  A10..A0:  Addr of Decoder (echte DCC Adresse)
                  B4..B0:  Aspect
    
    Antwort: 0  oder Error-Code
    
    Mögliche Error-Codes:
            OK        - 0x00: OK, Befehl ausgeführt
            XPWOFF    - 0x06: abgeschaltet!
            XBADPRM   - 0x02: Weichenadresse außerhalb des Bereichs (1 .. 4095)
            XLOWTSP   - 0x40: Die Queue ist fast voll
    
    (Dieser Befehl ist nur in der XP-Version verfügbar, ab V0.23)
  • XTrntFree (0x93)- Länge = 1 Byte
    Nicht unterstützt: es gibt keine Weichenreservierung in OpenDCC
    
    Antwort: 0 = Ok, accepted
    
  • XTrntSts (0x94)- Länge = 1+2 Bytes
    Befehlsbytes:
            0: 0x94 XTrntSts (= turnout bzw. Schaltbefehl - Status Abfrage)
            1: LSB der Weichenadresse (A7 ... A0)
            2: MSB der Weichenadresse
    
    Antwort: 0 = Ok, accepted (ein Byte folgt)
             oder Fehlercode
             2. Byte    7     6     5     4     3     2     1     0
                     +-----+-----+-----+-----+-----+-----+-----+-----+
                     |n.u. |n.u. |n.u. |n.u. |Conf1|color| Res |Conf0|
                     +-----+-----+-----+-----+-----+-----+-----+-----+
    
                    Conf0/1:  00              Motorola
                              10              DCC
                              01              SX
                              11              FMZ
    
             Hinweis: OpenDCC liefert immer DCC zurück;
                      Nach Kaltstart: immer "rot", "nicht reserviert"
             mögliche Fehlercode:
                    XBADPRM (02h)       illegal parameter value
                    XBADTNP (0Eh)       Error: illegal Turnout address for this protocol
    
    
    Hinweis: Wegen beschränkter RAM-Resourcen können nich alle Weichenlagen gespeichert werden. Zur Zeit ist der Speicher auf 512 Weichen beschränkt: (siehe config.h, SIZE_TURNOUTBUFFER).
  • XTrntGrp (0x95)- Länge = 1+1 Bytes
    Befehlsbytes:
            0: 0x95 XTrntGrp (= turnout bzw. Schaltbefehl - Status Abfrage, gruppenweise)
            1: Adresse der Gruppe: address = ((turnout address - 1) / 8) + 1;
            2: MSB der Weichenadresse
    
    Antwort: 0 = Ok, accepted (zwei Bytes folgen)
             oder Fehlercode
             2. Byte    7     6     5     4     3     2     1     0
                     +-----+-----+-----+-----+-----+-----+-----+-----+
                     |  W8 |  W7 |  W6 |  W5 |  W4 |  W3 |  W2 |  W1 |
                     +-----+-----+-----+-----+-----+-----+-----+-----+
                Bitfeld mit den Positionen der Weichen: jedes Bit steht für eine
                Weiche,  1 = gerade/grün, 0 = abbiegen/rot;
             3. Byte
                Bitfeld mit den "Reservierungsflags" der Weichen;
                wird von OpenDCC nicht unterstützt, immer als 0 zurückgemeldet.
    
             Hinweis: Nach Kaltstart: immer "rot", "nicht reserviert"
             mögliche Fehlercode:
                    XBADPRM (02h)       illegal parameter value
    
    
    Hinweis: Wegen beschränkter RAM-Resourcen können nich alle Weichenlagen gespeichert werden. Zur Zeit ist der Speicher auf 512 (1024 bei OpenDCC_XP) Weichen beschränkt: (siehe config.h, SIZE_TURNOUTBUFFER).
  • XSensor (0x98)- Länge = 1+1 Bytes
    Befehlsbytes:
            0: 0x98 XSensor (Abfrage S88 Rückmelder)
            1: s88 Modulnummer (1..128) (Modul = 16 Bits)
    
    Antwort: 1. Byte: 0 = Ok, accepted (zwei Bytes folgen)
                      oder Fehlercode (02 = XMsg_BADPRM = angefragter Melder > konfigurierte Melder)
             2. Byte  Kontakte 1..8 dieses Moduls (Bits 7..0)
             3. Byte  Kontakte 9..16 dieses Moduls
    
    
    Im Gegensatz zur IB liefert OpenDCC immer den akkumulierten Status der S88 Bits. Beim Lesen werden auch die Change-Flags zurückgenommen.
    (@modeltreno: wer hat eigentlich diese Bitanordnung verbrochen?)
  • XSensOff (0x99)- Länge = 1 Byte
    Befehlsbytes:
            0: 0x99 XSensOff (Löschen und Rücksetzen S88)
    
    Antwort: 1. Byte: 0 = Ok, accepted
    
    
    Löscht alle S88-Bits auf Null und löscht alle Change-Flags.
  • XP88Get (0x9C)- Länge = 1+1 Bytes
    Befehlsbytes:
            0: 0x9C XP88Get (Einlesen der S88 Konfiguration)
            1: Parameternummer:
               0: Zahl der automatisch gelesenen Bytes
               1: Zahl der Bytes auf Port 1
               2: Zahl der Bytes auf Port 2
               3: Zahl der Bytes auf Port 3
               4: Zahl der Weichenrückmelder (entspricht CV31)
    
    Antwort: 1. Byte: 0 = Ok, accepted oder Fehlercode
             2. Byte: Wert des abgefragten Parameters
    
    
    Hinweis: die orginal IB liefert bei 1 und 2 die Quelle für Timer und Counter zurück; dies gibt es bei OpenDCC nicht und ist durch die Angabe der Länge der Teilstrings ersetzt worden.
    TC benutzt dieses Kommando mit Parameter 0.
    Rechenregel: XP88Get(0) = max(XP88Set(0), Summe_S88)
    wobei gilt: Summe_S88 = max(Size1+Size2+Size3, feedback_offset + feedback_size)
  • X88PSet (0x9D)- Länge = 1+2 Bytes
    Befehlsbytes:
            0: 0x9D XP88Set (Einstellen der S88 Konfiguration)
            1: Parameternummer:
               0: Zahl der automatisch gelesenen Bytes
               1: Zahl der Bytes auf Port 1
               2: Zahl der Bytes auf Port 2
               3: Zahl der Bytes auf Port 3
               4: Zahl der Bytes für Weichenrückmeldung
    
    Antwort: 1. Byte: 0 = Ok, accepted oder Fehlercode
    
    
    Hinweise: die orginal IB stellt bei 1 und 2 die Quelle für Timer und Counter ein; dies gibt es bei OpenDCC nicht und ist durch die Angabe der Länge der Teilstrings ersetzt worden.
    Die Längen der Teilstrings können auch durch entsprechende Sonder-Optionen eingestellt werden. Die Maximalzahl unter Parameter 0 wird nur für die Festlegung der Arraygröße verwendet, eine automatischen Aufteilung in Teilstrings erfolgt nicht.
    Bitte beachten: Hier werden Bytes eingestellt, nicht Module; ein Modul hat üblicherweise 2 Byte.
    Wichtig: Es ist ein Neustart von OpenDCC erforderlich, damit die Einstellung wirksam wird.
  • Xs88Tim (0x9E)- Länge = 1+1 Bytes
    
    Hinweis: wird von OpenDCC nicht unterstützt. Wer braucht das?
  • Xs88Cnt (0x9F)- Länge = 1+1 Bytes
    
    Hinweis: wird von OpenDCC nicht unterstützt. Wer braucht das?
  • XVer (0xA0)- Länge = 1 Bytes
    Befehlsbytes:
            0: 0xA0 XVer (Versionsabfrage)
    
    Antwort: Liste, jeder Eintrag ist wie folgt aufgebaut:
             1. Byte: Zahl der Bytes in diesem Listenelement (0 bedeutet Liste
                      zu Ende)
             2. Byte: Niederwertiges Byte der Version.
             3.-n. Byte: Höherwertigere Bytes, sofern vorhanden.
    
    Im Falle OpenDCC bis Version 0.14 gibt es nur einen Listeneintrag der Länge 1. Ab Version 0.15
    werden 2 Byte zurückgeliefert - Softwareversion und Seriennummer. Damit lassen sich unterschiedliche
    Boxen unterscheiden.
    
    Beispiel:  0x02 = Länge 2
               0x0F = Version 0.15
               0x01 = Seriennummer 1
               0x00 = Ende der Liste
    
    Ab Version 0.23.8 liefert die Software OpenDCC_XP folgende Antwort zurück (Umstellung ab 10.03.2011):
               0x02 = Länge 2
               0x17 = Version 23
               0x08 = Subversion 8
               0x01 = Länge 1
               0x01 = Seriennummer 1
               0x00 = Ende der Liste
    
    Hinweis: die orginal IB liefert 6 Listenelemente inkl. einer Seriennummer zurück.
  • XP50XC (0xA1)- Länge = 1+1 Bytes
    
    Umstellen des "Escape-Zeichen" für das P50X Protokoll auf ein anderes Zeichen.
    Dies benutzt offenbar kein PC-Programm und wird auch von OpenDCC nicht unterstützt.
    War wohl von modeltreno eingebaut worden, um auf
    irgendwelche heimtückischen Protokolländerung von Tante M reagieren zu können.
  • XStatus (0xA2)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xA2 XStatus (Statusabfrage für Spannung, Zustand usw.)
    
    Antwort: Bitfeld, folgende Zuordnung:
             Bit 7:  Erweiterungsbit, wenn 1, kommt noch ein weiteres Byte als Antwort.
                     (momentan immer 0)
             Bit 6:  VREG: 1: Spannungsregelung eingeschaltet (ist bei OpenDCC gesetzt)
                           0: keine Spannungsregelung
             Bit 5:  I2C   1: externes I2C Gerät vorhanden
                           0: nichts angeschlossen (OpenDCC)
             Bit 4:  HALT  1: Loks angehalten, aber Gleisspannung vorhanden
             Bit 3:  PWR:  1: Zustand "EIN", grüne LED leuchtet.
                           0: Zustand "AUS", rot leuchtet.
             Bit 2:  HOT   1: zu heiss
                           0: (OpenDCC)
             Bit 1:  GO    1: falls gerade der grüne Taster gedrückt wird. (keine Entprellung)
             Bit 0:  STOP  1: falls gerade der rote Taster gedrückt wird. (keine Entprellung)
    
    
    Hinweis: Der HALT Zustand wird, da er bei der IB manuell nicht ausgelöst werden kann, von Steuerungsprogrammen (wie z.B. TC von Freiwald) einfach ignoriert (grrml!).
  • XSOSet (0xA3) - Länge = 1+3 Bytes
    Befehlsbytes:
            0: 0xA3 XSOSet (Spezial-Option setzen)
            1: Adresse niederwertiger Teil.
            2: Adresse höherwertiger Teil. Gültiger Bereich 0...1023
            3: Inhalt
    
    Antwort: entweder 0 (Kommando okay) oder Fehlercode
    
    Hinweis: Dieses Kommando gibt es bei der Orginal Intellibox nicht, es ist eine Erweiterung von OpenDCC.
    Achtung: Mit Bedacht verwenden, es können Variablen so verändert werden, dass OpenDCC nicht mehr funktioniert.
  • XSOGet (0xA4)- Länge = 1+2 Bytes
    Befehlsbytes:
            0: 0xA4 XSOGet (Spezial-Option auslesen)
            1: Adresse niederwertiger Teil.
            2: Adresse hoeherwertiger Teil. Gültiger Bereich 0...1023
    
    Antwort: entweder 0 (Kommando okay, ein Byte wird folgen) oder Fehlercode
             2. Byte: Inhalt der Spezual-Option
    
    Hinweis: Die Spezial-Optionen sind in Ihrer Adresse so gewählt, daß bestmögliche Übereinstimmung mit der Intellibox erreicht wird. Der Grund war die Analyse diverser Einstellungen durch railware, durch die Belegung wird die "Meckerquote" von railware reduziert.
    Hinweis: SO 1 wird beim Lesen umkodiert, jedoch nicht beim Schreiben.
  • XHalt (0xA5)- Länge = 1 Bytes
    Befehlsbytes:
            0: 0xA5 XHalt (Loks anhalten aber DCC bleibt aktiv)
    
    Antwort: 0 (Kommando okay)
    
    Hinweis: Offenbar benutzt kein Steuerprogramm diese Option, die schalten immer gleich ab.
  • XPwrOff (0xA6)- Länge = 1 Bytes
    Befehlsbytes:
            0: 0xA6 XPwrOff (DCC Hauptgleis ausschalten)
    
    Antwort: 0 (Kommando okay)
    
  • XPwrOn (0xA7)- Länge = 1 Bytes
    Befehlsbytes:
            0: 0xA7 XPwrOn (DCC Hauptgleis einschalten)
    
    Antwort: 0 (Kommando okay)
    
  • XClkSet (0xC0) - Länge = 5 Bytes
    Befehlsbytes:
            0: 0xC0 XClkSet: Stellen der Modellbahnuhr (Layout Time, Fast Clock)
            1: TCODE0: 00mmmmmm, this denotes the minute, range 0..59.
            2: TCODE1: 100HHHHH, this denotes the hour, range 0..23
            3: TCODE2: 01000WWW, this denotes the day of week,
                                 0=Monday, 1=Tuesday, 2=Wednesday, 3=Thursday, 4=Friday, 5=Saturday, 6=Sunday.
            4: TCODE3: 110FFFFF, this denotes the acceleration factor, range 0..31;
                                 an acceleration factor of 0 means clock is stopped,
                                 a factor of 1 means clock is running real time,
                                 a factor of 2 means clock is running twice as fast a real time.
    Antwort: 0 (Kommando okay), BADPRM (falscher Parameter) oder NOSLOT (Kommando-Queue ist voll)
    
    NEU:Dieser Befehl dient zum Steuern der Uhrzeit im DCC System, die Bytes 1 bis 4 entsprechen der DCC-Nachricht. Der Beschleundigungsfaktor darf nur geändert werden, wenn zuvor die Uhr mit einem Faktor 0 gestoppt wurde. Die Uhr darf zu jeder Zeit überschrieben werden. Bei Empfang dieses Befehls wird auf dem DCC Signal eine Clocknachricht erzeugt, auch wenn diese nicht im bisherigen Takt liegt.
    Das Zeitsystem sollte entweder in der Zentrale oder im PC vorgegeben werden: Wenn das PC Programm den Fast Clock selbst erzeugt, so wird periodoisch das Kommando an die Zentrale gesendet. Diese sendet dann die Clocknachricht auf das Gleis. Oder: Wenn in der Zentrale der Faktor eingestellt ist, dann sendet die Zentrale selbst das Clock Kommando auf das Gleis.
    Wenn beides zugleich gemacht wird, führt das zu (unerwünschten und nicht normgerechten) Doppelbefehlen, welche Sounddecoder irritieren.
  • XClkGet (0xC1) - Länge = 1 Bytes
    Befehlsbytes:
            0: 0xC1 XClkGet: Abfragen der Modellbahnuhr
    Antwort: 4 Bytes
            0: TCODE0: 00mmmmmm, this denotes the minute, range 0..59.
            1: TCODE1: 100HHHHH, this denotes the hour, range 0..23
            2: TCODE2: 01000WWW, this denotes the day of week,
                                 0=Monday, 1=Tuesday, 2=Wednesday, 3=Thursday, 4=Friday, 5=Saturday, 6=Sunday.
            3: TCODE3: 110FFFFF, this denotes the acceleration factor, range 0..31;
                                 an acceleration factor of 0 means clock is stopped,
                                 a factor of 1 means clock is running real time,
                                 a factor of 2 means clock is running twice as fast a real time.
    
    NEU:Die Bytes 0 bis 3 entsprechen der letzten ausgegebenen DCC-Nachricht.
  • XNop (0xC4)- Länge = 1 Bytes
    Befehlsbytes:
            0: 0xC4 XNop (nichts tun)
    
    Antwort: 0 (Kommando okay)
    
    Klar, "Nichts tun", das können wir, da sind wir stark! Nein, im Ernst: der Befehl dient für das komische BABI bei der Vielfalt der IB-Protokoll-Untervarianten zum Rausfinden der Baudrate.
  • XP50Len1 (0xC6)- Länge = 1+1 Bytes
    
    Dieser Befehl dient bei der orginal Intellibox zum Durchreichen des Befehl an das darunter liegende
    P50 Protokoll. Man war sich offenbar bei modeltreno nicht wirklich sicher und hat sich neben dem X-Char
    Befehl noch ein weiteres Hintertürchen aufgehalten.
    
    Wird von OpenDCC nicht unterstützt.
  • XP50Len2 (0xC7)- Länge = 1+2 Bytes
    
    Noch so eine Geheimtür wie oben.
    
  • XEvent (0xC8)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xC8 XEvent (Statusabfrage für Zustandsänderungen, wie z.B. S88, Programmierung usw.)
    
    Antwort: Liste von Bitfeldern (8 Bit) , jeweils das MSB zeigt an, ob noch ein weiteres
             Bitfeld folgt:
             Byte 1:
               Bit 7:  Erweiterungsbit, wenn 1, kommt noch ein weiteres Byte als Antwort.
               Bit 6:  LSY   1: da war ein Lissy Event
               Bit 5:  TRNT  1: da war mindestens ein Weichen-Event (**)
               Bit 4:  Tres  1: da war mindestens ein Zugriff auf eine reservierte Weiche
               Bit 3:  PWR   1: da war mind. ein Power Off Event (*)
               Bit 2:  S88   1: da war mind. ein s88-Event (*)
               Bit 1:  GO    1: da war ein IR-Event
               Bit 0:  LOK   1: da war mind. ein Zugriff auf eine Lok (**)
             Byte 2:
               Bit 7:  Erweiterungsbit, wenn 1, kommt noch ein weiteres Byte als Antwort.
               Bit 6:  Sts:  1: Aenderung im Status
               Bit 5:  Hot   1: Temperaturanzeige
               Bit 4:  PTsh  1: Schluss vom Programmiergleis zum Hauptgleis
               Bit 3:  RSsh  1: Schluss auf dem Programmiergleis oder auf dem Boosteranschluß
               Bit 2:  IntSh 1: Kurzschluss intern
               Bit 1:  LMSh  1: Kurzschluss auf den Lokmausanschluß
               Bit 0:  ExtSh 1: Kurzschlussmeldung eines externen Boosters
             Byte 3:
               Bit 7:  Erweiterungsbit, wenn 1, kommt noch ein weiteres Byte als Antwort.
               Bit 6:  EvBiDi: ( Neu: BiDi: Orts- oder Geschwindigkeitsrückmeldung eingetroffen, Abfrage mit XEvtBiDi)
               Bit 5:  BiDiCV: ( Neu: BiDi: CV-Meldung eingetroffen, Abfrage mit XEvtPT)**
               Bit 4:  ExVlt 1: Fremdspannung vorhanden
               Bit 3:  TkRel 1: Uebernahme einer Lok durch andere Controller
               Bit 2:  Mem   1: Memory Event
               Bit 1:  RSOF  1: RS232 Overflow
               Bit 0:  PT    1: Programming Track Event (*)
    
    
      Hinweise:
    • OpenDCC liefert nur die (*) gekennzeichneten Statusbits. OpenDCC_XP zusätzlich die mit (**) gekennzeichneten Bits.
    • OpenDCC_XP kann zusammen mit einen BiDi-fähigen Rückmelder am Xpressnet PoM Read machen; das Ergebnis wird über Bit 5 im Byte 3 (BiDiCV) angekündigt.
    • BiDiCV: Dieses Bit wird gesetzt, wenn eine CV-Rückmeldung über BiDi erfolgte. Diese Byte kann dann über XEvtPT (0xCE) ausgelesen werden. Das Bit wird gelöscht, wenn XEvtPT aufgerufen wird.
      Das entspricht dem bisherigen Programming Mode, birgt aber die Gefahr, dass wenn vom PC und von Handregler gleichzeitig PoM absetzt werden, nicht der korrekte Dateninhalt angezeigt werden könnte)
    • EvBiDi: Dieses Bit wird gesetzt, wenn seit dem letzten Auslesen von Xevent mind. ein BiDi-Ereignis (Speed oder Ortsänderung) aufgetreten ist. Das Bit wird nach dem Lesen von Xevent gelöscht. Diese Ereignisse werden mit dem Befehl XEvtBiDi ausgelesen.
  • XEvtLok (0xC9)- Länge = 1 Byte
    Antwort (bei OpenDCC): 0x80 (=nichts zu melden)
    Antwort (bei OpenDCC_XP):
         Es werden alle seit der letzten Abfrage veränderten Loks (z.B. per Handregler) gemeldet.
         Die Meldung erfolgt als verkettete Liste:
         1. Byte: 0x00 - 0x7F: Speed 0..127 (0 = Stop, 1 = Stop/Em.Stop), weitere Bytes folgen
                  0x80:        Keine (oder keine weitere Lok) zu melden
         2. Byte: F1..F8 (bit #0..7)
         3. Byte: low byte of Lok# (A7..A0)
         4. 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  |
                            +-----+-----+-----+-----+-----+-----+-----+-----+
         5. Byte: echte, aktuelle Fahrstufe (z.B. 0..14), das MSB ist ab Version 0.23.8 maskiert.  
  • XEvtTrnt (0xCA)- Länge = 1 Byte
    Antwort (bei OpenDCC): 0x00
    Antwort (bei OpenDCC_XP): Anzahl der zu meldenden Weichen (oder auch 0); max. 64 Weichen werden gemeldet.
                 in Folge werden für jede zu meldende Weiche zwei Bytes gesendet.
                 Byte:      1           2
                        addr low    addr high + 'color'
                 Color:  1 = closed (green), 0 = thrown (red)
    
    Hinweis: die Kodierung von Color ist umgekehrt wie bei Lenz.
  • XEvtSen (0xCB)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xCB XEvtSen (Abfrage Sensor Events)
    
    Antwort: Liste aus maximal 128 Einträgen, jeder Eintrag ist wie folgt aufgebaut:
             1. Byte: falls 0: dieses ist der letzte Listeneintrag.
                      falls !0: s88 Modulnummer (1..128) (Modul = 16 Bits)
             2. Byte  Kontakte 1..8 dieses Moduls (Bits 7..0)
             3. Byte  Kontakte 9..16 dieses Moduls (Bits 15 ..8)
    
    Das Vorliegen eines S88-Event wird mit XEvent gemeldet; Es kann sein, das ein Event gemeldet wurde, sich aber kein S88 geändert hat, weil es inzwischen schon wieder zurückgesetzt ist. Beim Lesen werden die Change-Flags zurückgenommen, es wird kein Modul zweimal gemeldet.
    (@modeltreno: wer hat eigentlich diese Bitanordnung verbrochen?)
  • XEvtPT (0xCE)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xCE XEvtPT (Abfrage Programmierergebnisse)
    
    Antwort: 1. Byte: falls 0xF5: noch nicht fertig, es gibt nichts zu melden
                      falls [1,2,3,4,6] Zahl der Folgebytes
             2. Byte  Status der Programming Task
                      0x00        Command completed, no errors
                      0xFF        Timeout
                      0xFE        No acknowledge from decoder (but a write maybe was successful)
                      0xFD        Short! (on the PT)
                      0xFC        No decoder detected
                      0xFB        Generic Error
                      0xFA        Error during DCC direct bit mode operation
                      0xF9        No acknowledge to paged operation (paged r/w not supported?)
                      0xF8        Error during Selectrix read
                      0xF7        XPT_DCCQD: Ok (direct bit read mode is (probably) supported)
                      0xF6        XPT_DCCQD: Not Ok (direct bit read mode is (probably) not supported)
                      0xF4        Task terminated (see XPT_Term cmd)
                      0xF3        No task to terminate (see XPT_Term cmd)
                      0xF2        Cannot terminate task (see XPT_Term cmd)
             3. Byte  (nur falls vom 1. Byte angekündigt)
                      Erstes Ergebnis der Programmiertask, dies kann sein:
                        - der Inhalt eines Register oder CV (DCC Read cmds);
                        - low byte einer langen Adresse (DCC long addr read cmd);
             4. Byte  (nur falls vom 1. Byte angekündigt)
                      Zweites Ergebnis der Programmiertask, dies kann sein:
                        - high byte einer langen Adresse (DCC long addr read cmd);
    
  • XEvtBiDi (0xD2) Länge = 1 Byte
    Antwort (bei OpenDCC_XP mit angeschlossenem BiDi-Rueckmeldern):
         Es werden alle seit der letzten Abfrage eingegangenen Orts- und Geschwindigkeitsmitteilungen gemeldet.
         Die Meldung erfolgt als verkettete Liste (ist damit moeglichst konform zur bisherigen p50x-Syntax):
    
         1. Byte:       bit#   7     6     5     4     3     2     1     0
                            +-----+-----+-----+-----+-----+-----+-----+-----+
                            |  LE | res | res | res | D11 | D10 |  D9 |  D8 |
                            +-----+-----+-----+-----+-----+-----+-----+-----+
    
                  LE:      0:   Listenende, es folgen keine weiteren Daten.
                           1:   Es folgen Daten fuer diesen Listeneintrag.
                           res: reserviert
                  D11-D8:  DID (DID = Detektor-ID), high nibble;
    
         2. Byte: D7-D0:   Detektor-ID, Low Byte
         3. Byte: low byte of Lok# (A7..A0)
         4. Byte: high byte of Lok#, high byte of Lok#, plus Dir and Speed status, coded as follows:
                        bit#   7     6     5     4     3     2     1     0
                            +-----+-----+-----+-----+-----+-----+-----+-----+
                            | Dir | Spd | A13 | A12 | A11 | A10 | A9  | A8  |
                            +-----+-----+-----+-----+-----+-----+-----+-----+
                  Dir: Lokrichtung
                  Spd: 1: es folgt ein weiteres Byte mit der Istgeschwindigkeit
         5. Byte: [optional] Speed gemaess der BiDi-Kodierung
                     0..63: speed = value / 2;
                     64..127: speed = value - 32;
                     128..254: speed = value * 4;
                     255: Kennzeichnet eine ungueltige Geschwindkeit (wird u.a. intern verwendet).
    
    Es werden max. 10 Lokomotiven in einer Antwort gemeldet. Wenn keine Antwort vorliegt, wird nur ein Byte (0x00) zurückgemeldet.
    Wenn die Lok von einem Detektor in einen anderen wechselt, so wird nur die Meldung für die neue DID erzeugt. Wenn die übermittelte Lokadresse 0 ist, so hat die Lok diesen Detektor verlassen (und ist auch nicht in einem anderen Detektor aufgetaucht) und der Detektor ist frei.
    Die Belegungen werden mit der Rückmelderadresse = DID auch in das S88 Array eingetragen. Damit ist sowohl das Melden von nicht BiDi-fähigen Fahrzeugen bzw. Waggons mit Widerstandsachsen sichergestellt, also auch die Auswertung der Belegung durch Software, welche BiDi noch nicht unterstützt.
    DID = Detektor-ID, also die Kennziffer des Detektorabschnittes. Es gibt max. 2048 DID, wenn die Meldung vom globalen DID (also nicht einem Gleisabschnitt zugeordnet werden kann) kommt, dann ist DID = 0xFFF = 2047.
    Hinweis zur Byteorder: Die DID wird Highbyte first übertragen, damit die Verkettung mit hineinkodiert werden kann. Die Adresse wird IB-typsich Lowbyte first übertragen.
  • XBiDiSet (0xD3) Länge = 1+1 Byte
    Befehlsbytes:
            0: 0xD3 XBiDiSet (Einstellen der BiDi Konfiguration)
            1: Parameter, Bitfeld:
                        bit#   7     6     5     4     3     2     1     0
                            +-----+-----+-----+-----+-----+-----+-----+-----+
                            | res | res | res | res | res | res | Spd | Loc |
                            +-----+-----+-----+-----+-----+-----+-----+-----+
                     Loc: 0: Es erfolgen keine Ortsmeldungen.
                          1: Alle Zuordnungen von Loks zu DIDs werden geloescht und neue Meldungen erlaubt.
                     Spd: 0: Es erfolgen keine Geschwindigkeitsmeldungen.
                          1: Alle Istgeschwindigkeiten werden gelöscht.
    
    Antwort: 0 = Ok, accepted.
  • XBiDiQuery (0xD4) Länge = 1+2 Byte
    Befehlsbytes:
            0: 0xD4 XBiDiQuery (Abfragen der Meldung fuer einen bestimmen Detektor)
            1. Parameter:    bit#   7     6     5     4     3     2     1     0
                                +-----+-----+-----+-----+-----+-----+-----+-----+
                                | res | res | res | res | D11 | D10 |  D9 |  D8 |
                                +-----+-----+-----+-----+-----+-----+-----+-----+
    
                  res:     reserviert
                  D11-D8:  DID (DID = Detektor-ID), high nibble;
    
            2. Parameter: D7-D0:
                  Detektor-ID, Low Byte
    
    Antwort: Eine einzelne Antwort wie unter XEvtBiDi beschrieben. Wenn dieser Detektor aktuell nicht belegt ist (bzw. von einer nicht BiDi-Lok belegt ist) dann wird 0 zurueckgemeldet.
  • XDCC_PAWX (0xD8) - Länge = 1+5 Bytes
    Befehlsbytes:
            0: 0xD8 XDCC_PAWX (= Extended Accessory-Programmieren auf dem Hauptgleis = POM, CV-Schreiben)
            1: LSB der Zubehöradresse
            2: MSB der Zubehöradresse (0-2043)
            3: Low Byte der CV-Adresse, welche zu schreiben ist.
            4: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            5: Datum, welches zu schreiben ist. (0...255)
    
    Antwort: 0 = Ok, accepted
             0x80 = busy, command ignored
    

    Unter Adresse ist hier die echte Adresse gemeint, siehe hierzu auch XtrntX. (und nicht um 1 verschoben, wie das die IB bei der Weichenadresse macht!)
    Ab Version 0.23 werden damit PoM-Read Befehle auf das Gleis gesendet.
  • XDCC_PARX (0xD9) - Länge = 1+4 Bytes
    Befehlsbytes:
            0: 0xD9 XDCC_PARX (= Extended Accessory-Programmieren auf dem Hauptgleis = POM, CV-Lesen)
            1: LSB der Zubehöradresse
            2: MSB der Zubehöradresse (0-2043)
            3: Low Byte der CV-Adresse, welche zu lesen ist.
            4: High Byte der CV-Adresse, welche zu lesen ist. (1..1024)
    
    Antwort: 0 = Ok, accepted
             0x80 = busy, command ignored
    
    Die Antwort wird über XEvtPT übergeben.

    Unter Adresse ist hier die echte Adresse gemeint, siehe hierzu auch XtrntX. (und nicht um 1 verschoben, wie das die IB bei der Weichenadresse macht!)
    Ab Version 0.23 werden damit PoM-Read Befehle auf das Gleis gesendet. Das Rücklesen ist vorläufig mangels Dekektor noch nicht möglich und muß noch über ein externes System wie z.B. Tams RC-Link erfolgen.
  • XDCC_PDR (0xDA) - Länge = 1+4 Bytes
    Befehlsbytes:
            0: 0xDA XDCC_PDR (= Lok-Programmieren auf dem Hauptgleis = POM, CV-Lesen)
            1: LSB der Lokadresse
            2: MSB der Lokadresse (1-10239)
            3: Low Byte der CV-Adresse, welche zu lesen ist.
            4: High Byte der CV-Adresse, welche zu lesen ist. (1..1024)
    
    Antwort: 0 = Ok, accepted.
             0x80 = busy, command ignored
    
    Die Antwort wird über XEvtPT übergeben.
    Ab Version 0.23 werden damit PoM-Read Befehle auf das Gleis gesendet. Das Rücklesen ist nur möglich, wenn am Xpressnet ein BiDi-fähiger Detektor angeschlossen ist.
  • XDCC_PAR (0xDB) - Länge = 1+4 Bytes
    Befehlsbytes:
            0: 0xDB XDCC_PAR (= Accessory-Programmieren auf dem Hauptgleis = POM, CV-Lesen)
            1: LSB der Zubehöradresse
            2: MSB der Zubehöradresse (0-510)
            3: Low Byte der CV-Adresse, welche zu schreiben ist.
            4: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
    
    Antwort: 0 = Ok, accepted
             0x80 = busy, command ignored
    
    Die Antwort wird über XEvtPT übergeben.

    Unter Adresse ist hier die Decoderadresse gemeint, nicht die Weichenadresse!
    Ab Version 0.23 werden damit PoM-Read Befehle auf das Gleis gesendet. Das Rücklesen ist nur möglich, wenn am Xpressnet ein BiDi-fähiger Detektor angeschlossen ist.
  • XPT_DCCEWr (0xDC)- Länge = 1+4 Bytes
    Antwort: 0x00
    Erzeugen und Schreiben einer Geschwindigkeitskennlinie.
    Hinweis: wird von OpenDCC (noch) nicht unterstützt.
  • XDCC_PD (0xDE)- Länge = 1+5 Bytes
    Befehlsbytes:
            0: 0xDE XDCC_PD (= Lok-Programmieren auf dem Hauptgleis = POM)
            1: LSB der Lokadresse
            2: MSB der Lokadresse (1-10239)
            3: Low Byte der CV-Adresse, welche zu schreiben ist.
            4: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            5: Wert
    
    Antwort: 0 = Ok, accepted
             0x80 = busy, command ignored
    
    Mit POM können Programmierbefehle am Hauptgleis gesendet werden - diese werden nicht quittiert.
  • XDCC_PA (0xDF)- Länge = 1+5 Bytes
    Befehlsbytes:
            0: 0xDF XDCC_PA (= Accessory-Programmieren auf dem Hauptgleis = POM)
            1: LSB der Zubehöradresse
            2: MSB der Zubehöradresse (1-510)
            3: Low Byte der CV-Adresse, welche zu schreiben ist.
            4: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            5: Wert
    
    Antwort: 0 = Ok, accepted
             0x80 = busy, command ignored
    
    Unter Adresse ist hier die Decoderadresse gemeint, nicht die Weichenadresse! Mit POM können Programmierbefehle am Hauptgleis gesendet werden - diese werden nicht quittiert.
  • XPT_Sts (0xE0)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xE0 XPT_Sts (= Abfrage Status der Programmierroutine)
    
    Antwort: zwei Bytes, wie folgt kodiert;
                bit#   7     6     5     4     3     2     1     0
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    | Evt |  x  |  x  |  x  |  x  |  x  | Rel | Mode|
                    +-----+-----+-----+-----+-----+-----+-----+-----+
                    Evt:  0 = no PT event is pending
                          1 = a PT event is pending
                    Rel:  0 = PT relay is off
                          1 = PT relay is on (always in OpenDCC Mode)
                    Mode: 0 = PT in 'PT only' mode
                          1 = PT in 'auto' mode
    
                    2. Byte
                    0 = es läuft keine Programmierroutine
                    1 = es läuft gerade was
    
  • XPT_On (0xE1)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xE1 XPT_On (= Programmiermodus)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_Off (0xE2)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xE2 XPT_Off (= Verlassen Programmiermodus)
    
    Antwort: 0 = Ok, accepted
    
    OpenDCC schaltet nach diesem Kommando auf RUN_OFF d.h. Hauptgleis ist gewählt, aber noch abgeschaltet.
  • XPT_DCCSr (0xEA)- Länge = 1 Byte
    Search for address of a DCC decoder (decoders which are not 'readable', e.g. Roco/Lenz digital crane) - not supported by OpenDCC
  • XPT_DCCQA (0xEB)- Länge = 1 Byte
    Read address using obsolete "Address Query" packet (can only report 7-bit addresses in range 1..111) - not supported by OpenDCC
  • XPT_DCCRR (0xEC)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0xEC XPT_DCCRR (= Lesen mit Hilfe des Register-Mode Befehls)
            1: Register, das zu lesen ist (1..8).
            2: 0
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCWR (0xED)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0xED XPT_DCCWR (= Schreiben mit Hilfe des Register-Mode Befehls)
            1: Register, das zu schreiben ist (1..8).
            2: 0
            3: Der zu schreibende Inhalt (0..255)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCRP (0xEE)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0xEE XPT_DCCRP (= Lesen mit Hilfe des Register-Mode Befehls und Pages)
            1: Low Byte der CV-Adresse, welche zu lesen ist.
            2: High Byte der CV-Adresse, welche zu lesen ist. (1..1024)
    
    Antwort: 0 = Ok, accepted
    
    Beim Paged Mode wird zuerst das Register 6 mit einer Auswahladresse beschreiben. Diese Auswahladresse wählt eine "Speicherseite" (= page) im Decoder an. Diese wird dann anstelle der Register 1-4 eingeblendet. Dann wird auf diesem Registern die tatsächliche Lese bzw. Schreiboperation vorgenommen. Das ist nicht wirklich schnell, deshalb sollte besser der nachfolgende Direktbefehl verwendet werden.
  • XPT_DCCWP (0xEF)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0xEF XPT_DCCWP (= Schreiben mit Hilfe des Page Mode (Auswahl von Page und dann mit Register-Mode Befehl)
            1: Low Byte der CV-Adresse, welche zu schreiben ist.
            2: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            3: Der zu schreibende Inhalt (0..255)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCRD (0xF0)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0xF0 XPT_DCCRD (= Lesen mit Hilfe des Direct-Modes)
            1: Low Byte der CV-Adresse, welche zu lesen ist.
            2: High Byte der CV-Adresse, welche zu lesen ist. (1..1024)
    
    Antwort: 0 = Ok, accepted
    
    Dieser Befehl liest mit Hilfe des DCC direkt-read Kommandos das CV aus der Lok aus. Mit diesem DCC-Befehl kann die Lok nur gefragt werden, ob das CV den angegebenen Inhalt hat. Also muß normalerweise die Zentrale alle möglichen Bitkombinationen der Reihe nach durchsuchen, bis ein Datum gefunden wird.
    Um das zu Beschleunigen, gibt es folgende Besonderheit beim direkten Lesen eines Bytes per DCC:
      Die OpenDCC Zentrale prüft vorher nach, ob der Decoder Bitoperationen beherrscht. Falls ja, wird das Byte mit den Bitbefehlen gelesen und dann noch gegengeprüft. Fall nein, wird konventionell mit einer Suchschleife über alle 256 möglichen Zustände gesucht. Die OpenDCC Zentrale merkt sich für 500ms, ob der Decoder Bitoperationen kann. Wenn innerhalb dieser 500ms ein weiterer Lesebefehl ausgeführt wird, so entfällt automatisch die erneute Prüfung auf Bitfähigkeit.
  • XPT_DCCWD (0xF1)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0xF1 XPT_DCCWD (= Schreiben mit Hilfe des Direct-Modes)
            1: Low Byte der CV-Adresse, welche zu schreiben ist.
            2: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            3: Der zu schreibende Inhalt (0..255)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCRB (0xF2)- Länge = 1+2 bytes
    Befehlsbytes:
            0: 0xF2 XPT_DCCRB (= Lesen mit Hilfe des Bit-Modes)
            1: Low Byte der CV-Adresse, welche zu lesen ist.
            2: High Byte der CV-Adresse, welche zu lesen ist. (1..1024)
    
    Antwort: 0 = Ok, accepted
    
    Dieser Befehl liest mit Hilfe des DCC bit-read Kommandos das CV aus der Lok aus. Obwohl es ein Bitbefehl ist, wird das ganze CV-Byte ausgelesen, die tatsächliche Bitmaske muß der Host machen. Vom den implementierten Lesemethoden ist diese die schnellste, da nur 8 Zugriffe zzgl. ein Kontrollzugriff erforderlich sind.
  • XPT_DCCWB (0xF3)- Länge = 1+3 bytes
    Befehlsbytes:
            0: 0xF1 XPT_DCCWD (= Einzelbit Schreiben mit Hilfe des Bit-Modes)
            1: Low Byte der CV-Adresse, welche zu schreiben ist.
            2: High Byte der CV-Adresse, welche zu schreiben ist. (1..1024)
            3: Bitposition (0..7)
            3: Der zu schreibende Inhalt (0|1)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCQD (0xF4)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xF4 XPT_DCCQD (= Abfrage, ob der Decoder Einzelbit kann)
    
    Antwort: 0 = Ok, accepted
    
  • XPT_DCCRL (0xF5)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xF5 XPT_DCCRL (= Abfrage lange Adresse)
    
    Antwort: 0 = Ok, accepted
    
    Die lange Adresse ist in CV17 und CV18 abgelegt und speziell codiert. In der CV-Übersicht ist ein Rechner dafür.
  • XPT_DCCWL (0xF6)- Länge = 1+2 Bytes
    Befehlsbytes:
            0: 0xF6 XPT_DCCWL (= Schreiben lange Adresse)
            1: Low Byte der langen Adresse.
            2: High Byte der langen Adresse.
    
    Antwort: 0 = Ok, accepted
    
    Es wird automatisch auch das Bit 5 in CV29 mitgeschrieben; dieses Bit schaltet die lange Adresse aktiv. Der Decoder muß Bit-Mode beherrschen.
  • XPT_DCCRA (0xF7)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xF7 XPT_DCCRA (= Abfrage lange Adresse, Accessory Decoder)
    
    Antwort: 0 = Ok, accepted
    
    Die lange Adresse ist in CV513 und CV521 abgelegt und speziell codiert. In der CV-Übersicht ist ein Rechner dafür. Dieser Befehl ist noch nicht implementiert!!!
  • XPT_DCCWA (0xF8)- Länge = 1+2 Bytes
    Befehlsbytes:
            0: 0xF6 XPT_DCCWA (= Schreiben lange Adresse, Accessory Decoder)
            1: Low Byte der langen Adresse.
            2: High Byte der langen Adresse. (0..511)
    
    Antwort: 0 = Ok, accepted
    
    Dieser Befehl ist noch nicht implementiert!!!
  • XPT_Term (0xFE)- Länge = 1 Byte
    Befehlsbytes:
            0: 0xFE XPT_Term (= Beenden der aktuellen Programmieraufgabe (Abbruch))
    
    Antwort: 0 = Ok, accepted and terminated
             0xF3 = no task is active
    

Konfiguration und Firmwareupdate:

  • Konfiguration:
    Es gibt eine Reihe von Parametern, welche das Verhalten von OpenDCC definieren. Diese sind permanent im EEPROM gespeichert.
  • Firmware-Update:
    Einfach beim Start des Gerätes die Stoptaste gedrückt halten und dann mit dem entsprechenden Tool die Firmware einspielen.