A DJI M300 RTK DAT file from a two-hour transmission line inspection contains somewhere between 400,000 and 700,000 data rows, depending on logging interval settings. That file is a complete record of the flight at the sensor level: GPS coordinates at 10 Hz, IMU readings, motor telemetry, battery state, gimbal position, and dozens of other fields, depending on firmware version and payload. It is also completely unreadable to an FAA auditor in its raw form.
The gap between raw telemetry and an audit-ready document is a data transformation problem, not a storage problem. This post describes the technical steps involved in closing that gap, from identifying what format a given log file uses through extracting the right fields to assembling a structured compliance record. This is how we approach it at NVdrones, and it is a representative picture of what any log processing pipeline needs to handle.
Step 1: Format Detection
DJI aircraft do not produce a single log format. The format depends on the aircraft model, the app used to fly it, and the firmware version at the time of the flight. A Mavic 3 Enterprise flown through DJI Pilot 2 produces a DAT binary file plus a CSV export if the operator chooses to export from FlightHub. A Phantom 4 Pro flown through the DJI GO 4 app produces a TXT file. The same Phantom 4 Pro with DJI Assistant 2 connected produces a DAT file with different field offsets than later aircraft models.
Format detection at ingestion time is therefore not optional. The processing pipeline has to identify the file type from its structure before attempting any field extraction. For DAT files, this means reading the file header to identify the version byte (DJI has used at least four distinct DAT format versions across production aircraft since 2017). For SRT files, the structure is plain text with a specific frame number and timestamp pattern. For CSV exports, the column headers identify the app source.
Getting this wrong means the field offsets are applied to the wrong byte positions in a DAT file, or the wrong column names are mapped from a CSV. The result is corrupted data that looks valid but is not. This is one reason we do not accept user-supplied format hints. The file must be self-describing at the parser level.
Step 2: Session Segmentation
A DAT file from DJI aircraft typically contains multiple flights if the operator flew more than one battery on a given day without clearing the log. Each power cycle creates a new session segment within the file. Audit records are per-flight, not per-day, so the processing pipeline has to segment the continuous log into individual flight sessions before applying field extraction.
Session boundaries are detected from motor arm and disarm events, which are present in DAT files as state transitions in the flight controller record. In SRT files, session boundaries are identified from timestamp continuity: a gap larger than a threshold value (typically 30 seconds) between consecutive subtitle frames indicates a new session. In CSV exports, the flight ID column serves as the segmentation key where present.
For the compliance use case, each segmented session becomes its own audit record. The session receives a start timestamp, an end timestamp, a derived duration, and a bounding box or track geometry derived from the GPS points within that session.
Step 3: Field Extraction and Normalization
The fields that matter for a Part 107 audit record are a defined subset of the total telemetry available. An auditor reviewing a commercial operation under 14 CFR Part 107 is looking for: the date and time of operation, the location (coordinates or operational area), the Remote ID broadcast serial number, the registered N-number or serial of the aircraft, the pilot certificate number, the maximum altitude above ground level, and whether any waivers applied to the operation.
From a DJI DAT file, most of these are present but named differently than an auditor would expect. The GPS fields provide position in WGS84 decimal degrees. The altitude field is barometric altitude above takeoff elevation, not above mean sea level and not above ground level. Converting to AGL requires knowing the takeoff point elevation, which comes from a digital elevation model lookup against the takeoff coordinates. This conversion is not optional for operations near terrain variation.
The Remote ID broadcast serial number is handled separately. DJI aircraft with Remote ID compliance enabled broadcast a Session ID or a FAA-registered UAS ID during flight, but this identifier is not always embedded in the DAT file itself. It comes from the Remote ID module registration record, which needs to be associated with the airframe record in the system rather than re-extracted from each flight.
Field normalization means bringing all of these extracted values into a consistent schema regardless of which aircraft or app produced the source file. The schema we use maps to the fields an auditor would expect in a Part 107 operation record, with units and formats standardized: UTC timestamps, decimal degrees coordinates, AGL altitude in feet (the unit the FAA uses), and certificate numbers in their standard format.
Step 4: Validation and Gap Flagging
Once fields are extracted and normalized, the pipeline checks for gaps and anomalies that would affect the usefulness of the record. Common issues include: GPS signal loss segments during the flight (which produce gaps in the position track), battery swap events that split what the operator intends as one mission into two session segments, and flights where altitude data is implausibly flat (suggesting the barometric sensor had a known issue or the aircraft was in a mode that suppresses altitude logging).
We do not discard records with gaps. An audit record with a flagged GPS gap is still a record. It is better to present an annotated incomplete record than to silently omit a flight from the compliance archive. The flag tells the operator that the record exists but that one field is partially unavailable, which is an actionable statement: the operator can supplement with their own mission notes or with data from a secondary source such as a site survey log.
Step 5: Report Assembly
The final step is assembling the structured data into a format that can be presented to an auditor. This is not a question of making things look nice. It is a question of making the data findable and verifiable. An auditor asking for all flights from a specific aircraft within a date range needs to be able to retrieve that record set in a form they can review. An auditor asking for proof that a specific flight operated below 400 feet AGL needs to be able to see the altitude track for that flight with the datum clearly stated.
NVdrones produces reports as structured PDF and CSV exports. The PDF format is designed around the fields an auditor typically requests: one page per flight session, with the key compliance fields visible at the top and the GPS track and altitude profile available for reference. The CSV export is for cases where the auditor has their own review tooling and needs the raw structured data rather than a formatted document.
The chain from DAT ingestion to report export is fully traceable: each report record includes the source file hash, the session segment identifier, and the extraction timestamp. If a question arises about how a field value was derived, the chain can be followed back to the source byte range in the original file. This traceability is what makes the record defensible, not just presentable.
What the Pipeline Does Not Cover
To be clear about scope: this pipeline produces a record of what happened during a flight. It does not determine whether the operation was legally authorized. Whether the operation had a current Part 107 waiver for night operations, whether the airspace authorization through LAANC was obtained before flight, whether the pilot certificate was current on the day of the flight: those are facts that exist outside the flight log. The pipeline can structure them and present them alongside the telemetry-derived record if the operator enters them, but it cannot derive them from the log data itself.
A complete audit package requires both sides: the telemetry-derived record from the log file, and the operator-entered authorization and certificate data. The processing pipeline handles the first side reliably and at scale. The second side depends on the operator having that documentation in a form that can be associated with each flight record.