The Zero Gen3 log format, record by record

Byte 11 is the cheapest integrity check in the format. It steps by one on every record the board writes, whatever the record’s type, so two records that sit next to each other in the file should differ by exactly one. Over the pairs of intact records that are adjacent on disk in the 18 native files, they do on 20,913 of 21,693 main-board pairs (96.4%) and on 13,628 of 14,177 pack pairs (96.1%). The exceptions are not noise. Each kind says something about the file:

Byte 12 is a signed byte holding the bike’s time-correction setting in whole hours: the offset the dash applies to show local time. The timestamp in bytes 3 to 6 is already UTC; the battery console proves it by printing the same epoch beside its own rendering. So the offset is informational: it says what the rider saw on the dash, never how to move a stored time, and a decoder that adds it to the timestamp shifts every event in the file by hours. This site’s decoder stores it once per file, as the most frequent value, with every other value it saw kept beside it.

Five of the 18 files carry a second value. A change inside one file is a change of the setting, not of the clock: a rider moving the dash an hour for daylight saving, or a board that wrote a few records before its stored setting was loaded. The counts look like both: 2,205 records at +1 after 33 at +2, 2,300 at 0 beside 33 at +1, 2,362 at +2 beside 18 at +1, 2,112 at +1 beside 2 at 0 on a pack, and one main board with 69 records at −7 before 2,347 at 0. Through all of it the timestamps stay UTC, so nothing on a timeline moves; only the label a rider would have read changes. Upstream’s own, larger file set shows mostly 0xF9, 0x02, 0xFC, 0xFB and 0x01 in this byte (−7, +2, −4, −5 and +1 as offsets), every one of them a civil time zone.

Exactly one header record opens every native Gen3 main-board file, and its timestamp is the download time rather than a log time. It names the motorcycle, and since release 3.37.0 this site’s decoder reads it out of the bytes (the VIN, the model, the model year, the board and firmware revisions and the firmware build) instead of taking any of them from the file name. On the ten native main-board files in this corpus every one of those fields is present and readable on all ten.

The VIN is accepted only when it passes the 49 CFR 565 check digit, the 538 or PAG prefix and the VIN character set. The slot is writable text, and the check digit is what makes it safe to prefer the header over the file name, which is the thing a rename changes. It starts at offset 0x29 on all ten files here. Upstream zero-log-parser found these offsets first (its header decode of 15 September 2026, credited there to AtomicDog’s 2022 pull request), and reports the VIN one byte later, at 0x2A, on about 2.6% of production files, with every other field moving with it; an escaped byte in the header’s own timestamp is the likeliest cause. The decoder therefore tries the unescaped header first, then raw offsets 0x29 and 0x2A, and reads nothing at all when no VIN validates, because the shift is then unknown.

The model year is this decoder’s addition. The two bytes before the model name are a uint16 holding the year times ten (20210 for a 2021), and on ten of ten files it equals the year encoded in the VIN’s tenth character. Its high byte, 0x4E or 0x4F, is what a scan for printable text used to read as part of the model, which is where "NSRF" and "ODSRX" came from. Here: model SRF on four files, SRS on three and DSRX on three; board revision 2 on three, 4 on five and 5 on two; firmware revisions 19, 29, 42, 43 and 44.

What a rider gets from it: a file that still says which motorcycle it came from after it has been renamed or forwarded, a model year that cross-checks the VIN, and the main board’s hardware and firmware revision on the day of the download, which is the first thing to compare when two files from the same bike decode differently. The values themselves identify a motorcycle or narrow it down, and none is printed on this page.

Text events are the bulk of the file and the only place a native Gen3 MBB ever states a high-voltage pack reading. The payload is null-terminated ASCII starting at record byte 13, after the four-byte microsecond field, the sequence byte and the UTC-offset byte. That last byte was described here as a board marker, 0x02 on the MBB and 0x01 on the BMS; it read 0x02 and 0x01 only because the files it was read from came from motorcycles set to UTC+2 and UTC+1.

A single hibernation wake cycle produces a highly repeatable burst of these. Measured over 416 complete wake cycles in the eight full-size app dumps, the median burst is 31 records, most often 27 text events, 2 telemetry records and 2 secondaries, written over a 91-second window. A cycle here is a pair of consecutive "Hibernating for N sec" markers 3,000 to 4,200 seconds apart, over length-chain-framed records; count only the markers that declare 3,600 seconds and the same eight files give 411. The markers recur on a 3,691-second median interval, which is the declared 3,600-second sleep plus the burst that follows it. That period is not inferred: the last record of each burst is literally the text "Saving Stats, Hibernating for 3600 sec", and 444 of the 462 hibernate directives in those eight files specify 3600 seconds (446 of 464 if the ninth, truncated file is counted). The remaining 18 specify 31,536,000 seconds, which is 365 days: a storage or transport mode.

The internal documentation stated the hibernation rate two different ways, "about 15 to 20 entries per hour" and "about 15 to 20 entries per wake-up cycle, occurring every 1 hour". Per wake-up cycle is the correct framing, and because the cycle is hourly the two rates coincide. The number is the part that was wrong: the measured median is 31 raw records per cycle, not 15 to 20.

This is the binary spine of the MBB log. The decoder reads the state field at a fixed offset per record type (record byte 42 on a 0x51, 46 on a 0x52, 50 on a 0x53) and accepts one of ten null-padded ASCII tokens there: RUN, STOP, HIB, STRT, PWSU, CHRG, WAIT, WAKE, REV, PARK. Every other offset is relative to it. It used to search the whole record for a token instead, and a text record that merely contained one of the words had a character of its message read as a state of charge: almost always a space, 0x20, which is 32. Production carried 512 rides ending at exactly SoC 32 before the anchor went in on the server, and the browser decoder behind /decode kept searching until 2026-10. Two populations are in play here and mixing them is how this page got the next number wrong twice. Once the escape is honoured there are 1,121 complete 75-byte 0x51 records across the nine native MBB files, and 1,078 of those were already 75 bytes on disk. The token lands at record byte 42 on every one of them. On 1,069 of the 1,078 it is one of the eight tokens the decoder originally knew; the remaining 9 carry REV or PARK (five and four, all on the one DSR/X here) and were discarded until those two were added, server-side in 2026-08 and in this browser decoder shortly after. They were never tokenless and never empty: all 9 carry a populated pack voltage at record[34:38], between 102.561 V and 102.630 V, so the two tokens recovered real telemetry rather than noise. The anchor table is what lets the same decoder read the 92-byte 0x52 record, where the state sits four bytes later, and the 106-byte 0x53, eight bytes later.

