RotorLabEvery flight-log reader and every diagnostic in RotorLab was run against a corpus of real public flight logs and a farm of scripted simulator flights with known faults. This page shows what came out. Every number here is written by the validation run itself, dated, with its denominator, and with the limits stated.
Detection is whether the reader identified the format from the bytes alone; parsed is whether the analysis completed; sane is whether the flight it read passes physical checks (duration, time order, pack voltage in range, current in range, armed time within the flight). Research telemetry files in formats we do not claim were kept as negative controls: the reader must refuse them cleanly rather than read them into nonsense.
| Format | Files | Detected | Parsed | Physically sane | Checks with data | Flight hours |
|---|
"Checks with data" is the share of crash-layer and diagnostic checks that had the records they read in that format. A telemetry log never carries the rate controller; a consumer app log never carries motor outputs. The share says what a format can support, not whether anything was wrong.
PX4 Flight Review publishes, for each public log, the flight's duration and vehicle type as the uploader's tooling recorded them. Those are an independent answer key: the reader's duration, vehicle family, firmware release and identified airframe were compared with it, log by log.
Vehicle family compares the catalog's type to what the reader inferred from the log; VTOL types count as agreeing with multirotor or fixed wing because PX4 reports whichever mode was active. Airframe agreement is stricter: a tiltrotor must come back as a tiltrotor. Catalog types that do not describe an airframe (rockets, submarines, balloons, "generic") are excluded from that comparison.
Each diagnostic reads specific records. This table is the share of logs, by family, on which the check had its data and ran. It is the honest map of what a given log can support.
| Check |
|---|
Real logs prove a reader reads. They cannot prove a diagnostic catches a fault, because nobody labels their crash logs. So a farm of simulator flights was scripted across the airframes RotorLab names, ArduPilot SITL and PX4 simulation-in-hardware, each with a labeled fault or none: vibration, accelerometer clipping, compass interference, GPS glitch and loss, estimator upsets, IMU disagreement, a motor lost in flight, a pitot failure, a stick-in-corner departure. The check has to fire on the fault and stay quiet on the clean flight. Simulated flights prove the logic; they do not stand in for real air, and the page says which results come from which.
| Diagnostic | Faults planted | Caught | Recall | Clean flights | False alarms |
|---|
A log filed against a flight in Fleet Manager goes through the same reader and then onto the aircraft's record. Every claimed-format file was pushed through that path and the flight record was compared with the analyzer's own reading of the same bytes.
| Format | Files | Accepted | Analyzed (under the size gate) | Above the gate, stored | Duration agrees with the analyzer |
|---|
The corpus is public flight data, held outside the product and never redistributed. Each file was analyzed independently under a time limit and scored for format detection, completion, physical sanity, diagnostic coverage and, for PX4, agreement with the catalog. The fleet leg filed each file against a flight in a test organization and compared the stored record with the analyzer's own reading. Each simulator flight is scripted with its fault applied at a set time and its expected outcome recorded beside the log; the analysis is then scored against that record.
.DAT files are recognized and refused; they are not a claimed format.Every percentage on this page is over the files, logs or flights named beside it. "Read" means the analysis completed; "physically sane" means what it read passes physical checks; a coverage share says what a log can support, not whether anything was wrong. Each run feeds the next release, and the next run measures it; the release notes carry that history.
The physics behind the Builder has its own page: How we validate. Questions about this page or the method: contact us.
Flight physics, fleet operations and what shipped — written for people who fly. No spam, unsubscribe in one click.