Why your Gen3 log shows no rides

Both dumps are 128 KiB aligned: 131,200 B for the MBB, 131,328 B for the BMS.

Neither board writes a fixed-size record, so the slot count is always file size ÷ mean record size. MBB entries average 55 B across the whole buffer (75-B binary state frames mixed with short ASCII events); the simulator above rounds that to ~57 B and ~2,300 slots, which sits inside the measured spread. Framing by declared length, the 8 full-size app dumps ran 2,238–2,535 records per file (median 2,383; 19,089 pooled). Counting raw 0xB2 delimiters with a plausible timestamp instead — a different, narrower population — gives 18,838, which is the figure this page published until 2026-07-30.

The BMS is not fixed 52 B. Across 15,998 data records in 7 native-Gen3 BMS files, framed at the 0xB2 gaps the way our BMS decoder frames them — 16,005 frames in all, one per file being the 0xFB header — the mix is 82.4% variable-length 0xFD text events (mean 55 B, range 28–192 B), 11.3% 52-byte 0x4B telemetry, 4.3% 78-byte 0x4D extended telemetry and 0.5% 70-byte 0x4C cell-detail records. Mean record: 57.5 B → ~2,300 slots (measured 2,050–2,339 per file). Chaining by the declared length instead of splitting at the gaps gives 15,890 records over the same seven files, 2,038–2,327 per file, and a mix of 82.9 / 11.4 / 4.4 / 0.5% — same bytes, different framing convention, so the two sets of numbers are not interchangeable. A 50-byte "FST Mono" telemetry variant on the SR/S 40-08201 board is handled by the parser but appears in none of these seven files.

Records start with a 0xB2 byte, then a declared length in byte 1, a type in byte 2 and a uint32 LE Unix timestamp in bytes 3–6. Entries are not in chronological order on disk, because the buffer wraps.

Splitting naively at every 0xB2 works on a native Gen3 BMS file — which is exactly what our BMS decoder does — and it is safe there: across the 15,998 gap-framed records the gap to the next delimiter matched the declared length in 95.7% of cases and was never shorter, so no record was ever cut in half.

It is not safe in general, though the reason is not the one this page gave until 2026-07-29. It said 0xB2 recurs inside payloads on the 538XX-firmware MBB variant. It does not: the writer escapes it, so 96,632 of 96,727 0xB2 bytes across the 14 538XX dumps our decoder adopts (99.90%) are genuine record starts, chaining by the declared length and resyncing at a tear. Of the 95 that are not, 61 fall interior to a chained record and 34 are never framed at all — and if you restrict "interior" to records whose declared length lands exactly on the next record start, only two are genuinely inside a payload; the other 59 sit at ring-wrap tears. The candidates the decoder rejects are something else again: unwritten ring-buffer slots — a slot the firmware has never reached still begins with 0xB2 and carries a zero timestamp, and there are 18,002 of those across the same 14 files (plus 3,104 whose timestamp is out of window). That decoder therefore accepts a candidate only when the uint32 at +3 of the unescaped record is a plausible timestamp (2019-01-01 to now + 365 days), and trusts the declared length in byte 1 rather than the gap. It does not chain from one record to the next, though — unlike the native Gen3 MBB decoder it advances one byte at a time and lets the timestamp gate and the per-type guards absorb the overlapping candidates that produces. Frame first, unescape second: unescaping the buffer before framing puts real 0xB2 bytes back into the middle of records, which is the failure that produced the wrong diagnosis in the first place.

Tooling (including this app) sorts by extracted Unix timestamp after parsing, then re-numbers entries.

State sequence: STRT → PWSU → HIB, once an hour while parked. The sleep interval is not inferred — the firmware writes it: Hibernating for 3600 sec.

Each cycle produces a burst of entries — wake reason, switch states, immobiliser, RTC check, two state changes, power limits, control-flag changes, 12 V DC-DC — so a parked MBB accumulates a median of 31 entries and 1,680 bytes an hour even when nothing is happening. That is where a "no rides" log goes.

The reporting mode lives at payload byte 37 of a 52-byte 0x4B telemetry record. The payload starts at record byte 8, so that is byte 45 of the record — not byte 37 of the entry.

The enum has seven values, not three. Counted over the 1,598 52-byte 0x4B rows the current decoder emits across the 7 Gen3 BMS files — the only class for which "payload byte 37" and "record byte 45" are the same byte: 1 = standard SOC reporting (32.7%), 3 = sleep (30.7%), 7 = active high-rate, during charge or discharge (27.3%), 4 (1.9%), 5 (1.8%) and 6 (1.8%). The remaining 3.8% read 0x00, 0xF0 or 0xFF — flash sentinels from partially overwritten records, not modes. The seventh value is 2, and it is written only by the 78-byte 0x4D record (520 of 619), whose payload sits 8 bytes later — so the mode byte is record byte 53 there, not 45. Those rows were invisible until the 2026-07 type dispatch started decoding them.

Population note: this page previously gave these shares over 1,557 rows. That was the population the decoder emitted before the July 2026 escape and type-dispatch fixes; it now emits 2,319, of which the 1,598 above are the 0x4B class. The distribution barely moved — but the label was wrong.

We publish no meaning for 4, 5 and 6. All three are rare, and all we can say from the data is what they are not: only 3 of the 88 rows carrying them have the byte-9 sleeping flag set (3.4%, against 88.4% on mode 3), so they are near-always waking states. Anything more specific would be a guess — and note that "never on a sleeping frame", which this page and the parser both used to assert, is not true on the current population.

Mode 7 is also not a charging flag, which matters for anyone trying to detect charging from it: it reads on 89% of charging samples but on 84% of riding samples too, so what it really separates is awake from asleep. A charging BMS writes a measured 48-72 entries/hour, median ~50 — this page previously said ~1,200, which was the buffer size divided by an assumed fill time rather than anything counted. All of those hours are AC onboard; we hold no DC fast-charge log, so the DC rate is an open question rather than an estimate.