Recent INAV development reports give unusually specific examples. One places recorded values under the wrong field names. Another emits an optional field using a different encoding than the decoder expects. A third writes motor channels that the log header never declares. In each case the aircraft's flight behavior and the record of that behavior are separate things.
The deeper issue is the contract between a log writer and its reader. Without that contract, high-resolution flight data can be incomplete, undecodable or, in the most misleading case, confidently displayed under the wrong label.
A recorder is a serialized interface, not a screenshot of flight state
Betaflight's Blackbox internals documentation explains its frame model. An I-frame, much like a video keyframe, carries data that can be decoded without depending on an earlier flight-data frame. A P-frame saves bandwidth by encoding changes relative to preceding values. A header describes the fields, their order, signedness, predictors and encoding.
That structure is efficient, but only if the writer and decoder agree on it. The actual binary frames are packed according to the declared order and encodings. Field names are not repeated beside every value.
A parser can check many things: whether a byte is a legal frame marker, whether time advances plausibly, whether an expected field can be decoded and whether synchronization resumes at an I-frame. Those checks cannot independently certify that a value labeled terrainAGL really came from the terrain-height variable in firmware.
This is the distinction between structural validity and semantic validity. Both are needed before a flight trace becomes evidence.
The wrong columns can look technically valid
INAV pull request #12125 documents a field-order problem on targets that enable both DroneCAN and terrain support.
The header declares three slow-frame fields in this order:
droneCANBusOffCount, terrainAGL, terrainAMSL.
According to the developer, the writer emitted the CAN bus-off count after the two terrain fields. A normal decoder would use the header order, so values were interpreted under the wrong names. Depending on their magnitudes, the results might look bizarre or might be mistaken for real changes in terrain data.
The proposed repair changes the order of emitted values to match the header. In a reported hardware comparison, the old build put a value of 1 into the decoded CAN bus-off column where the fixed build produced 0; other columns similarly moved into their intended positions. The developer identifies particular H7 and F7 boards and notes that the problem does not affect targets lacking the combined feature configuration.
The most important consequence is retrospective. A decoder reading one of the older files has no reliable way to know the true origin of those fields from the column names alone. The firmware revision in the header becomes essential context.
If a maintenance decision rests on whether a CAN bus experienced repeated errors, mistaking terrain-related data for a bus-off count is worse than being unable to open the file. It supplies an apparently specific but false answer.
An extra optional value can break an entire interval
INAV PR #12126 deals with a different kind of mismatch.
The author's example configures nine optional values in a Blackbox P-frame, including voltage, current, magnetometer axes, barometer, airspeed, surface distance and RSSI. The writer had space for eight values in a temporary array and serialized the group in a format designed for eight. Under that full sensor configuration, the ninth value could be written outside the array and its encoded representation did not consistently match what the reader expected.
The reported symptom was severe. In one three-minute log from a T-28 aircraft, the author says about 96.9% of log iterations were missing after decoding, while a comparison with the proposed fix and a different logging interval had no missing iterations. The tests are presented by the contributor, not by an independent lab, and the two samples differ in duration and logging rate. Still, the source includes concrete parser and test details rather than merely saying the file was corrupt.
An engineer seeing repeated gaps might blame SD-card write speed. In this case, the reported cause was a disagreement over serialization with all nine fields enabled.
That matters because the obvious mitigation for a failing logger, such as lowering the logging rate or replacing storage media, would not address the format mismatch. The correct diagnosis comes from checking which fields were enabled and what the writer actually emitted.
The author notes that previously recorded affected logs may be hard to recover because the bytes do not explicitly say whether the ninth value was present. A decoder might attempt alternate interpretations between recognizable frame boundaries, but that is a recovery heuristic, not a replacement for an unambiguous original encoding.
A vehicle with more motors can outgrow its own header
The third case is INAV PR #12127. The software supports a mixer with as many as 12 motors, while the Blackbox header previously declared only motor[0] through motor[7].
With a larger mixer, the firmware could emit extra motor data that was absent from the header. The developer reports that a 12-motor simulation produced 681 frame-decode failures and no data rows before the change. After declaring all motor fields, the same kind of test yielded 647 decoded rows.
This is not proof that real 12-motor aircraft suffered a flight-control problem. It describes a logging-format inconsistency discovered in simulated output, and the contributor explicitly asks for reports from actual aircraft with more than eight motors.
It also exposes a second layer of tooling risk. The author says the viewer's motor-specific presentation still assumes eight channels in places, even where a decoder can emit the additional fields. A log may be parseable into raw data while a particular visualization remains incomplete or incorrectly labeled.
When a builder expands a mixer configuration, the logging schema and viewer capabilities should be considered part of that change.
A missing sample is different from a mislabeled sample
The three defects produce different forms of uncertainty.
- Incorrect field order: a column may exist and contain reasonable numbers, but the meaning assigned to those numbers is wrong.
- Incorrect field packing: the decoder can lose synchronization and reject many subsequent frames.
- Incomplete field declarations: the writer emits more channels than the reader was told to expect.
The distinction is operationally important. A suspicious-looking trace should not immediately be treated as either a real aircraft event or random file damage.
Betaflight documents that its decoder can recover after a damaged sequence by finding a new I-frame and that P-frames depend on preceding data. It also notes that the Blackbox frame stream does not generally include per-frame checksums or explicit payload lengths, relying instead on frame boundaries and plausibility checks. Betaflight Blackbox internals
A recovered time series may therefore contain legitimate gaps. Those gaps should remain visible during analysis. Filling them with smooth interpolation risks inventing an event sequence the logger did not record.
A mislabeled column is harder. It can pass ordinary monotonic-time and boundary checks, leaving the analyst to compare the recorded schema against firmware implementation and known constraints.
Other autopilots show a different approach, but not immunity
PX4 uses the self-describing ULog format. Its current format specification describes message definitions, typed fields, timestamps and explicit dropout messages. That design helps parsers understand the recorded structure and identify missing intervals.
Self-description still depends on the producer emitting the right metadata and values. It does not independently validate whether the underlying sensor was calibrated or whether a message labeled as a particular physical quantity was filled from the correct source.
This is why a comparison of file formats should not be turned into a winner-takes-all judgment. Betaflight Blackbox is optimized for high-rate controller logging on constrained hardware. ULog serves a wider uORB topic model. They encode different design choices, and neither makes sensor or firmware defects impossible.
INAV's recent PRs are a reminder that application-specific implementation details sit between the specification and the file an investigator receives.
Storage faults introduce another evidence boundary
Correct serialization is not enough if the logging device cannot keep up or runs out of writable space.
INAV PR #12056 describes a FAT32 preallocation problem in which a Blackbox free-space file shrank over repeated logs and did not recover space in the expected way, even when the card had free clusters. A related proposal, PR #12060, discusses splitting logs across files when the current file can no longer grow. Its author also describes tests for header data loss under insufficient SD-card buffering.
Those are separate from the field-order bugs. They show another reason to verify that the recorder actually started, continued writing and finalized its output during the flight.
A 32 GB card does not guarantee 32 GB of available log space to a particular embedded filesystem strategy, just as a high declared logging frequency does not guarantee every control-loop sample reached storage.
How to use a log as engineering evidence
Before attributing a flight event to hardware or tuning, an investigation should establish four things.
First, identify the producer. Keep the exact firmware revision, board target, custom build flags, mixer configuration and enabled sensors. A format mismatch can depend on one unusual combination that an ordinary quadcopter never exercises.
Second, verify the transport. Did logging begin at the expected point? Is the file complete? Did the decoder report missing frames, synchronization errors or long gaps? A successful file transfer says nothing about what was recorded before the transfer.
Third, verify the schema. Compare the declared fields with the installed firmware's logging implementation. Pay particular attention when optional sensors, custom mixers, newly supported peripherals or development features are active.
Fourth, corroborate material conclusions. If a decoded column claims motor power disappeared, compare it with the relevant electrical and ESC telemetry if available. If an estimator jump appears, examine sensor inputs and measurement-validity flags rather than using a single plot as a complete causal explanation.
These checks do not guarantee that a log is perfect. They define where confidence comes from and where uncertainty remains.
A successful flight and a credible record are different products
The current INAV contributions have a useful characteristic: the authors describe how to reproduce the format failures, which combinations activate them, and what happens to the decoded output after a proposed change. The pull requests are still development claims. Their existence does not mean fixes have shipped in a stable release, and previously recorded affected files do not automatically become trustworthy after a firmware update.
When a log is used only to help tune a hobby quad, a bad trace may waste an afternoon. When it supports inspection evidence, a product defect investigation or an operational safety case, the same flaw can lead to an incorrect decision.
The threshold should be higher than "the viewer opened it." Trust begins with knowing which firmware wrote the bytes, whether the declared schema matches those bytes, and what the decoder discarded along the way.