When an FAA safety inspector or Aviation Safety Inspector (ASI) requests flight records for a Part 107 commercial UAS operation, they are looking for a specific set of information. They want to know the date and time of each operation, the location, the aircraft used and its registration, the remote pilot in command and their certificate number, the maximum altitude reached, and whether any waivers or authorizations applied. This is not a complicated list. The problem is that a DJI flight log contains all of this information encoded in a format that looks nothing like what the auditor asked for.
This post covers the field-level mapping between DJI log formats and FAA audit requirements, the transformations required to close the gap, and where the mapping is clean versus where it requires supplemental data from outside the log file.
What the FAA Actually Asks For
Part 107 does not specify a required format for flight records. The regulation at 14 CFR 107.49 requires that certain information be available, but the mechanism for capturing and retaining it is left to the operator. In practice, an FAA audit of a commercial Part 107 operation typically focuses on the following fields:
- Date and time of each UAS operation (takeoff and landing times preferred)
- Location of the operation, expressed as address, coordinates, or operational area description
- FAA registration number of the aircraft operated
- Remote pilot certificate number of the person who served as RPIC
- Maximum altitude above ground level during the operation
- Any waivers, airspace authorizations, or exemptions that applied
- Any incidents, accidents, or near-miss events during the operation
An audit involving a specific incident or accident will go deeper: the actual GPS track of the flight, the altitude profile, weather conditions at the time, and potentially the aircraft's systems data if an anomaly is under investigation. But the baseline documentation review focuses on the list above.
DJI DAT Files: Where the Data Lives
A DJI DAT file is a binary log recorded by the aircraft's flight controller. For most commercial DJI aircraft (M300, M30, Mavic 3 Enterprise series, older Phantom 4 Pro), the DAT file is the most complete flight record available, capturing telemetry at 10 Hz or higher. The fields present in a DAT file include GPS coordinates, altitude (barometric and sometimes GPS-derived), airspeed, ground speed, motor telemetry, battery state, gimbal position, RC input data, and numerous system status flags.
The FAA fields map to DAT data as follows:
Date and time: The DAT file records UTC timestamps for every data record. The session start timestamp is the takeoff time. The session end timestamp is the landing time. The raw timestamp format is a Unix millisecond epoch value, which needs to be converted to a human-readable UTC date and time string. This conversion is clean and lossless.
Location: GPS coordinates in WGS84 decimal degrees are present throughout the DAT file. The representative location for audit purposes is typically the takeoff point, since that defines where the operation was based. The GPS track provides the full operational area. The conversion to a human-readable location description (city and state, or address, or named operational area) requires a reverse geocoding step against the takeoff coordinates, because the DAT file stores only the raw coordinates.
Aircraft identification: The FAA registration number is not stored in the DAT file. The DAT file contains the aircraft serial number, which is the manufacturer's identifier. The mapping from serial number to FAA registration number must come from the operator's registration records. This is a join operation, not an extraction: the log data provides the serial number, and the registration database provides the N-number or small UAS registration number associated with that serial. If an operator has not maintained the serial-to-registration mapping in their records, this field cannot be derived from the log alone.
Pilot identity: The remote pilot's certificate number is not present in the DAT file at all. The DAT records RC (remote controller) serial number and other operator-side identifiers, but it does not record who was flying. Pilot assignment is either entered manually at the time of the flight or is associated with the log record through an operational system that links the aircraft to the assigned pilot for a given mission date and time. An operator who tracks this only in a manual logbook has a gap between the log data and the audit requirement.
Maximum altitude: The DAT file records barometric altitude above the takeoff point throughout the flight. The maximum value of this field over the session duration gives the maximum altitude above the launch elevation. Converting to altitude above ground level requires knowing the terrain elevation at the takeoff point (and, for flights over terrain with significant variation, a terrain model for the full operational area). The conversion from barometric AGL to true AGL is important because the FAA's 400-foot ceiling in 14 CFR 107.51 is measured above ground level, not above the takeoff point if those two differ.
SRT Files: A Narrower Record
SRT files are subtitle-format logs exported from DJI apps like DJI GO 4 and early versions of DJI Fly. They contain a subset of the DAT data: GPS coordinates, altitude, horizontal and vertical speed, and gimbal pitch angle, recorded at one-second intervals. SRT files are text-readable, which makes them more accessible than DAT files for manual inspection, but they contain less information than DAT files and are not the preferred source for detailed audit documentation.
For the FAA audit field list, an SRT file can provide timestamp, location, and altitude. It cannot provide motor data, battery state, or other system telemetry. For a routine audit, the SRT-derived fields may be sufficient. For an incident investigation, the DAT file is required because it contains the system-level data that shows what the aircraft was doing at the moment of the event.
CSV Exports: The Least Reliable Source
DJI FlightHub and DJI Pilot 2 can export flight records in CSV format. These exports are convenient but carry important caveats for compliance purposes. The CSV export is a processed representation of the underlying log data, and the processing choices made by the DJI export tool affect what is present and at what fidelity. Altitude values in some CSV exports are rounded to one meter resolution from the higher-precision values in the DAT file. Timestamp resolution may be reduced from milliseconds to whole seconds.
More significantly, CSV exports from FlightHub include a flight ID and summary fields (duration, distance, max altitude) but may not include the full per-second telemetry needed to reconstruct the altitude profile for a specific event during the flight. For a routine documentation request, a FlightHub CSV export may satisfy the audit fields. For an investigation into a specific altitude exceedance or airspace incursion, the CSV is unlikely to be sufficient.
Fields That Require Supplemental Data
Three audit fields reliably require supplemental data that is not present in any DJI log format:
Pilot certificate number: Must come from a pilot assignment record linking the flight to the RPIC. This is an operational recordkeeping function, not something the aircraft captures.
Waivers and authorizations: LAANC authorization numbers, COA reference numbers, and Part 107 waiver documentation exist in the FAA's DroneZone system and in the operator's correspondence with the FAA. They are not in the log file. The audit record needs to associate these with the relevant flights by date, time, and location.
FAA registration number: Comes from the operator's registration records mapped to the aircraft serial number. Not in the log.
These fields are not hard to supply if the underlying records exist and are organized. The failure mode is when they are not associated with the flight records at all, or when they exist in a separate system with no linkage to the log archive. An auditor who asks for the flight record for a specific operation on a specific date should be able to receive a single document that answers all the required fields, not a collection of separate files that the operator has to manually correlate.
The parsing work is the smaller problem. The harder problem is ensuring that supplemental fields are collected and associated with the correct flight records at the time of the operation, rather than being reconstructed under pressure after an audit request arrives.