Two fields are addressed relative to the token. SOC is the single byte nine before it, at record[33] on a 75-byte record. The six post-state uint32s begin nine bytes after the token starts, because the state field is padded to nine bytes.

The mode flag at record[17] deserves a note, because two different revisions of the internal documentation described it two different ways round. It is a mode flag, and it is at byte 17, not byte 11. Measured by state over the 1,121 complete 75-byte 0x51 records: it is 0x00 on 144 of 144 RUN records, 0x6A on 408 of 408 PWSU records, 0x6A on 397 of 417 HIB records with 0x60 on the other 20, and 0x6A on 7 of 7 CHRG. It varies within a single motorcycle by state, so it cannot be the per-bike hardware identifier it was once called. Byte 11, which an earlier revision named as the mode flag instead, is the record’s sequence byte: it takes 105 distinct values across those same 144 RUN records and lands in {0x00, 0x6A, 0x60} on none of them.

The 0x54 record is written beside every 0x51 and it is the motor channel: four signed int32 little-endian words after the header (shaft torque in micro-newton-metres, motor current in whole amps, a free-running counter, and the DC-bus voltage in millivolts), with FF FF FF FF meaning "not measured". This page listed it as purpose unknown until 2026-09-07, because on a parked bike it is almost empty: of the 968 records whose on-disk length is the nominal 29 bytes, across the eight app dumps, 848 (87.6%) have bytes 13 through 24 set to zero (no torque, no current, a stopped counter), and 782 (80.8%) end with the sentinel FF FF FF FF where the bus voltage goes; a further 78 (8.1%) end with four zero bytes.

Two internal checks have to hold, and both do on every record measured. The torque is exactly 0.2 N·m per amp of motor current (27.6 N·m at 138 A, 49.2 at 246, 59.2 at 296), so the first two words are one measurement through the motor constant, and that constant is the evidence the framing is right. And the bus voltage falls as torque rises, 111.9 V at 0.6 N·m to 106.9 V at 59.2 N·m, staying inside 3.82 to 4.00 V per cell on a 28-series pack. A published field map calls that word "discharge power W"; a power channel does not sag under load.

The 0x52 record has the same shape as 0x51 with four extra bytes inserted in the pre-state area, which moves the state token from record byte 42 to byte 46; the 0x53 inserts eight and puts it at byte 50. Both are rare (67 0x52 across the eight app dumps under length-chain framing, 87 with the ninth file included, and 0 to 31 per file, appearing mainly around WAKE events), and both carry a TAIL that a 0x51 ends before. An earlier version of this page said 66 0x52; that is the same quantity counted as raw 0xB2 delimiters whose un-unescaped timestamp passes the window, a different convention.

The tail holds the road speed in millimetres per hour (km/h × 1,000,000), the dash’s estimated remaining range in hundredths of a kilometre, and, on the newer firmware layout only (the one whose 0x51 is 75 bytes), the odometer in tenths of a kilometre. Relative to the state token: on the newer layout the odometer sits at +35, the speed at +39 and the range at +43 as a uint16; on the older layout the speed is at +35, the range at +39 as a uint32, and there is no odometer at all. The older layout’s word at +39 is the trap: it rises smoothly from 5,000 to 11,773 on one file and 11,005 to 18,642 on another, squarely in a Zero’s mileage band, and every sample of that rise is a CHRG record. An odometer does not move while the bike is plugged in; that is the range estimate climbing as the pack fills. The newer layout’s odometer passes the test the impostors fail: it is frozen across a whole charge, rises only under RUN, and is non-decreasing on 48 of 48 and 36 of 36 steps on the two files with enough samples. The decoder still checks the series per file and withdraws it if more than a tenth of its steps go backwards.

Four further main-board record types are decoded. The charger table (0x48), the queue-full report (0x4F) and the firmware build banner (0x32) each have a subsection of their own below; the two short ones are here.

Type 0x49 carries the charge ceiling in millivolts, the charge target as a percentage and a storage voltage: 117.60 V, 90% and 106.00 V on one bike, the 90 being the rider’s own limit.

Types 0x4B, 0x4C and 0x4D also occur on the main-board side of some production files, as 53-, 84- and 96-byte state snapshots with a state token at record byte 42, 46 or 50, the same three positions as 0x51, 0x52 and 0x53. None occurs in this corpus, so the decoder reads the token and nothing else, and does not use it for ride detection until something has measured what it would do there. The battery board writes the same three type codes at different lengths with an unrelated layout; the length is what tells them apart.

While the motorcycle charges, the main board writes a 0x48 about every 640 seconds: the 13-byte header followed by one 49-byte block for each charger that answered on the CAN bus (62 bytes with one block, 111 with two). This corpus holds 119 of them, in three of the ten native main-board files, from three motorcycles, and every one is 62 bytes long. Where a bike has two chargers they do not share a record here: each answers in a one-block record of its own, with CAN id 16 and 17, and on 48 occasions the two land in the same second. That is how a comparison that paired records by timestamp once matched the wrong two and reported a disagreement about the CAN id where there was none.

The mains fields prove the layout, and they prove it because this corpus spans two grids. One motorcycle reads 113 to 115 V at 60 Hz on the same bytes where the other two read 218 to 236 V at 49 or 50 Hz, and nothing but a real mains reading separates those populations on the same offsets. Frequency is therefore read as a class per bike rather than a number: one bike here charges from a 60 Hz grid and two from 50 Hz.

