Back to Learn Hub
Gen3 Hardware Behaviour

Why your Gen3 log shows no rides

Gen3 motorcycles (SR/F, SR/S, DSR/X, FXE) record diagnostic data into a small fixed-size ring buffer. If you wait too long before exporting, hibernation cycles silently overwrite your rides.

Last updated: May 9, 2026

TL;DR

Each board (MBB and BMS) keeps its own ~128 KB ring buffer holding roughly 2,300–2,500 entries. While the bike is parked, the MBB writes a hibernation entry roughly every hour, so after about 5–7 days the older ride data is overwritten on the bike itself. Export logs within 1–2 days of your last ride to keep useful telemetry.

See it for yourself — interactive simulator

Set how much you ride, charge and park per day, plus how many days have passed since the last log export. The two diagrams show what each board's ring buffer would look like when you finally pull the file.

Quick presets

hours

Active riding (state = RUN). ~360 entries/h on each board.

hours

Plugged in and charging. BMS jumps to ~1,200 entries/h.

days

Parked time/day = 24 − riding − charging.

Parked: 20.50 h/day · MBB hibernation rate: ~16 entries/h · BMS sleep rate: ~4 entries/h.
MBBFULL2,300 slots

6,916 written → 4,616 oldest lost

Only the most recent 2.3 days survive

Parked / hib2,296
Riding3,780
Charging840
BMSFULL2,520 slots

21,154 written → 18,634 oldest lost

Only the most recent 0.8 days survive

Parked / hib574
Riding3,780
Charging16,800

Approximate model. Actual rates vary by firmware version, ride pattern (lots of state changes vs steady cruise), and BMS reporting mode. The intent is to make the trade-off visible, not to predict exact byte counts.

MBB vs BMS — two separate ring buffers

When you export logs from the Zero app you get two files per bike: one from the MBB and one from the BMS. They're independent computers, each with its own ring buffer, recording different things. Why this matters: a long charging session can fill the BMS buffer in hours while the MBB is still mostly empty — or vice-versa for long touring days.

MBBMain Bike Board

Bike state, motor & controller telemetry, speed, odometer, ride detection.

Buffer size
~131 KB
Entry size
~57 B avg → 2,300 slots
Filename
VIN_MBB.bin or VIN_MbbD.bin
Parked rate
~16 entries/h
Riding rate
~360 entries/h
Charging rate
~60 entries/h

Fills fastest when parked for a long time (hibernation cycles dominate) or during long rides.

BMSBattery Management System

Cell voltages, pack current, SOC, BMS state machine, charge/discharge limits.

Buffer size
~131 KB
Entry size
~52 B avg → 2,520 slots
Filename
VIN_BMS.bin / BMS0 / BMS1 / BmsD0
Parked rate
~4 entries/h
Riding rate
~360 entries/h
Charging rate
~1200 entries/h

Fills fastest during active charging — the BMS jumps into high-rate reporting mode (byte 37 = 7). Long DC-fast-charging sessions can wipe the BMS buffer in a few hours.

Always upload both. Our parser cross-references the two: MBB tells us when a ride started and how far you went; BMS tells us how much energy moved and what the cells were doing. With only one file, large parts of the ride/charge view will be empty — even if the other file on the bike was perfectly fine.

What is a ring buffer?

A ring buffer is a fixed-size storage area that wraps around on itself. When it's full, the next write replaces the oldest entry. There's no archive — what gets overwritten is gone forever.

Both Gen3 boards (MBB and BMS, on the Cypher III / FST platform) use this approach because the on-board flash storage is small and writes are constant. Append-only logs would have filled the chip and bricked the board within months.

Gen2 bikes (S, DS, FX, FXS, DSR, SR — pre-2020) used append-only text logs, so old data was kept. The trade-off changed with Cypher III firmware: smaller files, lossy history.

Static example — buffer with mixed entries

MBB100%2,300 slots

Why hibernation eats your MBB data

The MBB doesn't fully shut down when parked. Roughly once an hour it wakes briefly to check the battery, write a hibernation entry, then sleeps again. That cycle continues 24/7 for as long as the bike is connected to its battery. The BMS, by contrast, drops into a sleep mode that writes entries much less often when there's no current flow.

~24 / dayMBB hibernation cycles while parked (each cycle writes multiple entries)
~2,300total slots in the MBB buffer
~5 daysto fill the MBB buffer with nothing but hibernation
7+ daysof being parked = ride data already overwritten on the MBB
DC fast chargea single 1-hour DC session writes ~1,200 BMS entries — half its buffer

Technical deep-dive

For developers and curious owners — here's how the on-bike storage is laid out and where the slot counts come from.

File size on the bike

Both MBB and BMS dumps are ~131 KB (128 KiB aligned).

MBB entries average ~57 B (mix of 75-B binary telemetry frames and short ASCII state events) → ~2,300 slots.

BMS entries are a fixed 52 B each → ~2,520 slots. Larger binary entries pack more telemetry per write but the higher write rate during charging fills it fast.

Memory layout

Entries are delimited by 0xB2 framing bytes. Reader software splits on those delimiters rather than relying on file order — entries are not in chronological order on disk because the buffer wraps.

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

MBB hibernation cycle

State sequence: STRT → PWSU → HIB every ~1 hour while parked.

Each cycle produces several entries (state change, power-up, hibernate event), so a parked MBB accumulates roughly 16 entries/hour even when nothing is happening.

BMS reporting modes

Byte 37 of each BMS entry encodes the reporting mode:
1 = standard SOC reporting (idle), 3 = minimal/sleep, 7 = high-rate during charge or discharge.

In mode 7 the BMS can write ~1,200 entries/hour — that's why fast charging fills the BMS buffer disproportionately fast compared to the MBB.

For the full binary-format breakdown — state field offsets, telemetry encoding, timestamp extraction quirks — read the Gen2 vs Gen3 reference page.

How to recognise an overflowed log

When you upload a Gen3 log we run a quick check on the entries. You'll see one of these warnings on the report:

  • Gen3 log: data limited to the last 5–7 days before export.

    Always shown on Gen3 logs as a reminder. Doesn't mean anything is wrong — it just sets expectations.

  • No ride data found: the ring buffer contains only hibernation cycles.

    The buffer was filled by wake/sleep cycles before you exported. Your rides happened, but they're no longer in this file. Re-exporting now won't help — the data is gone from the bike.

How to capture more data

Export within 1–2 days

After a ride, plug the bike into the Zero app and export logs the same evening or the next day. Anything older than ~5 days of parking risks being overwritten.

Export both MBB and BMS

The two boards have separate ring buffers with different fill rates. Uploading both lets us reconstruct ride and charge sessions even when one is partially overwritten.

Export regularly

Make it a habit — once a week, or after any ride you want to analyse. Each export is a snapshot; we'll merge the history together for you over time.

Don't leave the bike parked for weeks

If you can, ride a short loop before exporting. Long storage periods produce logs that look "empty" because hibernation entries dominate the buffer.

FAQ

My log is "empty" — can you recover the missing rides?

No. Once the ring buffer overwrites an entry, the data is gone from the bike itself. Nothing on the server can bring it back. The only fix is to export sooner next time.

Should I upload only the MBB or only the BMS file?

Always both. They record different things (see the MBB vs BMS section above): MBB has bike state, motor and ride detection; BMS has cell voltages, current and charge tracking. We cross-reference the two to build the unified ride and charge sessions you see in the dashboard.

Why does Gen2 not have this problem?

Gen2 bikes (S, DS, FX, FXS, DSR, SR — pre-2020) used larger text-based logs that grew append-only. They keep months of history but produce ~10× larger files. See Gen2 vs Gen3 log differences for the full comparison.

My data looks corrupt. Should I delete and re-upload?

If the issue is "no rides" on a Gen3 log, deleting and re-uploading the same file won't change anything — the overwriting happened on the bike, not during upload. If you suspect a parsing error instead, use the Re-parse option from the report's Export menu; it re-runs the parser without re-uploading the file.

Which Zero models are Gen3?

SR/F, SR/S, DSR/X and FXE — the Cypher III / FST platform. Older S, DS, DSR, FX, FXS, SR are Gen2. The earliest Zero S / DS / FX models (XMX platform) are Gen1.

Why does fast charging fill the BMS buffer so quickly?

During active charging the BMS switches into high-rate reporting mode (byte 37 = 7) so it can track cell voltages, current and temperature with high resolution. That's ~1,200 entries/hour vs ~4/hour while parked. A single 2-hour DC fast-charge can fill the BMS buffer entirely.

Still confused or want to share feedback?