Übertragung
Serielle Verbindung
BiDiBus
Netzwerk

BiDiBus, ein Highspeed-Bus für Modellbahnsteuerung, Belegtmeldungen und DCC-BiDi

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

1. Allgemeines

1.1. Zielsetzung, besondere Eigenschaften

Klassische Modellbahnprotokolle und Bussysteme wie z. B. S88, RS-Bus, Xpressnet® oder Loconet® kommen bei zunehmender Digitalisierung der Modellbahn an ihre Leistungsgrenzen, was Buszugriffsgeschwindigkeit, Datensicherheit und Störunempfindlichkeit angeht. Zusammen mit dem Protokoll BiDiB entstand daher der folgende Verbindungsbus, welcher hier einen deutlichen Fortschritt bringt. BiDiBus vereint eine Datenverbindung für BiDiB mit einer anlagenweiten Verteilung des Gleissignals, der Befehlsbestätigung des Gleissignals und einer Busstromversorgung. Dieser Bus kann ein Segment eines BiDiB-Systems abbilden, innerhalb eines gesamten BiDiB-Systems können Segmente baumförmig über Hubs verbunden werden.

  • Hohe Geschwindigkeit von 500kBaud.
  • Gesicherte Übertragung durch moderne Prüfsummenverfahren.
  • Dynamische Anpassung der Buszuordnung für kürzeste Latenz.
  • Freie Verkabelung ohne Busadressen oder DIP-Schalter, einfache Konfiguration (Plug & Play)
  • Max. Buslänge 200m je Segment, kurze Stichleitungen sind zulässig.
  • Max. Teilnehmerzahl: > 1000, (max. 32 je Segment)

1.2. Rechtliches, Lizenz

Das Protokoll BiDiB und die physikalische Verbindung BiDiBus ist für die Verwendung zusammen mit Modellbahnsteuerungssoftware vorgesehen und kann ohne Lizenzkosten sowohl auf der PC-Seite als auch auf der Hardwareseite implementiert werden. Zur Sicherstellung der Kompatibilität sind jedoch folgende Lizenz-Bedingungen einzuhalten:

Ergänzend kommt bei der physikalischen Verbindung BiDiBus hinzu:

  • Zur Prüfung der Kompatibilität müssen den Arbeitskreis BiDiB mind. 2 Baugruppen kostenlos zur Verfügung gestellt werden. Meßergebnisse, Oszilloskopausdrucke und Prüfprotokolle sind auf Verlangen zur Einsicht vorzulegen bzw. bei Komptibilitätsproblemen die entsprechende Implementierung offen zu legen.
    Sofern sich Kompatibilitätsprobleme auf diesem Weg nicht ausräumen lassen, soll in einer gemeinsamen Fehlersuchsitzung die Ursache gefunden werden.
  • Steckverbindungen nach dieser Norm sind mit dem Logo (  <<BiDiB>>  ) zu kennzeichnen.

1.3. Revisionsstand

Dieses Dokument beschreibt Revision 0.13 von BiDiBus, Stand 27.01.2017. Der Stand ist konsolidiert und getestet.

Revisionsgeschichte
V0.01 2011-12-01 Initiales Dokument
V0.02 2011-01-27 Klarstellung beim Paketaufbau, Multimessagepaket
V0.03 2011-03-30 Klarstellung bei der Adressierung, BiDiBus-Enums neu, kleinere Korrekturen
V0.04 2012-02-12 BiDiBus-Enums für Poll und Logon dazu, Erläuterungen zum Logon.
Zustand Busy sowohl für Upstream als auch Downstream dazu
V0.05 2012-06-22 BiDiBus-Power-Up als direkten Busbefehl entfernt. Grund: Zu große Falscherkennungsgefahr bei 0x3F (hier ist das Parity auch 1), vorhandener Ersatz durch direkte Kodierung bzw. Timeoutverhalten.
V0.06 2012-10-08 Definition Taktgenauigkeit hinzu
V0.10 2014-01-06 Feinjustage des Timing, minimale Reponsezeit von 0µs auf 2µs geändert.
V0.11 2014-07-11 Timing und Benutzung der ACK-Leitung eindeutiger definiert.
V0.12 2016-03-23 Lockerung bei den Buchsenanzahlen, verpflichtendes Biasing am Bus-Master.
V0.13 2017-01-28 Übertragung Systemzeit hinzu.

1.4. Glossar

In diesem Dokument werden folgende Bezeichnungen für die einzelnen Protokollteilnehmer oder Eigenschaften verwendet:

Interface, Master: Die Stelle im Bussystem, welche die Busverwaltung durchführt (und i. d. R. mit dem Host bzw. mit der übergeordneten Struktur kommuniziert).
Knoten: Ein Teilnehmer im Bussystem, also die (fallweise verteilte) Hardware. Ein Teilnehmer kann wiederum ein Interface enthalten, und als Hub darüber Sub-Knoten ansprechen.
Hub: Ein Teilnehmer im Bussystem, welcher zwei Busebenen miteinander verbindet. Die Unterstruktur kann evtl. auch nur virtuell sein. Beispiel: Ein Besetztmelder habe 12 normale Melder und 4 Bidi-Melder: das wird er sinnvollerweise als Unterstruktur mit separaten Features anmelden.
Unique-ID: Die von Hersteller in den Melder fest programmierte, eineindeutige Kennung, bestehend aus 16 Bit Herstellerkennung und 32 Bit herstellerspezifischer Nummer (z. B. Produktindex und Seriennummer).
NODE_ADDR: Die vom Interface nach der automatischen Anmeldung vergebene Nummer, unter welcher der Knoten in dieser Sitzung angesprochen wird. Das Interface hat fest die NODE_ADDR = 0, alle anderen NODE_ADDR für Knoten werden bei der Anmeldung vergeben.
Aktiv-Liste: Ein vom Interface verwaltete Liste, in welcher alle aktuell am Bus aktiven Teilnehmer verzeichnet sind. Die Aktivliste enthält Unique-ID, aktuelle zugewiesene NODE_ADDR und gemeldete Feature-Klassen.
Bus-Timeout: Das ist die Zeit, nach der z. B. nicht mehr reagierende Teilnehmer als inaktiv betrachtet werden. (250ms)
RJ45: 8-poliges Stecksystem gemäß TIA-968-A Spezifikation. (Netzwerkkabel)

2. Elektrische, mechanische Parameter

2.1. Verdrahtung

Als Datenmedium für BiDiB wird RJ45 (CAT5) verwendet. Der Masseschirm ist anzuschließen und an jedem Knoten durchzuverbinden. Die Übertragung findet im RS485 Standard mit 500kBaud statt.

Verdrahtungsregeln: Der Bus ist linear zu verlegen, die max. Kabellänge ist 200m, Das Kabel muss an beiden Enden mit 120 Ohm abgeschlossen werden. Hierzu ist auf jedem Busteilnehmer ein Abschlusswiderstand vorzusehen, dieser ist abschaltbar auszuführen (s.u.). Es sind max. 8 Verzweigungen in nicht abgeschlossene Leitungen erlaubt (Stichleitungen (=Stubs)), diese Stubs dürfen max. 4m lang sein. Zwischen zwei benachbarten Knoten muss mind. 30cm Kabel installiert sein.

Diese Verdrahtungsregeln garantieren einen sicheren Betrieb, der Bus ist aber bei sauberer, impedanzkorrekter Verlegung (Kabelausführung, Stecker) auch bei 500m sicher zu betreiben.

BiDiBus benutzt folgendes Verkabelungsschema:

BiDiBus, Pinout on RJ45
1Weiß/OrangeVCC
2Orangereserved
3Weiß/GrünGND
4BlauDATA_RS485+
5Weiß/BlauDATA_RS485-
6GrünACK
7Weiß/BraunDCC_RS485+
8BraunDCC_RS485-

Erläuterungen:

DATA_RS485+, DATA_RS485-:

DATA_RS485+ meint hier den nicht invertierenden Ausgang des RS485-Treibers (EIA-485 bezeichnet das als 'B', aber allgemein üblich in den Datenblättern der Chips ist der Pin mit A bezeichnet).

Die Leitung soll IDLE sein, wenn DATA_RS485+ > DATA_RS485-. Der Zustand IDLE ist ein Highpegel am Tx oder Rx der seriellen Verbindung zum Prozessor.

VCC:

Der Bus wird bevorzugt vom Interface gespeist, die Spannung liegt zwischen 9V und 13V DC. Die Speisung hat über eine in Serie liegende Diode und eine selbstrückstellende Sicherung zu erfolgen. Der maximale Speisestrom beträgt 1A. Ein Knoten, welcher VCC einspeist, ist am Stecker mit dem verfügbaren Strom zu beschriften.

Jeder Busteilnehmer darf max. 30mA aus dem Bus entnehmen, zzgl. des Strombedarfes, welcher durch aktives Senden entsteht (typischerweise 40mA = 2,4V an 60 Ohm). Die Stromaufnahme eines Busteilnehmer ist im Datenblatt anzugeben. Ist die Stromaufnahme höher, so muss die Stromversorgung des Knotens aus einem eigenen Netzteil erfolgen.

