The Packet — Live
SERIAL PACKET MONITOR
82 start · 10 end · length · sensor code,value · output type×10+state
RIGEL and the microcontroller exchange these frames 4 times a
second. The PC sends only its output states; the microcontroller
replies with every sensor reading and every output state. In
demonstration mode the monitor shows the frames this exchange would
use, so the protocol can be taught before any hardware is connected.
Frame Structure
| Byte | Content |
|---|
| 0 | START — 'R' = 82 |
| 1 | LENGTH — payload byte count |
| 2…N+1 | PAYLOAD — sensor pairs, then outputs |
| N+2 | END — newline = 10 |
In the payload, any byte over 90 is a sensor type code
(lowercase ASCII — see the table opposite) and the byte after it is
that sensor's value. Any byte under 90 is an output device,
encoded type × 10 + state: 41 is a fan (type 4) ON
(state 1); 80 is a valve (type 8) CLOSED (state 0).
⚠ The 90 boundary. Valve-open (type 8, state 1) encodes as 81 —
safely under 90. A type 9 would encode as 90+ and be misread as a
sensor, corrupting the parse. Eight output types is the ceiling.
Firmware Contract
1. Reply to the length-0 startup packet [82, 0, 10]
with a full sensor + output frame — rejecting it deadlocks the link,
because RIGEL can never learn your output set.
2. Report each motor's idle state inside its own range
(a single motor idles at 20, a robot drive at 25) so the control
profile locks correctly from the first packet.
3. Hold every output at its last commanded state until the PC
sends a change — all states latch.
Link Settings
| Microcontroller | Baud rate |
|---|
| Picaxe 08M2 / 14M2 | 19200 |
| ESP8266 / ESP32 | 38400 |
A Chromium browser (Chrome or Edge) is required — the Web Serial API
is not available elsewhere. Requests are sent at 4 Hz with a 750 ms
watchdog, so one lost reply never stalls the link. On a first run the
browser lists no COM ports until you click Connect and grant
access in the picker — that is the permission model, not a fault.
Sensor Codes (payload bytes > 90)
| Code | ASCII | Sensor | Value |
|---|
| 97 | a | Air pressure | value + 900 = hPa |
| 98 | b | Blue light | 0–100 |
| 99 | c | Contact | 0 or 1 |
| 100 | d | Distance | 0–254 cm |
| 101 | e | Heading | 1–16 → N…NNW |
| 103 | g | Green light | 0–100 |
| 104 | h | Humidity | 0–100 % |
| 105 | i | IR light | 0–100 |
| 108 | l | Ambient light | 0–100 |
| 109 | m | Magnetic field | 0–100 |
| 110 | n | Alpha particles | 0–100 |
| 111 | o | Respiration | 0–100 |
| 112 | p | Heart rate | 0–100 |
| 114 | r | Red light | 0–100 |
| 115 | s | Sound | 0–100 |
| 116 | t | Temperature | 0–100 °C; >100 = negative (105 = −5 °C) |
| 117 | u | UV light | 0–100 |
| 120 | x | Timer start | — |
| 121 | y | Yellow light | 0–100 |
| 122 | z | Timer stop | — |
Codes without a table entry still work — they
render with a generic Sensor [code] label.
Output Devices (payload bytes < 90)
| Type | Device | States (encoded) |
|---|
| 1 | Switch | 0 off · 1 on (10, 11) |
| 2 | Motor | see profiles below (20–29) |
| 3 | LED / RGB | 0 off · 4 red · 5 green · 6 blue · 7 yellow · 8 white (30–38) |
| 4 | Fan | 0 off · 1 on (40, 41) |
| 5 | Heater | 0 off · 1 on (50, 51) |
| 6 | Vent | 0 closed · 1 open (60, 61) |
| 7 | Pump | 0 off · 1 on (70, 71) |
| 8 | Valve | 0 closed · 1 open (80, 81) |
Motor Control Profiles
The state range declares, from the first packet alone, whether a
motor is a plain single motor or a two-motor robot drive — RIGEL then
shows the matching control surface with no configuration.
| Encoded | Profile | Action |
|---|
| 20 | Single motor | Stop |
| 22 | Single motor | Forward |
| 23 | Single motor | Reverse |
| 25 | Robot drive | Stop |
| 26 | Robot drive | Forward |
| 27 | Robot drive | Reverse |
| 28 | Robot drive | Turn left |
| 29 | Robot drive | Turn right |
21 and 24 are reserved (24 is the buffer
between the two ranges). The profile locks for the session once
detected.