BiDiB, ein universelles Steuerprotokoll für Modellbahnen

Nachrichten für Belegtmeldung

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

Allgemeines

Das Protokoll BiDiB dient zur Kontrolle einer Modellbahnanlage. Es ermöglicht die Ansteuerung von Loks, Zubehör und sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner.

BiDiB kann über verschiedene Übertragungsmedien transportiert werden, dabei wird das Framing und die Sicherung der Nachrichten gewährleistet.

Eine Erläuterung der hier verwendeten Begriffe und der Protokollgrundzüge findet sich im allgemeinen Teil der Protokollbeschreibung, gleiches gilt auch für die Hinweise zur Benutzung und zur Lizenz.

Dieser Abschnitt der Protokollbeschreibung erläutert nur einen Teil der Nachrichten.

Revisionsstand

Dieses Dokument beschreibt Revision 1.26 von BiDiB, Stand 15.08.2016.

Die Revisionsgeschichte ist dem allgemeinen Teil zu entnehmen.

4.7. Belegtmeldung

4.7.1. Erfassung und Absicherung

Belegtmeldung dient dazu, den Aufenthaltsort von Fahrzeugen zu melden. Dieser wird i. d. R. durch eine Stromverbrauchsmessung detektiert. Parallel dazu können Belegtmelder in der Lage sein, bidirektionale Nachrichten (railcom) der Fahrzeuge auszuwerten.

Melder haben das Bit 'Melderfunktion' in der ClassID gesetzt. Melder dienen nur zur Anzeige von Belegtzuständen, nicht zum Melden sonstiger Ereignisse wie z. B. ein Tastendruck oder eine Eingabe aus der Anlage (z. B. von einem Stellpult). Hierfür ist die Klasse 'Zubehör' vorgesehen.

Eine verloren gegangene Belegtmeldung kann im Rechnerbetrieb dramatische Auswirkungen haben: wenn die Belegtmeldung eines Haltabschnittes nicht eingeht, wird ein Zug nicht rechtzeitig angehalten und es kann zu einem Unfall mit materiellen Schäden und Betriebsunterbrechung kommen.

Deshalb ist zum einen die Übertragung in BiDiB mit CRC abgesichert und die Nachrichtenfolge sequentiell durchnummeriert, so dass Übertragungsfehler erkannt werden. Darüber hinaus bietet BiDiB für Belegtmelder noch weitere Sicherungsmethoden:

Secure-ACK-Quittungsverfahren für Belegtmeldungen
Secure-ACK ist ein erweitertes, automatisiertes Quittungverfahren, welches das korrekte Einlesen des Rückmelderinformation auch bei evtl. vorhandenen Übertragungsfehlern garantiert.
Bei aktiviertem Secure-ACK-Quittungsverfahren sendet der Host alle erhaltenen Belegtmeldungen an das Rückmeldersystem zurück. Das Rückmeldesystem vergleicht nun den echten Rückmelderzustand mit dem quittiertem Zustand. Stellt es dabei eine Differenz fest, so werden die fehlerhaften Rückmelderbits erneut übertragen. Wenn die Rückübertragung des Hosts nicht innerhalb der festgelegten Zeit eintrifft, versucht der Melder selbständig, die Meldung erneut abzusenden.
Es ist sowohl bei der Rückmeldebaugruppe als auch beim Hostprogramm klar anzugeben, ob das Secure-ACK-Quittungsverfahren unterstützt wird.
'Vertrauens'-Kontrolle
Ein Melder kann die den Host mitteilen, wie gut die Erfassung ist, also ob die gemeldeten Belegungen auch glaubhaft sind.
Es kann z. B. der Fall eintreten, dass bedingt durch einen Kurzschluss am Gleis nur noch 'eingefrorene' Belegtmeldungen existieren oder gar die Belegtmeldung unmöglich ist. In diesem Fall kann der Melder dies dem Host mitteilen und so evtl. eine durch fehlerhafte Belegtmeldung verursachte Programmreaktion verhindern.
'Alive'-Kontrolle
Das Interface kontrolliert die Verbindung zu seinen Meldern (Knoten) und sendet dem Host eine Änderungsmitteilung, wenn ein Melder verlorengegangen ist oder ein neuer hinzugekommen ist. Darüber hinaus kann der Host periodisch eine PING Nachricht an einen Melder absenden, diese wird dort innerhalb einer festgelegten Zeit entweder mit einer normalen Nachricht oder mit einer PONG-Nachricht (das ist einfach eine leere Nachricht) beantwortet.