Erfolgt die Stromversorgung des Teilnehmers aus dem Bus, so darf diese nur über einen Schutzwiderstand von mind. 22 Ohm und eine Verpolschutzdiode (diese liegt in Serie zum Widerstand) erfolgen.

Bei Verdrahtungslängen über 100m kann eine zweite Einspeisung erforderlich sein bzw. die maximale DC-Buslast darf nicht ausgenutzt werden.

Es ist empfohlen, auf dem Interface eine Kontrolleinrichtung zur Messung von Spannung und Strom vorzusehen.

DCC_RS485+, DCC_RS485-:

Das DCC-Leitungspaar dient zur synchronen Verteilung des Gleissignals auf mehrere Booster. Das DCC-Signal am Bus ist immer differentiell, es enthält keine Cutout. Die Gleisausgänge eines Boosters sind mit '+' (oder 'P') und '-' (oder 'N') zu kennzeichnen. Wenn DCC_RS485+ > DCC_RS485+, soll der mit '+' oder 'P' gekennzeichnete Gleisausgang höheres Potential als der mit '-' oder 'N' gekennzeichnete Ausgang haben.

Die erlaubte Verzögerungszeit des Gleisausgangssignales gegenüber der RS485-Leitung ist 0µs bis 5µs.

DCC_RS485+ soll in der ersten Hälfte eines DCC-Bits höhere Polarität als DCC_RS485- haben, d.h. das DCC-Signal beginnt mit einer steigenden Flanke.

Das DCC-Signal ist zur Verteilung an Booster gedacht, nicht als Ansteuerung von Busteilnehmern.

Ein Busknoten, welcher als Interface agiert, soll das DCC-Signal für sein Bussystem neu verstärken, dabei ist eine maximale Latenz von 50ns (übliche Gatterlaufzeit) zulässig.

Ob ein Knoten die DCC-Verteilung treibt oder empfängt, wird durch Feature FEATURE_GEN_DRIVE_BUS (107) festgelegt. Es ist sicherzustellen, dass nicht auf zwei Knoten dieses Feature aktiviert ist. Deshalb gilt folgende default-Festlegung:

  • Interface-Knoten haben das Feature gesetzt und treiben das DCC-Leitungspaar ihres untergeordneten Busses.
  • normale Knoten haben das Feature nicht gesetzt und empfangen DCC.
ACK:

Openkollektorring für Befehlsbestätigung am DCC Bus und für Notaus. Die ACK-Leitung ist am Interface mit einer Stromquelle von 5mA-10mA gegen VCC hochgezogen (i. d. R. ein Pullup von 1k). Jeder Teilnehmer kann die ACK über einen Widerstand von 22 Ohm auf Low ziehen. ACK gilt dann als aktiviert (Low), wenn der Pegel der ACK-Leitung unter 0.8V liegt.

Die ACK-Leitung übermittelt zwei Informationen:

  • DCC Befehlsbestätigung: Direkt nach dem DCC-Befehl und eng an das DCC-Timing gekoppelt liefern Bidi-Detektoren einen Rückmeldepuls über den BiDiBus, diese zeigt an, dass ein Lok/Zubehördekoder den DCC-Befehl des vorangegangenen DCC-Telegramms positiv bestätigt hat (erkannt und ausgeführt).
    Dies ermöglicht die Optimierung der Signalausgabe in der Zentrale, eventuell geplante Wiederholungen des DCC-Befehls können dann eingespart werden; Dadurch kann man in einem DCC-System eine signifikante Durchsatzsteigerung erreichen. Zudem kann eine Gleisausgabeeinheit erkennen, ob die Lok noch reagiert oder das System verlassen hat bzw. wegen Kontaktschwierigkeiten liegen geblieben ist.
    Die folgenden Timingangaben beziehen auf das Ende des Endebits des vorangegangen DCC-Befehls. Nach dem DCC-Befehl schließt sich i. d. R. die Cutoutlücke an (bis 464us), es folgen die Präambelbits des nächsten Befehls. Die Timingvorgaben am BiDiBus sind so gewählt, dass bei regulärer Präambel die Zentrale den Zustand der ACK-Leitung beim ersten DCC-0-Bit abfragen kann.
    Timing ACK-Puls (ab Ende der DCC-Nachricht)
     min:max:
    Beginn:0us1400us
    Ende:2500us4000us
    Auswertung:1750us2450us
  • Not-Abschaltung: Wenn ACK für mehr als 10ms kontinuierlich auf Low gezogen ist, so muss eine Gleisausgabe abschalten. Das Ausschalten bleibt permanent erhalten, bis es mit einem Systembefehl wieder aufgehoben wird.
    Booster sollen selbst abschalten, wenn auf dem DCC-Signal länger als 15ms keine Flankenwechsel erfolgen. Bei Wiederkehr des DCC-Signals am Eingang soll der Booster selbständig einschalten, sofern ACK high ist. Damit kann nach einer Notabschaltung einfach durch eine kurze DCC-Unterbrechung der Betrieb synchron auf allen Boostern wieder aktiviert werden.
    Diese Eigenschaft des automatischen Wiederanlaufes von Boostern muss über das Feature FEATURE_BST_INHIBIT_AUTOSTART abschaltbar sein.
