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.27 von BiDiB, Stand 07.04.2017.

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 Belegt- und Positionsmeldungen
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
30 FEATURE_BM_TIMESTAMP_ON 0: Der Melder liefert keine Zeitstempel
1: Der Melder liefert Belegtmeldungen mit Systemzeitstempeln
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_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.

  • 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 nicht mit dem Zustand im Melder übereinstimmende 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.

    Anmerkung:
    Die Quittierung soll nur dann byteweise erfolgen, wenn auch die Belegtmeldung byteweise übertragen wurde. Der Grund hierfür liegt im Echtzeitverhalten: Angenommen, der Belegtmelder meldet mehrere Bits sehr schnell hintereinander als Einzelmeldungen MSG_BM_OCC / MSG_BM_FREE. Würde der Host die erste Meldung mit einem ganzen Byte quittieren, in dem dann jedoch nur ein Teil der Belegtmelderbits korrekt ist, bekäme er vom Belegtmelder-Knoten postwendend noch eine MSG_BM_MULTIPLE-Nachricht mit dem richtigen Vektor. Dasselbe geschähe für alle folgenden Einzelnachrichten, 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 folgen ein Byte mit der lokalen Melderadresse (MNUM) und optional zwei Bytes mit einem BiDiB-Systemzeitstempel (TIMEL, TIMEH).

    Ist das FEATURE_BM_TIMESTAMP_ON aktiviert und liegt dem Melder eine gültige Systemzeit vor, liefert er einen Zeitstempel für den Zeitpunkt der Melderauslösung mit. Ist dieser nicht genau bestimmbar, soll der Zeitstempel weggelassen werden.

    Hinweis: Die Systemzeit wird auf dem BiDiBus mittels MSG_LOCAL_SYNC-Nachrichten in Abständen von bis zu 32 s synchronisiert. Ein Melder muss eine Clock-Genauigkeit besser als 30ppm haben, um innerhalb dieser Zeitspanne maximal 1 ms wegzudriften. Hat der Melder eine höhere Ungenauigkeit (z. B. mit RC-Oszillator), darf er dieses Feature nicht verwenden.

    Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_OCC für dieselbe MNUM an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Der Ereignis-Zeitstempel kann dabei weggelassen werden, wenn er nicht mehr vorliegt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

    Es soll auch solange keine Freimeldung für den Abschnitt gegeben werden, bis die Belegtmeldung bestätigt worden ist; dies ist insbesondere für Punktmelder mit kurzen Auslösezeiten wichtig.

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

    Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_FREE für dieselbe MNUM an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

  • 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[1…16] Melderdaten. Das LSB des ersten Bytes entspricht der Basisadresse, das MSB des ersten Bytes der Basisadresse + 7. Das LSB des zweiten Bytes entspricht Basisadresse + 8 usw. Ein gesetztes Bit steht für einen belegten Abschnitt, ein nicht gesetztes für einen freigemeldeten.

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

    Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_MULTIPLE für denselben Bereich an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

  • 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üheren 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
    ADDR[2] 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_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 0: Der Detektor leitet Speedmeldungen nicht weiter.
1…255: Der leitet Speedmeldungen weiter, 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; Intervall 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)
31 FEATURE_BM_POSITION_ON 0: Der Detektor leitet Positions-Meldungen des Dekoders nicht weiter
1: Der Detektor leitet Positions-Meldungen des Dekoders weiter
32 FEATURE_BM_POSITION_SECACK 0: Der Detektor wiederholt Positions-Meldungen des Dekoders nicht.
1…255: Das Secure-ACK-Quittungsverfahren ist für Positionsmeldungen enabled. Der Wert gibt das Retransmitintervall in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 20 entsprechend 200ms.
4.7.6. Downlink: Nachrichten für BiDi-Detektoren
  • MSG_BM_MIRROR_POSITION:

    Mit diesem Befehl wird eine Positionsmeldung eines Dekoders zurück an den Detektor übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_POSITION_SECACK) wird die letzte Positionsmeldung vom Detektor nochmal übertragen, falls der dem Detektor bekannte Ort für den Dekoder nicht mit der Mirrormeldung übereinstimmt.

    Liegen dem Detektor keine Ortsinformationen zu dem Dekoder vor oder ist Secure-ACK nicht aktiviert, ignoriert der Detektor diese Nachricht.

    Es folgen fünf Bytes mit der Adresse des Dekoders und der ID der Ortsmarke, kodiert wie bei MSG_BM_POSITION.

4.7.7. 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 mit linker Lokseite zum Detektor
10Lokadresse, Orientierung mit rechter Lokseite zum Detektor
01einfache Zubehördekoder, 11 Bit Weichenadresse (Basic Accessory, "Ausgangspaar" nach RCN 217)
11erweiterte Zubehördekoder, 11 Bit Adresse (Extended Accessory)
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.
Das Richtungsbit kodiert die (fahrtrichtungsunabhängige) Aufgleisrichtung, es ist gesetzt wenn die mit dem Detektor verbundene Schiene rechts liegt. Links/rechts bezieht sich dabei auf die Lok, bei Blickrichtung nach vorn (Vorwärtsfahrt, zur Rauchkammertür bzw. Führerstand 1). Auf der linken Seite ist bei Verdrahtung mit Farben nach NEM 650 der Radschleiferanschluss in schwarz ausgeführt, auf der rechten Seite in rot.
An welcher Gleisseite der Detektor installiert ist kann von Abschnitt zu Abschnitt verschieden sein, es wird aber empfohlen konsistent DCC1 (positive Polarität, gekennzeichnet auch als +, P oder A) als gemeinsamen Pol vom Booster zur Schiene durchzuverbinden und Detektoren sowie Belegtmelder in DCC2 (negative Polarität, gekennzeichnet auch als -, N oder B) einzuschleifen.

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] Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    CV[2] 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] Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    SPEED[2] 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_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] Adresse des meldenden Dekoders, kodiert wie oben beschrieben
    DYN_NUM Kennzeichnung des ü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 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.
  • MSG_BM_POSITION:

    Positions-Meldung, es folgen fünf Bytes: ADDRL, ADDRH, TYPE, LOCATIONL, LOCATIONH

    MSG_BM_POSITION Parameter
    ParameterBeschreibung
    ADDR[2] Adresse des meldenden Dekoders, kodiert wie oben beschrieben.
    TYPE Art der Ortsangabe:
    • 0: Ortsmarke mit vom Anwender vergebener 16-Bit-Kennung
    • 1…255: reserviert
    LOCATION[2] Ortsangabe des Dekoders, Lowbyte wird zuerst übertragen.

    Positionsmeldungen werden gesendet, wenn ein Fahrzeugdekoder über bidirektionale Nachrichten seine Position bekanntgibt. Diese bestimmt er üblicherweise aus Ortsmarken, die ihre Kennnung (ID, auch: Adresse) per Infrarot oder Ähnlichem direkt an das Fahrzeug übertragen. Im Gegensatz zu Belegtmeldungen, bei denen die Fahrzeuge von einem fest installierten Sensor detektiert werden und je Meldeabschnitt (MNUM) ein oder mehrere Dekoderadressen vorliegen können, wird hier jeder Dekoderadresse eine Ortskennung zugeordnet.

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

    Ist das FEATURE_BM_POSITION_SECACK aktiviert, muss der Host sofort eine MSG_BM_MIRROR_POSITION mit demselben Inhalt an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

    Es soll darauf geachtet werden, je Dekoder erst dann eine neue Position zu melden wenn die vorherige bestätigt worden ist.

    MSG_BM_POSITION-Nachrichten mit Adressfeld = extended Accessory werden von stationären Empfängern gesendet, die zur Identifikation von Ortsmarken dienen.