Measured against real flights
RotorLab's flight-log readers and diagnostics were run against thousands of real public flight logs and a farm of scripted simulator flights with planted faults. Every figure on this page is written by the validation run itself, dated, with its denominator.
What was measured, and how
Three legs, each with its own answer key, each scored by the run and not by hand.
- Real public logs, one file at a time. Each file was analyzed on its own under a time limit and scored for format detection, completion, physical sanity and which checks had their data.
- An answer key we did not write. PX4 Flight Review publishes each log's duration and vehicle type; the reader's own reading was compared with it, log by log.
- Faults we planted ourselves. Scripted simulator flights carry a labeled fault or none, so a check is scored on firing when it should and staying quiet when it should.
How the PX4 catalog comparison works
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 left out of that comparison rather than counted either way.
Every claimed format, file by file
Detected, read, physically sane, and the share of checks that had their data, for every format RotorLab claims. The last two rows are files it is meant to refuse.
| Format | Files | Detected | Parsed | Physically sane | Checks with data | Flight hours |
|---|
What each column means
Detection is whether the reader identified the format from the bytes alone. Parsed is whether the analysis completed. Physically 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.
"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.
Research telemetry files in formats RotorLab does not claim were kept as negative controls: the reader must refuse them cleanly rather than read them into nonsense. Refusing them on purpose is part of the proof.
Which checks answer, on which kind of log
Each diagnostic reads specific records. This table is the share of logs, by family, on which the check had its data and ran: the map of what a given log can support.
| Check |
|---|
Scripted flights with planted faults
Real logs prove a reader reads. They cannot prove a diagnostic catches a fault, because nobody labels their crash logs. So each simulator flight carries a fault we planted, or none, and the check is scored on both.
| Diagnostic | Faults planted | Caught | Recall | Clean flights | False alarms |
|---|
The airframes, the crash verdict and what is not scored
The farm runs across the airframes RotorLab names, on ArduPilot SITL and PX4 simulation-in-hardware, each flight scripted with its fault applied at a set time and its expected outcome recorded beside the log. The faults: 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.
Airframe families identified from the log
Reading the table
The crash verdict
Simulated flights prove that a check fires on a known fault and stays quiet on a clean one. They are not real air, and the page says which results come from which.
The same files through Fleet Manager
A log filed against a flight goes through the same reader and then onto the aircraft's record. Every claimed-format file was pushed through that path and the record was compared with the analyzer's own reading of the same bytes.
Format by format: accepted, analyzed, and duration agreement
Accepted is the share of files Fleet Manager took; analyzed is the share read at filing time, under the size gate. A file above the gate is stored with the flight and counted in its own column. Duration agrees is the share of compared files whose stored flight duration equals the analyzer's reading of the same bytes.
| Format | Files | Accepted | Analyzed (under the size gate) | Above the gate, stored | Duration agrees with the analyzer |
|---|
How to reproduce it
Public flight data, held outside the product and never redistributed: the run, the sources and the refusals, for the evaluator who checks the method before the numbers.
Dated, not typed
Negative controls
A page of its own
The Builder's equations are re-run in your browser against worked examples at How we validate. Questions about the method: contact us.
The sources
What this run does not show
- Autel: no public Autel Explorer log exists anywhere we could find, so only detection of that format is validated.
- DJI onboard
.DATfiles are recognized and refused; they are not a claimed format. - Encrypted DJI flight records (format 13 and later) are read with DJI's decryption key. The run behind this page had no key, so those records are left out of the DJI rows rather than counted either way.
- The harmonic-notch check needs ESC shaft speed, which the simulator's telemetry does not carry, so it has data only on real logs.
- Battery sag is not scored on the simulator, because the simulator's pack does not sag under load.
- Catalog types are uploader-declared. Where the catalog's own label does not describe an airframe, that log is left out of the airframe comparison rather than counted either way.
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.
See it on your own logs.
Read one free, or talk to us about measuring your fleet's formats.
