WRP, Wireless Railroad Protocol

    Wireless Railroad Protocol - Logo Version: 0.09
    Datum: 02.08.2010

    Innerhalb des Funknetzwerkes z.B. mit XBEE-Modulen werden die Nutzinformationen ('Payload') byteweise eingebettet. Nachfolgendes Protokoll definiert die Nachrichten zum Steuern einer Modellbahn, wie z.B. vom Handregler verwendet wird. Dieses Protokoll ist zum einen auf Effizienz optimiert, zum anderen durch den hierarchischen und logischen Aufbau besonders leicht zu dekodieren und damit für Mikrocontroller gut geeignet.

Prinzipieller Aufbau

    Das Protokoll WRP ist immer gemäß folgender Konvention aufgebaut: [[header][type][opcode][addr][data]]. Mehrfache Header in einer XBEE Nachricht sind zulässig, jedoch muß eine XBEE-Nachricht immer mit einem Header beginnen. Eine einzelne Modellbahnnachricht darf sich nicht über mehrere XBEE-Nachrichten erstrecken. Dadurch ist es möglich, bei vielen Nachrichten den prozentualen Overhead der Verwaltungsschicht (framing und routing) signifikant zu reduzieren.
    Nachrichten, welche von einem Teilnehmer nicht verstanden werden (z.B. weil sie noch nicht implementiert sind oder weil die Fähigkeiten nicht ausreichen), werden einfach ignoriert (Ausnahme: state-Nachrichten). Abfragen sind innerhalb von 200ms zu beantworten. Wenn eine Abfrage innerhalb von 400ms nicht beantwortet ist, wird die Verbindung als unterbrochen betrachtet. Die Zentrale bzw. Basisstation soll in diesem Fall bewegte Objekte (z.B. Loks) in einen konfigurierbaren Zustand (z.B. SOFT_STOP) umschalten.
    Dabei bedeutet:
    WRP Protokoll
    [header]8 Bit Gibt die Größe der Nachricht in Bytes an, Bereich 0-127; Ein gesetztes MSB bedeutet, diese Nachricht ist bestätigt und kommt von der Zentrale. Ein gelöschtes MSB bedeutet eine Anforderung oder Anfrage an die Zentrale. Nachrichten an die Zentrale können (und sollen), müssen aber nicht bestätigt werden. State-Nachrichten an die Zentrale müssen bestätigt werden, erst dann gilt der neue State als bestätigt.
    Die Länge ist in Bytes angegeben, der header selbst wird nicht mitgezählt. Ein header=0 markiert das Ende einer Befehlssequenz. Wenn das Ende der Befehlssequenz durch die Art der Übertragung sicher erkannt werden kann (z.B. bei ZigBEE/XBEE wird die Zahl der übertragenen Bytes mitgeliefert), dann kann die Endemarkierung entfallen. Der Nachrichtenempfänger muß in diesem Fall das Ende selber abprüfen.
    [type]4 Bit (0..3) Gibt die Klasse der Nachricht an. Es sind folgende Nachrichtenklassen definiert:
    1state
    2loco
    3accessory
    4feedback
    5programming
    13clock
    14system
    15firmware
    [opcode]4 Bit (4..7) Gibt innerhalb einer Nachrichtenklasse die anforderte oder auszuführende Operation an. z.B. speed setting|function setting|...
    [addr]16 Bit Optional: Gibt innerhalb einer Nachrichtenklasse die Nummer des Objekts (z.B. Lok) an, die für diese Operation verwendet werden soll. [addr] = 0xFFFF bezeichnet i.d.R. einen Broadcast, d.h. die Nachricht gilt für alle Objekte in dieser Klasse. Dieser Wert wird 'little endian' übertragen, d.h. das niederwertige Byte kommt zuerst.
    [data]0 Byte ... 64 Byte, byteweise organisiert. Enthält die notwendigen Daten und Parameter zum Befehl.

type: state

    Der type state ist als 0x1 codiert. Prinzipiell wird der type 'state' von der Zentrale bestätigt, erst dann ist er gültig. 'state'-Nachrichten von Clients sind Anfragen/Wünsche, den System-Zustand zu ändern. Es gibt folgende Opcodes:
    type: state
    WertopcodeBedeutung
    0x0OFFDas System wird abgeschaltet.
    0x1STOPAlle Loks werden mittels Nothalt angehalten, jedoch Weichen können nach wie vor geschaltet werden. Wenn Stop von der Zentrale nicht unterstützt wird, so wird OFF ausgeführt.
    0x2SOFT-STOPAlle Loks werden mit Fahrstufe 0 (also mit ihrer eigenen Verzögerung) angehalten, Weichen können weiterhin geschaltet werden. Wenn Soft-Stop von der Zentrale nicht unterstützt wird, so wird STOP ausgeführt.
    0x3GOWiederaufnahme des Betriebes
    0x8PROGProgrammiermode; Die Zentrale hat in den Programmiermode umgeschaltet und ist zur Ausführung von Programmierbefehlen (auf den Programmiergleis) bereit. Der normale Betrieb ruht.
    0x9PROGBUSYProgrammiermode; diese Meldung zeigt an, dass aktuell ein Programmiervorgang auf dem Programmiergleis durchgeführt wird.
    0xDBUSYDie Basestation bzw. der Funkkanal ist nicht mehr aufnahmefähig. Jeder Funkteilnehmer soll für mind. 100ms keine weiteren Nachrichten absenden.
    0xEDISCONNECTBase Station is no longer connected to a command station.
    0xFQUERYAbfrage des aktuellen Status. Wenn die Basestation dieses Kommando erhält, sendet sie den Status erneut ab.
    State-Nachrichten enthalten keine Adresse und kein Datenfeld. Wenn State-Nachrichten von der Zentrale gesendet werden, wird entweder eine Broadcast-Technik verwendet oder die gleiche Nachricht geht kurz hintereinander an alle bekannten Clients. (Anmerkung hierzu: der Broadcast der XBEE-Module hat relativ große Latenz und Bandbreitenoverhead, deshalb benutzt z.B. das Gateway hier die Einzeladressierung.)

type: loco

    Der type loco ist als 0x2 codiert. Es gibt folgende Opcodes:
    type: loco
    WertopcodeBedeutung
    0x0ESTOPHält die Lok [addr] mittels Notstop (DCC Fahrbefehl mit Wert 1) an. Es können auch mehrere Loks (jeweils Adresse als 16-Bitwort) in einer Nachricht übermittelt werden. Diese weiteren Loks werden als Liste von 16-Bit Werten (little endian) im Datenfeld übertragen.
    ESTOP ist nur zulässig auf Adressen, welche vorher diesem Handregler zugeteilt wurden. ESTOP löst keinen Eigentümerwechsel aus, der bisherige Eigentümer erhält auch keine Benachrichtung (obwohl der Nothalt durchgeführt wird).
    0x1CONTROLEinstellen von Speed, Dir, Licht, Funktionen F1-F28 der Lok [addr]. Die Werte sind im Datenfeld kodiert. Wenn ein Handregler diese Nachricht an eine Zentrale senden, so heißt dass, er will die Lok auch übernehmen.
    data[0]Bitfeld
    BitBedeutung
    0Operated:
    0: die Lok ist aktuell frei und kann übernommen werden.
    1: die Lok ist an anderer Stelle in Benutzung; sie kann übernommen werden, wird dabei jedoch von einer anderen Kontrollinstanz geklaut.
    3..1reserviert
    6..4Format:
    000: DCC14 (14 speed steps)
    001: reserveriert
    010: DCC28
    011: DCC128 (126 speed steps)
    1xx: reserveriert
    7Richtung, 0=vorwärts, 1=rückwärts
    data[1]Geschwindigkeit (1)
    data[2]FL, F4 - F1; 3 MSB sind reserviert. Die Bitorder ist: FL, F4, F3, F2, F1
    data[3]F8 - F5
    data[4]F20 - F13
    data[5]F28 - F21
    0x2DRIVEEinstellen von Speed, Dir der Lok [addr]. Die Werte sind im Datenfeld kodiert. Wenn ein Handregler diese Nachricht an eine Zentrale senden, so heißt dass, er will die Lok auch übernehmen.
    data[0]Bitfeld
    BitBedeutung
    0Operated:
    0: die Lok ist aktuell frei und kann übernommen werden.
    1: die Lok ist in Benutzung; sie kann übernommen werden, wird dabei jedoch von einer anderen Kontrollinstanz geklaut.
    3..1reserviert
    6..4Format:
    000: DCC14 (14 speed steps)
    001: reserveriert
    010: DCC28
    011: DCC128 (126 speed steps)
    1xx: reserveriert
    7Richtung, 0=vorwärts, 1=rückwärts
    data[1]Geschwindigkeit (1)
    0x4QUERYAbfragen der Lokparameter. Die Zentrale antwortet mit mit einer CONTROL-Nachricht, die Lok wird dabei nicht übernommen.
    0x5STOLENDie Lok wurde an anderer Stelle übernommen. Diese Nachricht erhält der Client, welcher zuletzt die Lok kontrollierte. (2)
    0x6ERRORDie Lok kann nicht gesteuert werden (Masternachricht). Normalerweise ist ein Fehler aufgetreten beim Versuch, die Lok zu steuern. (z.B. Lokbuffer voll)
    0x8RESERVEDie Lok wird gegen Übernahme durch einen anderen Regler gesichert. Wenn diese Nachricht vom Master kommt, konnte die Lok nicht übernommen werden. (3)
    0x9FREEDie Lokreservierung ist aufgehoben. (3)
    0xFLOCATEDie Lok [addr] wurde vom railcom Detektor SID (Sensor ID) erkannt.
    data[0]Lowbyte der SID
    data[1]Highbyte der SID
  • (1) Die Geschwindigkeit wird immer als Ganzzahl von 0 bis * kodiert, z.B. bei DCC126 also von 0 bis 126. Fahrstufe 1 bedeutet langsame Fahrt (und nicht Nothalt wie bei der Gleisausgabe); Es liegt im Ermessen der Basisstation, diese Angabe je nach verwendetem Digitalsystem und/oder Decoder in die Fahrstufen des Zieles umzurechnen, i.d.R. werden aber die Fahrstufen 1:1 durchgereicht.
  • (2) Ein Client, welchem die Kontrolle über eine Lok entzogen wurde, darf erst nach einer Bedieneraktion zu dieser Lok wieder versuchen, die Lok wieder unter Kontrolle zu nehmen. Beispielsweise sind automatische Sequenzen (Massensimulation) abzubrechen. Der Client darf aber die aktuellen Parameter dieser Lok nachfragen (QUERY) um seine Anzeige aktuell zu halten, jedoch nicht öfter als 3 Anfragen/s.
  • (3) Die Mechanismen zum Schützen und Freigeben sind optional.

type: accessory

    Der type accessory ist als 0x3 codiert. Es gibt folgende Opcodes:
    type: loco
    WertopcodeBedeutung
    0x0A_QUERYAbfragen der Stellung. Durch eine Abfrage der Stellung wird die Weiche automatisch in die Watchliste aufgenommen. Die Zentrale antwortet mit mit einer A_POSIT-Nachricht.
    0x1A_SETDer Zubehördekoder mit der Adresse [addr] wird mit Begriff in data[0] angesteuert. [addr] steht hier für die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    Zweibegriffige Zubehördekoder werden mit (aspect 0 = red) und (aspect 1 = green) angesteuert.
    (Die Zentrale erzeugt den Einschaltbefehl auf dem zugehörigen (gepaartem) Spulenausgang.)
    0x2A_RESETDer Zubehördekoder mit der Adresse [addr] wird mit Begriff in data[0] angesteuert. (Coil off, Abschaltbefehl; die Zentrale schickt den DCC-Abschaltbefehl an den Dekoder, anschließend wird eine eventuelle Stellungsrückmeldung eingelesen.)
    0x3A_POSITAnzeige der Stellung (Nachricht von der Zentrale). Dieser Befehl ist wie A_SET kodiert, er löst aber keine Aktion aus. (Nur Stellungsanzeige). Wenn beim Aspect das MSB (0xFF) gesetzt ist, ist die Weiche noch nicht umgelaufen bzw. die Stellung unbekannt.
    0x4WATCHMit diesem Kommando kann ein Client die in [addr] übergebene Weiche beobachten lassen. Er wird dann bei Zustandsänderungen dieser Weiche automatisch benachrichtigt. Eine Basisstation muß mind. 4 Beobachtungsplätze je Regler anbieten; sollte keine Beobachtungsplätze mehr frei sein, antwortet die Zentrale mit UNWATCH.
    0x5UNWATCHMit diesem Kommando wird die Beobachtung wieder aufgehoben.
    Wenn bei UNWATCH der Parameter [addr] == 0xFFFF ist, dann werden alle aktuell gesetzten Beobachtungen dieses Handreglers gelöscht.
    0x8XA_SETDer Extended Zubehördekoder mit der Adresse [addr] wird mit Begriff in data[0] angesteuert.
    0x9XA_POSITAnzeige der Stellung (Nachricht von der Zentrale). Dieser Befehl ist wie XA_SET kodiert, er löst aber keine Aktion aus.
    0xAXA_QUERYAbfragen der Stellung. Die Zentrale antwortet mit mit einer XA_POSIT-Nachricht

type: feedback

    Der type feedback ist als 0x4 codiert. Der maximale Adressbereich der Meldeereignisse ist auf 2040 festgelegt. Feedback bezeichnet hier nicht nur die tatsächliche Belegtmeldung eines Abschnittes oder das Auftreten eines Melderereignisses (wie z.B. eine Lichtschranke), sondern einem Melder können fallweise weitere Eigenschaften wie z.B. aktueller Stromverbrauch zugeordnet sein. Zudem kann ein Melder Konfigurationsmöglichkeiten besitzen (z.B. Ansprechschwelle, Haltezeit (Memory), usw.).
    Ergänzend zu den reinen Belegtmelderbits werden daher weitere Nachrichten definiert. Zur Optimierung der Übertragung sind Belegtmelderabfragen sowohl bitweise als auch byteweise möglich. Bei byteweiser Übertragung wird je ein Modul (d.h. 8 Bits) angesprochen, es sind 255 Moduladressen vorgehen, die 256.te Moduladresse ist als 'ungültig' reserviert.
    Fallweise habe die Bussystem, mit denen WRP verbunden ist, weniger Bits, dann werden die höheren Adressen ignoriert.

    Es gibt folgende Opcodes:
    type: feedback
    WertopcodeBedeutung
    0x0FEVENTEin oder mehrere einzelne Sensorereignisse wird übermittelt.
    Jedes Sensorereignis ist als 16 bit kodiert, little endian. Die Aufteilung der 16 Bits erfolgt gemäß folgender Tabelle.
    Sensorereignisse werden fortfolgend in ADDR und Datenpaaren (Data[0/1], Data[2/3] usw.) kodiert. Je Feedbackmeldung dürfen maximal 16 Sensorereignisse übertragen werden.
    0x1FBITS8Übermittlung eines Blocks von 8 Belegtmeldebits. Dieser Opcode ist die Antwort auf eine FQUERY8-Anfrage.
    ADDR kodiert den Byteblock, Wertebereich 0..254; (ergibt dann 2040 Melderbits) DATA[0] enthält den Belegungsvektor, Bit 0 entspricht der niederwertigsten Melderadresse. Der Belegtvektor deckt die Melderadressen von ADDR*8 bis ADDR*8+7 ab.
    0x2FBIDIMeldung eines Railcomereignisses (noch genauer zu definieren)
    0x3FCONFIGEinstellen eines Parameters am Rückmelder (noch genauer zu definieren)
    0x8FQUERY1Abfrage eines Rückmeldeereignissen. ADDR enthält direkt die Melderadresse, Wertebereich 0...2039. Die Antwort kann neben der reinen Belegtmeldungsinformation auch weitere Daten wie z.B. Stromverbrauch enthalten.
    0x9FQUERY8Abfrage von Rückmeldezuständen (Belegtmeldung). Es werden je 8 Bit 'en bloc' abgefragt. ADDR kodiert den Byteblock, Wertebereich 0..254;
    0xAFSUBSCRIBEAnmelden für Benachrichtigung bei Eintritt eines Rückmelderereignisses
    ADDR0: unsubscribe
    1: subscribe
    Data[0..n]Bytefolge, bezeichnet die jeweils abonnierten 8-Bitbereiche, Wertebereich wie bei FQUERY8
    Damit der Handregler nicht bei jedem Rückmeldeereignis benachrichtigt werden muß, werden nur die vom Handregler abonnierten Rückmelderbereiche bei einer Statusänderung auch an den Handregler übertragen.
    Ein Unsubscribe ohne weitere Parameter löscht alle Abonnements dieses Handreglers.
    Wenn diese Nachricht vom Master kommt (mit Addr=0), dann war der letzte SUBSCRIBE nicht erfolgreich, vermutlich die max. mögliche Zahl an Abonnements überschritten.
    0xBFQBIDIAbfragen eines Railcomereignisses (noch genauer zu definieren)
    0xCFQCONFIGAbfragen eines Parameters am Rückmelder (noch genauer zu definieren)
    Sensorereignis
    Bit 15..12Bit 11..0Bedeutung
    0b0000ADDRDas Rückmeldebit mit der Adresse ADDR ist nicht gesetzt.
    0b1000ADDRDas Rückmeldebit mit der Adresse ADDR ist gesetzt.
    ...... reserviert.

type: programming

    Der type programming ist als 0x5 codiert. Es gibt folgende Opcodes:
    type: programming
    WertopcodeBedeutung
    0x0PROG_STATStatusreport beim Programmieren; hier werden die Parameter ADDR, DATA[0..3] übermittelt. Der Statuserport wird als Antwort auf eine PQUERY Anfrage übermittelt.
    addrHier wird die Lok- oder Zubehöradresse übermittelt. Wenn addr = 0 ist, dann handelt es sich um einen Programmiervorgang auf dem Programmiergleis.
    Zur Unterscheidung bei Hauptgleisprogrammierung wird im Falle Accessory 0x8000 zur Adresse addiert, im Falle extended Accessory 0xC000.
    data[0]Status
    0Programmieren fehlerfrei beendet.
    1läuft noch.
    2offen, keine Dekoderantwort.
    3Kurzschluß
    data[1,2]CV-Adresse die gelesen oder programmiert wurde. (little endian, Wertebereich 0..1023.
    data[3]Inhalt, der gelesen oder programmiert wurde.
    Der Statusreport bezieht sich immer auf den letzen Programmiervorgang, dies gilt (bis auf weiteres) auch bei mehreren parallel ausgelösten Programmiervorgängen.
    0x1RDCVLesen einer CV (Read) auf dem Programmiergleis.
    [addr]Adresse der CV, welche gelesen werden soll. Wertebereich: 1..1024
    Nach einem Read-Befehl muß das Ergebnis mit einem PQUERY abgeholt werden.
    0x2WRCVSchreiben einer CV (Read) auf dem Programmiergleis.
    [addr]Adresse der CV, welche geschrieben werden soll. Wertebereich: 1..1024
    data[0]Der zu schreibende Inhalt
    Nach einem WRITE-Befehl muß das Ergebnis mit einem PQUERY abgeholt werden.
    0x3POM_RDCVLesen einer Lok-CV (Read) auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse
    data[0][1]Adresse der CV, welche gelesen werden soll. Codierung 1..1024, little endian
    Nach einem Read-Befehl muß das Ergebnis mit einem POMQUERY abgeholt werden.
    0x4POM_WRCVSchreiben einer Lok-CV auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse;
    data[0][1]Adresse der CV, welche geschrieben wird. Codierung 1..1024, little endian
    data[2]Der zu schreibende Inhalt
    0x5PAC_RDCVLesen einer Accessory-CV (Read) auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse
    data[0][1]Adresse der CV, welche gelesen werden soll. Codierung 1..1024, little endian
    Nach einem Read-Befehl muß das Ergebnis mit einem POMQUERY abgeholt werden.
    0x6PAC_WRCVSchreiben einer Accessory-CV auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse;
    data[0][1]Adresse der CV, welche geschrieben wird. Codierung 1..1024, little endian
    data[2]Der zu schreibende Inhalt
    0x7PEX_RDCVLesen einer Extended Accessory-CV (Read) auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse
    data[0][1]Adresse der CV, welche gelesen werden soll. Codierung 1..1024, little endian
    Nach einem Read-Befehl muß das Ergebnis mit einem POMQUERY abgeholt werden.
    0x8PEX_WRCVSchreiben einer Extended Accessory-CV auf dem Hauptgleis (PoM).
    [addr]enthält die Lokadresse;
    data[0][1]Adresse der CV, welche geschrieben wird. Codierung 1..1024, little endian
    data[2]Der zu schreibende Inhalt
    0xEPQUERYAbfrage Programmierergebnis vom Programmiergleis
    Die Zentrale antwortet mit einer PROG_STAT Nachricht.
    0xFPOMQUERYAbfrage Programmierergebnis von der letzten Hauptgleisprogrammierung
    Die Zentrale antwortet mit einer PROG_STAT Nachricht.
  • Nach Absenden eines Programmiergleisbefehls kann (muß aber nicht) die Zentrale mit einem Status PROG MODE antworten. Ein Status PROG MODE zeigt an, dass jetzt eine Programmierung läuft und der normale Betrieb unterbrochen ist. Bei Programmieren auf dem Hauptgleis erfolgt kein Umschalten in den PROG MODE. Eine Multi-Mode-fähige Zentrale kann die Programmierung parallel zum normalen Betrieb durchführen, hier kann dann der normale Betrieb weiterlaufen.

type: clock

    Der type clock ist als 0xD codiert. Es gibt folgende Opcodes:
    type: clock
    WertopcodeBedeutung
    0x0CLKOFFDie Uhr wird angehalten.
    0x1CLKON Die Uhr (mit bereits bekannten Parametern) wird eingeschaltet. Sie läuft bei der bisherigen Zeit weiter.
    0x2CLKSETDie Datenbyte data0 bis data3 enthalten die Uhrbefehl (analog zu DCC und Xpressnet)
    data[0]0x00 + set minute (0..59)
    data[1]0x80 + set hour (0..23)
    data[2]0x40 + set day of week (0..6))
    data[3]0xC0 + speed-up (clock multiplier 1..31)
    Wenn diese Nachricht von der Zentrale gesendet wird, wird Broadcast verwendet. Alle 4 Bytes sind verpflichtend, wenn ein Feld unverändert bleiben soll (weil z.B. keine Eingabemöglichkeit dafür vorgesehen ist), dann wird der entsprechende Parameter außerhalb des gültigen Bereiches übertragen.
    0x3CLKQRYAbfragen der Uhrzeit. Die Zentrale antwortet mit mit einer CLKSET-Nachricht.
    Hinweise:
      Die CLKSET-Nachricht wird zyklisch jede (Modellbahn-)Minute von der Zentrale übertragen.   Beim Clockbefehl wird die [addr] als 0 übertragen.