The name is the charger’s own ASCII: "3kW" on 97 records and "Flt 6" on 22 here; upstream zero-log-parser also reports "Charger", "6kW" and "3kWFCC" from its own files. "Flt 6" is what the only charger on one bike writes in its name field on every one of its records while it delivers 15 to 26 A, so it is not a charger that stopped, and what it abbreviates is not known. Charger firmware versions 201 (66 records), 206 (31) and 104 (22) occur, each on one bike. The serial number is decoded and never published.

What a rider can read from it: which chargers answered, and when one stops answering; the voltage and frequency at the socket; how much current each unit drew from the wall (5 to 12 A here) and what it delivered to the pack. It is the AC side of a charge, and no other record carries it.

A 0x4F is 31 bytes: the header, a 10-byte NUL-padded queue name and two uint32 values. It is written when a firmware task tries to post a message to a FreeRTOS queue that is already full. The message is dropped, and this record is the firmware saying so. Eighteen occur here, in four of the ten native main-board files, and every one names a CAN queue: CAN2txQ eleven times, CAN1txQ six and CAN0RxQ once. On these motorcycles a full queue is CAN-bus congestion.

The first value is constant for each queue (64 for CAN1txQ, 16 for CAN2txQ and 48 for CAN0RxQ) and reads like the queue’s capacity. The second varies, from 46 to 76 on CAN2txQ and from 735 to 79,252 on CAN1txQ. Neither meaning is confirmed, so both are published under neutral names, as upstream does.

What a rider can read from it: one record is one dropped message, not a fault, and nothing on the dash corresponds to it. Recurrence is what counts: the same queue overflowing on every ride, or overflows clustering around a charge or a fault, says which bus was overloaded, and when.

Type 0x32 is a firmware build banner. It uses the older record layout (no microseconds, sequence or offset byte, payload from record byte 7), and its four time bytes hold a small boot-relative number, not a date. In this corpus all 59 of them sit in 32 files from Gen2-platform main boards: 31 of those are 538XX-variant dumps, the ones routed to the Gen3 main-board path, and none is a native Gen3 ring buffer.

After one byte of unknown meaning, the payload is a C compiler’s build stamp (month, day, year and time, as __DATE__ and __TIME__ print them), followed, optionally, by a build number and a flash bank, "banka" or "bankb", each NUL-terminated. Here 54 records carry all three (a 32-byte payload) and 5 carry the date alone (22 bytes); upstream also lists 31- and 38-byte forms. The banks split 45 "banka", 9 "bankb" and 5 unnamed, and the builds were compiled between 2019 and 2024.

What a rider can read from it: which firmware build the main board ran while the buffer was being written, and whether that changed. A file that names more than one build spans an update (11 of the 32 files here do), and the decoder lists every build in file order, with how many records announced it. Two bank names suggest an A/B flash scheme, in which an update is written to the bank not in use; that is an inference from the names. Build numbers and dates narrow a motorcycle to a small population, so this page does not print them.

This is the trap that will cost a third-party implementer the most time. The same motorcycle can write different record layouts at different times, and the MBB part number does not change with it.

A 2021 SR/F with MBB part number 40-08155 produced a 2023 export containing 190 records of type 0x51 at declared lengths of 71, 72 and 74 bytes, plus 31 records of type 0x48, 30 of type 0x53 and 8 of type 0x49, and no 0x54 records at all. The same VIN, same part number, produced a 2026 export containing 151 records of type 0x51 at 75 and 76 bytes, 151 of type 0x54, and none of 0x48, 0x49 or 0x53. A firmware update changed the record set and the record size while the header still reported 40-08155.

The practical consequence: a decoder must key its field map on the declared record length, not on the part number, the model or the year. But this page previously drew a second, wrong conclusion from the same table: that a length one or two bytes over the nominal (76 rather than 75, or 30 rather than 29) is firmware drift and is benign. It is neither. Those are escaped records, and L minus the escape count lands on the canonical length without a single exception across the corpus. The distinction is testable. Across the nine native MBB files there are 69 over-length 0x51 records, and 56 of them carry their state token one byte late, at raw byte 43, which is exactly what one unhonoured escape does; the other 13 carry more than one and are displaced further. (An earlier version of this page said 81 and 71. The 81 folds the 12 over-length 0x52 records into the 0x51 count, and 71 reproduces under no framing convention tried.) Unescape first and the token sits at byte 42 on 1,347 of 1,356 records using the decoder’s eight tokens, and on all 1,356 once REV and PARK are counted.

The signature is read from the file bytes, not from the VIN: bytes 0 to 3 are the ASCII "MBB" plus a null, and bytes 38 to 41 are A1 A1 A1 A1, followed in real files by an ASCII build date.

Genuine Gen2 MBB files share that signature exactly, so it is not a discriminator on its own. The probe therefore runs the full decode first and adopts the result only if the outcome clears a threshold: at least 10 state-change entries and at least 50 telemetry entries.

This page used to explain that threshold by saying "real Gen2 passes the signature but writes no 0x2c telemetry records at all". That is flatly wrong. Genuine Gen2 files write plenty: the 121 signature-sharing files this gate rejects contain 137,944 length-chained 0x2c records between them, 46,721 of which are the same canonical 40-byte form, and a 40-file sample decodes 22,831 of 22,867 of them to a plausible pack voltage with a median of 104,392 mV and a pack-to-cell ratio of 28.043. The 40-byte 0x2c is the newer-firmware Riding Status record, present throughout the mainstream Gen2 corpus that upstream already parses.

What separated the two populations was a second bug. The old gate tested the on-disk length against 40 and so could not see an escaped record; on most Gen2 bikes a field pinned at a value whose low byte is 0xB2 means every telemetry record is escaped, so they scored 0 to 8 while genuine 538XX files scored 146 to 2,353. Fixing the escape erases that accidental separation: 30 of the 135 signature-sharing files jump to between 425 and 2,408 telemetry records. Adopting this decoder for them would be a routing change rather than a decode fix, so the yield gate deliberately keeps counting the pre-unescape population until that question is settled on its own terms, and the same 14 files are adopted before and after. Native Gen3 starts with 0xB2 and fails the signature outright.