reserved:
Diese Leitung ist an jedem Busknoten 1:1 durchzuverbinden.
Spannungspotentiale:
Alle Knoten sind über GND miteinander verbunden, das ist auch die Referenz für das Gleissignal. Booster schalten DCC zwischen GND und Versorgung, eine eventuelle Railcom-cutout wird auf der GND-Seite erzeugt.
Der Stromausgleich beim Überfahren von Boosterdomains mit Fahrzeugen soll mit einer zusätzlichen Masseverbindung gestützt werden.

Beispielschaltung:

Einfaches Interface, ohne Auskopplung von DCC. Die Spannungsstabilisierung für den RS485-Treiber ist nicht dargestellt. Zu beachten ist, dass bei Fehlfunktion oder Reset des Knotens der Bus nicht getrieben werden darf, es wird empfohlen, auf BIDIB_DIR einen Pulldown vorzusehen.

2.2. Regeln für Busteilnehmer:

Jeder festinstallierte Busteilnehmer hat zwei RJ45 Buchsen für eine problemlose Durchschleifung des Busses anzubieten.

Es ist abschaltbarer 120 Ohm Abschlusswiderstand sowohl für BiDiB als auch für DCC vorzusehen, die Abschaltung ist bevorzugt mechanisch/elektrisch so auszuführen, dass bei zwei steckendem Kabeln in der der Abschluss abgeschaltet ist. Sollte der Abschluss über eine Steckbrücke schaltbar sein, so ist die Beschriftung TERM zu verwenden. Ein Biasing (s.u.) ist nur am Interface zulässig. Die am Abschluss anfallende typ. Verlustleistung von ca. 125mW (max. 250mW) ist zu beachten.

Es dürfen nur Transceiver-Chips verwendet werden, welche die nachfolgende Spezifikation einhalten. Das Datenblatt des verwendeten Tranceiver-Chips, die Art der Clockerzeugung und ein Nachweis zum Mikrotiming ist auf Nachfrage offen zu legen.

Spezifikation der für BiDiBus zugelassenen RS485 Transceiver
Baudrate: >500kBaud
Buslast: <1/8 Unit Load
Anstiegs-, Abfallzeit: > 200ns (slew rate limited)
Failsafe: sowohl 'open' als auch 'short'
Receive-Threshold: <-200mV: 0; >-50mV: 1
Empfohlene Bustransceiver: z. B. Max3085, Max3075E, Max13451E, ADM3075, ADM2483 (isoliert), ISO15, Exar SP3075, XR3175, ISL3175, ISL83075

Ein Schutz der Transceiver mit einer TVS-Diode (transient voltage suppressor) ist empfohlen (z. B. mit Semtech SM712, SOT23).

Anstiegszeit (slew rate):
Hier wird ein unteres Limit von 200ns definiert. Das entspricht bei der Mindestempfindlichkeit der Empfänger von 200mV einer SlewRate von > 1µs/V. Dadurch lassen sich Reflexionen an unabgeschlossenen, kurzen Stichleitungen gut vermeiden.
Taktgenauigkeit:
Zur Sicherstellung des fehlerfreien Empfang werden folgende Taktgenauigkeiten für die Baudrategeneratoren der Busteilnehmer festgelegt:
Spezifikation Baudrate BiDiBus
Baudrate: >500kBaud
Taktfehler Interface: < 200ppm
Taktfehler Knoten: < 1%
Identifikation:
Jeder Teilnehmer muss eine einfache Möglichkeit haben, eine sog. Identifikation auszulösen. Dies ist bevorzugt ein Taster, beschriftet mit IDENTIFY. Jeder Teilnehmer muss den Identify-Zustand deutlich anzeigen können, z. B. durch eine schnell blinkende Leuchte.
Besondere Regeln für Interfaces:
An einem Interface genügt es auch, nur eine RJ45 Buchse zum Anschluss des Busses bereitstellen.
Ein Interface muss den von ihm kontrollierten Bus gleichspannungsmäßig vorspannen (Biasing) und überwachen. Die Vorspannung besteht aus 1,5kOhm von A nach VCC und 1,5kOhm von B nach GND.
Besondere Regeln für Hubs:
Hubs erweitern den Protokollbereich auf eine weitere Struktur. Hier kann es evtl. erforderlich sein, die Leitungen und damit die Gültigkeitsbereiche für DCC und ACK zu trennen. Deshalb müssen Hubs diese Leitungen trennen können.
Besondere Regeln für Verzweigungen:
Bausteine, die mehr als zwei Buchsen besitzen (z. B. zur Anbindung eines Handreglers über eine Stichleitung), müssen diese zusätzlichen Buchsen explizit als solche kennzeichnen.

