OpenDCC GBM16, Gleisbesetztmelder, Details zur Software

    Auf dieser Seite wird die Software des Besetztmelders näher erläutert. Diese Seite ist für den Einsatz nicht erforderlich, gibt aber dem Interessierten aufschlußreiche Hintergrundinformationen.
    Intern sind in GBM sind zwei Prozessoren verbaut, dies ist wegen der unterschiedlichen Versorgungsbereiche erforderlich. Gekoppelt sind diese Prozessoren mit einer schnellen seriellen Verbindung.
  • Der Gleisprozessor ist auf das Potential des Gleises bezogen und wertet Stromverbrauch bzw. BiDi-Nachrichten aus und sendet eine Zusammenfassung dieser Auswertung an den Controlprozessor.
  • Der Controlprozessor ist auf 'Erde' bezogen (also entweder Masse vom PC oder von der Zentrale). Er empfängt die Daten von Gleisprozessor, reduziert diese fallweise auf das jeweils verwendete Rückmeldeprotokoll und reicht diese per USB, Xpressnet und/oder S88 an den Host oder die Zentrale weiter.

Software des Gleisprozessors

    Die Software des Gleisprozessors ist mit CORTOS realisiert und umfaßt folgende Funktionen:
  • DCC Empfänger:
    hier kommt die auch in den Dekodern verwendete Routine zur Anwendung. Diese ist hier allerdings um folgende Funktionen erweitert:
    • Verzögerung des DCC-Einlesen um 0,75 Periode (siehe hierzu: Methoden des DCC-Empfangs) erfolgt hier nicht per Interrupt, der dann einen Timer ansteuert, sondern diese Aktion wird mit dem Eventsystem des ATXmega erledigt.
    • Automatische Polaritätserkennung und Umschaltung der Polarität. Damit erfolgt ein phasenrichtiges Einsynchronisieren auf die erste Bithälfte.
    • Generieren eines Startpulses für die A/D Messung nach jeder Flanke des DCC-Signals. Hierzu wird per Pin-Change Konfiguration ein Event aus jedem Wechsel des DCC-Signal generiert. Dieses Event setzt ein Timer zurück. Wenn der Timer dann ein bestimmt Zeit gelaufen ist, wird wiederum per Event eine Analog-Digital-Wandlung ausgelöst.
  • DCC Programmiereinheit:
    diese erlaubt das Verändern von internen Variablen des Gleisprozessors. Dieser wird dabei wie ein Zubehördekoder angesprochen. Über diesen Weg kann z.B. die DID gesetzt oder die Empfindlichkeit werden.
  • Strom-Meßsystem:
    Synchron zum DCC-Eingang wird eine Spannungsmessung an den Gleiseingängen durchgeführt. Diese Messung erfolgt 20µs nach jeder Flanke, es werden immer 8 Kanäle parallel gemessen. Dadurch ist bereits nach 4 Flanken des DCC-Signals eine komplette Erfassung erfolgt. Zur Stabilisierung der Messwerte werden die einzelnen Messungen mit einem digitalen Filter gewichtet und dann an die Belegungsüberwachungen weitergeleitet.
  • Offset-Abgleich des Wandlers
    Wie jeder A/D-Konverter ist auch der integrierte Wandler des Atxmega128A1 mit einem kleinen Offset behaftet, dieser setzt sich zusammen aus dem Offset des Wandlers selbst und dem Offset der Eingangsstufe. Beim Atxmega128A1 ist der Offset der Eingangsstufe sehr klein, beim neueren Atxmega128A1U hat auch die Eingangstufe etwa 5 LSBs Offset und muß mit in den Abgleich einbezogen werden. Um die Messung möglichst genau und empfindlich zu machen, ist ein (teil-)automatischer Offsetabgleich vorgesehen.
    Es wird folgender Ablauf verwendet:
    • Existieren bereits gültige Offsetdaten - dann werden diese verwendet.
    • Falls keine Daten existieren, dann zeigt der GBM16T ein Lauflicht auf den Status-LEDs an (als Fehlermeldung) und auch im Debug-IF wird angezeigt, dass die Daten ungültig sind.
    • Jetzt muß der Anwender einmalig folgende Aktionen machen:
        - alle Gleisanschlüsse abklemmen bzw. DCC abschalten.
        - Programmierknopf drücken.
      Es wird ein Offsetabgleich durchgeführt und sofern dieser glaubwürdige Daten liefert, werden die Offset-Daten permanent gespeichert.
    • Sollte dieser Offset-Abgleich keine brauchbaren Daten ergeben, wird das mit einem Wechselblinker (je zwei LEDs paarweise im Wechsel) angezeigt. Wenn man jetzt nochmal den Programmierknopf drückt, dann startet der GBM16T trotz fehlender Offset-Daten (mit Offset = 0; das wird vermutlich auch Geisterbelegungen zur Folge haben). Man kann dann mit dem Debug-Interface arbeiten und z.B. Parameter verändern.
      Die Offsetmessung geht immer dann schief, wenn sich die Offsets innerhalb einer 8ter-Gruppe um mehr als max_offset_delta (=CV37) LSBs unterscheiden. Dieser Wert steht per default auf 5.
    • Eine erneute Kalibrierung kann man auslösen, indem man entweder J0 setzt oder CV70 auf 0 setzt. Dann wird beim nächsten Start eine Offsetmessung durchgeführt.
      Hinweis: es empfiehlt sich, vor dem Nullsetzen der CV70 diese vorher prüfzulesen: da sollte 0x55 stehen.
  • Belegungs-Überwachung:
    Task, welche die Stromverbräuche filtert und auf Änderung überwacht und diese an den Commandprozessor bzw. den LED Controller weiterleitet. Zugleich legt diese Überwachungstask fest, welche Kanäle dem BiDi-Sampler zugeordnet werden. Hierzu wird auch die Adresse der aktuellen DCC-Nachricht mit ausgewertet, damit der Kanal, in welchem sich die aktuell angesprochene Lok befindet, auch sicher mit ausgewählt wird. Dadurch wird eine eventuelle Ch2-Antwort dieser Lok sofort erfaßt.
    Die Kanalauswahl erfolgt nach folgenden Regeln (modifizierter Round-Robin):
    1. Wenn der aktuelle DCC-Befehl ein Lokbefehl ist und ein Kanal diese Lok bereits erkannt hat, wird er in die Auswahl aufgenommen. (Das ist wichtig für Ch2-Nachrichten).
    2. Kanäle, in denen eine Adressmeldung nur zum Teil vorliegt - damit werden Adressen so schnell wie möglich komplett erkannt.
    3. Frisch belegte Kanäle, dies sorgt für einen sehr schnellen Update bei Neubelegungen.
    4. Alle sonstigen belegten Kanäle
  • BiDi-Sampler: dieser zeichnet das Sensorsignal in den vorher bestimmten Gleisabschnitten auf. Hierbei werden je Wandler 4 Kanäle parallel aufgezeichnet, der Speicherbedarf hierfür: 220 * 16 Bit * 8 Känal = 3520 Byte;
  • BiDi-Receiver, dieser wertet die aufgezeichneten Sensorsignale mit systemtheoretischen Methoden aus, erkennt die Aufgleisrichtung und gewinnt die übertragenen Nachrichten zurück. Das gemessene Eingangssignal wird hierbei gefiltert und auf eine feinere Zeitauflösung umgerechnet (Resampling). Auf den so interpolierten Daten wird dann eine Augenöffnungsanalyse gerechnet, die auch gestörte Signale sicher erkennen kann.
  • BiDi-Analysator, dieser analysiert den empfangenen Protokoll-Inhalt, wertet ihn aus und schickt fallweise eine Nachricht an den Controlprozessor.
  • Command-IF:
    Diese Task enthält eine Pipeline für erzeugte Nachrichten an den Controlprozessor und einen Parser für Befehle von Controlprozessor. Das Kommunikationsprotokoll ist nachfolgend beschrieben.
  • LED Controller:
    dieser zeigt belegte Kanäle (statisch leuchtend) und solche mit BiDi-Verkehr (schnell blinkend) an. Zudem übernimmt der LED Controller die Ansteuerung der LED für die allgemeinen Zustände.
  • Debugger: kann als Datenlogger an jeder Stelle eingehängt werden, die Kommunikation erfolgt über ein optogekoppeltes USB Interface.