Ein weiterer beachtenswerter Punkt ist der verwendete Adressraum. DCC kennt eigentlich zwei Adressräume: kurze und lange Adresse. Es ist jedoch allgemeine Praxis, dass in Steuergeräten diese beiden Adressräume zu einem Adressraum vereint werden. Immer dann, wenn eine Adresse mittels kurzer Adresse darstellbar ist, dann wird kurze Adresse verwendet.

BiDiB behandelt alle DCC Adressen als eindeutig (nach RCN 211), die Unterscheidung kurz-lang existiert im Protokoll nicht.

4.7.2. Features für Belegtmelder
Aufstellung der Features für die Belegtmelder-Klasse
NummerNameBedeutung
0 FEATURE_BM_SIZE Anzahl der Belegtmeldungen. Hier werden die Anzahl der Melderbits eines Knotens abgefragt. Für Melder mit unbekannter Anzahl am Eingängen (z. B. Interface zu einem S88-Bus) kann diese Variable auch geschrieben werden. Wertebereich: 0…128.
1 FEATURE_BM_ON 0: Der Knoten liefert keine Belegtmeldung.
1: Der Knoten liefert Belegtmeldungen (Spontan). Dies erfolgt automatisch bei einer Änderung des Zustandes.
2 FEATURE_BM_SECACK_AVAILABLE 0: keine Quittungen
1: Der Melder beherscht das Secure-ACK-Quittungsverfahren für Belegtmeldungen
3 FEATURE_BM_SECACK_ON Wenn dieses Feature ungleich 0 ist, dann ist Secure-ACK-Quittungsverfahren enabled. Der Wert gibt das Retransmitintervall in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 20 entsprechend 200ms.
4 FEATURE_BM_CURMEAS_AVAILABLE 0: keine Strommessdaten
1: Der Melder kann Strommessdaten (eines Abschnittes) liefern
5 FEATURE_BM_CURMEAS_INTERVAL Wenn dieses Feature ungleich 0 ist, dann ist Strommessung enabled.
Der Wert gibt das Abtastintervall der Strommessung in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 200 entsprechend 2s.
6 FEATURE_BM_DC_MEAS_AVAILABLE 0: keine Ersatzmessung verfügbar. (siehe hierzu auch MSG_BM_CONFIDENCE)
1: Ersatzmessung: Der Melder kann Belegtmeldungen auch bei abgeschaltetem Fahrstrom liefern
7 FEATURE_BM_DC_MEAS_ON 1: Der Melder liefert Belegtmeldungen auch bei abgeschaltetem Fahrstrom
8 FEATURE_BM_ADDR_DETECT_AVAILABLE 1: Der Melder kann erkannte Lok-Adressdaten liefern (sofern im Lokdekoder aktiviert)
9 FEATURE_BM_ADDR_DETECT_ON 1: Der Melder liefert die Adressdaten
4.7.3. Downlink: Nachrichten für Belegtmelder

Vorbemerkung: Die Anzahl der Melder eines Knotens wird mit den Befehlen MSG_FEATURE... abgefragt bzw. verändert. Man kann die über die Featureeinstellung auch die Zahl der Melder konfigurieren, diese Möglichkeit dient speziell zum Support von Interfaces auf bisherige Meldersysteme: z. B. ein S88-System hat erst mal eine unbekannte Länge und muss daher erst in der Größe definiert werden. Die Zahl der Melder je Knoten ist auf 128 beschränkt.

  • MSG_BM_GET_RANGE:

    Mit diesem Befehl werden die Zustände aller Belegtmelder in einem bestimmten Bereich übertragen. Es folgen 2 Bytes: START, ENDE, welche die zu übertragenden Melderbits bezeichnen. START und ENDE müssen je durch 8 teilbar sein.

    Das Rückmeldersystem antwortet mit allen Belegtmeldungen von START bis (exklusiv) ENDE. Die Antwort soll bevorzugt mittels MSG_BM_MULTIPLE erfolgen.

    Hinweis:
    Wenn START außerhalb des Bereiches der verfügbaren Melder liegt, erfolgt eine Fehlermeldung. Wenn ENDE außerhalb liegt, wird die Angabe bei der Antwort auf die verfügbaren Melder beschränkt.
  • MSG_BM_MIRROR_MULTIPLE:

    Mit diesem Befehl werden die eingelesenen Zustände byteweise zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) werden evtl. falsch übertragene Belegtmeldungen vom Melder nochmal übertragen.

    Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren, bei aktiviertem Secure-ACK erfolgt die Antwort umgehend (mit MSG_BM_MULTIPLE).

    Es folgen Angaben zur Basisadresse dieses Abschnittes und Länge der Meldung sowie die Belegtmeldungsdaten, kodiert wie bei MSG_BM_MULTIPLE.

  • MSG_BM_MIRROR_OCC:

    Mit diesem Befehl wird eine einzelne Belegtmeldung zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) wird diese einzelne Belegtmeldung vom Melder nochmal übertragen, falls der Zustand im Melder nicht mit der Mirrormeldung übereinstimmt.

    Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren.

    Es folgt ein Byte mit der lokalen Melderadresse (MNUM) wie bei MSG_BM_OCC.

  • MSG_BM_MIRROR_FREE:

    Mit diesem Befehl wird eine einzelne Freimeldung zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) wird diese einzelne Freimeldung vom Melder nochmal übertragen, falls der Zustand im Melder nicht mit der Mirrormeldung übereinstimmt.

    Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren.

    Es folgt ein Byte mit der lokalen Melderadresse (MNUM) wie bei MSG_BM_FREE.