The probe runs before Gen3 classification rather than after, because 538XX VINs land on both sides of the veto: some are vetoed to the Gen2 path and others are not vetoed and would be routed to the native-Gen3 decoder.

Offsets are record-absolute, on the unescaped record. This map is upstream zero-log-parser’s own run_status table, not something derived here; upstream’s payload offsets are these minus 7. Every channel is range-guarded so that corrupt ring-buffer frames are dropped rather than charted. Two derived quantities are computed in the decoder: power as V × A / 1000, and shaft torque as kW × 9549 / rpm for rpm above 100, which is gearing-independent in a way that speed is not.

This subsection used to be titled "Calibration provenance" and it opened: "None of the scale factors above was assumed. Each channel was fitted against either BMS ground truth or a physical conservation law, and the fit statistics are the reason the map is trusted." It then cited voltage fitted against BMS pack voltage at r = 0.96, current validated by distribution matching, and a speed scale of 0.023323 km/h per RPM falling out of odometer distance conservation at r = 0.999. All three claims are withdrawn. This was the worst mistake on the page, and it shows how a fit with a good correlation coefficient can be wrong.

Voltage. The retired read was a uint16 at +12 scaled by 0.24608 with an offset of 4.25 V. That uint16 is the middle two bytes of an exact 32-bit millivolt integer, with the low byte discarded: the identity u32 at +11 equals 256 × u16 at +12 plus record byte 11 holds on 19,513 of 19,516 records. Fitting a line to a lossy slice of a number you already have exactly cannot be right, and it is not: against the true value the fitted line is off by a median of 0.1391 V, a 99th percentile of 0.5710 V and a maximum of 0.9728 V, and it exceeds 0.1 V on 62.8% of records. A self-contained check that needs no external reference: u32 at +11 divided by the cell voltage at +36 has a median of 28.070, which is a 28-series pack read in millivolts. The correlation of 0.96 was real and it was uninformative, because a monotone lossy transform of a quantity correlates with that quantity by construction.

Current. This one was worse than an approximation. The retired read was an int16 at +22 divided by 256, presented as Q8.8 amps. Record byte 22 is a pad byte (zero on 19,511 of 19,516 records), so that expression reduces algebraically to int8 of record byte 23, an identity verified on all 19,516. The real field is an int16 at +23 in whole amps. 487 records (2.50%) exceed int8 range and 418 of those came out sign-inverted, so a +206 A launch was charted as −50 A. Every motorcycle’s peak discharge was clipped at about 127 A against true per-file peaks of 199 to 385 A, understating the peak by 37.7% to 70.5%. That range compares each decoder’s peak under its own guard, which is what a user would have seen; restrict the retired read to only the records the current ±400 A guard accepts and it becomes 37.7% to 73.8%.

Road speed. There is no speed field in this record, and there never was. The 0.023323 constant was fitted from odometer distance conservation, which is a sound method for a constant that exists; refitting it per file gives 0.02273 to 0.02504 across the 13 files with more than 50 km of motion, a spread of ±5.2%, because final drive ratio and tyre circumference differ by model. The shipped constant sat between 6.9% low and 2.6% high depending on the bike. A per-model table could have been fitted, but the 14 adopted files carry seven distinct VINs and four of those contribute a single file each, so that table would have been fitting noise, the same mistake the voltage calibration made one level up. The decoder now publishes motor RPM, which is measured, and no derived speed at all.

The fit was replaced by upstream zero-log-parser’s own run_status field map, which has dispatched 0x2c since 2015. The independent check that it is right is physical rather than statistical: over 483 ride sessions with at least 5% SOC used and at least 2 km covered, integrated electrical energy per SOC percent moved from 43.1 Wh/% to 50.0 Wh/%, implying a usable pack of 5.00 kWh rather than 4.31 kWh (correct for the ZF3.6 and ZF7.2 packs these motorcycles carry), and energy per kilometre moved from 46.3 to 54.1 Wh/km against Zero’s own published 55 to 70. The coefficient of variation across sessions fell from 44.8% to 39.4%. A correction that both moves an estimate to the physically right value and reduces its scatter is doing something a better-fitting line cannot.

The odometer carries its own guard, because it is lifetime non-decreasing and the ring buffer is not. Any reading below the running maximum, or zero, is rejected and the last good value is carried forward flat. A forward step is accepted only when the increase is no more than the larger of 5 km and 200 km/h times the elapsed hours since the previous accepted reading. The cadence term stops sparse telemetry from under-counting a long gap while still dropping bit-flipped frames.

This firmware writes none of the native-Gen3 binary state tokens. State is derived from ASCII text events whose payload starts at record byte 7 rather than byte 13, and it is carried forward by timestamp onto the following telemetry records.

Charging is deliberately not detected on this path. The 538XX MBB carries no charge telemetry, and its charger-contactor events fire repeatedly within a single charge, which fragments one real charge into dozens of dataless markers. The decoder therefore emits no MBB charging sessions at all and leaves charge detection entirely to the BMS.

The before-and-after numbers are real pipeline outcomes and they are worth keeping, provided they are labelled for what they measure. Two 538XX motorcycles went from nothing to a complete history: one from 0 rides and 0 km to 112 rides and 678 km, the other from 0 to 88 rides and 423 km. Over the same run, native-Gen3 and genuine Gen2 files produced byte-identical output, so the new path introduced no regression on the formats that already worked.

Those numbers measure a file finally reaching a decoder. Upstream could already read these records; the entries were lost to the binary-structure override described at the top of this section. Read the figures as the cost of a routing bug, not as evidence that a new record layout was cracked.

