Hexadezimalsystem

Das Hexadezimalsystem (kurz Hex, von griechisch hexa „sechs“ und lateinisch decem „zehn“) ist ein Zahlensystem mit der Basis 16. Es verwendet die Ziffern 0 bis 9 und die Buchstaben A bis F für die Werte zehn bis fünfzehn. Programmierer benutzen es, weil eine Hex-Ziffer genau vier Bit darstellt und ein Byte deshalb immer mit genau zwei Hex-Ziffern geschrieben werden kann. In OmegaSim begegnet es überall dort, wo die App mit dem Carrera HYBRID spricht: Die Streckenteile melden sich mit Codes wie 0x01 oder 0x0A, jeder Fahrbefehl beginnt mit dem Byte 0xAF, und die Neutralstellung des Gases ist 0xDF. Dieser Artikel erklärt das System von Grund auf und zeigt an Beispielen aus dem Quellcode, wie OmegaSim damit rechnet.

Im Alltag schreiben wir Zahlen im Dezimalsystem: Jede Stelle ist zehnmal so viel wert wie die Stelle rechts von ihr. Die Zahl 223 bedeutet

223 = 2 × 100 + 2 × 10 + 3 × 1
    = 2 × 10² + 2 × 10¹ + 3 × 10⁰

Die Zahl 10 heißt hier Basis. Man kann jede andere ganze Zahl ab 2 als Basis nehmen. Dann braucht man genau so viele verschiedene Ziffern, wie die Basis groß ist: im Dezimalsystem zehn (0–9), im Binärsystem (Basis 2) zwei (0 und 1), im Hexadezimalsystem (Basis 16) sechzehn. Weil es nur zehn arabische Ziffern gibt, nimmt man für die Werte zehn bis fünfzehn die Buchstaben A bis F.

Allgemein gilt für eine Ziffernfolge zn … z1 z0 zur Basis b:

Wert = z_n × b^n + … + z_1 × b^1 + z_0 × b^0

• zi – die Ziffer an Stelle i (von rechts, beginnend bei 0)
• b – die Basis (10, 2 oder 16)
• b^i – der Stellenwert, also „Basis hoch Stellennummer“

• Ein Bit ist die kleinste Informationseinheit: 0 oder 1, aus oder an. Es ist eine Ziffer des Binärsystems.
• Ein Nibble (auch Halbbyte) sind 4 Bit. Mit 4 Bit lassen sich 2⁴ = 16 verschiedene Werte darstellen, also genau die Werte einer Hex-Ziffer.
• Ein Byte sind 8 Bit, also zwei Nibble. Es kann 2⁸ = 256 Werte annehmen, dezimal 0 bis 255, hexadezimal 00 bis FF.

Die Bits eines Bytes werden von rechts nach links von 0 bis 7 nummeriert. Bit 0 ist das niederwertigste (Wert 1), Bit 7 das höchstwertige (Wert 128). Wenn in OmegaSim von „Byte 14, Bit 5“ die Rede ist, ist das Bit mit dem Wert 2⁵ = 32 = 0x20 im fünfzehnten Byte gemeint (gezählt wird ab Byte 0).

Diese Tabelle ist der Schlüssel zu allem Weiteren. Wer sie kann, kann jedes Byte im Kopf umrechnen.

Weil „10“ im Dezimalsystem zehn, im Hexadezimalsystem aber sechzehn bedeutet, muss man kennzeichnen, welches System gemeint ist:

• 0x0A – das Präfix 0x stammt aus der Programmiersprache C und gilt auch in JavaScript, Java und Python. OmegaSim benutzt im Code ausschließlich diese Form (meist mit Kleinbuchstaben, etwa 0xdf; Groß- und Kleinschreibung bedeuten dasselbe).
• 0Ah – das nachgestellte h ist in Assembler und in manchen Datenblättern üblich. Beginnt die Zahl mit einem Buchstaben, setzt man eine 0 davor (0DFh), damit sie nicht mit einem Namen verwechselt wird.
• #000000 – in HTML und CSS werden Farben als drei Bytes (Rot, Grün, Blau) in Hex geschrieben. Die Datei manifest.webmanifest von OmegaSim legt so die Hintergrundfarbe Schwarz fest.
• 0b00001010 – das Präfix 0b kennzeichnet Binärzahlen.
• Ohne Präfix in Fließtext steht häufig „0A hex“ oder ein tiefgestelltes 0A16.