3. Bustiming

Der Bus wird im Halbduplex betrieben, die Daten auf dem Bus werden als serielle UART-Daten mit den Parametern 500kBaud, 9 Bits, keine Parity, ein Stopbit (auch als 9N1 bezeichnet) übertragen.

Es sind insgesamt 32 Busteilnehmer auf einer Ebene zugelassen.

3.1. Mikrotiming

Regelbetrieb:

Das Interface kontrolliert die Buszuteilung und erteilt den einzelnen Knoten jeweils Sendeerlaubnis. Hierzu verwendet es ein Pollkommando, bestehend aus 8 Bit und gesetztem 9. Bit (als Framekennung). Nach Aussenden des Pollkommandos wird der Transmitter des Interface innerhalb 1µs nach Ablauf des Stopbits abgeschaltet und spätestens 2µs nach dem Ende des Stopbits wird der Empfänger freigeschaltet. Nach dem Abschalten des Transmitters ist mind. 1µs zu warten, bis der Empfänger freigegeben wird. Damit wird ein fehlerhafter Empfang unterdrückt, welcher durch einen Spike beim Umschalten auftreten könnte. (Diese enge Regel für das Abschaltens gilt nur für das Interface, nicht für Knoten. Damit wird es den Knoten leichter gemacht, das Timing einzuhalten.)

Ein Busknoten, dem der Bus zugeteilt wurde, darf frühestens 2µs nach Ablauf des Stopbits vom Pollkommando und spätestens 20µs nach Ablauf des Stopbits mit seinem Startbit beginnen. Ein Knoten muss seine Datenübertragung ohne Lücken durchführen und nach der Übertragung des Stopbits nach dem letzten Zeichen seinen Transmitter innerhalb von 5µs abschalten. Das Interface sendet daraufhin das nächsten Pollkommando frühestens nach 10µs nach dem Stopbit der letzten erhaltenen Nachricht. Es ist dem Interface erlaubt, hier eine längere Pause einzulegen.

Sollte eine Nachricht eines Knotens (aus Fehlergründen) vor Erreichen der angekündigten Zeichenanzahl abbrechen, so wird nach 50µs der Knoten als 'defekt' angenommen und nicht mehr adressiert.

Anmeldevorgang:

Beim Anmeldevorgang kann es zu einer Kollision von Nachrichten von Knoten kommen, um diese soweit wie möglich zu vermeiden, gelten bei Antwort auf ein Anmeldekommando unterschiedliche Regeln:

Ein Busknoten, der auf ein Anmeldekommando antwortet, darf frühestens nach einer Verzögerungszeit NODE_CA_TIME mit seiner Antwort beginnen. NODE_CA_TIME ist eine Zeit im Bereich von 2 bis 34µs, welcher jeder Knoten individuell aus seiner Unique-ID berechnen muss. Bevor die Antwort tatsächlich gesendet wird, ist im gesamten Zeitbereich NODE_CA_TIME der Bus auf Aktivität zu überwachen. Wenn dort eine 0 detektiert wird (d.h. ein anderer Knoten sendet bereits eine Antwort auf das Anmeldekommando), so ist die Aussendung der eigenen Antwort nicht zu beginnen.

(NODE_CA_TIME: CA=Collision Avoidance, Zeitintervall zur Kollisionsvermeidung)

3.2. Makrotiming

Ein Busteilnehmer muss mindestens alle 'Bus-Timeout' ein (beliebiges) Pollkommando oder Pingkommando des Interfaces beantworten. Zulässig als Antwort ist irgendeine sinnvolle Datenübertragung oder eine leere Nachricht. Ein Busknoten, der innerhalb 'Bus-Timeout' keine Nachricht sendet, wird aus der Aktiv-Liste entfernt.

Ein Busteilnehmer, welcher seit 'Bus-Timeout' nicht aktiv adressiert oder angepingt wurde, hat sich als abgemeldet zu betrachten, und muss sich erneut anmelden.

4. Busprotokoll

4.1. Allgemeine Festlegung

Das Interface erteilt mit dem Pollkommando die Sendeerlaubnis für einen Teilnehmer. Dies gilt auch für das Interface selbst – es hat fest die lokale Adresse 0 und 'erteilt' sich selbst durch Pollkommando(0) die Sendeerlaubnis.

Auf dem Bus wird BiDiB als Protokoll verwendet, dabei ist folgender Nachrichtenaufbau vorgeschrieben:

BIDIBUS_PKT ::= P_LENGTH  MESSAGE_SEQ  CRC
MESSAGE_SEQ ::= ε | MESSAGE  MESSAGE_SEQ

Ein BIDIBUS_PKT besteht also aus einer MESSAGE_SEQ, der ein Längenparameter vorangestellt ist und welche durch CRC abgesichert ist. Die MESSAGE_SEQ besteht aus keiner (in Ausnahmefällen), einer oder mehreren MESSAGEs (siehe hierzu BiDiB Nachrichtenaufbau), ein Knoten kann also mehrere Nachrichten in einer Antwort bündeln. Diese Eigenschaft ist insbesondere für Interfaces wichtig, welche Nachrichten des nachgeordneten Busses zusammenfassen und 'en bloc' weitersenden können. Auch Melder profitieren davon, können doch damit nach dem Einschalten auflaufende Belegtmeldungen zusammengefasst an den Host übertragen werden.

P_LENGTH gibt die Paketgröße in Bytes an. Hierbei wird die Länge der MESSAGE_SEQ angegeben, P_LENGTH und CRC wird nicht mitgezählt.

CRC bezeichnet das CRC8-Byte; Auf der Senderseite wird das gemäß Polynom x8 + x5 + x4 + 1 über das Paket (also Length, Message(s)) gebildet, beginnend bei P_Length, Init=0, nicht invertiert. Empfängerseitig wird die CRC mit dem gleichen Polynom über das Paket inkl. CRC gebildet, das Ergebnis muss 0 sein.

In der Message ist eine Adresse enthalten, diese kann aus einem oder mehreren Bytes bestehen. Wenn die Nachricht von einem Knoten direkt kommt, so ist die Adresse 0. Die lokale Adresse des Knotens wird erst im Interface hinzugefügt. Kommt die Nachricht von untergeordneten Knoten, so beginnt das Adressfeld mit der lokalen Adresse auf der untergeordneten Struktur. Das Interface stellt dann dem Adressfeld die lokale Adresse voran.

4.2. Buszuteilung, Nachrichten des Interfaces

Das Interface steuert seinen Bus über Buskommandos. Es gibt Befehle für die lokale Verwaltung (Systemkommandos) und für die Buszuteilung bzw. normale Datenübertragung (Pollkommandos). Buskommandos haben neun Datenbits und werden vom Interface gesendet, das MSB (9.Bit) ist hierbei gesetzt.

  • Systemkommandos: 
    SYSTEM ::= (SYS_MSG + 0x40 + PARITY * 128)
SYS_MSG ::= 0x00 | … | 0x3F
PARITY ::= (XOR(SYS_MSG) ^ 1)

    Bei einem Systemkommando (=SYS_MSG) ist das Bit 6 gesetzt (0x40) und in den unteren 6 Bits wird die Art des Systemkommandos kodiert.

    • 0x3F: reserved

      Dieses Kommando ist reserviert und wird nicht benutzt. Grund: hier würde sich zu leicht eine falsche Erkennung ergeben.

    • 0x3E: BIDIBUS_LOGON (Anmeldeaufforderung)

      Das Interface sendet periodisch eine Anmeldeaufforderung. Wenn bei 64 aufeinanderfolgenden Anmeldeaufforderungen kein weiterer Anmeldevorgang mehr stattgefunden hat, dann nimmt das Interface an, dass die Erstanmeldung erfolgt ist und meldet gegenüber dem Host die NODETAB als verfügbar.

      Ein Client, welcher sich anmelden möchte, antwortet auf einen BIDIBUS_LOGON mit einem Paket, dessen Inhalt eine einzelne Nachricht mit der MNUM 0 und folgendem Aufbau ist. Dabei sind bestimmte Regeln zur Reduzierung von möglichen Buskollisionen einzuhalten (siehe unten).

      P_LENGTH M_LENGTH 0x00 0x00 MSG_LOCAL_LOGON UNIQUE_ID CRC8

      Hierbei ist UNIQUE_ID 7 Bytes lang, damit ergibt sich M_LENGTH zu 10 und P_LENGTH zu 11. Adresse und MSG_NUM sind hier 0. Der systematische Aufbau der Logonmessage ist identisch zu den normalen Messages.

    • 0x3D: BIDIBUS_BUSY

      Das Interface kann zur Zeit keine Nachrichten annehmen (z. B. weil die Weiterleitung Richtung Host überlastet oder blockiert ist), die Knoten werden jedoch weiterhin von der Aktivität des Interfaces benachrichtigt, um dort ein Abmelden zu verhindern. Ein Knoten sendet keine Antwort auf BIDIBUS_BUSY.

    • 0x00 … 0x3C: reserviert
  • Pollkommando: 
    POLL ::= (NODE_ADDR + 0x00 + PARITY * 128)