Anmerkungen zu den BM_MIRROR_* Befehlen:
Bei der Quittierung von Belegtmeldungen sollte die Quittung mit der gleichen Befehlsart wie die Belegtmeldung erfolgen: erfolgte die Belegtmeldung byteweise, sollte auch die Quittung byteweise erfolgen. Ebenso für Einzelmeldungen. Der Grund hierfür liegt im Echtzeitverhalten: Angenommen, der Belegtmelder meldet mehrere Bits sehr schnell hintereinander mittels MSG_BM_OCC / MSG_BM_FREE. Wenn jetzt der Host die erste Meldung quittiert und hier ein Byte zurückschickt, in dem nur ein Teil der Belegtmelderbits korrekt ist, dann bekommt er vom Belegtmelder-Knoten postwendend eine MSG_BM_MULTIPLE-Nachricht, welche ihm den richtigen Vektor anzeigt. Das passiert ebenso für alle folgenden MSG_BM_*-Nachrichten, welche noch in der Pipeline sind.
  • MSG_BM_ADDR_GET_RANGE:

    Es folgen 2 Bytes: START, ENDE;

    Mit diesem Befehl werden die vom Rückmelder erfassten Lok-Adressen erneut übertragen und zwar für die Abschnitte von Index START bis Index ENDE-1. Es erfolgt eine Reihe von (Einzel-)Adressmeldungen (MSG_BM_ADDRESS). Wenn ein Abschnitt keine Lokadresse enthält, wird dieser Abschnitt nicht übertragen.

  • MSG_BM_GET_CONFIDENCE:

    Es folgen keine Parameter.

    Die aktuelle 'Qualität' der Belegtmeldung wird angefragt, der Knoten antwortet mit einer MSG_BM_CONFIDENCE.

4.7.4. Uplink: Nachrichten für Belegtmelder

Vorbemerkung: Generell erfolgen Meldungen im Uplink spontan (nach erfolgter Freigabe im Interface). Bestimmte Meldungsarten können mittels Feature-Einstellung ein- oder ausgeschaltet werden.

