Supported log formats

RotorLab's forensics tools read the logs a working fleet actually produces. The autopilot formats: ArduPilot dataflash (.bin), MAVLink telemetry logs (.tlog) and PX4 ULog (.ulg). And the consumer and export formats: DJI flight records (DJIFlightRecord_*.txt), Parrot FreeFlight JSON, GUTMA flight-logging JSON, and flight-log CSV exports from Litchi, Airdata and DJI GO conversions. The format is always detected from the file's own bytes, never from its name, so a renamed or extension-less file still reads correctly. Whatever the format, every log is judged by the same analysis, so two logs of the same flight get the same reasoning applied to them.

Consumer logs carry a fraction of what an autopilot records: no motor outputs, no vibration, no parameters, sometimes battery percent without voltage. RotorLab does not quietly show less. Every crash report lists the checks the log could not support and says whether that is a limit of this file or of the format itself, because "not checked" and "checked and fine" must never look the same in an incident record.

Uploads to the Log Analyzer and Crash Analyzer are limited to 64 MB. If a file is larger, the page tells you the size and the limit before uploading anything.

ArduPilot dataflash (.bin)#

The onboard log written by ArduPilot flight controllers: ArduCopter, ArduPlane, Rover, ArduSub and traditional helicopters. Download it from the flight controller's SD card or through your ground station.

This is the richest of the three formats and the best one to upload after an incident. It carries:

• The autopilot's own crash verdict: crash-check errors, the disarm method (including "disarmed by crash detector"), thrust-loss and vibration failsafes.
• The full parameter set, which is what makes configuration readouts and flight-to-flight parameter comparison possible.
• High-rate attitude with the commanded target, motor outputs, vibration, battery, GPS, and, where the hardware logs them, per-motor ESC temperatures and RPM, multiple IMUs, magnetometers, estimator health, and auxiliary sensors such as rangefinders and optical flow.

The vehicle type is read from the log itself, and mode changes are decoded with the right table for that vehicle, because the same mode number means different things on a copter, a plane and a rover. RotorLab is also careful with unit changes between firmware versions (for example the climb-rate and throttle columns, which changed representation across ArduPilot releases), so old and new logs read consistently. Truncated or partly corrupted files are read as far as possible rather than rejected.

MAVLink telemetry log (.tlog)#

The recording your ground station makes of the radio downlink while it is connected: Mission Planner, QGroundControl and RotorLab GC all write one. It works for both ArduPilot and PX4 aircraft, and it is often the only log you have when the aircraft was lost or the SD card is unreadable.

Expect less from it than from an onboard log, and the analysis says so in its warnings:

• It is a recording of the downlink, so it is sampled slower than the onboard log and can have gaps wherever the radio link dropped.
• ArduPilot's own crash-check records are not transmitted over MAVLink, so the crash verdict rests on status text and flight data instead of the autopilot's ruling.
• The disarm method is not carried over telemetry, so a disarm cannot be attributed to the crash detector.
• If no attitude target was received, attitude is judged on absolute angle only, which is deliberately far more conservative.
• On a VTOL quadplane, hover-phase checks are not applied, because the throttle in the telemetry stream is the plane throttle, not the hover throttle.

PX4 ULog (.ulg)#

The onboard log written by PX4 autopilots. RotorLab decodes every topic from the format definitions carried in the file itself, so PX4 releases that add or reorder fields still read correctly.

Practical notes:

• PX4 has no ArduPilot-style crash detector and logs no crash verdict, so every finding is inferred from the flight data and the autopilot's own status messages. The analysis states this plainly in its warnings.
• Vibration limits are not evaluated, because PX4's vibration metric is a different measurement from the one those thresholds were set for.
• PX4 parameters with true ArduPilot equivalents (hover throttle, PWM range, fixed-wing minimum and stall airspeeds) are mapped so the same checks apply. Anything without a true equivalent is reported as unknown rather than assumed.
• Estimator innovation test ratios, pilot input, compass, GPS quality and battery data are all read, including the unfiltered voltage and current pairs that make the pack internal-resistance fit honest.

DJI flight record (DJIFlightRecord .txt)#

The flight record the DJI apps (GO, GO 4, Fly, Pilot) keep on the phone or controller. Despite the .txt name it is a binary file, and RotorLab reads every generation of it: the aircraft and app that produced it, the aircraft's serial number (matched against your registry automatically), flight modes with DJI's own names, position, attitude, altitude and the app's warning messages.

• Current records are encrypted by DJI; RotorLab decrypts them through DJI's own key service as part of the analysis. Older records read entirely offline.
• On current encrypted records the battery data lives in a record DJI does not publish; the report says battery data is unavailable rather than guessing.

Parrot FreeFlight (.json)#

The JSON flight log FreeFlight keeps for the Anafi family (and the same format back to the Bebop era). Position, altitude, attitude, flight state, alerts and battery percent all read; the aircraft serial matches against your registry. Two honest limits: the format carries battery percent but no voltage, so pack-health checks report no data; and its crash counter is a summary flag with no timestamp, so it is surfaced as a warning rather than invented into the timeline.

Flight-log CSV (Litchi, Airdata, DJI GO conversions)#

One reader covers the CSV dialects DJI-ecosystem pilots actually have: Litchi's flight logs (both its imperial and metric variants), Airdata's CSV export, and the "Standard" CSV conversions of DJI GO records. Units are read from the column headers (altitude(feet) vs altitude(m)), the flight modes on the timeline are the file's own mode names, and Litchi's files carry the flight controller serial and aircraft name into the record. Any other CSV with at least time(millisecond), latitude and longitude columns reads as a generic flight log; a CSV missing those is refused by naming exactly what is missing.

GUTMA flight log (.json)#

The GUTMA flight-logging exchange format. Position, speed and pack voltage read, and it is the one format that declares its own altitude datum and units, which the report carries through. GUTMA names the airframe but not its class, so the vehicle is reported as unknown and multirotor-specific checks stand down rather than judge a fixed wing by hover rules.

Autel#

Autel Explorer flight records are recognized and named when uploaded, and their format is documented in RotorLab's engineering notes — but no sample file has been available to verify a reader against, so they do not read yet. If you fly Autel and can share a flight record, that is the missing piece.

Related#

• Log Analyzer
• Crash Analyzer
• Compare