OpenDCC GBM, Software

OpenDCC GBM16, Gleisbesetztmelder, Details zur Software

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

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 nun ein Offsetabgleich durchgeführt und sofern dieser glaubwürdige Daten liefert, werden die neuen 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 oder dem BiDiB-Monitor arbeiten und z.B. Parameter verändern.
  Die Offsetmessung wird dann als fehlerhaft betrachtet, 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 die laut railcom-Spezifikation vorgeschriebene 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 (also obe es sich z.B. um eine Geschwindigkeitsmeldung oder eine 'Dirty-Track'-Meldung handelt), 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. Die Kommunikation mit dem Debug-Interface erfolgt mit 115200, 8N1. Eine Befehlsliste kann mit ? <cr> abgefragt werden.

Software des Controlprozessors

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 250000 Baud, 9N1. Es ist folgendes Protokoll definiert:

Uplink-Protokoll

⁸

⁵

⁴

Uplink: Header (9. Bit is gesetzt)

7-5

Diese gibt den Typ der Nachricht an, dabei gilt folgende Zuordnung: >

UPM_TYPE_SYSTEM

Systemnachricht. Die nähere Bedeutung ist mittels der QID und der Folgebytes kodiert:

QID 0	Protokollextension, zweites Byte hat Sonderbedeutung
QID 1	System-Power-Up Nachricht
QID 2	Pong Active (Antwort auf Ping, Heartbeat)
QID 3	Pong BiDi (Antwort auf Ping, Heartbeat)
QID 4	Pong Inactive (Antwort auf Ping, Heartbeat)
QID 5	Versionsinfo, es folgen HW, SW, Protokoll
QID 6	Detektor-ID Basisadresse (DID-Base), es folgen DID-Low, DID-high
QID 7	Kanalzahl, es folgt ein Byte mit der Kanalzahl dieses Gleisprozessors
QID 8	Antwort auf eine SO-Abfrage, es folgen AddrL, AddrH, Dat
QID 9	Slave ist in Progmode
QID 10	Slave ist in Normalmode (default)

UPM_TYPE_CURRENT

Current, one byte to follow: Current

UPM_TYPE_ADDR

ADDR: 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.

UPM_TYPE_SPEED

Speed, three bytes to follow: AL, AH, Speed

UPM_TYPE_CV

CV: five bytes will follow: LOK-AL, LOK-AH, CV-AL, CV-AH, DAT

Lok-Report: tbd.

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

Wert

Bedeutung der ID

reserviert (eventuelle Protokollerweiterung)

UPM_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.

UPM_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.

UPM_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.

UPM_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.

UPM_SYSQID_VERSION
Diese Nachricht sendet den Releasestand des Trackproc. Es folgen 3 Bytes:

HW	Hardwareversion; z.Z. 1
SW	Softwareversion; eine Nummer von 0..255
Protocol	Versionsstand des Inferfaceprotokoll

UPM_SYSQID_DID
Diese Nachricht meldet die diesem Belegtmelder zugeordnete Belegtmelderadresse (Basisadresse). Es folgen 2 Bytes mit der Adresse. (Low Byte zuerst)

UPM_SYSQID_CC
Diese Nachricht meldet die diesem Belegtmelder zugeordnete Anzahl an Belegtmelderadressen. Es folgen 2 Bytes mit der Anzahl. (Low Byte zuerst)

UPM_SYSQID_SO
Diese Nachricht ist eine Antwort auf eine SO Abfrage. Es folgen 3 Bytes:

ADDR_L	Adresse
ADDR_H	Adresse
DAT	Datum

UPM_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.

UPM_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
Wert	Bedeutung
0	kein Stromverbrauch, Gleis ist frei.
1..100	Stromverbrauch, in mA. Möglicher Bereich: 1..100mA
101..200	Stromverbrauch, Wert ist Datum - 100 * 10mA. Möglicher Bereich: 10..1000mA
201..250	Stromverbrauch, Wert ist Datum - 200 * 100mA. Möglicher Bereich: 100..5000mA
251..254	reserviert.
0xFF	Nur Belegtmeldung, kein exakter Verbrauch bekannt.

