The Zero Gen3 log format, record by record

Exactly one header record appears per file, and its timestamp is the download time rather than a log time. The fields below were read from real files; VIN serials are masked here in the same way the internal documentation masks them.

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 a four-byte internal counter, a sequence number and a board marker byte (0x02 on the MBB, 0x01 on the BMS).

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 — a cycle being 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 median burst is 31 records, most often 27 text events, 2 telemetry records and 2 secondaries, written over a 91-second window. 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 does not read the state field at a fixed offset; it searches the record for one of eight null-padded ASCII tokens — RUN, STOP, HIB, STRT, PWSU, CHRG, WAIT, WAKE — and derives every other offset from where it lands. 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 decoder’s eight tokens; the remaining 9 carry REV or PARK — five and four, all on the one DSR/X here — and are discarded only because GEN3_STATES does not list those two. They are not tokenless, and they are not empty: all 9 carry a populated pack voltage at record[34:38], between 102.561 V and 102.630 V, so adding the two tokens would recover real telemetry rather than noise. The search-based approach is what lets the same decoder read the 92-byte 0x52 record, where the state sits four 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 low byte of the entry counter: 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 paired one-to-one with 0x51 in every burst observed, and its content is almost entirely absent. 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, and 782 (80.8%) end with the four-byte sentinel FF FF FF FF at record[25:29]; a further 78 (8.1%) end with four zero bytes.

What the record is for is genuinely unknown. The pairing and the sentinel are consistent with a null or error secondary channel — a second measurement source that reports "no data" — but nothing in the corpus distinguishes that hypothesis from a reserved slot the firmware never fills. It is listed here as unknown rather than guessed at, and no decoder reads it.

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 and pushes the post-state block to byte 55. Because the decoder finds the state by search rather than by offset, it reads 0x52 records without special-casing them. Extra bytes at the end hold additional counters that nothing decodes. The record is rare — 67 across the eight app dumps under length-chain framing, 87 with the ninth file included, and 0 to 31 per file — and it appears mainly around WAKE events. An earlier version of this page said 66. That is the same quantity counted as raw 0xB2 delimiters whose un-unescaped timestamp passes the window, which is a different convention and a smaller number.

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 rather than cosmetic. 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 simply the newer-firmware Riding Status record, present throughout the mainstream Gen2 corpus that upstream already parses.

What actually 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 is worth setting out exactly 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 actually 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 genuinely 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.

What replaced the fit is not another fit. It is 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, which is 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.

What those numbers do not measure is a format being decoded for the first time. They 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, honest 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, except that the board marker at record byte 12 is 0x01 rather than 0x02. These events are the highest-confidence signal for when the motorcycle was actually turned on, which makes them load-bearing for session detection.

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.

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.

What the byte actually looks like: 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 the temperature byte at payload[43] in the same record it gives r = −0.05, and the two bytes are equal on 1.3% of rows. 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 sitting 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, and the honest thing is to report the one that held.

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.

The honest summary is short. 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 — it means a decoder using the 0x4B map on a 0x4D does not degrade, it fails completely, 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 0x4B temperature byte at record 51 — 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 58. 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 temperature at record byte 55 has a median of 14 °C 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 temperature byte at payload[43]. The decoder accepts a 50-byte gap into the telemetry path on that basis.

It is worth being clear about the limits of that: 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.

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.

The reason to tell this story rather than quietly fix the offset is that 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 actually 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 three-byte sequence F0 FF 00 has been described as a flash artifact appearing "at random positions within records" throughout both MBB and BMS logs. Measured, it is neither random nor present in both.

In every one of the seven Gen3 BMS files, the sequence occurs exactly 1,025 times, first at byte offset 129 (0x81) and then at a stride of exactly 128 bytes, running to offset 131,201. The spacing histogram across 1,024 intervals contains a single value: 128. In all nine native Gen3 MBB files it occurs zero times, and no repeating three-byte pattern exists at any 128-byte stride.

That makes it a structural feature of the BMS log driver: a fixed marker written once per 128-byte flash page. It also explains the file size. A BMS export is 131,328 bytes and an MBB export is 131,200 — a difference of exactly 128, one extra page.

The practical consequence is much better than "treat records containing it as corrupt". The marker positions are entirely predictable: any byte at an offset congruent to 129, 130 or 131 modulo 128 in a BMS file is a page marker rather than record data. A decoder can splice them out before framing, instead of discarding whole records that happen to straddle a page boundary.

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 — 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.