Für Belegtmeldung werden 3 verschiedene Nachrichtentypen verwendet:

  • MSG_BM_OCC:

    eine einzelne Belegtmeldung (als Änderungsmeldung); es folgt ein Byte mit der lokalen Melderadresse (MNUM).

  • MSG_BM_FREE:

    eine einzelne Freimeldung (als Änderungsmeldung); es folgen ein Byte mit der lokalen Melderadresse (MNUM). Wenn durch eine Belegtmeldung ein Abschnitt als frei gemeldet wird, so ist implizit auch eine evtl. gemeldete Lok auf diesem Abschnitt verschwunden.

  • MSG_BM_MULTIPLE:

    Diese Nachricht übermittelt Belegt/Freimeldungen eines ganzen, zusammenhängenden Bereiches an Melderadressen. Es folgen Angaben zur Basisadresse dieses Bereiches und Anzahl der der Meldungen sowie die Belegtmeldungsdaten selbst.

    MSG_BM_MULTIPLE Parameter
    ParameterBeschreibung
    MNUM Basisadresse des gemeldeten Abschnittes (wie bei MSG_BM_OCC), diese muss hier aber ein ganzzahliges Vielfaches von 8 sein.
    SIZE Anzahl der gemeldeten Bits, Wertebereich 8… 128. Size kann ebenfalls nur vielfache Werte von 8 annehmen.
    DATA[0…N] Melderdaten: 1…16 Bytes, wobei das LSB des ersten Bytes der Basisadresse entspricht, das MSB des ersten Bytes Basisadresse + 7 entspricht. Das LSB des zweiten Bytes entspricht Basisadresse + 8 usw.

    Diese Nachricht ist speziell in der Initialisierungsphase bzw. nach einem Protokollfehler zum schnellen Einlesen der Belegtmeldung gedacht.

  • MSG_BM_CONFIDENCE:

    Diese Nachricht übermittelt eine Information über die 'Vertrauenswürdigkeit' der aktuellen Belegtmeldung, es folgen 3 Bytes, welche den Zustand bezeichnen. Je nach Zustand des Gleissignals kann die Erfassung der Belegtmeldung beeinträchtigt sein: so ist z. B. bei einem Kurzschluss des Gleissignals je nach internem Aufbau des Belegtmelders nur eine 'eingefrorene' oder gar keine gültige Meldung möglich.

    Bei Ausfall der Gleisstromversorgung oder des Erfassungsystems muss die entsprechende CONFIDENCE-Meldung zeitlich vor den Änderungen der Belegt- oder Adressmeldungen eingehen, damit hat das Hostprogramm die Möglichkeit, nachfolgende Belegt- oder Adressmeldungen im richtigen Kontext zu sehen.

    Nach einem Wechsel des Vertrauenszustands sind die Nachrichten zur Lokgeschwindigkeit und eine evtl. davon abgeleitete Ortsbestimmung fallweise veraltet.

    MSG_BM_CONFIDENCE Parameter
    ParameterBeschreibung
    VOID 0: die Belegtmeldung leitet sich aus der tatsächlichen Situation am Gleis ab.
    <>0: die gemeldete Belegung ist ungültig, eine Erfassung zurzeit nicht möglich.
    FREEZE 0: die Belegtmeldung wurde mit dem Eingangssignal oder einer Ersatzmethode des Melders ermittelt.
    <>0: die Belegtmeldung ist nicht aktuell, sondern der gespeicherte Zustand einer frühreren Situation.
    NOSIGNAL 0: die Belegtmeldung wurde mit gültigem Eingangssignal ermittelt (d.h. es liegt ein Gleissignal an).
    <>0: es fehlt ein gültiges Eingangssignal vom Booster.

    Es handelt sich bei diesen Bytes also um 'Warnstufen':

    • ¬VOID ∧ ¬FREEZE ∧ ¬NOSIGNAL: das Meldeergebnis ist komplett okay.
    • ¬VOID ∧ ¬FREEZE ∧ NOSIGNAL: es handelt es sich um eine Ersatzmessung (mit geringerer Fehlerfreiheit, insbesondere im Kurzschlussfall) und das Gleissignal ist ausgefallen.
    • ¬VOID ∧ FREEZE ∧ NOSIGNAL: es handelt sich um einen eingefrorenen Zustand vom letzten Zeitpunkt bevor das Gleissignal ausgefallen ist. Der Belegtmelder schickt in diesem Zustand keine Spontanmeldungen mehr, Abfragen sind aber möglich.
    • VOID ∧ ¬FREEZE ∧ NOSIGNAL: Es liegen (noch) keine Ergebnisse einer Erfassung vor (z. B. beim Start), es liegt kein Gleissignal an. Der Belegtmelder schickt in diesem Zustand keine Spontanmeldungen mehr, Abfragen sind sinnlos.

    Anmerkung: Mittels dieser Nachricht lässt sich auch ohne Boosterüberwachung ein Boosterausfall erkennen, welcher z. B. durch Kurzschluss, Nothalt oder einen Hardware-Defekt ausgelöst werden kann.

    Es ist zulässig, dass der Melderbaustein bis zu 8 Erfassungsbereiche hat, in diesem Fall soll je Erfassungsbereich das entsprechende Bit in VOID, FREEZE und NOSIGNAL gesetzt werden. Wenn nur ein Erfassungbereich vorhanden ist, wird jeweils das LSB gesetzt, bei 2 Erfassungsberreichen die beiden unteren Bits, usw. Eine Hostsoftware muss die Bereiche nicht zwingend getrennt betrachten, sondern kann die Meldung auch einfch für den gesamten Knoten gelten lassen.

    Wenn spontane Belegtmeldung aktiviert ist, dann erfolgt auch eine spontane Meldung bei Änderung des Vertrauenszustandes des Melders. Sollte ein Melder mehrere Erfassungsbereiche besitzen (welche evtl. zugleich den Zustand wechseln), soll die Zusammenfassung zeitlich dicht aufeinanderfolgender Zustandsänderungen zu einer einzigen Meldung bereits im Knoten erfolgen.

  • MSG_BM_ADDRESS:

    Mit dieser Meldung wird das Auftreten einer Lok in einem bestimmten Abschnitt angezeigt.

    Es folgen drei oder mehrere Bytes: MNUM, ADDRL, ADDRH, [ADDRL, ADDRH], ...

    Ist nur ein Dekoder im Abschnitt so erfolgt eine 3 Byte Nachricht. Sind mehrere Dekoder im Abschnitt, so werden die Adressen der Dekoder in folgenden Adresspaaren ADDRL, ADDRH übertragen. Es können maximal 16 Adressen in einem Abschnitt gemeldet werden.

    MSG_BM_ADDRESS Parameter
    ParameterBeschreibung
    MNUM Lokale Nummer des Belegtmelders, Wertebereich 0…127
    ADDRL, ADDRH Adresse des Lok- bzw. Zubehördekoders. Wertebereich entsprechend dem DCC-Wertebereich. Kodierung wie bei BiDi-Detektoren.
    Hinweise zum Verhalten des Knotens:
    Wenn eine Adressmeldung erfolgt ist und der Dekoder in diesem Abschnitt nicht mehr detektiert werden kann, dann meldet der Knoten diese mit einer MSG_BM_ADDRESS mit Adresse 0.
    Wenn bei mehreren Dekodern einer in diesem Abschnitt nicht mehr detektiert werden kann, dann meldet der Knoten eine MSG_BM_ADDRESS mit den noch vorhandenen Adressen.
    Wenn keine Belegung auf einem Abschnitt gemeldet wird (z. B. via MSG_BM_FREE), sind implizit auch alle Adressmeldungen aufgehoben.
  • MSG_BM_CURRENT:

    Strom-Meldung, es folgen zwei Bytes: MNUM, CURRENT

    MSG_BM_CURRENT Parameter
    ParameterBeschreibung
    MNUM lokale Adresse des Melders
    CURRENT Stromverbrauch
    Kodierung des Stromwertes
    WertBedeutung
    0kein Stromverbrauch, Gleis ist frei.
    1…15Stromverbrauch, in mA. Möglicher Bereich: 1…15mA
    16…63Stromverbrauch, Wert ist (Datum - 12) * 4mA. Möglicher Bereich: 16…204mA
    64…127Stromverbrauch, Wert ist (Datum - 51) * 16mA. Möglicher Bereich: 208…1216mA
    128…191Stromverbrauch, Wert ist (Datum - 108) * 64mA. Möglicher Bereich: 1280…5312mA
    192…250Stromverbrauch, Wert ist (Datum - 171) * 256mA. Möglicher Bereich: 5376…20224mA
    251…253reserviert.
    254Overcurrent aufgetreten.
    0xFFNur Belegtmeldung, kein exakter Verbrauch bekannt.

    MSG_BM_CURRENT wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des Feature FEATURE_BM_CURMEAS_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