Software des Controlprozessors

    Die Software des Controlprozessors umfaßt folgende Funktionen:
  • Empfänger für Gleisnachrichten: hier werden die Nachrichten der Gleisprozessoren empfangen und analysiert. Statusänderungen werden an die Upstream-Module weitergegeben bzw. im Statusspeicher aktualisiert.
  • Überwachungstask für die Trackproc: es wird permanent die Verfügbarkeit der Gleisprozessoren überwacht und fallweise wird die Rückmeldung eingefroren.
  • Xpressnet Client-Interface: der Controlprozessor meldet sich als normaler Teilnehmer am Xpressnet an und schickt dort seine Nachrichten (z.B. Belegtmeldung oder Befehlsquittierung) an die Zentrale
  • Xpressnet Master-Interface: der Controlprozessor agiert als XPressnet-Master und sammelt von den anderen Rückmeldern die Nachrichten ein.
  • Host-Interface: der Controlprozessor emuliert ein Hostprotokoll wie z.B. BiDiB, HSI88 oder RC-Link. Alternativ kann hier auch eine Debugschnittstelle geladen werden.
  • S88-Slave-Funktion: die aktuellen Belegungen werden als Bits in den S88-Strom eingetragen.

Interne Kommunikation zwischen den Prozessoren

    Die beiden Versorgungsbereiche sind mittels Optokoppler verbunden. Die Datenübertragung über diese Trennstelle erfolgt mit RS232, dadurch ist nur je ein Optokoppler je Richtung erforderlich. Die Übertragung erfolgt mit 115200 Baud, 9N1. Es ist folgendes Protokoll definiert:

Uplink-Protokoll

    Hier handelt es sich um ein einfaches Punkt-zu-Punkt Protokoll, das paket-orientierte Nachrichten sendet. Der Paketbeginn wird mit einem gesetztem 9. Bit angezeigt. Im Byte des Paketheaders sind der verursachende Melderbaustein und die Nachrichtenart kodiert; es folgen fallweise Parameter wie die logische Melderaddresse und Daten.
    Der Gleisprozessor sendet vollkommen asynchron, Antworten auf Anfragen müssen nicht zwingend in der Reihenfolge der Anfragen kommen bzw. können auch durch Spontanmeldungen unterbrochen sein. Nachrichten können also entweder spontan erfolgen oder als Antwort auf Anfragen. Es ist auch zu beachten, dass der Gleisprozessor jederzeit stromlos geschaltet werden kann (er hängt am Zentralenausgang und ist bei 'STOP' stromlos.), die Kommunikation muß also diese Situation beherrschen.

    Nach dem Einschalten wird eine System-Power-Up Meldungen gesendet, der Controlprozessor muß daraufhin bei allen Zuständen eine erneute Übermittlung der Nachrichten anfordern. Im laufenden Betrieb werden nur Änderungen und neue Nachrichten übertragen.

    Das erste Byte (header) enthält eine fortlaufende Nachrichtennummer (4 bit) und die Anzahl der Bytes in dieser Nachricht (4 bit). Am Ende der Nachricht wird ein CRC8 mit Polynom x8 + x5 + x4 + 1 angehängt. Das zweite Byte ist wie folgt kodiert:
    Uplink: Header (9. Bit is gesetzt)
    7-5 Diese gibt den Typ der Nachricht an, dabei gilt folgende Zuordnung: >
    0UPM_TYPE_SYSTEMSystemnachricht. Die nähere Bedeutung ist mittels der QID und der Folgebytes kodiert:
    QID 0Protokollextension, zweites Byte hat Sonderbedeutung
    QID 1System-Power-Up Nachricht
    QID 2Pong Active (Antwort auf Ping, Heartbeat)
    QID 3Pong BiDi (Antwort auf Ping, Heartbeat)
    QID 4Pong Inactive (Antwort auf Ping, Heartbeat)
    QID 5Versionsinfo, es folgen HW, SW, Protokoll
    QID 6Detektor-ID Basisadresse (DID-Base), es folgen DID-Low, DID-high
    QID 7Kanalzahl, es folgt ein Byte mit der Kanalzahl dieses Gleisprozessors
    QID 8Antwort auf eine SO-Abfrage, es folgen AddrL, AddrH, Dat
    QID 9Slave ist in Progmode
    QID 10Slave ist in Normalmode (default)
    1UPM_TYPE_CURRENTCurrent, one byte to follow: Current
    2UPM_TYPE_ADDRADDR: Adressemeldung neu eingegangen, es folgend 2 Bytes mit der Adresse AL, AH; wenn AL und AH jeweils 0 ist, dann ist diese Quell-ID nicht mehr belegt.
    3UPM_TYPE_SPEEDSpeed, three bytes to follow: AL, AH, Speed
    4UPM_TYPE_CVCV: five bytes will follow: LOK-AL, LOK-AH, CV-AL, CV-AH, DAT
    5 Lok-Report: tbd.
    6 reserved
    7 reserved
    4-0 Dies gibt eine Quell-ID an (QID): Bei normalen Nachrichten wird hier der verursachende Eingang gemeldet. Wertebereich 0..31, für die aktuelle Hardware (HW-ID=1) ergibt sich nur 0..15.
    Bei Systemmeldungen gibt QID die Art der Meldung an (siehe obige Tabelle).

      Uplink-Protokoll, Details

      • Nachrichtentyp 0: System
        Nachrichtentyp 0: System
        WertBedeutung der ID
        0reserviert (eventuelle Protokollerweiterung)
        1UPM_SYSQID_POWER_UP
        Diese Nachricht wird immer gesendet, wenn der Gleisprozessor gestartet wird. Das kann auch während des Betriebes erfolgen, der Gleisprozessor hängt an der Gleisspannung und kann bei Abschalten der Booster stromlos werden. Es folgen keine weiteren Daten.
        2UPM_SYSQID_PONG_A
        Diese Nachricht (oder die u.g. UPM_SYSQID_PONG_*) wird als Antwort auf einen Ping gesendet. Damit kann der Controlproc per PING feststellen, ob der Trackproc noch 'lebt', also mit Strom versorgt ist. Ein PONG_A Antwort zeigt dabei an, dass der trackproc mit DCC versorgt ist. PONG kann entfallen, wenn normale Nachrichten übertragen werden (auch diese kennzeichnen das 'lebendig' sein). Es folgen keine weiteren Daten.
        3UPM_SYSQID_PONG_BIDI
        Diese Nachricht (oder eine andere UPM_SYSQID_PONG_*) wird als Antwort auf einen Ping gesendet. UPM_SYSQID_PONG_BIDI zeigt an, dass der GBM16T mit einem DCC-Signal versorgt ist, welches die cutout für BiDi enthält. Es folgen keine weiteren Daten.
        4UPM_SYSQID_PONG_I
        (Siehe UPM_SYSQID_PONG_A). Die UPM_SYSQID_PONG_I Nachricht (=inaktiv) wird als Antwort auf einen Ping gesendet, wenn kein DCC Signal anliegt. Es folgen keine weiteren Daten.
        5UPM_SYSQID_VERSION
        Diese Nachricht sendet den Releasestand des Trackproc. Es folgen 3 Bytes:
        HWHardwareversion; z.Z. 1
        SWSoftwareversion; eine Nummer von 0..255
        ProtocolVersionsstand des Inferfaceprotokoll
        6UPM_SYSQID_DID
        Diese Nachricht meldet die diesem Belegtmelder zugeordnete Belegtmelderadresse (Basisadresse). Es folgen 2 Bytes mit der Adresse. (Low Byte zuerst)
        7UPM_SYSQID_CC
        Diese Nachricht meldet die diesem Belegtmelder zugeordnete Anzahl an Belegtmelderadressen. Es folgen 2 Bytes mit der Anzahl. (Low Byte zuerst)
        8UPM_SYSQID_SO
        Diese Nachricht ist eine Antwort auf eine SO Abfrage. Es folgen 3 Bytes:
        ADDR_LAdresse
        ADDR_HAdresse
        DATDatum
        9UPM_SYSQID_PROG_ON
        Diese Nachricht meldet, dass sich der GBM16T im Programmiermode befindet. (Dieser Programmiermode wird aus Sicherheitsgründen bei jedem Zustandswechsel des GBM16T gelöscht, d.h. der GBM16T löscht das Programmierflag, wenn z.B. die Versorgung des GBM16T von DCC auf DC wechselt. In diesem Fall ist der Programmiermode erneut aufzurufen.
        10UPM_SYSQID_PROG_OFF
        Diese Nachricht meldet, dass sich der GBM16T nicht mehr im Programmiermode befindet.
      • Nachrichtentyp 1: Strommeldung/Belegtmeldung
        Es folgt ein Byte:
        Kodierung Stromverbrauch
        WertBedeutung
        0kein Stromverbrauch, Gleis ist frei.
        1..100Stromverbrauch, in mA. Möglicher Bereich: 1..100mA
        101..200Stromverbrauch, Wert ist Datum - 100 * 10mA. Möglicher Bereich: 10..1000mA
        201..250Stromverbrauch, Wert ist Datum - 200 * 100mA. Möglicher Bereich: 100..5000mA
        251..254reserviert.
        0xFFNur Belegtmeldung, kein exakter Verbrauch bekannt.
      • Nachrichtentyp 2: Adressmeldung
        Es folgen zwei Byte, ADDRL, ADDRH:
        0: keine Adresse erkannt. 1..10239: Lokadresse.
        Kodierung Adressmeldung
        WertBedeutung
        0keine Adresse erkannt.
        1..10239Lokadresse; das MSB zeigt die Aufgleisrichtung an, also wie rum die Lok auf dem Gleis steht.
      • Nachrichtentyp 4: CV-Meldung
        Es folgen fünf Bytes, ADDRL, ADDRH, CVL, CVH, DAT
        Kodierung CV-Meldung
        WertBedeutung
        ADDR2 Byte, die beiden MSB geben den Adresstyp des meldenden Dekoders an:
        00: Lokadresse, 10:Accessory, 11: extended Accessory
        CV2 Bytes, CV, Wertebereich 0...1023 (0 entspricht also CV1)
        DATDas gelesene Datum.
    • Nachrichtentyp i: tbd.
      Weitere, noch zu definierende Nachrichten:
      • Geschwindigkeitsmeldung (Befehlsbestätigung)
      • Geschwindigkeitsmeldung (Istgeschwindigkeit)
      • CV-Meldung
      • Eine weitere Lok hat den Abschnitt betreten. Dies könnte zum automatischen Rangieren interessant sein.

    Downlink-Protokoll

      Im Donwlink sendet der Control-Prozessor Anfragen an den Gleisprozessor, diese werden mit einer entsprechenden Antwort beantwortet (siehe oben). Die Antwort wird nicht zwingend direkt nach der Anfrage geschickt, sondern in den Datenstrom eingefügt.
      Downlink: Header (9. Bit is gesetzt)
      0 reserved
      1 Ping
      2 Get Revision Info
      3 Get DID Base Address (DID = Detektor-ID)
      4 Set DID Base Address (DID = Detektor-ID); es folgend 2 Bytes: DIDL, DIDH
      5 Get number of Channels
      6 Set SO; es folgend 3 Bytes: AddrL, AddrH, Dat
      7 Get SO; es folgend 2 Bytes: AddrL, AddrH
      8 Get last Occupancy Messages again;
      9 Get last Current Messages again;
      10 Get last Speed again;
      11 Get last Addr Messages again;
      Im Regelbetrieb sendet der ControlProc kontinierlich einen PING an den Trackproc, wenn die Anwort ausbleibt, so nimmt er an, dass der Trackproc stromlos ist und 'hält' seine Belegung aufrecht.

      Nach dem Unstellen der DID eines Trackproc werden bereits geladene Belegungen an der Stelle der bisherigen DID nicht verändert - hier empfielt sich ein Neustart ...

    Trackproc - Debugschnittstelle

      Der Trackproc verfügt über eine Hostschnittstelle für den Firmwareupdate und für eine vereinfachte Konfiguration. Der PC wird per USB über ein FTDI-USB-Kabel 3V3 (wichtig) an der seriellen Schnittstelle des ATXmega angeschlossen. Dabei wird ein virtueller COM-Port initialisiert.

    Firmware-Update

      Wenn beim Einschalten des Dekoders der Bootjumper gesteckt ist, dann wird der Bootloader aktiv und es kann ein Firmware-Update durchgeführt werden. Die LED leuchtet zu Beginn permanent und blinkt da bei jedem Byte kurz auf. Der Bootloader kommuniziert im standard-AVROSP Protokoll mit 19200 Baud, 8N1. Nähere Informationen finden sich in der Bauanleitung zum Regler. Verwendet wird im GBM der xboot.

    Konfigurationsschnittstelle

      Im regulärem Betrieb ist auf dem USB-Port ein Kommando-Interface (API) implementiert, mit dem man Befehle an den Dekoder absenden kann. Hierzu kann z.B. das Terminalprogramm hterm.exe verwendet werden.

      Die API arbeiten mit einem seriellen Protokoll, eingestellt sind 115200 Baud, 8 Bit, keine Parity, 1 Stopbit (8N1). Übertragen werden 8-Bit ASCII, die API unterscheidet bei Befehlen nicht nach Groß-Kleinschreibung. Gesendete Befehle werden mit <cr> oder <cr-lf> terminiert, die Antwort enthält <cr-lf> als Endemarkierung.
      Unbekannte Befehl werden mit 'unknown command' beantwortet.

    Allgemeine API Befehle

    • Help
      Parameter: keine
      Antwort: ein Hilfetext, der die API-Befehle kurz erläutert.
    • Info
      Parameter: keine
      Antwort: "OpenDCC_BiDiGBM hw 1.0, sw 02, api 01" (Beipiel)
      Die Antwort besteht aus einem String, beginnend mit dem Hardware Identifier ("OpenDCC_BiDiGBM) und Versionnummern. Es folgen weitere Schlüsselworte, jeweils gefolgt von einem Zahlenwert.
      hwHardware-Version
      sw Software-Version
      api Dies ist die Versionnummer des Parsers, anhand dieser kann unterschieden werden, welcher Befehlsvorrat unterstützt wird.
    • CV ADDR, [DATA]
      Parameter:
      ADDRCV-Adresse von der gelesen oder auf die geschrieben werden soll.
      DATAWenn dieser Parameter angegeben ist, dann wird geschrieben, wenn DATA fehlt, dann wird gelesen.
      Antwort: CV1234:56 (= die Adresse 0x1234 hat den Inhalt 0x56; die Antwort hat immer gleiche Länge)
    • REBOOT
      Parameter: keine
      Antwort: keine
      Der Decoder führt einen Neustart aus (notwendig z.B. nach Umstellen von Betriebarten-CVs

    Befehle zum Mitloggen

    • L
      Es wird der aktuelle Status des Loggers angezeigt.
      Antwort: Folge von Buchstaben, jeweils gefolgt von + oder -.
      Beispiel: logging: A+ B1+ B2+ C- S+ T+ U+
      NameLog-Aktivität
      AAdressmeldungen
      B1BiDi, Ch1
      B2BiDi, Ch2
      CCV-Meldungen
      SSpeed-Meldungen
      TBelegtmeldungen
      UUnbekannte BiDi-Meldungen
    • LA [0|1]
      LA 1: Es werden alle eingehenden Adressmeldungen angezeigt.
      LA 0: die Anzeige der Adressmeldungen wird abgeschaltet.
      Antwort: Statusanzeige (wie bei L)
    • LB [0|1|2|3]
      LB 0: die Anzeige der BiDi-Meldungen wird abgeschaltet.
      LB 1: Es werden alle eingehenden BiDi-Meldungen im Ch1 angezeigt.
      LB 2: Es werden alle eingehenden BiDi-Meldungen im Ch2 angezeigt.
      LB 3: Es werden alle eingehenden BiDi-Meldungen im Ch1 und Ch2 angezeigt.

      Antwort: Statusanzeige (wie bei L)
    • LC [0|1]
      LC 1: Es werden alle eingehenden CV-Meldungen angezeigt.
      LC 0: die Anzeige der CV-Meldungen wird abgeschaltet.
      Antwort: Statusanzeige (wie bei L)
    • LT [0|1]
      LT 1: Bei einer Änderung im Belegtstatus erfolgt eine Ausgabe aller Belegungen.
      LT 0: die Ausgabe der Belegungen wird abgeschaltet.
      Antwort: Statusanzeige (wie bei L)

    Befehle zum Testen und Simulieren

    • SA TRACK ADDR
      Es wird intern im trackproc das Auftreten einer BiDi-Nachricht (Adressmeldung) simuliert.
      Parameter:
      TRACKBelegtmelder, dem diese Nachricht zugeordnet werden soll.
      ADDRDie auf diesem Belegtmelder gemeldete Adresse.
      Antwort: ok
    • ST TRACK
      Es wird intern im trackproc das Auftreten einer Belegtmeldung simuliert.
      Parameter:
      TRACKBelegtmelder, dessen Aktivierung simuliert wird.
      Antwort: ok
    • M
      Es werden die aktuellen Meßwerte (für beide Polaritäten) aller Kanäle ausgelesen.
      Parameter: keine Antwort: Folgen von Zahlenpaaren, beginnend bei Track 0.
    • LW <TRACK>
      Der angebene TRACK wird als besonders zu beobachtender Meldekanal aktiviert. Dieser Kanal ist dann bei jeder Auswertung dabei. Wenn TRACK auf 16 gestellt wird, ist die Beobachtung abgeschaltet. Wenn kein Parameter angegeben wird, dann wird die momentane Einstellung angezeigt.
      Wenn ein Dump der aufgenommen Daten getriggert wird, muß vorher der Meldekanal gesetzt werden.
      Antwort: watch <nummer>
    • DD
      Dump Data: mit diesem Befehl wird der durch die Triggerbedingung abgespeicherte Meldekanal komplett ausgegeben: Ch1, CH2 Inhalt sowie der im Meldekanal aufgenommene Signalverlauf.
      Antwort: Mehrer Felder mit Zahlenwerten.
    • DTC <data>
      Wenn kein Parameter angegeben wird, wird DTC abgeschaltet. Ansonsten erfolgt ein Dump des Meldekanals, wenn die gelesene CV den Inhalt <data> hat. Der Dump kann dann mit DD ausgelesen werden.
      Antwort: aktueller Zustand von DTC
    • Die folgenden Befehle sind nur für Debugzwecke gedacht, es erfolgt keine Parameterprüfung - bitte vorsichtig benutzen :-)
    • XER ADDR
      Lese von der EEPROM Adresse (z.B. XER 0x34)
    • XEW ADDR DATA
      Schreibe auf EEPROM Adresse (z.B. XEW 0x34 0x45)

    Integration des OpenDCC BiDi-GBM

    Adresszuordnung der Meldeabschnitte

    • S88
      Innerhalb des S88-Protokolls erfolgt die Adresszuordnung einfach durch die physikalische Position innerhalb der Rückmelderkette, es ist keine Einstellung erforderlich.
    • Xpressnet
      Jeder Gleisprozessor liefert an seinen Controlprozessor die DID (Detektor-ID), also die gewünschte Basisadresse. Der Controlprozessor sortiert nun die von diesem Gleisprozessor eingehenden Nachrichten entsprechend in den Rückmelderadressraum ein.
    • Hostschnittstelle
      Hier sind verschiedene Protokollemulationen möglich:
      • BiDiB: Die Meldungen der Gleisprozessoren werden entsprechend der Reihenfolge der Gleisprozessoren als Melder 0-15, 16-31, 32-47 bzw. 48-63 auf diesem Knoten gemeldet. Wahlweise sind noch 8 Meldebits für Boosterausfall nachgeordnet.
      • HSI88: Die Meldungen der Gleisprozessoren werden entsprechend der DID einsortiert.
      • RCTalk: Nur der Gleisprozessor 0 wird als RCTalk 1..16 einsortiert. Die anderen Gleisprozessoren sind nicht auswertbar.

    Einbindung in die Zentrale

      Um eine speicher-effiziente Implementierung in der Zentrale zu erreichen, bietet sich folgendes Vorgehen an:
      Erweiterung des Locobuffers um drei Variablen:
    • eine DID (Detektor-ID): auf welchem Belegtabschnitt diese Lok sich zuletzt gemeldet hat
    • welche Ist-Speed sie gemeldet hat
    • ein Flag, ob die letzte Änderung bereits an den PC gemeldet wurde
    • ein Flag, ob die Lok im Refresh berücksichtigt wird

    • Bei einer BiDi-Meldung wird auch der S88-Rückmelder mit der logischen Adresse des DID gesetzt, damit sind BiDi-Rückmeldung in beide Richtungen kompatibel: PC-Programme, welche BiDi (noch) nicht kennen, sehen die Belegtmeldung. Loks, welche keine BiDi-Meldung auslösen, erzeugen zumindest eine Belegung.

      Wenn der Detektor eine Lok zugeweisen hat, wird diese in der Zentrale entsprechend eingetragen. Zusätzlich noch ein Verfallscounter, der Meldungen nach einer bestimmten Zeit automatisch vernichtet. Fragen hierzu: was passiert, wenn die Lok aus dem Locobuffer dynamisch rausfliegt?

    Erweiterung p50x-Protokoll

      p50x wird wie folgt erweitert:

      Im XEvent (0xC8) wird folgendes hinzugefügt:
      Byte 3: Bit 5: 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)(implementiert)
      Byte 3, Bit 6: 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. (geplant)
      XEvtBiDi (0xD2) Laenge = 1 Byte
      Antwort: Es werden alle seit der letzten Abfrage eingegangenen Orts- und Geschwindigkeitsmitteilungen gemeldet. Die Meldung erfolgt als verkettete Liste (verkette Liste deshalb, damit es möglichst konform zur bisherigen p50x-Syntax ist (wobei da eh alles moegliche vertreten ist)):
           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; es gibt max. 2047 DID, wenn die Meldung vom globalen DID kommt,
                           dann ist DID = 0xFFF = 2047.
           2. Byte
                  D7-D0:   Detektor-ID, Low Byte
           3. Byte: low byte of Lok# (A7..A0)
           4. Byte: 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 (Aufgleisrichtung)
                 Spd:     1: es folgt ein weiteres Byte mit der Istgeschwindigkeit
              Wenn die Lok von einem Detektor in einen anderen wechselt, so wird nur die Meldung fuer die neue DID erzeugt.
              Wenn die uebermittelte Lokadresse 0 ist, so hat die Lok diesen Detektor verlassen (und ist auch nicht in einem
              anderen Detektor aufgetaucht.) und der Detektor ist frei.
              (Hinweis: Belegung wird ueber das S88-Array angezeigt)
           5. Byte
               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 je XEvtBiDi gemeldet.
      
        

      XBiDiQuery (0xD3) Laenge = 1+2 Byte
        Parameter:  DID-low DID-high
      
        
      Antwort: Es wird die komplette BiDi-Information, bis zur Geschwindigkeit, nur für diese Besetztmeldung gesendet.

      XBiDiSet (0xD4) Länge = 1+1 Byte
        Parameter:
                          bit#   7     6     5     4     3     2     1     0
                              +-----+-----+-----+-----+-----+-----+-----+-----+
                              | res | res | res | res | res | res | Spd | Loc |
                              +-----+-----+-----+-----+-----+-----+-----+-----+
                  Loc:     1: Alle Zuordnungen von Loks zu DIDs werden geloescht.
                  Spd:     1: Alle Istgeschwindigkeiten werden geloescht.
                  res:     reserviert
      
        

    Controlproc - Hostschnittstelle

      Der Controlproc verfügt über eine USB-Hostschnittstelle für die Meldungen (mit wählbarer Hostemulation (z.B. BiDiB oder HSI88), für Firmwareupdate und für eine vereinfachte Konfiguration. Die USB-Schnittstelle kommuniziert über einen virtueller COM-Port.

    Firmware-Update

      Wenn beim Einschalten des Dekoders der Bootjumper gesteckt ist, dann wird der Bootloader aktiv und es kann ein Firmware-Update durchgeführt werden. Die LED leuchtet zu Beginn permanent und blinkt da bei jedem Byte kurz auf. Der Bootloader kommuniziert im standard-AVROSP Protokoll mit 19200 Baud, 8N1. Nähere Informationen finden sich in der Bauanleitung zum Regler.

    Konfigurationsschnittstelle, USB

      Im Konfiguration-Betrieb ist auf dem USB-Port ein Kommando-Interface (API) implementiert, mit dem man Befehle an den Dekoder absenden kann. Hierzu kann z.B. das Terminalprogramm hterm.exe verwendet werden.

      Die API arbeiten mit einem seriellen Protokoll, eingestellt sind 115200 Baud, 8 Bit, keine Parity, 1 Stopbit (8N1). Übertragen werden 8-Bit ASCII, die API unterscheidet bei Befehlen nicht nach Groß-Kleinschreibung. Gesendete Befehle werden mit <cr> oder <cr-lf> terminiert, die Antwort enthält <cr-lf> als Endemarkierung.
      Unbekannte Befehl werden mit 'unknown command' beantwortet.

    API Befehle

    • Help
      Parameter: keine
      Antwort: ein Hilfetext, der die API-Befehle kurz erläutert.
    • Info
      Parameter: keine
      Antwort: "OpenDCC_BiDiGBM hw 1.0, sw 02, api 01" (Beipiel)
      Die Antwort besteht aus einem String, beginnend mit dem Hardware Identifier ("OpenDCC_BiDiGBM) und Versionnummern. Es folgen weitere Schlüsselworte, jeweils gefolgt von einem Zahlenwert.
      hwHardware-Version
      sw Software-Version
      api Dies ist die Versionnummer des Parsers, anhand dieser kann unterschieden werden, welcher Befehlsvorrat unterstützt wird.
    • EB
      Parameter: keine
      Antwort: Now running BiDiB
      Der GBM schaltet aus dem Debugmode in die BiDiB-Emulation um, diese Unschaltung erfolgt permanent.
    • EH
      Parameter: keine
      Antwort: running HSI88 Emulation
      Der GBM schaltet aus dem Debugmode in die HSI88-Emulation um, diese Unschaltung erfolgt permanent. Der HSI88-Mode kann mit dem Befehl 'X' (groß geschrieben) wieder verlassen werden. Achtung: z.Z. wird die Baudrate beim Umschalten in den HSI88 Modus nicht verändert, dieser läuft dann auch mit 115200 Baud.
    • ER
      Parameter: keine
      Antwort: running RCTalk Emulation
      Der GBM schaltet aus dem Debugmode in die RCTalk-Emulation um, diese Unschaltung erfolgt permanent. Der RCTalk-Mode kann mit dem Befehl '0x22' (Hex) wieder verlassen werden. Dabei bleibt die Baudrate gleich. Das RCTalk Protokoll hat recht eingeschränkten Adressbereich und Funktionsumfang und ist daher nur für einen ersten Test brauchbar. Es wird im RCTalk auch nur der GBM16T[0] weitergemeldet, für einen zweiten GBM16T reicht der Adressbereich nicht. Belegtmeldungen werden auch nicht weiter gemeldet.
    • REBOOT
      Parameter: keine
      Antwort: keine
      Der Decoder führt einen Neustart aus (notwendig z.B. nach Umstellen von Betriebarten-CVs
    • Die folgenden Befehle sind nur für Debugzwecke gedacht, es erfolgt keine Parameterprüfung - bitte vorsichtig benutzen :-)
    • XER ADDR
      Lese von der EEPROM Adresse (z.B. XER 0x34)
    • XEW ADDR DATA
      Schreibe auf EEPROM Adresse (z.B. XEW 0x34 0x45)

    Interne Konfigurationsvariablen am GBM16C

      CVBedeutung
      1parser_mode
      0: Debug-Interface
      1: HSI88-Emulation
      2: p50x (nicht implementiert)
      3: RC-Talk 1 (nur für GBM16T[0])
      2VID Vendor ID (13)
      3Product ID, low byte (101)
      4Product ID, high byte (1)
      5Seriennummer, low byte (1)
      6Seriennummer, high byte (0)
      7jumper
      8s88_extended
      Extra s88 byte for booster fail
      9s88_extended_did_l
      Detector-ID low für das extra s88 byte.
      10s88_extended_did_h
      Detector-ID high für das extra s88 byte.
      11xp_slot_mode
      automatic oder manuell
      12xp_slot_addr
      Adresse 1..31
      13xp_use_occupancy
      Belegtmeldungen werden auf XP gesendet
      14xp_use_location
      Adressmeldungen werden auf XP gesendet
      15xp_use_speed
      Speedmeldungen werden auf XP gesendet

    Befehle bei HSI88-Emulation

      Der OpenDCC GBM kann auf der Hostschnittstelle das HSI88 von Littfinksi (LDT) emulieren. Die HSI88-Ansteuerung kennt zwei Betriebsarten: binary und ascii. In der Betriebsart binary werden Adressen und Daten als unsigned int8 übergeben, in der Betriebsart ascii werden diese 8-Bit Daten als Hex, bestehend aus 2 Zeichen ohne weiteres Präfix übertragen. LDT bezeichnet die Betriebsarten mit Terminalmode.

      Ein Kommando oder eine Antwort wird immer mit einfachen <cr> (ohne <lf>) abgeschlossen. Es gibt folgende Kommandos:
    • v <cr>
      Antwort: Ver. 0.01 / 14.10.10 / HSI-88 / OpenDCC <cr>
      Versionsabfrage, bis auf den 'Kernstring' HSI-88 können sich alle Bestandteile des Strings ändern, auch die Länge.
    • t <cr>
      Antwort: t[MODE]<cr>
      Umschalten der Betriebsart (Terminalmode). Die Betriebsart wird bei jeden Befehl umgeschaltet, default nach dem Start der Emulation ist binary. MODE = '0' bedeutet binary, MODE = '1' bedeutet ascii.
    • s [LINKS][MITTE]RECHTS]<cr>
      Antwort (Teil 1): s[SIZE]<cr>
      Mit diesem Befehl wird die Größe (Size) der jeweiligen Teilketten (angegeben in Modulen zu je 16 Bit) eingestellt. Für den OpenDCC GBM ist die Aufteilung in Teilketten ohne Belang, beachtet wird nur die Summe aus LINKS, MITTE und RECHTS, diese wird in der Antwort als SIZE auch zurückgemeldet.
      Je nach Betriebsart erfolgt sowohl die Übergabe der Parameter für s als auch die Antwort entweder binary oder ascii.
      Als zweiter Teil der Antwort folgt eine Initialmeldung (siehe unten), wobei alle Module gemeldet werden.
      Dieser Befehl ist nach dem Start einmal auszuführen, erst dann können Initialmeldungen geänderter Rückmelder erfolgen.
    • m <cr>
      Antwort: Bytefolge mit folgenden Aufbau:
      m[SIZE][[MODUL][DATA_HIGH][DATA_LOW]<cr>
      SIZEAnzahl der Module, die gemeldet werden.
      MODULNummer des Moduls. Ein Modul umfaßt 16 Rückmelderbits.
      DATA_HIGHDie oberen 8 Rückmelderbits dieses Moduls
      DATA_LOWDie unteren 8 Rückmelderbits dieses Moduls
      Mit dem Befehl m werden alle angeschlossenen Rückmeldemodule abgefragt. Je nach Betriebsart ist die Länge der Antwort unterschiedlich: binary: 3+SIZE*3, ascii: 4+SIZE*6
    • X <cr>
      Antwort: X <cr>
      X (groß geschrieben) beendet die HSI88 Emulation und kehrt zum Konfiguration-Interface zurück. Dieses Kommando ist am Orginal HSI88 nicht vorhanden.
    • Initialmeldung
      Bytefolge mit folgenden Aufbau:
      i[SIZE][[MODUL][DATA_HIGH][DATA_LOW]<cr>
      SIZEAnzahl der Module, die gemeldet werden.
      MODULNummer des Moduls. Ein Modul umfaßt 16 Rückmelderbits.
      DATA_HIGHDie oberen 8 Rückmelderbits dieses Moduls
      DATA_LOWDie unteren 8 Rückmelderbits dieses Moduls
      Diese Initialmeldungen erfolgt spontan und liefert nur die geänderten Rückmeldemodule. Je nach Betriebsart ist die Länge der Antwort unterschiedlich: binary: 3+SIZE*3, ascii: 4+SIZE*6