DJI flight log recovery is not about getting video back. It is about getting the record of what the aircraft was doing, where it was, and when it stopped — data that is stored in a completely different place from the footage and often survives when the aircraft itself does not. A drone that is at the bottom of a lake still has a flight log sitting on the controller or phone that launched it.
That makes logs the only practical evidence in a large share of incident cases. They are also the fastest way to answer the question every client asks after a failed shoot: was the missing footage ever recorded at all? This page covers where logs live, how to export them, what the fields mean, and where their usefulness ends.
What a Flight Log Actually Records
A flight log is a time series. Once per sample interval — typically a fraction of a second — the aircraft or the app appends a row of telemetry to an ongoing record. Across a normal flight that adds up to thousands of rows, each one stamped with a position, an altitude, a battery condition, and a flight mode.
The fields that matter most in a recovery or incident context are:
- Timestamp, usually in UTC or in the device’s local time depending on where the log was written.
- GPS position and altitude, which give you a search area if the aircraft is missing.
- Battery voltage, current, and remaining percentage, which reveal whether power was cut deliberately or lost involuntarily.
- Satellite count and GPS signal quality, which determine how much weight the position data deserves.
- Flight mode and stick inputs, which distinguish controlled flight from a failsafe event, an obstacle avoidance trigger, or a loss-of-signal return.
- Event flags, which is where recording state changes appear — camera start, camera stop, storage errors, and mode changes.
- Aircraft and payload identifiers, which matter when a client or an insurer wants to confirm which aircraft flew the mission.
The most valuable field in a failed-recording investigation is the camera state flag and its timestamp. If the log shows the camera recording at the last telemetry sample, the footage exists on the storage medium even if the file is missing from the directory listing. That justifies a deeper scan than the file system alone would suggest.
Where the Logs Live, and Why That Matters
Logs are fragmented across multiple locations, and the one people reach for first — the aircraft — is usually the one that is gone.
| Location | Written by | Survives what | Typical format |
|---|---|---|---|
| Mobile device running the flight app | The app, during the flight | Loss of the aircraft; almost everything except losing the phone | Text or encrypted records handled by the app’s own viewer |
| Remote controller | The controller’s internal storage | Loss of the aircraft, if the controller was recovered | Controller-specific records |
| Aircraft onboard storage | The flight controller | Only if the aircraft is recovered and boots | Proprietary binary records |
| Cloud account linked to the app | Automatic upload after flight | Loss of device and aircraft, if sync completed | Server-side records exported from the account |
The consequence is worth stating plainly: the copy on your phone is more valuable than the copy on the aircraft, because the phone is the one you still have after a crash, a flyaway, or a water landing. Pilots who clear their flight app’s data to free up storage, or who switch phones without syncing, routinely destroy the only surviving record of a mission.
Two timing details cause most of the confusion. First, logs are often uploaded only when the device has network access, so a flight in a remote area may sit unsynced for days. Second, the aircraft clock and the phone clock are separate. If the aircraft was never synchronized, its timestamps can be off by minutes or hours, so the time in the log will not match the modified time on the video files on the card.
Aircraft-side records are more complete: they sample at a higher rate and include internal state the app never receives. Getting them requires the aircraft to boot, which is why the DJI internal storage recovery process treats a booting aircraft as an asset to preserve rather than a device to take apart.
Exporting Logs Without Damaging Anything Else
The export procedure is straightforward, and the risks come from what people do alongside it.
- Deal with the footage before you connect anything. Connecting is generally read-only for logs, but every operation on a damaged aircraft is a chance to lose the storage it still holds.
- Export from the app first. It is the safest source and the only one guaranteed to be available after an aircraft loss.
- Use the manufacturer’s own viewer or export function rather than opening the raw record in a text editor. Many logs are structured binary or encrypted, and a text editor will show noise.
- Save exports to two locations before you begin analyzing them.
- Record the export time, app version, and device model alongside the files. If the log will support a warranty claim or a client dispute, provenance matters as much as content.
The mechanics differ slightly between aircraft generations and between the mobile and controller copies; the step-by-step version is in the guide to extracting DJI flight logs.
A counter-intuitive detail: exporting the log does not touch the video files, and it does not risk the card. The two data streams are stored independently, which is precisely why logs are so useful as corroboration. Analysis of the log can proceed in parallel with a card recovery attempt, and the two results can then be cross-checked against each other.
Reading the Log: Five Questions It Can Answer
Did the recording ever start? The camera state flag at the beginning of the flight settles this. A client who insists the whole mission was filmed may be working from a mistaken assumption about which button was pressed.
When exactly did it stop? The last sample in which the camera was recording, plus the first in which it was not, brackets the interruption to within one sampling interval. That timestamp tells you which file on the card is the damaged one.
Was it a planned stop or a failure? A recording that stops while voltage is nominal and the aircraft is hovering is a manual stop or a storage error. One that stops as voltage collapses is a power event — the mechanism covered in battery voltage sag cutting recording.
Where was the aircraft when it stopped? This field recovers hardware. The last known coordinates narrow a search grid, and the final altitude tells you whether to look on the ground or in a tree.
Was the storage already failing? Repeated write errors, dropped frames, or storage warnings earlier in the same flight suggest the media was degrading, not that the crash caused the loss. That distinction changes what a repair attempt should target.
Once you know the interruption timestamp, the media-side work is the interrupted recording recovery procedure: identify the unfinished file, keep the intact chapters beside it as a structural reference, and rebuild the index.
Why Logs Matter as Evidence
Flight logs carry weight in three situations, and in all three the log is doing something the footage cannot.
Recovering the aircraft. Last position, altitude, and flight mode are the difference between a search and a guess. For a flyaway or a signal-loss event, the log is the only source describing the aircraft’s behavior after the link dropped. The finding a lost drone’s card guidance picks up from there, because the media often survives the aircraft.
Settling a client conversation. A commercial client disputing a missing segment is best answered with a timestamped record showing exactly when recording began and ended. This is considerably more persuasive than an assurance that the camera was running, and it prevents a recoverable technical failure from becoming a reputational one.
Supporting a warranty or insurance claim. Manufacturers and insurers routinely ask for the flight record when a loss involves a malfunction. A complete log with intact provenance supports the claim; a partially overwritten or unsynced record weakens it. This is the practical reason to export logs promptly rather than when a dispute arises.
The drone crash data loss article covers how the media and the log evidence work together after an incident.
What Logs Cannot Do
A flight log is not a backup, and three limits are worth internalizing.
It cannot reconstruct footage. If the video data was overwritten, the log proves the flight happened but returns no images. The when footage is unrecoverable criteria explain how that conclusion is reached.
It cannot describe what the camera saw. Position, altitude, and gimbal angles are not a picture. A log can tell you the aircraft was pointed at a building from sixty meters; it cannot show you the building.
Its coverage is finite. Onboard logs are stored in a limited ring, so older flights are overwritten by newer ones. App logs persist longer but are tied to the device. Retention is a design choice, not a guarantee, so export anything you may need while it still exists.
One operational note: if the aircraft is intact and boots, exporting its onboard logs and copying its internal footage are separate operations, and the footage should come first because it cannot be regenerated.
Frequently Asked Questions
Can you recover video from a flight log?
No. Flight logs contain telemetry, not image data. What a log can do is prove that the camera was recording at a specific time, which tells you the footage exists on the storage medium and justifies a deeper scan for the unfinished file. The video itself has to come off the card or the aircraft’s internal storage.
Where are DJI flight logs stored?
They are kept in several places: on the mobile device running the flight app, on the remote controller, on the aircraft itself, and in the cloud account if automatic sync is enabled. The app copy is the most valuable after an incident, because it survives the loss of the aircraft.
Do I need the drone to read its flight logs?
No. The app and controller copies can be exported with the aircraft missing entirely, as long as you still have the device that flew the mission. Only the onboard record requires the aircraft to boot, and that record is also the one lost most often in a crash.
Why does the log timestamp not match my video file times?
The aircraft clock and the phone clock are set separately, and the aircraft clock syncs only when it acquires a satellite fix. If it never synced during that flight, its timestamps will be offset by a fixed amount. Measure the offset from the first synchronized sample and apply it to the whole record.