4.7.5. Features für BiDi-Detektoren

Bidirektionale Nachrichten (railcom) der Fahrzeuge können in verschiedenen Knoten wie Belegtmeldern und Boostern ausgewertet werden. Dazu können diese die folgenden Features anmelden:

Aufstellung der Features für Bidi-Detektoren
NummerNameBedeutung
10 FEATURE_BM_ADDR_AND_DIR 1: Der Detektor hat Richtungserkennung, d.h. die prinzipielle Fähigkeit dazu.
11 FEATURE_BM_ISTSPEED_AVAILABLE 0: Der Detektor versteht keine Speedmeldungen
1: Der Detektor kann Speedmeldungen vom Dekoder weiterleiten
12 FEATURE_BM_ISTSPEED_INTERVAL Wenn dieses Feature ungleich 0 ist, dann werden Speedmeldungen weitergeleitet. Der Wert gibt das Intervall der Speedmeldungen in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 50 entsprechend 500ms
13 FEATURE_BM_CV_AVAILABLE 0: Der Detektor versteht keine CV-Antworten
1: Der Detektor kann CV-Antworten von Dekodern einlesen und weiterleiten
14 FEATURE_BM_CV_ON 0: Der Detektor leitet CV-Antworten des Dekoders nicht weiter
1: Der Detektor leitet CV-Antworten des Dekoders weiter
28 FEATURE_BM_DYN_STATE_INTERVAL 0: Der Detektor leitet DYN-Antworten des Dekoders nicht weiter
1…255: Der Detektor leitet DYN-Antworten des Dekoders weiter; Interval in Einheiten von 100ms
29 FEATURE_BM_RCPLUS_AVAILABLE 0: Der Detektor versteht keine RailcomPlus-Antworten
1: Der Detektor kann RailcomPlus-Antworten von Dekodern melderabschnittsbezogen weiterleiten
2: Der Detektor kann RailcomPlus-Antworten von Dekodern global weiterleiten (MNUM=255)
4.7.6. Uplink: Nachrichten für BiDi-Detektoren