type: system

    Der type system ist als 0xE codiert. Es gibt folgende Opcodes:
    type: system
    WertopcodeBedeutung
    0x0IDLEDiese Nachricht hat keinen Inhalt, sie wird von der Zentrale zyklisch (mind. alle 2s) gesendet. IDLE wird nicht gesendet, wenn irgendein anderes Paket (z.B. clock oder state) bereits (innerhalb der Zykluszeit) an diesen Client gesendet wurde.
    (Broadcast-)Pakete enthalten die PAN und MAC der Basisstation. Handregler können anhand dieser Parameter entscheiden, zu welcher Basisstation sie Kontakt aufnehmen.
    Handregler müssen sich bei der Basisstation regelmäßig melden (z.B. auch mit einer IDLE-Nachricht), ansonsten stuft die Basisstation den Handregler auf einen Zustand SILENT zurück und hält alle Loks an, die von diesem Handregler gefahren wurden. Im Zustand SILENT ist der Handregler aber noch an der Zentrale angemeldet und wird auch mit Nachrichten versorgt. Jedoch wird allen Nachrichten des Typs State oder Clock eine weitere Nachricht SILENT mit angehängt.

    Die IDLE-Quittierung ist bei einem ungesicherten Funkkanal erforderlich. Ist die Verbindung zwischen Master und Client bereits durch ein Quittungsverfahren abgesichert (wie es z.B. bei ZigBEE der Fall ist), so sind die erhaltenen Empfangsquittungen des Clients ausreichend, um den Zustand ACTIVE dieses Clients zu halten. Wenn zukünftig Sleep-Modi aktiviert werden, übernimmt das IDLE auch die Funktion des Netzwerk-Beacon.
    0x1SILENTMit diesem Opcode teilt die Basisstation dem Handregler mit, dass er ausgebucht wurde und die von ihm kontrollierten Lokomotiven angehalten wurden. Bevor der Handregler neue Befehle absetzt, muß er sich erneut anmelden. Diese Nachricht wird anstelle von IDLE gesendet und auch an alle Clockmeldungen oder Systemzustandsmeldungen angehängt.
    0x2APPLYMit diesem Opcode kann sich ein Client um Aufnahme an der Basisstation bewerben oder sich abmelden. Erst wenn der APPLY von der Zentrale bestätigt wurde, kann und darf der Client Befehle absetzen. APPLY muß die erste und auch einzige Nachricht innerhalb eines Paketes sein.
    addr
    =0der Funkhandregler meldet sich ab.
    Die Zentrale bucht den Handregler aus und stoppt alle Lokomotiven, die von diesen Handregler gefahren wurden.
    =idDer Funkhandregler meldet sich mit seiner Hardware-Enum (id) an. (MFT = 1)
    data[0]1..31: die (freie wählbare) User-ID des Reglers; (0=void)
    0x3GRANTEDMit diesem Opcode bestätigt die Zentrale die An- oder Abmeldung bzw. die Erneuerung der Anmeldung.
    Erst wenn die Granted-Message eingegangen ist, dann darf der Handregler Befehle absenden.
    Sollte der Zustand des Handregler SILENT gewesen sein und sich im der Basisstation (bzw. im Übertragungskanal) dadurch blockierte Nachrichten befinden, so werden diese vor einem GRANTED gelöscht.
    0x4CONNECTMit dem Opcode connect wird festgelegt, ob sich weitere Handregler an das Funknetz anschließen dürfen oder nicht.
    addr=0es werden keine weiteren Funkhandregler aufgenommen.
     =1das Funknetzwerk ist offen für neue Handregler (Voreinstellung nach dem Start)
     =2alle aktuell bekannten Funkhandregler werden von der Basisstation permanent als zugelassen gespeichert.
    Diese Funktion verhindert, dass sich unerwünscht Handregler in das System einwählen können. Dies könnte z.B. auf Ausstellungen störend sein.
    0x6SYSINFO
    0Anzeige der Vebindungsqualität. (Link Quality Show) Es wird der momentane RSSI-Wert übermittelt.
    1Power Level, Wertebereich 0..100.
    0x7SYSQUERY
    0Abfrage der Verbindungsqualität. (Link Quality) Zugleich mit der Abfrage wird auch der eigene RSSI übermittelt. Als Anwort wird eine SYSINFO gesendet. Diese Nachricht kann auch zum Sicherstellen der Verbindung dienen, sie wird dann zyklisch wiederholt und kann IDLE ersetzen.
    1Power Level Abfrage
    0x8PICTUREEs wird ein Bild einer Lok übertragen; [addr] enthält die Bildkennung (Picture-ID). Ein Bild hat typischerweise nicht innerhalb einer Nachricht Platz, hier werden also Nachrichten kaskadiert. Details folgen, wie das Bild genau kodiert wird:(Bildtyp, colors,x,y,page,store)
    0x9LOCO_DBlok database text transfer:
    addr16Lokadresse, little endian
    speedsteps8echte Fahrstufen der Lok (14, 28, 126)
    Picture-ID16zugeordnetes Bild
    Lokname length8Anzahl Zeichen Lokname (0..10)
    Lokname0..80Lokname (ASCII)
    0xDVERSIONDie aktuell verwendete WRP-Version dieses Teilnehmers.
    0xECS_CV_QRYCV der Zentrale abfragen. [addr] enthält die Adresse der abzufragenden CV. Die Zentrale antwortet mit einer CS_CV_SET Nachricht.
    Hinweis: die Zugriffe auf Configvariablen der Zentrale dürfen nur von einem Handregler aus zur gleichen Zeit abgesetzt werden. Treffen während der Bearbeitung weitere Anfragen (z.B. von anderen Handreglern) ein, so werden diese ignoriert. Diese Zentralenreservierung wird automatisch bei Beantwortung oder zwangsweise nach Ablauf einer Sekunde wieder aufgehoben.
    0xFCS_CV_SETCV der Zentrale setzen. [addr] enthält die Adresse der zu setzenden CV, [data[0]] ist der Inhalt. Die Zentrale antwortet mit einer CS_CV_SET Nachricht.
  • turnout database transfer

type: firmware

    Der type firmware ist als 0xF codiert. Über diesen Typ werden Software-Updates und Tests abgewickelt. Im Regelbetrieb sind Nachrichten dieses Typs nicht vorhanden. Es gibt folgende Opcodes:
    type: firmware
    WertopcodeBedeutung
    0x0PINGDummy-Nachricht, die einfach beantwortet wird. ADDR enthält den lokalen System-Timer, Einheit 10ms. Hier kann einfach das Vorhandensein einer Verbindung getestet werden.
    0x1ANNOUNCEAnkündigung eines Firmware-Updates. Der Handregler geht in Debugmode.
    0x2FIRMWAREDownloadpaket für Firmwareupdate. Details folgen (addr, size, (i/n), store)
    0xDDISPLAYDirekte Displayausgabe. Details folgen (Cursorpositionierung, Graphikbefehle, Zeichenausgaben)
    0xELEDDirekte LED-Ansteuerung. Addr gibt die LED-Position an, Data[0..2] die RGB-Werte. (Position, Helligkeit, Farbe)
    0xFKEYBOARDDer Handregler sendet (im Debugmode) die erkannten Tastendrücke direkt ab. Diese Nachricht dient zum Test.

Beispiele:

    Verbindungsaufbau:
    Ein Handregler sucht nach den Einschalten nach Broadcast-Meldungen, welche mit seiner PAN übereinstimmen. Sofern er eine solche Nachricht empfängt, sendet er an diese emittierende MAC-Adresse eine SYSTEM/APPLY Nachricht. Die Basisstation entscheidet je nach Konfiguration, ob dieser Handregler zugelassen ist. Sofern er von der Basisstation zugelassen wird (SYSTEM/GRANTED), ist er fortan an diese Basisstation angekoppelt und bezieht von dieser Basisstation alle Information über den Anlagenzustand und stellt auch alle Anfragen an diese Basisstation.

    Sollte für eine Zeitspanne von 2 Sekunden kein weitere Nachricht von der Basisstation eingehen, betrachtet der Handregler und die Basisstation die Verbindung als unterbrochen. Die Basisstation versorgt den Handregler aber weiterhin mit Systemzustandsmeldungen verbunden mit der Nachricht, sich erneut zu melden.

Copyright:

    Das Copyright für dieses Protokoll liegt bei mir (Wolfgang Kufer). Jegliche Weiterveröffentlichung oder Verwendung dieses Protokoll oder des Logos (sowohl kommerziell als auch nicht kommerziell) bedarf der vorherigen schriftlichen Zustimmung. Diese Einschränkung dient vor allem der Sicherstellung von Kompatibilität, nicht dem Aussperren von Konkurrenzsystemen.

    Zur vereinfachten Erstellung von Applikationen und Wartung des Protokolls gibt es eine gemeinsame header-Datei (wrp.h) mit Typ-Definitionen (#typedef) für die einzelnen Protokollfelder.

Revisionshistory

  • V0.07 25.07.2010
    Feedback erweitert; Programmiermodes erweitert
  • V0.08 28.07.2010
    Debug-Modi hinzugefügt
  • V0.09 02.08.2010
    Subscribe für Feedback hinzugefügt.

Links: