DJI aircraft generate flight log data in at least three distinct formats, and a given operation may accumulate all three depending on which aircraft model, which firmware version, and which ground station application the operator uses. Each format was designed for a different purpose and captures a different slice of flight data. For compliance documentation, understanding what each format contains and where its data is trustworthy matters considerably.
This is a technical breakdown of the three primary formats: SRT subtitle files, DAT binary logs, and CSV exports. It covers structure, field contents, firmware and model dependencies, and what each format is and is not reliable for in a compliance context.
SRT: The Subtitle Telemetry File
SRT files are generated by DJI cameras and gimbal controllers during video recording. The SRT format is borrowed directly from the SubRip subtitle standard: timestamped text blocks that were originally designed to overlay text onto video playback. DJI uses this format to embed telemetry data as subtitle tracks in the video recording session.
A typical DJI SRT file contains blocks like this:
1
00:00:01,000 --> 00:00:02,000
[iso : 100] [shutter : 1/2000] [fnum : 2.8] [ev : 0] [ct : 5400] [color_md : default]
[focal_len : 24] [latitude: 34.052235] [longitude: -118.243683] [rel_alt: 45.30 abs_alt: 87.50]The fields present in an SRT file vary by aircraft model and firmware version. Older DJI Phantom 4 and Mavic 2 SRT logs typically include latitude, longitude, absolute altitude, relative altitude, barometric altitude, and some camera parameters. Mavic 3 and Matrice 300 SRT logs add additional fields including GPS signal strength, satellite count, and in some firmware versions, aircraft serial number as a header field.
SRT files are created on the SD card by the camera module during recording. They are only generated when a video recording is active. A flight with photos only, or a flight where the camera was not recording continuously, may produce incomplete or missing SRT coverage. This is the main limitation of SRT as a compliance data source: it depends on camera operation, not flight operation.
For compliance purposes, SRT is useful for location data and flight time within a recording session, but it is not the primary source for aircraft serial number or total flight duration. Aircraft serial number must be confirmed from a separate source (DAT or fleet register), and flight duration should be calculated from the log's actual takeoff and landing times rather than inferred from SRT recording duration.
DAT: The Binary Flight Record
DAT files are the most information-dense DJI log format. They are binary logs written to the aircraft's internal flight controller storage, not the removable SD card. To access DAT logs, you connect the aircraft to a computer running DJI Assistant 2 and export them from the flight controller. This is a different workflow from pulling SD card contents, which is why many operators have SRT and CSV logs from every flight but have never pulled a DAT log.
DAT logs record data at a high sample rate, typically 10 Hz for flight controller state data, and capture far more fields than the other formats. The core fields include:
- Aircraft serial number (from the flight controller)
- GPS coordinates at high temporal resolution
- Barometric altitude and GPS altitude
- IMU data: accelerometer and gyroscope readings on three axes
- Motor RPM and motor temperature per motor (on supported aircraft)
- Battery voltage, current draw, and cell voltage per cell
- RC signal strength and channel values
- Compass heading, magnetic field readings
- Firmware version and flight controller version
- Takeoff and landing events with precise timestamps
The DAT format is binary and undocumented officially by DJI. The community-maintained parsing tools (most notably the work behind tools like Airdata and the open-source DAT parsing libraries) have reverse-engineered the format for many aircraft models, but coverage is not complete. Matrice 300 DAT logs decode well with current tools. Older Phantom 4 Pro DAT files have some field coverage gaps. Aircraft released in the last 12 months may have DAT format variations that are not yet fully decoded.
For compliance documentation, DAT logs are the most authoritative source for aircraft serial number, precise flight duration, and the motor and battery data that drives maintenance tracking. If your operation pulls DAT logs regularly using DJI Assistant, you have access to the richest data set available. If you are relying only on SD card contents, you are missing the most mechanically important telemetry.
CSV: The Processed Export Format
CSV files in the DJI ecosystem come from two sources: DJI FlightHub or DJI Pilot 2, and third-party flight planning applications that export post-mission data in CSV format.
FlightHub CSV exports are a processed representation of flight data. FlightHub receives telemetry from the DJI RC during flight and stores it server-side, then makes it available for export. The CSV columns typically include timestamp, latitude, longitude, altitude (relative and absolute), speed, heading, battery level, and distance from home point. Aircraft serial number is usually available as a flight metadata field when exporting through the FlightHub interface, though not always present in the CSV itself depending on export settings.
The important distinction with FlightHub CSV is that the data in it is the telemetry that was successfully transmitted to FlightHub during the flight over the data link. In areas with poor connectivity, or during any period where the RC-to-device link was interrupted, there will be gaps in the FlightHub record. The FlightHub CSV is a cloud-synchronized data stream, not a complete onboard record. This makes it less reliable than DAT for scenarios where the complete flight trace is needed.
Third-party CSV exports (from applications like DroneDeploy, Pix4D Capture, or similar) vary in what fields they include. Most include date, time, GPS track, and aircraft identifier. Whether they include battery data, motor status, or altitude references varies by application. For compliance documentation, these exports are useful for mission context but usually insufficient as the sole flight record.
Format Selection for Compliance Documentation
Given the three formats, the question for compliance documentation is which data to pull from each. Our approach at NVdrones is to treat the formats in a priority order based on what each does reliably.
Aircraft serial number: DAT, then FlightHub metadata, then SRT header fields where present. We do not infer serial numbers from model identification alone.
Flight date and time: DAT takeoff/landing events, then FlightHub session records, then SRT recording window with a caveat that SRT may not capture the full flight duration.
GPS track and location: All three formats provide this, but DAT at the highest resolution. For location documentation that just needs a takeoff and landing coordinate, SRT or FlightHub CSV is sufficient.
Maintenance-relevant telemetry (motor temperature, battery cell voltage, IMU): DAT only. This data is not present in SRT or standard FlightHub CSV exports.
When a fleet operation provides only SRT or CSV files, we can produce location and time-based compliance documentation, but maintenance signal data is not available without DAT. We flag this gap in the generated reports rather than silently omitting the data without explanation. An operator who knows their DAT logs exist but has not been pulling them can take action. An operator who is told their documentation is complete when it is not is worse off.
Format Version Drift and Firmware Sensitivity
One practical problem with DJI log parsing at scale is that format structure is not stable across firmware versions. DJI updates aircraft firmware regularly, and field layouts in both SRT and DAT logs have changed across major firmware releases. The Mavic 3 Enterprise SRT format differs meaningfully from the Mavic 2 Enterprise SRT format, for instance, and the difference is not just field names. Some fields moved positions in the structured text blocks; some were added or removed.
For a compliance system parsing logs from a mixed fleet with aircraft that received different firmware update timings, robust format detection is a requirement, not an optional feature. We detect format version per log file before attempting field extraction, which handles cases where an operator has some aircraft on older firmware and some on current. Operators should be aware that a parsing tool or script that works well on their current aircraft may produce incorrect output for older log files from the same fleet.