A second defence of the purpose-built path does survive, and it is narrower than the original claim. On the five files that did reach the upstream Gen2 path, its session detector over-fragments badly (546 rides across 602 km, about 1.1 km per "ride", against 131 rides and 491 km here), and this project’s physical guards reject about 0.24% of upstream rows as impossible. So the session logic and the guards earn their place. The record decoder did not need to be written; only the router needed fixing.

The odometer unit was confirmed to be kilometres, not metres, by continuity with the same motorcycles’ historical Gen2 odometer readings. The format contract and the discriminator are both pinned by automated tests, so a future change that breaks either fails the build rather than silently reverting these bikes to zero rides.

One per file. The BMS header identifies the battery control board rather than the motorcycle, which is why it is the right place to look when a pack has been swapped.

Same structure as the MBB text record: the common 13-byte header, then NUL-terminated ASCII from record byte 13. This page used to say the BMS differs by a "board marker" of 0x01 at byte 12 where the MBB has 0x02; byte 12 is the UTC-offset setting, and the two values were two motorcycles’ time zones. These events are the highest-confidence signal for when the motorcycle was turned on, which makes them load-bearing for session detection.

The decoder did not know where the text starts until 2026-10. It took "the first printable byte at or after byte 7", so whenever a sub-second, sequence or offset byte happened to be printable the text began there, and stopped at the next zero, which on a UTC+0 motorcycle is byte 12 itself. Over the 13,522 BMS text records in eight files whose header is intact and whose timestamp is plausible, 4,268 (31.6%) came out right, 7,234 (53.5%) were dropped as "too short" (7,025 of them carrying real text such as "Entering ZERO_BMS_STATE_IDLE"), and 1,890 were published as garbage like "Po\x0e", with 130 more carrying a junk prefix. Byte 13 is printable on 8,786 of the 8,788 BMS text records no page marker touched, and on 18,570 of 18,570 MBB text records. Only type 0xFD is text: every other record that reached the text parser (a telemetry record of the wrong length, a record whose type byte a page marker had overwritten) was being mined for printable bytes and published as an "event", and no longer is. The fix more than doubles the state-machine events a file yields, and it changes BMS ride detection for the better: split rides merge back into the one ride the MBB recorded.

All of that is the FST record layout, and the decoder now checks for it per file, from the bytes, before applying any of it. The same decoder is also handed files that are not FST at all (Gen2-shaped BMS dumps and odd exports that the 0xB2 telemetry probe routes here), and in their records the text does start at byte 7. On those the byte-13 rule cut six characters off every message ("DEBUG: CAN Link Is Down" became "CAN Link Is Down") and dropped the records left too short. A file counts as FST when the page marker opens its second and third pages, or, failing that, when the sub-second word is at most 1,000,000 on at least 80% of its records and byte 12 reads as one dominant civil UTC offset; measured over 374 files the two populations sit far apart (at least 0.97 against at most 0.16 on the first test). Anything else keeps the original rule exactly.

A text record a page marker ran through is a prefix of what the firmware wrote, because the marker opens with a zero byte and ends the string there. It is kept and flagged as truncated, and a pattern that captures up to the end of it is not trusted: "Entering ZERO_BMS_STATE_HIB" cut short is not the state HIB.

Payload offsets below are relative to the payload start at record byte 8, matching the convention the decoder uses. To convert to record-absolute, add 8: payload[38] is record[46].

The decoder validates before it trusts. Cell voltages outside 2,500 to 4,500 mV cause the whole record to be discarded as corrupt, which is also what rejects the text events that occasionally land on a telemetry-sized gap. SOC is accepted only in 1 to 100; a zero means sleeping or not calculated, not empty.

The pack current is the largest single measurement error this page has had to correct. It was read as a signed 16-bit value in milliamps, which caps at ±32.767 A. A Zero pack draws several hundred amps under acceleration, and because nothing clamps, the stored value wrapped instead of clipping: it held the true current modulo 65,536 mA, which inverts the sign rather than flattening the peak. That is why the recorded direction was near a coin flip while riding: 55.5% discharge, against 78.4% on the same bike’s own MBB log over the same rides.

It is a 32-bit value, and the two bytes this page described as a firmware charging indicator are its high half. Over all 72 native Gen3 BMS files on production, 45,060 telemetry records: those bytes read FF FF on 80.5% of records whose low half is negative and 00 00 on 84.9% of those whose low half is positive. That is a sign extension. The flag was real in that it fired during charging, but not for the reason given: FF FF is what a negative number looks like, and charge currents are negative.

Three checks, each against its own null. Coulomb counting against the pack’s own state of charge: over 84 contiguous segments the sign of the integrated current agrees with the direction of the SOC change on 83 of 84 under the 32-bit read, against 49 of 84 under the 16-bit one, where 50% is the coin-flip null. The implied capacity is 138.7 Ah per 100 points of SOC (a ZF14.4, ZF15.6 or ZF17.3 pack is 129, 139 or 154), against 16.8 Ah before, which is not a motorcycle. And Ohm’s law against the separately verified pack voltage gives a median slope of −29.9 mΩ, negative on 35 of 38 bikes, a plausible 28-series internal resistance; the old read gave −5.6 mΩ and negative on 20 of 38.

An unreadable current window now yields nothing rather than zero, because zero reads as an idle pack. A genuine zero is kept: it is a real reading on about a fifth of all records.

This site published, and our own internal notes carried, a four-value enum for payload[24]: 0x0B idle, 0x0C active, 0x09 unlock, 0x0A precharge. It is withdrawn. The byte is read out of every telemetry record and stored verbatim, no decoder acts on its value, and nothing in the corpus supports mapping it to the BMS state names. If you have taken that enum from here, from a copy of it, or from a decoder built on it, discard it.

Across the same 2,319 telemetry rows the shipping decoder emits, used everywhere else on this page, payload[24] takes 37 distinct values: every value from 0x00 to 0x23 except 0x02, plus the two flash sentinels 0xF0 and 0xFF. The four codes the enum named cover 1,358 rows, which is 58.6%, so two rows in five are a value the enum has no name for; and 0x09, the "unlock" state, is 47 rows, 2.0% of the corpus.

