Slotbaer / Slotbaer Projekte (Digital) / ELWMSD / ELWMSD Polling
 

Die nachfolgende Beschreibung wurde mit größter Sorgfalt erstellt. Trotzdem erfolgt der Nachbau auf eigene Gefahr und wir übernehmen weder Verantwortung noch Haftung für eventuell entstehende Schäden jedweder Art.

Worum geht's ?

ELWMSD kann mit einem Rechner kommunizieren. Damit man nicht für Alles und Jedes neue Software benötigt gibt es ein Kommunikationsprotokoll das auf dem von XLap verwendeten aufbaut.

Bei diesem Protokoll verhält sich der Rundenzähler bzw. ELWMSD so lange still, bis der Rechner eine Übertragung anfordert bzw. beginnt. Um z.B. Herauszufinden ob eine Zieldurchfahrt erfolgte, muss der Rechner ständig den Rundenzähler fragen "War was ?". Dieses Verfahren der ständigen Abfragen nennt man polling.

Diese Seite beschreibt die Befehle die ELWMSD versteht.

XLap kompatibel und Extended

ELWMSD kann so konfiguriert werden, dass die Befehle die XLap verwendet "0, "?, "I und "H so verhalten, wie XLAP es erwartet. Somit kann man ELWMSD als Carrera 30346 Ersatz mit der PC-Unit und XLAP verwenden.

Für Selbermacher, gibt es noch zusätzliche Befehle, die weitere Features, wie eine Spritverwaltung ermöglichen.

Es gibt einen zweiten Modus, den Extended Modus, der die selben zusätzlichen Befehle enthält aber die Standardbefehle ebenfalls mit zusätzlichen Möglichkeiten versieht.

Warum zwei Modi?

Nun ja, der kompatible Modus dient offensichtlich der Kompatibilität. D.h. man hat mit ELWMSD einen 4 Spur Rundenzähler, der mit schon vorhandener Software funktioniert. Wer eine PC-Unit und XLAP besitzt kann sofort loslegen.

Der Extended Modus kann ncihts, was man nicht auch im kompatiblen Modus machen könnte. Allerdings vereinfacht der Extended Modus die Softwareanpassung um die zusätzlichen Möglichkeiten der ELWMSD zu nutzen.

Statt abzufragen ob das Rennen begonnen hat und dann abzufragen ob es einen Frühstart gab und dann Abzufragen wie weit die Startampel ist, startet man nur eine Abfrage und erhält je nach Vorkommnis die entsprechende Antwort.

Befehlsaufbau

Alle Befehle folgen einem von zwei Schemata, je nach dem ob sie Informationen von ELWMSD holen oder ihr welche senden.

Im folgenden sind alle vom Rechner gesendeten Daten rot und alle von ELWMSD gesendeten Daten blau.

Fordert der Rechner Daten von der ELWMSD an, so beginnt er indem er den Befehl sendet dieser besteht aus einem Gänsefüßchen gefolgt von dem Befehlsbuchstaben.

Kennt ELWMSD den Befehl nicht so antwortet es mit einem Hash und die Übertragung endet. Das sähe dann so aus:

"U#

Kennt ELWMSD den Befehl so antwortet es mit der Wiederholung des Befehlsbuchstabens gefolgt von den Daten einer Prüfsumme bestehend aus einem Zeichen und einem Dollarzeichen als Abschluss.

"III9$

Auf den Befehl I folgt als Antwort ein I gefolgt von der Prüfsumme 9 und dem Dollarzeichen.

Die Prüfsumme wird nur über die Datenbytes berechnet. Dazu werden alle Datenbytes addiert. Nur die letzten 4 Bit genommen und dann wird der Hexwert $30 aufaddiert. In unserem Beispiel bestehen die DAten nur aus einem I. Das I hat den Hexwert $49. Behält man nur die letzten 4 Bit, so bleibt $09. Addiert man $30 do erhält man $39 und die Asciidarstellung dazu ist die 9.

Sendet der Rechner Daten an die ELWMSD, so beginnt er ebenfalls mit Gänsefüßchen und Befehlsbuchstabe und ELWMSD antwortet mit eine Hash oder der Wiederholung des Befehlsbuchstabens.

Allerdings schickt der Rechner, falls der Befehlsbuchstabe wiederholt wurde, nun die Daten gefolgt von Prüfsumme und Dollarzeichen. Stellt ELWMSD fest, dass die Daten und Prüfsumme übereinstimmen so antwortet sie mit einem Dollarzeichen, ansonsten mit einem Hash. Eine erfolgreiche Übertragung sieht z.B. so aus:

"PP121217$$

Standard XLap kompatible Befehle

In den nachfolgenden Beschreibungen steht P$ immer für die aufeinanderfolgenden Prüfsummen- und Dollarzeichen.

Ein A steht für ein beliebiges Asciizeichen. Ein Z in den Daten steht für eine Ziffer, ein X für eine Hexziffer. Eine Hexziffer ist in diesem Fall ein Asciizeichen, das aus der Summe eines 4 Bit Hexwertes und 0x30 gebildet wird. Ein : entspicht als $A.

Diese Befehle stehen im XLap kompatiblen Modus zur Verfügung. Syntax und Funktionalität entsprechen den selben Befehlen im Carrera Rundenzähler.

H
"HHZP$ Der Rechner fragt an, ob das Rennen gestartet wurde. Das Z ist für gewöhnlich 1, ausser in einer Periode von etwa 5 Sekunden direkt nach einem Rennstart. Dann ist Z gleich 0.
0
"03AZZZP$ Das ist eine Null. Die 4 Zeichen geben die Versionsnummer der Hard- (erste Stelle) und Software (restlichen 3 Stellen) an. Die Hardwareversion der ELWMSD ist E.
?
"?#
"??ZXXXXXXXXP$
Abfrage der Zieldurchfahrten. Ist seit der letzten Abfrage keine Zieldurchfahrt erfolgt, so antwortet ELWMSD mit einem Hash, so al würde es den Befehl nicht kennen. Ist hingegen eine Zieldurchfahrt erfolgt, so wir die Fahrzeugkennung und die Zeit zu der sie erfolgte übertragen. Die Fahrzeugnummer ist eine Zahl zwischen 1 und 8. Die Zeit ist ein Hexwert in Tausendstel-Sekunden. Je zwei Hexstellen bilden ein Byte. Zuert kommt das niederwertige Nibble, dann das höherwertige Nibble eines Bytes. Die 8 Stellen bilden also einen 4 Bytewert wobei das höchstwertige Byte zuert übertragen wird."??2456789:0P$ bedeutet das Fahrzeug 2 zum Zeitpunkt $5476980A das Ziel durchfahren hat.

 

Extended Befehle

Diese Befehle stehen im Extended Modus zur Verfügung und ersetzen dort die Standardbefehle. Man kann mit Hilfe der Zusätzlichen Befehle dieselbe Funktionalität auch im XLap kompatiblen Modus erreichen, aber sie können das Softwaredesign erleichtern.

H
"HHXXXXXXXXXXP$
"HHSZXXXXXXXXP$
"HHPXXXXXXXXP$
"HHZXXXXXXXXP$

 

Solange das Rennen nicht gestartet wurde und ein Frühstart vorliegt, wird eine 8 Bit Bitmap der Frühstarter in Form eines Hexbytes übertragen, gefolgt von der Zeit des letzten Rennstarts (10 Datenbytes). Das Frühstarter Byte wird wie üblich als zwei Hexstellen, niederwertigste zuerst, übertragen. Auch die Zeit wird im üblichen Format übertragen.
Trifft das nicht zu und wurde das Rennen noch nicht gestartet, aber die Startampel ist aktiv, so bestehen die Daten aus einem S gefolgt von der Startampelphase und der Zeit des letzten Rennstarts (10 Datenbytes inkl. dem S).
Ist das Rennen noch nicht gestartet, aber die Startampel nicht aktiv, so wird ein P gefolgt von der Zeit des letzten Rennstarts (9 Datenbytes inkl. P) übertragen.
Trifft das auch nicht zu so bestehen die Daten aus einer 1, ausser 5 Sekunden nach einem Rennstart, dann bestehen die Daten aus einer 0. Beides wird gefolgt vom Zeitpunkt des letzten Wechsels auf 0 (9 Datenbytes).
?
"??ZXXXXXXXXP$
"??ZXXXXXXXXAP$
"??AXXXXXXXXXXXXP$
Liegt eine Sensordurchfahrt seit der letzten Abfrage vor, so wird die Zeit wie bei einer normalen ? Abfrage übertragen. Sollte allerdings der Sensor so konfiguriert sein, dass er eine Kennung hat, so wird diese noch angehängt.
Liegt keine Sensordurchfahrt vor wird ein Zeichen bestehend aus der Summe einer Fahrzeugkennung und $40 egfolgt vom letzten Fahrzeugkommando und dem Spritverbrauch dieses Fahrzeuges seit der letzten Abfrage dieses Fahrzeuges übertragen.
Der erste Wert ist 16 Bit der zweite 32 Bit lang und bestehen aus 4 bzw. 8 Hexstellen. Je zwei bilden ein Byte (niederwertige Nibble zuerst) und je zwei bzw. vier Byte (höherwertiges zuerst) bilden den Gesamtwert. Der Spritverbrauch enstpricht einem Verbrauch von 0-15 Einheiten pro ms multipliziert mit der Zeit in ms seit der letzten Übertragung.

 

Zusätzliche Befehle

Diese Befehle stehen im XLap kompatiblen und Extended Modus zur Verfügung.

i
"iiAA..AAP$ Es wird eine Zeichenkette übertragen, die das Gerät beschreibt.  
h
"hhXXXXXXXXXXP$
"hhSZXXXXXXXXP$
"hhPXXXXXXXXP$
"H
HZXXXXXXXXP$

 

Solange das Rennen nicht gestartet wurde und ein Frühstart vorliegt, wird eine 8 Bit Bitmap der Frühstarter in Form eines Hexbytes übertragen, gefolgt von der Zeit des letzten Rennstarts (10 Datenbytes). Das Frühstarter Byte wird wie üblich als zwei Hexstellen, niederwertigste zuerst, übertragen. Auch die Zeit wird im üblichen Format übertragen.
Trifft das nicht zu und wurde das Rennen noch nicht gestartet, aber die Startampel ist aktiv, so bestehen die Daten aus einem S gefolgt von der Startampelphase und der Zeit des letzten Rennstarts (10 Datenbytes inkl. dem S).
Ist das Rennen noch nicht gestartet, aber die Startampel nicht aktiv, so wird ein P gefolgt von der Zeit des letzten Rennstarts (9 Datenbytes inkl. P) übertragen.
Trifft das auch nicht zu so bestehen die Daten aus einer 1, ausser 5 Sekunden nach einem Rennstart, dann bestehen die Daten aus einer 0. Beides wird gefolgt vom Zeitpunkt des letzten Wechsels auf 0 (9 Datenbytes).
 
q
"qqZXXXXXXXXP$
"qqXXXXXXXXAP$
"qqAXXXXXXXXXXXXP$
Liegt eine Sensordurchfahrt seit der letzten Abfrage vor, so wird wie bei einer normalen ? Abfrage übertragen. Sollte allerdings der Sensor so konfiguriert sein, dass er eine Kennung hat, so wird diese noch angehängt.
Liegt keine Sensordurchfahrt vor wird ein Zeichen bestehend aus der Summe einer Fahrzeugkennung und $40 egfolgt vom letzten Fahrzeugkommando und dem Spritverbrauch dieses Fahrzeuges seit der letzten Abfrage dieses Fahrzeuges übertragen.
Der erste Wert ist 16 Bit der zweite 32 Bit lang und bestehen aus 4 bzw. 8 Hexstellen. Je zwei bilden ein Byte (niederwertige Nibble zuerst) und je zwei bzw. vier Byte (höherwertiges zuerst) bilden den Gesamtwert. Der Spritverbrauch enstpricht einem Verbrauch von 0-15 Einheiten pro ms multipliziert mit der Zeit in ms seit der letzten Übertragung.
 
t "ttXXXXXXXXP$ Gibt die gegenwärtige Zeit aus. Wie üblich als 4 ByteWert in Tausendstel Sekunden.  
A

"AASP$$

 

Startet den automatischen Ablauf der Startampel. Die Startampel durchläuft die Stufen 0 bis 6. Solange die Startampel nicht Stufe 6 erreicht hat, geben die h-Befehle je nach Modus eine 1 oder die Startampelphase zurück. Sobald Stufe 6 erreicht ist wird der h-Befehl mit einer 0 beantwortet und das Rennen gestartet.

Diese interne Startampel durchläuft diese Stufen immer, auch wenn keine oder nur einige Ausgänge als Startampelausgänge konfiguriert sind.

 
w "wwXXP$$

Dieser Befehl ist ab Firmware Version 040 verfügbar.
Die zwei Hexstellen bilden ein Byte, dess Wert in das General Output Register geschrieben wird. Die Bits dieses Registers können mit Ausgängen verbunden werden. dazu müssen sie im Bb Modus als General Outputs konfiguriert werden. Beachten sie, dass die Zuweisung von General Output Register Bits und Ausgang willkürlich erfolgen kann. Man kann also Bit 3 des GO-Registers mit Ausgang 5 verbinden, Bit 2 mit Ausgang 1 und alle anderen Bits gar nicht mit Ausgängen verbinden.

 
b
o
s
u

"bbX..XP$
"ooX..XP$
"ssX..XP$
"uuX..XP$

Diese Befehle lesen die Konfigurationsdaten für die Bahn, die Ausgänge, die Sensoren und USB. Je zwei Hexstellen bilden ein Byte (niederwertige Nibble zuerst). Die Anzahl der Bytes ist bei den Befehlen unterschiedlcih und kann sich von Firmware Version zu Firmware Version ändern.

Auch die Bedeutung der einzelnen Bytes kann sich Ändern, deshalb rate ich vom manuellen Ändern der Daten ab.

 
B
O
S
U
"BBX......XP$$
"OOX......XP$$

"SSX......XP$$
"UUX......XP$$

Diese Befehle schreiben die Konfigurationsdaten für die Bahn, die Ausgänge, die Sensoren und USB. Je zwei Hexstellen bilden ein Byte (niederwertige Nibble zuerst). Die Anzahl der Bytes ist bei den Befehlen unterschiedlcih und kann sich von Firmware Version zu Firmware Version ändern. Es empfiehlt sich vor dem Schreiben der Daten zu überprüfen ob die Versionsnummer von Hard- und Software der der gespeicherten Konfiguration entspricht.

Auch die Bedeutung der einzelnen Bytes kann sich Ändern, deshalb rate ich vom manuellen Ändern der Daten ab.

 
* "*XModem Übertragung Die Syntax dieses Befehls ist anders als bei den anderen Befehlen. Erkennt ELWMSD den Befehl sendet es nicht das Befehlsbyte zurück, sondern ein ACK. Dieses Ack ist der Beginn eines XModem Datentransfers vom Rechner zur ELWMSD.