Nachrichtentyp 2: Adressmeldung
Es folgen zwei Byte, ADDRL, ADDRH:
0: keine Adresse erkannt. 1..10239: Lokadresse.

Kodierung Adressmeldung

Wert Bedeutung

0 keine Adresse erkannt.

1..10239 Lokadresse; 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
Wert	Bedeutung
ADDR	2 Byte, die beiden MSB geben den Adresstyp des meldenden Dekoders an: 00: Lokadresse, 10:Accessory, 11: extended Accessory
CV	2 Bytes, CV, Wertebereich 0...1023 (0 entspricht also CV1)
DAT	Das 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

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;

GBM16T / Trackproc - Debugschnittstelle

3V3

virtueller COM-Port

Firmware-Update

Intelhex-basierend (aktuelle Version): Der Bootloader kommuniziert in ASCII mit 19200 Baud, 8N1. Er funktioniert identisch zum Bootloader des GBMBoost. Hierzu muß beim Starten der Taster auf dem GBM16T gedrückt sein und gedrückt gehalten werden, bis eine LED aufleuchtet. Es reicht, wenn nur die Ersatzspeisung angesteckt wird, der Fahrstrom braucht nicht eingeschaltet zu sein.
Jetzt verbinden mit hterm, 19200, 8N1, newline mit <cr>. Testhalber mal ein ?<cr> an den Bootloader schicken - wir bekommen die Antwort: Bootloader V*.*
Nun gibt drei Kommandos:
- e<cr>: EEPROM als Ziel auswählen
- f<cr>: FLASH als Ziel auswählen
- x<cr>: beenden
Nach der Wahl eines Zieles wird einfach mit der Send-File Funktion von hterm die entsprechende hex-Datei an den GBMBoost gesandt. Je Zeile antwortet der GBMBoost mit einem '.';
Dateien mit der Endung 000.hex sind für das Flash, .001.hex für das EEPROM.

AVROSP-basierend (Ältere Version)

Bauanleitung zum Regler

xboot

Konfigurationsschnittstelle

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.

hw	Hardware-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:

ADDR	CV-Adresse von der gelesen oder auf die geschrieben werden soll.
DATA	Wenn 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

Ausgaben

Tracks[15..0]: .... .... .... ..*

A01:v5v0v0v0v0

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+

Name	Log-Aktivität
A	Adressmeldungen
B1	BiDi, Ch1
B2	BiDi, Ch2
C	CV-Meldungen
S	Speed-Meldungen
R	RailcomPlus-Meldungen
Q	Quality-Meldungen (Verschmutzungssensor)
T	Belegtmeldungen
U	Unbekannte BiDi-Meldungen
G	Geisterlokomotiven (verursacht durch offensichtlich fehlerhafte Lokdekoder

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)
LDA [0|1]
LDA 1: Es werden Accessorybefehle auf dem DCC-Eingang ausgewertet und angezeigt.
LDA 0: die Ausgabe wird abgeschaltet.
Antwort: Statusanzeige (wie bei LD)
LDP [0|1]
LDP 1: Es werden POM-Befehle auf dem DCC-Eingang ausgewertet und angezeigt.
LDP 0: die Ausgabe wird abgeschaltet.
Antwort: Statusanzeige (wie bei LD)
LQ [0|1]
LQ 1: Schaltet das Logging für QoS Nachrichten ein.
LQ 0: Schaltet das Logging für QoS Nachrichten aus.
LQ 2,34,12: injeziert einen QoS-Wert auf Abschnitt 2, Lok 34, Wert 12 (Zahlen nur beispielhaft).
Antwort: Statusanzeige (wie bei L)
Log-Anzeige: c2, Lok:34, Qual=12

LG [0|1] [addr]
LG 1: Schaltet das Logging für Geistermeldungen ein.
LG 0: Schaltet das Logging für Geistermeldungen aus.
der zweite Parameter [addr] (optional) legt das 'Jagdverhalten' des Geitermeldungs-Loggers fest:

Es erfolgt eine Ausgabe, wenn zwei Antworten in Channel2 auf unterschiedliche DCC-Adressen erkannt wurden.

1..10324

Es erfolgt eine Ausgabe, wenn über Channel2 eine Lok erkannt wurde, welche folgende Bedingung erfüllt:
- sie unterscheidet sich zur angegebenen Adresse
- die angegebene Adresse ist bereits in diesem Abschnitt vorhanden. (Dadurch läßt sich feststellen, ob der angegebene Dekoder durch Antworten in der falschen cutout Geisterloks verursacht. Hinweis: es gibt die CV39 (chan2_addr_debounce, Voreinstellung 4, ab FW 2.05.00) zur Unterdrückung von Geisterloks, diese kann einzelne Fehlnachrichten unterdrücken)

Antwort: Statusanzeige (wie bei L)
Log-Anzeige: DCCaddr:last=361,curr=369 (zum Zeitpunkt der Triggerung war Lok 369 adressiert, vorher Lok 361)

Befehle zum Testen und Simulieren

SA TRACK ADDR
Es wird intern im trackproc das Auftreten einer BiDi-Nachricht (Adressmeldung) simuliert.
Parameter:

TRACK Belegtmelder, dem diese Nachricht zugeordnet werden soll.

ADDR Die auf diesem Belegtmelder gemeldete Adresse.

Antwort: ok
ST TRACK
Es wird intern im trackproc das Auftreten einer Belegtmeldung simuliert.
Parameter:

TRACK Belegtmelder, 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.
MO
Es werden die aktuellen Meß-Offsets angezeigt. Diese wurde einmalig bei der Inbetriebnahme hinterlegt und justieren die ADC-Ablage des Prozessors. Mit MO 0 kann man diese üngültig erklären. Es wird dann beim nächsten Neustart des GBM16T ein erneuter Abgleich durchgeführt. Zum Abgleich darf kein Gleissignal anliegen, die Gleise sollten getrennt sein.
Parameter: keine bzw. 0
Antwort: Messwerte
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: Mehrere 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
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

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

Fragen hierzu: was passiert, wenn die Lok aus dem Locobuffer dynamisch rausfliegt?

Erweiterung p50x-Protokoll

p50x

XEvent (0xC8)

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)

(geplant)

XEvtBiDi (0xD2)

     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

BiDiB

virtuellen COM-Port

Firmware-Update

Bauanleitung zum Regler

Konfigurationsschnittstelle, USB

API Befehle

Help
Parameter: keine
Antwort: ein Hilfetext, der die API-Befehle kurz erläutert.

hw	Hardware-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
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

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

Befehle bei HSI88-Emulation

HSI88

Littfinksi (LDT)

Terminalmode

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>

SIZE	Anzahl der Module, die gemeldet werden.
MODUL	Nummer des Moduls. Ein Modul umfaßt 16 Rückmelderbits.
DATA_HIGH	Die oberen 8 Rückmelderbits dieses Moduls
DATA_LOW	Die 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>

SIZE	Anzahl der Module, die gemeldet werden.
MODUL	Nummer des Moduls. Ein Modul umfaßt 16 Rückmelderbits.
DATA_HIGH	Die oberen 8 Rückmelderbits dieses Moduls
DATA_LOW	Die 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

Kodierung Adressmeldung
Wert	Bedeutung
0	keine Adresse erkannt.
1..10239	Lokadresse; das MSB zeigt die Aufgleisrichtung an, also wie rum die Lok auf dem Gleis steht.

TRACK	Belegtmelder, dem diese Nachricht zugeordnet werden soll.
ADDR	Die auf diesem Belegtmelder gemeldete Adresse.