Three separate tests were run against the byte and it failed all three. It is not a counter: 82.0% of consecutive deltas inside a 120-second window are exactly zero, 973 of 1,186, and the sequence neither increases monotonically nor wraps. It is not a temperature: correlated against payload[43] in the same record it gives r = −0.05, and the two bytes are equal on 1.3% of rows, though that particular comparison is now worthless, because payload[43] turned out not to be a temperature either. And it does not track the BMS text state machine as a partition. Carry each "Entering ZERO_BMS_STATE_x" event forward in time and one of the four does line up with the name it was given (0x09 sits under UNLOCK on 62% of rows, n = 45), but 0x0B does not: the value called "idle" sits under HIBERNATE on 41%, IDLE on 26% and UNLOCK on 14%. One match out of four is what a four-state enum looks like when it is wrong.

The one property that does survive is weak and it is not an enum. Ranked by the fraction of rows that are under load, the byte orders as a rough activity proxy over at least eight values, but two values the enum never named, 0x10 at 62.2% under load and 0x0F at 40.7%, sit inside the very chain the enum used as its evidence, one of them above the supposed "active" code. A four-state machine cannot have unnamed states sitting between its states.

payload[24] is a firmware-internal byte that varies with activity, has at least 37 values, and has no decoded meaning. Treat it as opaque, and do not write "0x0B = idle, 0x0C = active" anywhere without re-deriving it from your own files first.

This page said "the first 52 bytes of a 0x4D record are identical in layout to a 0x4B record". They are not, and this is the single field-map error most likely to cost a third-party implementer a day. A 0x4D shares only the 13-byte header. It then inserts eight bytes, so every measurement field sits eight bytes later than its 0x4B position, and the "26 extra bytes" this section used to describe are the last 26 bytes of a shifted payload rather than a suffix appended to an unshifted one.

The measurement is unambiguous. Sweeping candidate shifts from 0 to 12 and testing whether the two cell-voltage words land between 2,500 and 4,500 mV, over the length-exact records in seven Gen3 BMS files: a 0x4B scores 1,598 of 1,732 at shift 0 and at most 14 anywhere else; a 0x4D scores zero at shift 0 and 619 of 666 at +8, with the next-best shift scoring 2; a 0x4C scores zero at shift 0 and 75 of 78 at +4, with the next-best scoring 3. Denominators move by a few records depending on how the file is walked (a length-chain walk over the same dumps gives 624 of 671), but the fraction is 92.9% every way we have counted it, and the score at the 0x4B offsets is zero every way. Zero at the nominal offsets is the important number: a decoder using the 0x4B map on a 0x4D fails completely instead of degrading, and if it has a cell-voltage sanity check it will discard every record silently.

Four corroborations of +8 that never touch the cell gate that selected those records. The uint24 at record[54:57] is the pack voltage the 0x4B writes at record[46:49], with a median of 104,793 mV, inside the 28-cell envelope on 578 records, a pack-to-low-cell ratio with median 28.020, and low cell no greater than high cell on 619 of 619. Record byte 59 behaves exactly like the byte at record 51 of a 0x4B (the byte this page once published as a temperature, and which is not one; see the callout below): median 10 against the 0x4B’s 13, and a range of 0 to 27 once the 14 rows carrying a 0xF0 or 0xFF flash sentinel are set aside; taken raw the range is the full 0 to 255, which is what a sentinel does to a small-integer field. Record bytes 51 and 52 are each zero on 603 of 619 and both zero on 594, mirroring the two zero pads flanking the 0x4B report-mode byte. And the load flag, bus-engaged byte and report mode agree with each other rather than with anything external, though not perfectly: of the 72 records reading load 0xFF, 68 also read bus engaged and 67 read report mode 7; of the 527 reading load 0x78, 502 read report mode 2. Report mode 2 occurs on 520 rows in all, so the two sets nearly but do not exactly coincide.

That last number is a small finding in its own right. Report mode 2 is a value the 0x4B record never writes, so the enum has seven values, not six: 1, 3, 4, 5, 6 and 7 from the 0x4B plus 2 from the 0x4D.

The cost of the shift, before it was found, was that every 0x4D and every 0x4C telemetry row was discarded: 744 records at the canonical lengths reached the telemetry branch and every one was gated out by the cell-voltage check. Fixing the offsets recovered 694 of them on this corpus, 619 from the 0x4D and 75 from the 0x4C, which is 42.7% more Gen3 BMS telemetry with none lost. Eighty-four percent of the recovered 0x4D rows (521 of 619, and 47% to 96% depending on the file) land inside a gap of more than an hour in the same file’s 0x4B series, so this is real sampling density rather than duplicates, and it feeds the battery page and the state-of-health estimate. The one field that always survived is the capacity register, because it is harvested by record length before the gate runs.