NODE_ADDR ::= 0x00 | … | 0x3F
PARITY ::= XOR(NODE_ADDR)

    Ein Pollkommando besteht aus der Knotenadresse (max. 6 Bits) und dem Paritybit. Das Parity wird als XOR über die Bits 0…6 gebildet und als Bit 7 eingefügt. Das Byte (also die Bits 0…7) hat also Even Parity.

    Nach einem Pollkommando darf nur der Knoten, dessen Adresse gleich der übertragenen NODE_ADDR ist, eine Nachricht senden.

    Die Nachricht des Knotens besteht aus:

    BIDIBUS_PKT ::= P_LENGTH  MESSAGE_SEQ  CRC

    Sofern der Knoten keine Nachricht absenden will, sendet er nur ein Byte P_LENGTH (Ping-Funktion), keine Nachricht und auch kein CRC-Byte. Als Inhalt für P_LENGTH sind 0, 1, 2 oder 3 zulässig. (Anmerkung: die minimale P_LENGTH eines regulären Pakets ist 4.)

    P_LENGTHBedeutung
    0NODE_READY: Knoten ist online und bereit, Nachrichten zu empfangen.
    1NODE_BUSY: Knoten ist online und nicht bereit, Nachrichten zu empfangen.
    2reserviert.
    3reserviert.
    4…64Knoten sendet eine Nachrichtensequenz, es folgen weitere Bytes.
    65…127reserviert.
    128…255MSB reserviert für Längenerweiterung.

    Ein Paket kann bis zu 64 Bytes an Nutzdaten enthalten, alle Empfänger müssen genug Speicher vorsehen um damit zurechtzukommen. Längere Nachrichtensequenzen müssen zerteilt und auf mehrere Pakete aufgeteilt werden.

4.3. Adressierung, Broadcast

Downstream:
Das Interface sendet seine Daten mit einem vorangestellten Pollkommando auf die Adresse 0. Die Zieladresse der Nachricht ist das erste Byte im Adressfeld der jeweiligen Nachricht. Innerhalb eines Pakets vom Interface kann es also vorkommen, dass Nachrichten an verschiedene Knoten enthalten sind. Die Knoten müssen daher Nachrichten des Interfaces dekodieren und überprüfen, ob diese an sie adressiert sind.
Broadcast:
Ist die lokale Adresse einer Nachricht leer (also nur die schließende 0 vorhanden), so handelt es sich bei dieser Nachricht um einen Broadcast. Broadcasts werden auf dem BiDiBus nicht bestätigt und sind zum einen für 'untergeordnete' Nachrichten wie z. B. Uhrzeit vorgesehen, zum anderen für Testzwecke und Debugzwecke wie z. B. einen Notfahrbetrieb oder eine Weichenschaltung abseits jeglicher Fahrstraßensicherung.
Upstream:
Das Interface sendet reihum ein Pollkommando an die angemeldeten Knoten. Die im Pollkommando enthaltene Adresse ist zugleich auch das erste Byte der Nachrichtenadresse, wenn diese Nachricht im Interface dann nach oben weitergereicht wird. D.h. das Adressfeld der Nachrichten enthält 0 (wenn diese Nachricht aus dem adressierten Knoten selbst kommt) bzw. den Adress-Stapel der nachgeordneten Knoten.

4.4. Anmeldevorgang

Das Interface sendet periodisch eine Anmeldeaufforderung (als System-Nachricht), diese geht an alle Knoten in dieser Ebene.

Auf diese Anmeldeaufforderung dürfen (und sollen) alle nicht angemeldeten Knoten antworten. Für die Antwort auf eine Anmeldeaufforderung gibt es besondere Timing-Regeln.

Jetzt können drei verschiedene Fälle auftreten:

  • kein Knoten sendet eine Antwort: es erfolgt keine weitere Aktion seitens des Interfaces, es sendet weiterhin periodisch Anmeldeaufforderungen (BIDIBUS_LOGON).
  • genau ein Knoten sendet eine Antwort: Das Interface erkennt dies daran, dass die Nachricht des Knotens fehlerfrei angekommen ist. Abgesichert wird dieser Vorgang dadurch, dass in dieser Nachricht die Unique-ID des Knotens mitgesendet wird. Es bestätigt dem Knoten die Anmeldung und weist ihm eine NODE_ADDR zu. Dies geschieht mittels einer Broadcast-Nachricht MSG_LOCAL_LOGON_ACK, der Knoten darf die NODE_ADDR nur dann aus der MSG_LOCAL_LOGON_ACK übernehmen, wenn die übertragene UNIQUEID mit seiner eigenen übereinstimmt.
  • mehrere Knoten senden gleichzeitig: es entsteht eine Kollision, die Antwort auf die Anmeldenachricht ist fehlerhaft. Es erfolgt keine Zuordnung eine Knotens auf eine NODE_ADDR.
    • Das Interface sendet keine Bestätigung und sendet weiterhin periodisch Anmeldeaufforderungen.
    • Der Knoten erhält keine Anmeldebestätigung. Er reagiert daraufhin für eine bestimmte Anzahl nicht mehr auf Anmeldeaufforderungen (sog. Backoff). Die Anzahl der zu ignorierten Anmeldeaufforderungen bestimmt er mit einer Zufallszahl, in deren Startbedingung die Unique-ID eingeht. Diese Zufallszahl vergrößert sich bei jedem fehlgeschlagenen Versuch bis zu einem (bestimmten) Maximalwert (=63). Der Algorithmus hierzu ist dem Beispielcode zu entnehmen.

Wenn aus irgendwelchen Gründen ein Logon eines Knotens vom Interface nicht angenommen werden kann (und dieser Zustand so auch dauerhaft sein wird), dann sendet das Interface eine MSG_LOCAL_LOGON_REJECTED Broadcast-Nachricht mit der betreffenden Unique-ID. Der angesprochene Knoten muss dann einen Fehlerzustand anzeigen und weitere LOGON-Versuche unterbleiben lassen, hierbei ist noch maximal ein weiterer Logonversuch (nach einem Timeout von 2 Sekunden) erlaubt.

Ein Besonderheit gilt noch beim ersten Einschalten: Damit sich hier nicht alle Busteilnehmer auf das erste Anmeldekommando stürzen, sollen Knoten bei Einschalten eine (von der Unique-ID abgeleitete, zufällige) Verzögerungszeit von 50 … 200ms nach der Power-Up Nachricht des Interfaces einhalten. Die Verzögerungszeit beim Anmelden ist auch wichtig, um bei Hotplug (und mehrfachem Starten infolge Kontaktprellen) doppelte Anmeldeversuche zu vermeiden.

Auch ist der erste Wert für Backoff möglichst zufällig zu bestimmen, Wertebereich 1…63.

4.5. Busverhalten in Sonderfällen

Für irreguläre Vorgänge am Bus sind folgende Verhaltensweisen festgelegt:

  • Sollte der Host die Nachrichten des Interfaces nicht abholen (Stau), so pollt das Interface die Knoten nicht mehr und verhindert dadurch, dass es weitere Nachrichten empfängt, die es nicht mehr weitersenden kann. Der lokale Ping läuft jedoch weiter.
  • Es liegt im Ermessen des Interfaces, wie es die Pollkommandos priorisiert. Das Interface soll aber vermeiden, einem Knoten, welcher aktuell Ziel einer Nachricht war, nach dieser Nachricht ein Pollkommando zu senden.
  • Die zeitlich korrekte Reihenfolge der Nachrichten ist nur für jeweils einen End-Knoten garantiert.

4.6. Systemzeit

Zur Synchronisation der Systemzeit sendet das Interface regelmäßig MSG_LOCAL_SYNC-Nachrichten als Broadcast. Der darin enthaltene Zeitstempel bezieht sich auf das Ende des Poll-Kommandos (nach dem Stopbit). Ein Interface, das BiDiB-Systemzeit unterstützt, muss solche MSG_LOCAL_SYNC-Nachrichten mindestens einmal alle 32 s (215ms) senden; damit werden Knoten mit üblichen Quarzen (Abweichung ≤30 ppm) noch häufig genug versorgt. Darüberhinaus soll darauf geachtet werden, auch gleich nach der Anmeldung von Knoten eine Synchronisation durchzuführen.