ArduPilot .bin vs .tlog vs PX4 .ulg — Which Log Format Do You Have?

TL;DR: ArduPilot and PX4 produce three log formats with distinct strengths. .bin is ArduPilot’s DataFlash log, written to the onboard SD card at the autopilot’s native rate — highest fidelity, biggest files. .tlog is the MAVLink telemetry log captured by the GCS over the radio link — lower fidelity, smaller, useful when the SD card log is missing. .ulg is PX4’s ULog format, written onboard at PX4’s native rate — fully self-describing schema, high fidelity. For forensic analysis prefer .bin on ArduPilot or .ulg on PX4; fall back to .tlog only when the onboard log isn’t available.

The three formats in one paragraph

.bin is ArduPilot DataFlash: a compact binary format written directly to the autopilot’s SD card during every flight. .tlog is MAVLink telemetry: whatever messages the autopilot transmitted live over the radio, captured by the ground station that received them. .ulg is PX4 ULog: a self-describing binary written to the PX4 autopilot’s SD card with full schema embedded in the file. All three are produced automatically; you just need to know which one you have.

What each format actually contains

.bin (ArduPilot DataFlash)

• Written by ArduPilot directly to the onboard SD card during flight.
• Compact binary format with field schema defined per-message in a fixed dictionary.
• Rate is configurable via LOG_BACKEND_TYPE and LOG_BITMASK; defaults give you 25-50 Hz for IMU and 10 Hz for most other messages.
• Contains everything: ATT, RATE, GPS, BARO, BAT, RCIN, RCOU, VIBE, ERR, MSG, all the EKF messages (XKF1-5, NKF1-5), all the parameters at takeoff.
• File extension can be .bin or .log — same format, different names.

.tlog (MAVLink telemetry)

• Captured by the ground station as MAVLink messages arrive over the radio link.
• Only contains messages the autopilot was streaming — bandwidth-limited by the radio.
• Rate per message is set by the autopilot’s SRn_* parameter family.
• Useful when the onboard SD card log is missing or corrupted, or for telemetry-link diagnostics.
• Not a substitute for .bin for deep forensics — many messages won’t be present at high enough rate.

.ulg (PX4 ULog)

• Written by PX4 directly to the autopilot’s SD card during every flight.
• Self-describing binary — the file carries its own field schema, so parsers don’t need an external dictionary.
• Default rate is set by SDLOG_PROFILE; covers vehicle_status, estimator_status, sensor_combined, actuator_outputs, battery_status, etc.
• Comparable forensic depth to ArduPilot .bin — the same kind of information, different message names.

Where each format comes from

• .bin — Download from the autopilot’s SD card after the flight. Mission Planner: Flight Data → DataFlash Logs → Download via MAVLink, or pop the SD card.
• .tlog — Created automatically by Mission Planner (and most GCS software) during connected flights. Saved to the Mission Planner logs folder.
• .ulg — Download from the PX4 autopilot’s SD card after flight, or via QGC. PX4 always writes a fresh file per arming.

Which format for which problem

Crash forensics

Use .bin for ArduPilot, .ulg for PX4. The onboard log has the highest rate and the most messages, including the ERR and MSG sequence that tells you exactly what the firmware did. Fall back to .tlog only if the SD card log isn’t available — you’ll lose detail.

Tuning verification

.bin or .ulg. Rate-loop tracking analysis needs RATE/vehicle_rates_setpoint at the highest available rate, which the telemetry log usually can’t deliver.

Telemetry-link diagnostics

.tlog is the right format here — it captures exactly what arrived over the radio, including dropouts, RSSI variation, and message-rate degradation. The .bin won’t show telemetry-link problems because the onboard log was written regardless.

Long-term archival

For DGCA 7-year retention or insurance archival, retain the .bin or .ulg. The .tlog alone doesn’t carry enough fidelity for an audit if the question is about flight performance details.

Common confusions

• “The .tlog should be a complete record.” No — it’s a record of what the radio link delivered, which can be a fraction of what the autopilot wrote.
• “The .bin and .log are different formats.” No — they’re the same DataFlash format with different extensions. Some autopilots produce .log, some produce .bin, depending on storage backend.
• “PX4 logs are .px4 files.” No — PX4 logs are .ulg. The .px4 extension is for parameter files, not flight logs.
• “A bigger .bin file means a longer flight.” Not necessarily — logging bitmask, rate, and IMU sampling all affect file size at constant flight duration. A 20-minute hover at default logging is usually 20-40 MB.

Which one to upload to LogHat

LogHat accepts all three (plus .log as a DataFlash variant). The analysis depth depends on what’s in the file:

• If you have .bin or .log (ArduPilot operator) — upload this. Full forensic depth.
• If you have .ulg (PX4 operator) — upload this. Same forensic depth on the PX4 side.
• If you have only .tlog — upload it; you’ll get useful analysis but some fields the deeper analysis depends on (high-rate EKF state, raw IMU) won’t be present.
• If you have all three from the same flight — upload the .bin or .ulg. The telemetry log adds little when the onboard log is available.

When LogHat helps — and when it doesn’t

LogHat reads all three formats through a normalising pipeline so the downstream analysis runs identical logic. What we don’t do is reconstruct a missing log — if your SD card failed and only the telemetry log survived, the analysis depth is limited by the telemetry log’s coverage. For mission-critical operations, retain both the onboard log and the GCS’s telemetry log redundantly so you have a fallback.