How a Zero talks over Bluetooth

A Gen3 bike advertises service 0xFEFB, the 16-bit UUID the Bluetooth SIG assigned to Telit (formerly Stollmann), whose "Terminal I/O" profile carries a serial stream over BLE. The client connects over LE without autoConnect, asks for an MTU of 512, subscribes to the characteristics below through their 0x2902 descriptors, and writes without response. Flow control is by credits: each side grants the other a number of packets it may send.

Every Gen3 owner’s manual from 2020 to 2026 gives the pairing ID as Zero_XXXXX, the last five digits of the VIN, and notes that "only one cell phone can be paired to your motorcycle at a time". No Gen2 manual carries that note.

PrVr answers one word, 00 17 00 00 on this bike. Gbki answers 104 bytes of mostly NUL-terminated ASCII. The offsets below are measured on the one bike captured; read the strings up to their first NUL rather than trusting fixed lengths.

PwPk is the richest live read. Its cell list has no length field: cell voltages, as u16 millivolts, run until the first value under 128, and that value is the state of charge. This 28-cell pack read 3.673 V to 3.764 V at connect, a spread of 91 mV.

After the state of charge come the pack’s capacity and remaining charge in amp-hours, then thirteen temperature slots in °C, where −100 means "no sensor fitted". On this bike slots 0–3 and 8–9 track the pack temperature the main board logs at the same moments, slots 4–7 are absent, and slots 10–12 sit with the electronics: slot 10 follows MbbR’s motor temperature (equal in 541 of 566, and never more than 1 °C apart) and slot 12 its controller temperature (545 of 566, and never more than 1 °C apart), pairing each reply with the MbbR read less than a second before it. The pack current sits 8 bytes before the end; its sign convention is not settled, and the last 6 bytes are not decoded.

BtSt repeats the pack voltage and amp-hours and adds two things PwPk lacks: a word of status bits and the odometer, in whole miles: 20,776 mi (33,436 km) at the first ride and 20,818 mi (33,503 km) at the second. The log the same bike wrote, read by this site’s parser, shows the same two odometer values in kilometres at those two rides.

MbbR is the main board’s live read, and its speed is a whole number of miles per hour. The check: integrate it over each ride and read it as mph, and it gives 4.71 km and 1.90 km, against 4.80 km and 2.00 km on the dash’s trip meter; read as km/h it would give only 2.93 and 1.18 km. The motor turns a steady 68.3 rpm per mph (median, both rides). Over the ride drawn below the reading peaked at 38 mph and 2,601 rpm.

Bytes 20–27 are four percentages that stayed the same in every reply, riding and parked. They are known as the limits of the Eco mode (top speed, torque, coast regen, brake regen) — the values are measured, the naming is not — and not those of whatever mode is selected: the active mode is not in any Gen2 read we know of.

The three DSt reads are short and come back with the numbers on the dash. Trip meters and the range estimate are in hundredths of a kilometre, so the trip advances in steps of 10 — the dash’s 0.1 km. The dash’s code is a plain number: it read 0 riding and 45 parked, and what each value means is not published, so show it as a number, never as an alarm.

DSt3’s first word is a minutes-until-full figure: 185 in a short session with BtSt’s "charger 1 attached" bit set. It is 0 most of the time otherwise, but in 38 of the 564 replies during the two rides it read 75 to 148, for a few seconds at a time, around 20 mph with the brake bit set — perhaps while regenerating; that is not settled. The other three words look like consumption figures, but under the "Wh/km × 100" scale that suggests itself they read 19.4 and 2.31 Wh/km, which no Zero does. Keep them raw until a ride settles them.

Two more reads are known but not yet in our captures. Ecus lists the control units: a u32 count, then one 30-byte record per unit. Errs lists the active fault codes: a u32 count, then one u16 per code, with zero codes as padding. Not every Gen2 bike may answer Errs.

Once connected, the session polls five reads in a fixed order — MbbR, PwPk, DSt1, DSt2, DSt3 — with one request in flight at a time. The median round trip is 85 ms, so each reading comes back about every 0.5 s. PrVr, Gbki and BtSt are asked only in the first second or so after connecting.

The second figure is 8 minutes of one ride, every MbbR and DSt2 reply decoded at the offsets above. Nothing in it is smoothed.

BmsD runs the same loop for the battery management system: CmCh with read address 0, then BmsD repeated. On the 2016 FXS the battery kept answering past 1,024 blocks without ever sending the end flag (seen with the ZeroLogs app in October 2026), so a client needs a stop of its own. ZeroLogs stops at the main board’s block count, 1,024 on this bike; whether that is exactly the size of the battery’s log is not confirmed yet.

A bike with a second battery (a Power Tank) selects the second battery management system through CmCh before BmsD. That step is known but we have not tried it on a bike.

Gen3 addresses every block. LOG_INIT (type 24, empty body) answers with the number of files and, per file, its size in bytes (u32 LE) and its block count (u16 LE); from protocol major version 27 on, each file entry is also preceded by its unit id. LOG_BLOCK (type 25) asks for one block: a file number (u8) and a block number (u16 LE). The answer’s body is 128 bytes of raw flash. The main board’s file comes first, then the battery’s. LOG_DONE (type 26) ends the session; the bike answers LOG_DONE or ACK.

Ask for exactly the block count, 0 to count − 1. A request one past the end still returns 128 bytes, and they are not log data: in the Gen3 files we hold that carry such a block, it is almost always a blank page — the marker 00 F0 FF 00 and zeros. A full Gen3 board log is 131,200 bytes, 1,025 blocks of 128.