Sowohl in Belegtmeldern als auch in anderen Knoten wie etwa Boostern können bidirektionale Nachrichten (railcom) der Fahrzeug- bzw. Stationärdekoder ausgewertet werden. Globale Detektoren, die nicht zwischen mehreren Meldeabschnitten unterscheiden, setzen das MNUM-Feld auf 255.

Bei der Meldung einer Dekoderadresse wird folgendes Schema verwendet:

Kodierung der Adressmeldung
WertBedeutung
0 keine Adresse erkannt.
1…10239 Lok- bzw. Zubehöradresse; Zur Unterscheidung werden die beiden MSB verwendet.
Bit 15,14Bits 13…0
00Lokadresse, Orientierung (Aufgleisrichtung) nach vorne
10Lokadresse, Orientierung nach hinten
01Accessory-Adresse
11Extended Accessory Adresse
Hinweise zur Fahrzeugorientierung:
Die Richtungsangabe im MSB ist nur gültig, wenn auch die entsprechende Einstellung (FEATURE_BM_ADDR_AND_DIR) die Übertragung der Aufgleisrichtung vorsieht. Falls dieses Feature abgewählt ist, soll das Richtungsbit mit 0 übertragen werden und darf nicht ausgewertet werden.
Ein gesetztes Richtungsbit bedeutet, dass die Lok mit Ihrer linken Seite (bei Blickrichtung in Fahrtrichtung vorwärts, Führerstand 1) mit der Gleisseite verbunden ist, in welcher der Detektor installiert ist. An der linken Seite ist bei Verdrahtung mit NEM-Farben der Radschleiferanschluss in schwarz (rechte Seite ist rot).

In Knoten, die BiDi unterstützen, dienen die folgenden BiDiB-Nachrichten zur Weiterleitung der entsprechenden Rückmeldungen:

  • MSG_BM_ACCESSORY:

    (noch genauer zu spezifizieren)

    Mit dieser Meldung wird die Rückmeldung eines Accessory Dekoders angezeigt.

  • MSG_BM_CV:

    CV-Meldung, es folgen fünf Bytes: ADDRL, ADDRH, CVL, CVH, DAT

    MSG_BM_CV Parameter
    ParameterBeschreibung
    ADDR 2 Byte, Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    CV 2 Bytes, CV, Wertebereich 0…1023; 0 entspricht der CV1
    DAT Das gelesene Datum.
    Hinweise:
    Ein Rückmeldebaustein soll kurz hintereinander eintreffende, mehrfache POM-Antworten zur gleichen CV auf einer Lok filtern und nur eine Nachricht an den Host schicken. Trotzdem ist es möglich, dass zu einem POM-Befehl mehrere Antworten eingehen (wenn z. B. eine Lok zwei verschiedene Rückmelder überbrückt).
    POM-Nachrichten können auch durch andere Befehlsgeräte (z. B. Handregler) verursacht werden, ein Hostprogramm muss das berücksichtigen.
    Sollte das Detektorsystem nicht in der Lage sein, die Lokadresse zu bestimmen, so ist das Adressfeld für die Lokadresse mit 0xFFFF zu übertragen; Ebenso wird mit der CV-Adresse verfahren, hier wird 0xFFFF statt der richtigen CV-Adresse übertragen. (Das ist nur ein Notbehelf, um extrem einfach gebaute PoM-Detektoren zu unterstützen und nicht empfohlen!)
  • MSG_BM_XPOM:

    CV-Meldung einer POM-Operation, es folgen 10 bis 13 Bytes: ADDRL/DID0, ADDRH/DID1, 0/DID2, 0/DID3, 0/VID, OPCODE, CVL, CVH, CVX, DATA[1…4]

    Alle Parameter sind wie bei MSG_CS_POM kodiert, eine Lokadresse enthält jedoch zusätzlich die Aufgleisrichtung wie oben beschrieben.

    Hinweis:
    XPOM-Block-Leseoperationen sind seitens der Zentrale mit einer Sequence-ID ausgerüstet, das Detektorsystem muss die Rückmeldeantwort des Dekoders mittels dieser Sequence-ID dem DCC-Befehl zuordnen und die Felder für Decoder-ID bzw. Adresse und CV passend zuweisen.
  • MSG_BM_SPEED:

    Geschwindigkeits-Meldung, es folgen vier Bytes: ADDRL, ADDRH, SPEEDL, SPEEDH

    MSG_BM_SPEED Parameter
    ParameterBeschreibung
    ADDR 2 Byte, Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    SPEED 2 Bytes, Geschwindigkeit in km/h, Lowbyte wird zuerst übertragen

    FEATURE_BM_ISTSPEED_INTERVAL legt fest, wie oft die Übertragung erfolgt. Empfohlen ist eine Einstellung von mind. 200ms. Der Detektor soll Speednachrichten mitteln, wenn diese vom Dekoder häufiger als die eingestellte Übertragungsrate eintreffen. Sollte keine Änderung der Geschwindigkeit erfolgen, soll der Detektor nichts übermitteln, dies gilt insbesondere bei der Geschwindigkeit 0.

    Die MSG_BM_SPEED soll nur einmal je (Lok-)Dekoder erfolgen, auch wenn dieser Dekoder aktuell verschiedene Abschnitte überbrückt und daher in diesen Abschnitten zugleich erfasst wird.

    MSG_BM_SPEED wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des Feature FEATURE_BM_ISTSPEED_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

    MSG_BM_SPEED Nachrichten mit Adressfeld = extended Accessory werden von stationären Messanlagen gesendet.

  • MSG_BM_DYN_STATE:

    Zustands-Meldung eines Dekoders, es folgen fünf Bytes: MNUM, ADDRL, ADDRH, DYN_NUM, VALUE

    MSG_BM_DYN_STATE Parameter
    ParameterBeschreibung
    MNUM Lokale Nummer des Belegtmelders, Wertebereich 0…127; 255
    ADDR 2 Byte, Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    DYN_NUM 1 Byte, kennzeichnet den übertragenen Zustand.
    0:reserviert
    1:Signalqualität
    2:Temperatur
    3:Behälter 1
    4:Behälter 2
    5:Behälter 3
    6-255:reserviert
    VALUE 1 Byte, Zustandswert.
    Dyn-NumKodierung des Zustandswertes
    0: reserviert
    1: Signalqualität, Wertebereich 0…100
    Übertragen wird das Verhältnis fehlerhaft empfangener Pakete zu Gesamtpaketen in Prozent.
    Ein Wert von 0 bedeutet fehlerfreien Empfang (seitens des Dekoders).
    2: Temperatur (signed char).
    WertBedeutung
    0…127Temperatur in der Einheit Grad Celsius.
    128…225reserviert.
    226…255negative Temperatur (-30°C…-1°C).
    3: (Betriebs-) Energievorrat, Wertebereich 0…100
    Angabe des Füllstandes des Behälters 1; Antriebsenergie (z. B. Akkustand)
    4: Behälter 2
    5: Behälter 3
    6-255: reserviert

    FEATURE_BM_DYN_STATE_INTERVAL legt fest (in Einheiten von 100ms), wie oft die Übertragung erfolgt. Empfohlen ist eine Einstellung von mind. 1s. FEATURE_BM_DYN_STATE_INTERVAL = 0 schaltet die Übertragung ab. Der Detektor soll Zustandmeldungen der Lok nicht übermitteln, wenn diese vor Ablauf von eines FEATURE_BM_DYN_STATE_INTERVAL vom Lokdekoder eintreffen.

    Die MSG_BM_DYN_STATE soll nur einmal je (Lok-)Dekoder erfolgen, auch wenn dieser Dekoder aktuell verschiedene Abschnitte überbrückt und daher zugleich in mehreren Abschnitten erfasst wird.

    MSG_BM_DYN_STATE wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des Feature FEATURE_BM_DYN_STATE_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

    Hintergrund-Information zur DYN_NUM = 1: Entsprechende Lokdekoder vorausgesetzt (diese müssen railcom ID7, Sub-ID7 bedienen) kann damit eine Art Quality-of-Service Anzeige realisiert werden. Der Lokdekoder führt eine Statistik über alle empfangenen DCC-Pakete (Zahl fehlerhafter Pakete / Gesamtzahl). Diese Statistik wird an den Detektor übertragen und von BiDiB weitergeleitet. Das Hostprogramm entscheidet dann über die Auswertung: korreliert der Fehler mit der Lok, kann ein Hinweis über verschmutzte Radkontakte ausgegeben werden, korreliert der Fehler mit dem Gleisabschnitt, kann auf verschmutztes Gleis geschlossen werden.

  • MSG_BM_RCPLUS:

    Meldung eines Dekoders im RailcomPlus-Anmeldeprozess. Ein BiDi-Detektor sendet diese Nachricht ab, wenn im Anmeldevorgang eine entsprechende Rückmeldung eines oder mehrerer Dekoder im Abschnitt erkannt wurden.

    Es folgen zwei oder mehr Bytes: MNUM OPCODE DECVID DECUID[4]

    MSG_BM_RCPLUS Parameter
    ParameterBeschreibung
    MNUM Lokale Nummer des Belegtmelders, Wertebereich 0…127; 255
    OPCODE Klassifizierung der Antwort, s.u.
    DEC_MUN[4] Seriennummer des Dekoders, diese 4 Bytes (Manufacturer Unique Number) bilden zusammen mit der DEC_MID die Unique-ID des Dekoders (DID).
    DEC_MID Herstellerkennung des Dekoders (Manufacturer IDentifier, wie DCC Vendor ID)
    Kodierung des Opcode für RailcomPlus Erkennung
    WertBedeutung
    TCP
    RC_PONG LOCO OKAY 0 Auf den Gleisausgabebefehl PING oder FIND hat genau ein Dekoder geantwortet.
    T gibt an, ob ein Lok- oder Accessory-Dekoder geantwortet hat. C gibt an, ob der Dekoder die CID dieses Systems bereits kennt; wenn nicht dann sind weitere Abfragen erforderlich, insbesondere eine Kontrolle der Adresse. P gibt die Orientierung des Dekoders an.
    Es folgen 5 Bytes mit der DID des antwortenden Dekoders.
    1
    NEW 0
    1
    ACCESSORY OKAY 0
    1
    NEW 0
    1
    RC_PING_COLLISION 0 Auf den Gleisausgabebefehl PING haben mehrere Dekoder gleichzeitig geantwortet. Die Antwort am Gleis ist nicht kollisionsfrei und fehlerhaft.
    1
    RC_FIND_COLLISION 0 Auf den Gleisausgabebefehl FIND haben mehrere Dekoder gleichzeitig geantwortet. Die Antwort am Gleis ist nicht kollisionsfrei und fehlerhaft.
    Es folgen 5 Bytes mit der DID des Suchbefehls, auf den geantwortet wurde.
    1
    RC_BIND_ACCEPTED LOCO Auf den Gleisausgabebefehl BIND ist eine Bestätigung des Dekoders erfolgt. Der Dekoder ist unter der zugewiesenen Adresse ansprechbar.
    Es folgen 7 Bytes mit der DID des quittierenden Dekoders sowie der befohlenen Adresse, kodiert wie oben beschrieben, um den Aufbau einer Zuordnungstabelle im Host zu erleichtern.
    ACCESSORY
    Hinweise:
    BIND, FIND bzw. PING-Nachrichten werden von der Gleisausgabe mehrfach 'back-to-back' wiederholt. Ein Detektorsystem darf dabei nur eine entsprechende Quittungs-Nachricht je Abschnitt erzeugen.
    PING-Nachrichten werden von der Gleisausgabe zyklisch wiederholt (z. B. im Abstand von 1…2s). Ein Detektorsystem darf dabei nur dann eine entsprechende BM_RCPLUS-Nachricht erzeugen, wenn sich der Inhalt des PONGs gegenüber der vorherigen Nachricht verändert hat.
    Bei FIND-Nachrichten der Gleisausgabe muss das Detektorsystem eine BM_RCPLUS-Nachricht erzeugen, wenn sich der Inhalt der FIND-Nachricht verändert hat (neuer Suchbereich) oder wenn sich die Antwort(en) der Dekoder (PONG) gegenüber den vorherigen Nachrichten verändert hat.