Damit gilt: 0x0A = 10 dezimal = 00001010 binär.

Der Computer rechnet binär. Binärzahlen sind aber lang und für Menschen fehleranfällig: 11011111 ist schwer zu lesen, und eine vertauschte Stelle fällt kaum auf. Dezimal (223) ist kurz, verbirgt aber die einzelnen Bits: Ob in 223 das Bit 5 gesetzt ist, sieht man der Zahl nicht an. Hex verbindet beide Vorteile:

• Kurz: Ein Byte sind immer genau zwei Zeichen. Ein 20-Byte-Befehl an das Auto passt in 40 Zeichen.
• Bitgenau: Jede Hex-Ziffer steht für genau ein Nibble. 0xDF zerfällt ohne Rechnen in D = 1101 und F = 1111, also 1101 1111.
• Ausrichtung: Bitmasken wie 0x80 (nur Bit 7), 0x20 (nur Bit 5) oder 0x0F (die unteren vier Bit) sind auf einen Blick erkennbar.

Deshalb schreiben Protokollmitschnitte, Datenblätter, Speicheradressen, Farbwerte, Prüfsummen und Gerätekennungen fast immer Hex. Auch die Bluetooth-Kennungen (UUIDs) sind 128-Bit-Zahlen in Hex, und die Prüfsummen in app-update.json (SHA-256, 256 Bit) bestehen aus je 64 Hex-Ziffern, weil 256 / 4 = 64.

OmegaSim enthält einen kleinen Übungsbereich für Zahlensysteme (Status WIP):

1. Optionen → System → Entwicklertools zeigen einschalten (oder ?dev an die Adresse hängen).
2. Im Hauptmenü die Kachel Entwickler öffnen und dort Zahlensysteme wählen.
3. Der Binär-Trainer zeigt eine vierstellige Binärzahl (0000 bis 1111, dezimal 0 bis 15), der Hex-Trainer eine vierstellige Hexzahl (0000 bis FFFF, dezimal 0 bis 65 535).
4. Die Dezimalzahl in das Feld eintragen und Prüfen drücken (oder Eingabetaste).
5. Die App meldet „Richtig!“ oder nennt den richtigen Wert und zählt mit („… von … richtig“).
6. Mit Neue Zahl geht es weiter; eine zweite Antwort auf dieselbe Zahl wird nicht gezählt.

Die Zufallszahl entsteht als Math.floor(Math.random() × basis4) und wird mit toString(basis) in Großbuchstaben und auf vier Stellen mit führenden Nullen angezeigt.^[1]

Wer Bytes am echten Auto sehen will, findet sie unter Entwickler → Code-Sonde (was der Sensor gerade liest) und im Protokoll der BLE-Werkbank, das jeden geschriebenen Befehl als Hex-Folge ausgibt.

Verfahren: fortgesetzt durch 16 teilen und die Reste von unten nach oben lesen.

223 : 16 = 13  Rest 15   → F   (niedrigste Stelle)
 13 : 16 =  0  Rest 13   → D
Ergebnis von unten nach oben gelesen: DF   → 223 = 0xDF

Zweites Beispiel, der Befehlskopf:

175 : 16 = 10  Rest 15   → F
 10 : 16 =  0  Rest 10   → A
Ergebnis: 0xAF

Jede Ziffer mit ihrem Stellenwert (16⁰ = 1, 16¹ = 16, 16² = 256, 16³ = 4096) malnehmen und addieren:

0xDF   = 13 × 16 + 15 × 1   = 208 + 15 = 223
0xAF   = 10 × 16 + 15       = 160 + 15 = 175
0x0A   =  0 × 16 + 10       = 10
0x5E   =  5 × 16 + 14       = 80 + 14  = 94
0x3F2A =  3 × 4096 + 15 × 256 + 2 × 16 + 10
       = 12288 + 3840 + 32 + 10 = 16170

Die letzte Zeile ist die Beispielzahl, die auf der Kachel des Hex-Trainers abgebildet ist.

Hier muss man nicht rechnen, nur gruppieren: Die Binärzahl von rechts in Vierergruppen teilen und jede Gruppe mit der Tabelle oben ersetzen.

1101 1111   →   D F    →  0xDF
1010 1111   →   A F    →  0xAF
0010 0000   →   2 0    →  0x20  (nur Bit 5)
1000 0010   →   8 2    →  0x82  (Bit 7 und Bit 1)

Umgekehrt wird jede Hex-Ziffer durch ihre vier Bits ersetzt.

Die Stellenwerte eines Bytes sind 128, 64, 32, 16, 8, 4, 2, 1. Man addiert die Werte der gesetzten Bits:

Bit:      7   6   5   4   3   2   1   0
Wert:   128  64  32  16   8   4   2   1
0xDF:     1   1   0   1   1   1   1   1   → 128+64+16+8+4+2+1 = 223
0x0A:     0   0   0   0   1   0   1   0   → 8+2 = 10

Ein Byte kann mehrere unabhängige Schalter enthalten. Byte 14 des Fahrbefehls ist so ein Feld: Bit 0 schaltet das Bremslicht, Bit 1 den Scheinwerfer, Bit 5 die Leseart „Auf der Bahn“, Bit 7 die Leseart „Ausdruck“ (siehe Strecke). Im Code stehen dafür Konstanten:^[2]

Mit drei bitweisen Operatoren lässt sich jedes Bit einzeln bearbeiten:

Rechnung zum Löschen Bit für Bit:

~0x02          = 1111 1101   (0xFD, nach & 0xff)
 0x22          = 0010 0010
 0x22 & 0xFD   = 0010 0000   = 0x20

Genau so maskiert OmegaSim defekte Lampen: Bei einem Schaden an der Front wird im Paket lb &= ~LIGHT_HEAD & 0xff gerechnet, abgesehen von kurzen Zuckungen eines simulierten Wackelkontakts.^[3] Das Prüfen ist im Meldekanal üblich: (bytes[15] & 0x08) !== 0 fragt Bit 3 von Byte 15 ab, mit dem das Auto die Start/Ziel-Linie meldet.^[4]

Ein Byte kann nur 0 bis 255 aufnehmen. Rechnet man darüber hinaus, läuft es über: Nach 255 (0xFF) kommt wieder 0 (0x00), wie bei einem Kilometerzähler mit drei Stellen nach 999. Mathematisch ist das Rechnen modulo 256.

JavaScript kennt keine Bytes, sondern rechnet mit Kommazahlen; bei bitweisen Operatoren wandelt es in 32-Bit-Ganzzahlen. Der Ausdruck x & 0xFF behält nur die untersten 8 Bit und wirkt deshalb wie „modulo 256“, und zwar auch für negative Zahlen. In OmegaSim steht er an vielen Stellen.

Byte 6 des Fahrbefehls trägt das Gas nicht als 0 bis 255, sondern als Abstand von der Neutralstellung 0xDF (223):^[5]

const throttleDelta = Math.max(MIN_THROTTLE_DELTA,
                               Math.min(127, Math.round(throttleFloat * 127)));
const throttleByte = (0xdf + throttleDelta) & 0xff;

• throttleFloat – Gaswunsch von −1 (voll rückwärts) bis +1 (Vollgas)
• throttleDelta – derselbe Wunsch in Stufen, begrenzt auf −64 bis +127 (MIN_THROTTLE_DELTA = -64)
• throttleByte – das gesendete Byte

Bei Vollgas ist 0xDF + 127 = 223 + 127 = 350. Das passt nicht in ein Byte; 350 & 0xFF = 350 − 256 = 94 = 0x5E. Das Gas-Byte „läuft“ also beim Gasgeben über 0xFF hinaus und beginnt wieder bei 0x00. Eine Protokollbeschreibung von seVen nennt dazu die Bereiche 0xE0–0xFF und weiter 0x00–0x6F für vorwärts sowie 0x80–0xDE für rückwärts. Das erklärt eine alte Beobachtung: Der volle Rückwärtswert 0xDF − 127 = 0x60 liegt im Vorwärtsbereich, und genau dieser Wert ließ das Auto im Versuch vorwärts fahren. OmegaSim begrenzt Rückwärts deshalb auf −64 (0x9F); ob −95 (0x80) sicher ist, ist am Auto noch nicht gesichert.^[6]

In jeder Meldung des Autos steht in Byte 11 ein Kachelzähler, der bei jedem neu befahrenen Streckenteil um eins steigt. Als Byte läuft er nach 255 auf 0 über. Wer wissen will, wie viele Teile zwischen zwei Meldungen lagen, rechnet deshalb nicht einfach neu − alt, sondern

schritte = (neu − alt) & 0xFF

• alt – Zählerstand der früheren Meldung (0 bis 255)
• neu – Zählerstand der späteren Meldung (0 bis 255)
• schritte – Zahl der Teile dazwischen (0 bis 255)

So steht es etwa in der Ortung der NPCs (dort zusätzlich auf 1 bis 3 begrenzt) und in der Zählung des Anlaufs vor der ersten Runde.^[7] Das Beispiel steht unten unter Beispiele.

Ein Byte kann auch negative Zahlen tragen. Die übliche Regel heißt Zweierkomplement: Die Werte 0x00–0x7F bedeuten 0 bis 127, die Werte 0x80–0xFF bedeuten −128 bis −1. Umrechnung:

vorzeichenbehaftet = b ≥ 128 ? b − 256 : b

So steht es wörtlich in OmegaSim (function s8signed(b) { return b >= 128 ? b - 256 : b; }).^[8] Umgekehrt wird aus einer negativen Zahl mit & 0xFF das passende Byte: −40 & 0xFF = 216 = 0xD8, und 216 − 256 = −40 führt zurück.

Die Lenkung in Byte 7 ist so ein vorzeichenbehaftetes Byte: steerByte = steerDelta & 0xff mit steerDelta von −127 bis +127. Positiv lenkt nach rechts, negativ nach links. Hier zeigt sich, warum die App den Ausschlag streng auf ±127 begrenzt: Ein Wunsch von 1,2 ergäbe 152, als Byte 0x98, und das liest das Auto als 152 − 256 = −104, also als kräftigen Einschlag in die andere Richtung.^[9]

Auch Meldewerte des Autos werden so gelesen: Die Bytes 1 und 3 der Meldung (Bewegungssignale, die OmegaSim unter anderem für die Crash-Erkennung nutzt) werden mit s8signed() in −128 bis 127 umgerechnet.

Eine Prüfsumme ist eine kleine Zahl, die aus allen Bytes einer Nachricht berechnet und mitgeschickt wird. Der Empfänger rechnet dieselbe Zahl nach. Stimmen beide nicht überein, wurde die Nachricht unterwegs verfälscht (oder falsch gebaut) und wird verworfen.

Die einfachste Form ist die Summe aller Bytes modulo 256 oder ein XOR über alle Bytes. Solche Verfahren übersehen aber manche Fehler, zum Beispiel zwei vertauschte Bytes. Besser ist eine CRC (zyklische Redundanzprüfung): Die Nachricht wird als lange Binärzahl aufgefasst und durch ein festes Polynom geteilt; der Rest der Division ist die Prüfsumme. Die Division läuft ohne Überträge, Subtraktion ist dabei XOR.

Der Fahrbefehl an das Carrera HYBRID endet mit einer CRC-8 über die Bytes 0 bis 18, mit Polynom 0x31 und Startwert 0xFF:^[10]

function crc8(bytes) {
  let crc = 0xff;
  for (const b of bytes) {
    crc ^= b;
    for (let i = 0; i < 8; i++) {
      crc = (crc & 0x80) ? ((crc << 1) ^ 0x31) & 0xff : (crc << 1) & 0xff;
    }
  }
  return crc;
}

• crc – das laufende Register, ein Byte
• crc ^= b – das nächste Nachrichtenbyte wird mit XOR eingemischt
• crc & 0x80 – ist das oberste Bit gesetzt?
• crc << 1 – alle Bits eine Stelle nach links schieben (mal 2), & 0xff wirft das herausgeschobene Bit weg
• ^ 0x31 – wenn oben eine 1 herausfiel, das Polynom abziehen (XOR). 0x31 = 0011 0001 steht für x⁸ + x⁵ + x⁴ + 1; das x⁸ ist das herausgeschobene Bit und wird nicht mitgeschrieben.

Dass diese Deutung stimmt, ist belegt: Für drei aufgezeichnete Leerlaufpakete der Original-App mit Byte 14 = 0x80, 0x82 und 0x83 liefert crc8() genau die mitgeschnittenen Prüfsummen 0xA4, 0x33 und 0xE0.^[11] Der Selbsttest „Protokoll: CRC-8“ prüft bei jedem Lauf den Fall 0x33.^[12] Die Beschreibung von seVen nennt ein XOR über die Bytes 0 bis 18; das reproduziert die Mitschnitte nicht.

Weil das Auto Pakete mit falscher Prüfsumme vermutlich verwirft, rechnet OmegaSim die CRC immer zuletzt, nachdem alle Sonderbytes (Leitplanken-Modus, Versuchsvarianten der Byte-Werkbank) eingesetzt sind.

In der Android-App reisen die Befehle zwischen Webseite und Java-Code nicht als Bytes, sondern als Hex-Text, zum Beispiel "af0000000000df008000600001002004000000ef" (40 Zeichen für 20 Byte). Die Seite wandelt mit zuHex() jedes Byte in zwei Zeichen, das Plugin OmegaBle wandelt sie mit hexZuBytes() zurück:^[13]

int hi = Character.digit(hex.charAt(i * 2), 16);
int lo = Character.digit(hex.charAt(i * 2 + 1), 16);
out[i] = (byte) ((hi << 4) | lo);

Für "df" ist hi = 13, lo = 15; 13 << 4 schiebt um vier Bit (mal 16) auf 208, | 15 setzt die unteren vier Bit, Ergebnis 223. Für den Rückweg (Meldungen des Autos) nutzt die Seite eine Nachschlagetabelle statt parseInt, weil rund 22 Meldungen je Sekunde und Auto durchlaufen.

Das Leerlaufpaket in der Leseart „Auf der Bahn“, ohne Licht, Gas und Lenkung neutral:

Byte:  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
Hex:  AF 00 00 00 00 00 DF 00 80 00 60 00 01 00 20 04 00 00 00 EF

• AF (175) – Befehlskopf
• DF (223) – Gas neutral
• 00 – Lenkung gerade (Byte 7, Kopie in Byte 9)
• 20 (32, Bit 5) – Leseart „Auf der Bahn“
• EF – CRC-8 über die Bytes 0 bis 18

Schaltet man den Scheinwerfer ein, wird Byte 14 zu 0x20 | 0x02 = 0x22, und die Prüfsumme ändert sich von 0xEF auf 0x78. Ein einziges geändertes Bit ändert die ganze Prüfsumme; genau das soll eine CRC leisten. (Beide Prüfsummen sind mit der Funktion crc8() nachgerechnet.)

Startwert 0xFF, erstes Byte 0xAF:

Danach wird das nächste Byte (0x00) eingemischt, und so weiter bis Byte 18.

Zurück rechnet die Prüfbank so: d = (b6 − 0xDF) & 0xFF, und ist d > 127, dann d − 256. Für 0x9F: (159 − 223) & 0xFF = −64 & 0xFF = 192, und 192 − 256 = −64.^[14]

Das Auto meldet zuletzt den Zählerstand 254 (0xFE), die nächste empfangene Meldung zeigt 2 (0x02), weil unter Funklast einige Meldungen verloren gingen.

neu − alt          = 2 − 254 = −252
−252 & 0xFF        = 4

Probe: 254 → 255 → 0 → 1 → 2 sind vier Schritte. Ohne & 0xFF käme −252 heraus, und eine Rundenzählung würde rückwärts laufen. Die Ortung der NPCs nimmt den Wert anschließend höchstens als 3, weil mehr Sprünge auf einmal eher eine Störung als echte Fahrt sind.

Die Codes, die der Sensor in Byte 12 meldet, sind kleine Zahlen; Hex wird hier nur aus Gewohnheit geschrieben:

In der Leseart „Ausdruck“ bedeutet 0x0A dagegen Start/Ziel auf dem Original-Druckblatt. Deshalb zählt OmegaSim auf der Bahn nur 0x01 als Ziellinie, sonst würde jede Engstelle eine zusätzliche Runde zählen.^[15] Einzelheiten stehen im Artikel Strecke.

Der Bau der Android-App macht aus der Version 1.2.9 die ganzzahlige Versionsnummer 1 × 100000 + 2 × 1000 + 9 = 102009.^[16] Das ist ein Stellenwertsystem mit gemischten Stellenwerten, aber kein Hex: Android verlangt eine wachsende ganze Zahl, und dezimale Blöcke bleiben für Menschen lesbar.

• Der Hex-Trainer ist als WIP gekennzeichnet. Er übt nur die Richtung „fremdes System → dezimal“ und nur vierstellige Zahlen; Binärzahlen gehen damit nur bis 15.
• Wie viele Bits der Gaswert wirklich auflöst und wo genau die Grenze zwischen Vorwärts und Rückwärts liegt, ist nicht am Auto gemessen; die Grenze −64 ist eine sichere, beobachtete Stelle, −95 nur ein Vorschlag aus der seVen-Beschreibung.
• Ob das Auto Pakete mit falscher CRC verwirft oder anders behandelt, ist naheliegend, aber nicht eigens geprüft.
• Ein Kachelzähler-Sprung von mehr als 255 Teilen zwischen zwei Meldungen ist mit & 0xFF nicht erkennbar; bei einer Meldung etwa alle 45 ms kommt das praktisch nicht vor.

• Bluetooth Low Energy
• Strecke
• Carrera HYBRID
• Original-App
• Firmware
• Glossar

• src/20-protocol.js – buildCommandPacket(), Konstanten LIGHT_HEAD, LIGHT_BRAKE, TRACK_BIT_RAIL, TRACK_BIT_PRINT
• src/10-ble-explorer.js – crc8(), MIN_THROTTLE_DELTA
• src/05-app-bruecke.js – zuHex(), ausHex(), uuid()
• src/60-track.js – isStartCode(), TILE_OFFTRACK
• src/70-race.js – s8signed(), handleDashboardBytes(), ZIEL_SPERRE_BIT
• src/90-ghosts.js – Kachelzähler in der NPC-Ortung
• src/92b-num-trainer.js – Binär- und Hex-Trainer
• src/95-selftest.js – Test „Protokoll: CRC-8“
• android-app/…/OmegaBlePlugin.java – hexZuBytes()
• CARRERA_HYBRID.md – Rückwärtsgrenze, Lenkgrenze, Abgleich mit seVen

• Browserfassung, Android-App und Quellcode: Links auf der Hauptseite