The 0x4C record appears during operational periods only and is rare: 84 records across the whole corpus, with a per-file count between 0 and 65: three of the seven files carry none at all, and one carries 65 of the 84. (This sentence used to say "0 and 58", contradicting the table above it. Re-measured on 2026-07-30 under the shipped byte scan: the per-file counts are 0, 0, 0, 4, 7, 8, 65, and the same scan reproduces the table's 0x4B 186–527 / 1,803 and 0x4D 79–126 / 691 exactly. The table was right.) It carries the same payload as a 0x4B shifted four bytes later, by the same mechanism as the 0x4D’s eight: four bytes inserted after the shared 13-byte header. Over the 78 length-exact 0x4C records here, cell voltages are plausible at +4 on 75 (96.2%) and at the 0x4B offsets on zero.

At +4 the rest of the record is equally coherent, which is what distinguishes a real shift from a lucky one. Record byte 48 is a zero pad on 75 of 75 and record byte 47 on 74 of 75, record byte 49 is the report mode and reads 7 (active high-rate) on 75 of 75, the not-a-temperature byte at record byte 55 has a median of 14 once the three flash-sentinel rows are excluded (16 if they are not), and the uint24 pack voltage at record[50:53] has a median of 108,144 mV. Median current is −9.5 A, so these records are written while charging.

Until this decoder learned the shift it never read one: 70 was not on the gap-dispatch list, so every 0x4C went to the text and event parser. Eighteen of them across the corpus produced an "event" whose text was three consecutive printable bytes of binary payload, strings like "@~\x05" and "7\x0b3". Those eighteen rows are the only entries the type dispatch takes away.

A 50-byte telemetry variant, sometimes called FST Mono, is documented on the SR/S board with part number 40-08201. It uses the same field map as the 52-byte record, truncated by the two trailing bytes, so it has no payload[43] at all. The decoder accepts a 50-byte gap into the telemetry path on that basis.

Resolved since, and kept for the record. Measured over all 72 native Gen3 BMS files on production, eight files across four bikes are written entirely in the short family (40-08201 "FST Mono" on seven, 40-08213 "FST Mod" on one), with no standard-family telemetry record between them, and the +4 / +8 shifts hold unchanged. What follows was true of the seven-file corpus. None of the seven BMS files measured here comes from a 40-08201 board (they are 40-08247-01 on three files, 40-08295-01 on two and 40-08367-01 on two, and that list is exhaustive for this corpus), so nothing here can confirm the variant. What it does show is a cost. Of the 514 fifty-byte gaps in the corpus, 509 are still fifty bytes after unescaping, and 98.0% of them carry the type byte 0xFD, meaning they are text events; none carries 0x4B. Every one of those is passed to the telemetry decoder and then rejected by the cell-voltage sanity check, which is why the misrouting is harmless in practice rather than merely undetected.

Where the marker falls inside a record decides what reading through it costs. Counted over all 8,200 markers in the eight battery files, against the delimiter gap each one falls in:

This page once described a three-byte "page footer", F0 FF 00, that a decoder could splice out. Both halves were wrong: the marker is four bytes, and there is nothing to splice, because it does not sit between records.

The record lengths prove it is an overwrite. Over the 8,005 delimiter gaps that straddle a page boundary in the eight battery files, the declared length equals the gap on 7,246 and is shorter on 759, and it is never the gap minus four: the marker’s bytes are counted inside the record they land in. Over the 10,365 gaps with no marker in them the declared length equals the gap every time. The file size agrees: a battery export is 131,328 bytes and a main-board export 131,200, exactly one 128-byte page apart.

A timestamp is four little-endian bytes, so its low byte comes first. When the marker starts on a record’s type byte it writes F0 FF 00 over the timestamp’s three low bytes and leaves only the top one, which changes once every 2^24 seconds, about 194 days. Every record hit that way within the same 194 days therefore decodes to the same second, whichever motorcycle wrote it: 0x6800FFF0 is 2025-04-17 13:19:44 UTC, 0x6900FFF0 is 2025-10-28 17:40:00 UTC and 0x6A00FFF0 is 2026-05-10 22:00:16 UTC. When the marker starts one byte earlier, on the length, the timestamp’s two low bytes become FF 00, and the forged time lands up to 18 hours from the real one, on a value every hit in the same 18-hour block shares.

In this corpus that produced 268 rows with a forged but plausible timestamp, on 38 distinct seconds, and 2025-10-28 17:40:00 alone appears on 95 records from five of the six motorcycles whose battery files are here. When unrelated bikes share a date to the second, the cause is this marker, not a coincidence or a firmware event.

Days and rides were built on those rows. A handful of forged timestamps on a day the bike was parked becomes a day of activity; real current values carried onto a forged date become a ride that never happened. Re-decoded with release 3.37.0, the eight local battery files lose 13 file-days and 18 of their 65 battery-detected rides, and every day removed is one that only forged timestamps supported.

Since release 3.37.0 both decoders (the server’s and the browser port behind /decode) do four things with the marker, and never a fifth:

The change was graded against the full production corpus before it shipped: 1,220 log files, decoded by master and by release 3.37.0. Gen1, Gen2 and Gen3 main-board files decode identically on every metric; only the 224 native Gen3 battery files change, and they change the way the arithmetic above says they must.

Record byte 67 has been described (including in our own internal notes, and in a decoder that briefly shipped) as a uint8 charge-cycle count, presented as a key health metric with a per-motorcycle table of values: 16, 105, 137, 187 and 209 across five bikes. That reading is wrong, and the table has been deleted rather than corrected, because the numbers in it meant nothing.

Byte 67 is the low byte of the uint24 little-endian full-charge-capacity register at record[67:70]. It wanders across 0 to 255 with no monotonicity and no relationship to charge count, which is exactly what the low byte of a capacity reading in milliamp-hours does.

The old table refutes itself on its own numbers. It recorded the two bytes above the supposed cycle count as a "per-bike constant, e.g. 486". Read 486 as the high two bytes of the same uint24 and the register sits at byte 67 plus 124,416 mAh. The five "cycle counts" were the bottom 0.2% of a single pack-capacity reading of about 124 Ah, a number that is, unsurprisingly, in the same range as the medians measured above.

The decoder that wrote this value into a charge-cycle column shipped and was reverted the same day once the register was identified. The dataclass field still exists for compatibility and is never populated, and the non-assignment is documented at the point where it would otherwise happen. Anything reading a Gen3 charge-cycle count from this pipeline is reading a null.

This page tells the story instead of correcting the offset without comment, because the wrong reading is loose in the world. If you have a Gen3 decoder, or a spreadsheet, or an article that reports charge cycles from byte 67, the number in it is the bottom byte of a capacity register and it should be discarded rather than recalibrated.

No explicit state-of-health percentage field exists in any generation of the Zero binary format. Three health-related signals do exist on Gen3, and only the first is close to actionable.

The full-charge-capacity register is the direct reading, and dividing it by the VIN-nominal design capacity gives a state-of-health ratio that does not depend on catching a large charge. It is extracted and stored today but not yet consumed by any endpoint, so no percentage currently shown anywhere is derived from it. Open-circuit voltage at payload[15:17] is an infrared-compensated idle cell voltage that could in principle be mapped to SOC through a cell reference curve, and is available even in a hibernation-only dump; no such curve is implemented. A third signal listed here previously, a coulomb counter at extra[2:4] said to track self-discharge at about 3 units per hour, does not exist: those bytes are the low half of the 0x4D pack voltage, and the decay is pack sag in millivolts.

What ships is a generation-independent session method: capacity is estimated per session as energy divided by the fraction of SOC moved, divided by the number of active battery modules, and state of health is the mean of the last five estimates against the nominal per-module capacity.

The timestamp is a uint32 little-endian at record bytes 3 to 6, and two different windows are applied to it at two different stages. Conflating them produces either silently dropped records or garbage sessions.

The Gen3 binary framers use the strict window of 2019-01-01 (Unix 1,546,300,800) to the present plus 365 days. This page previously described that window as a framing signal: the thing that distinguishes a genuine record boundary from a 0xB2 byte sitting inside a payload. Measured, it does almost none of that. Over the 14 adopted 538XX files the shipped decoder’s own counters turn down 21,106 candidates: 18,002 whose timestamp field reads exactly zero (an erased flash slot the firmware never wrote) and 3,104 that hold something outside the window. Neither class is delimiter disambiguation; the escape does that. (Over all 135 signature files the same counters read 154,668 and 164,256 against 614,539 accepted candidates. That is a different denominator and a byte-scan population, so quote it only with both stated.) An earlier version of this page gave 23,026 rejects, 22,972 genuine starts, 17,992 zeros and "only 54 true non-boundaries"; none of that quartet reproduces, and the genuine-start decomposition of the 3,104 is not something this corpus settles, so it is not claimed here.

The generic post-parse filter, applied to every generation after decoding, accepts calendar years 2015 to 2030. That is what separates entries with usable timestamps from real-time-clock-reset garbage before session detection runs. Records that fail it are kept but sorted to the end, because a record with a broken clock can still carry a valid measurement.

Two practical notes on the values themselves. The most significant byte of the timestamp, record byte 6, is around 0x69 for 2025 and 2026 dates; that byte has occasionally been mistaken for a record type marker, and it is not one: the type byte is record[2]. And read the timestamp from the unescaped record, never from the wire. An escape landing inside bytes 3 to 6 shifts everything after it, and a record whose on-disk bytes read as June 2019 can decode to November 2023 once the FE 01 pair is honoured.

This site decodes Gen1 and Gen2 logs with the community parser, zero-log-parser, pinned at commit 90c8cb2 (29 September 2026; at 87c6e757, February 2026, before that); the native Gen3 records on this page are decoded by this site’s own code. On 3 October 2026 the two Gen3 decoders were compared record by record, aligned by file offset, against the parser’s main branch at 90c8cb2 (29 September 2026, the version the hosted parser at home.hasslers.net/zerologparser runs). Wherever both decode a record they agree: all 2,866 cell-voltage readings, the state of charge, the state fields, the temperatures, the charger table and the queue-full reports. Several of those records were decoded upstream first (the Gen3 main-board header and the 0x32 firmware build on 15 September, the 0x48 charger table and 0x4F queue-full on 20 September, a page-aware walker for the pack’s flash pages on 22 September), and this site’s versions, released on 3 October, were checked against them. Four differences remain, one of them in the parser’s favour: it reads both serial numbers out of a Gen3 pack’s header, which this decode does not. Since the pin moved, the site records the two serials the parser reads, as information only; nothing identifies a pack by them yet. In the other direction, the parser does not yet decode the Gen3 text records (type 0xFD), the largest record class on Gen3: its message decoder reads the record’s six-byte prefix as the string. It reads the first four payload bytes of the 0x54 record as an odometer; they are the sub-second part of the record’s timestamp. And its LOG_STRUCTURE.md still places an odometer in bytes 0–3 of the 0x51 record, where this corpus finds none; on this site’s reading the odometer is in the tail of the newer-layout 0x52 and 0x53 records.

Each record is framed once, by this site’s framers (the declared-length chain on the main board, the delimiter gap with the page-marker cut on the battery board), and the same unescaped bytes are handed to both decoders: this one its frame, upstream its payload, which starts at record byte 7. A record is identified by where it sits in the file, and nothing else.

Timestamps cannot do that job. Two records written in the same second are the normal case, not the exception: in the ten native main-board files 19,705 of 21,724 framed records (90.7%) share their second with at least one other record, and 16,919 (77.9%) with another record of the same type; in the eight battery files it is 15,735 of 18,370 (85.7%) and 13,184 (71.8%). A join on time pairs the wrong records and reports disagreements that do not exist. An earlier comparison reported the two decoders disagreeing about a charger’s CAN id, 16 against 17, when it had paired two different chargers that answered in the same second.

The corpus is every native Gen3 file in this repository: 18 files, ten main-board and eight battery-management dumps. Upstream’s current code is loaded only for the comparison and never in the same process as a full decode, because loading it beside the version this site pins changes what the pinned library returns. The script that runs it, gen3_upstream_crosscheck.py among this repository’s backend scripts, writes nothing and exits 0: it is a report, not a gate, because a disagreement can be upstream’s error as easily as ours.

Measured on 3 October 2026 against upstream main at 90c8cb2.

Every difference in the table has a cause that can be named:

A comparison against a moving upstream is a measurement, not a test. What keeps this decode from drifting is a committed fixture of 43 anonymised real records (22 main-board, 18 battery-management and 3 older-layout battery records), together with the values this decoder produces from each. It holds no header record and no identifying text, and the charger serials in it are zeroed. The Python decoder is tested against it in the backend suite and the browser decoder behind /decode against the same file in the frontend suite, so the two implementations cannot drift apart on a record without a test failing. When the browser port was brought back in step for release 3.37.0, it differed from the server decoder on 0 values across the 18 native files.

Much of what this page added in October 2026 was found first by the community parser, and the decoder here was checked against it rather than written in isolation. In upstream’s main branch: