Mavic Flight Log Retrieval and Analysis Guide

jclarkw · Mar 4, 2021

sar104 said:
I updated the guide, which is the first post in this thread.

Got it. Sorry I didn't see the change log at first.

Thanks for all the effort on this! -- jclarkw

doodlebug777 · Mar 11, 2021

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

got an internal error for logs from DJI Fly 1.3.0 (437). Is that as expected?

doodlebug777 · Mar 11, 2021

doodlebug777 said:
got an internal error for logs from DJI Fly 1.3.0 (437). Is that as expected?

FYI, MA2

slup · Mar 11, 2021

doodlebug777 said:
got an internal error for logs from DJI Fly 1.3.0 (437). Is that as expected?

TXT logs coming from a DJI FLY app version above 1.2.1 can only be read through Airdata.com for time being. Further more, mobile device DAT logs from the Mini2 is encrypted & can only be read by DJI.

doodlebug777 · Mar 12, 2021

slup said:
TXT logs coming from a DJI FLY app version above 1.2.1 can only be read through Airdata.com for time being. Further more, mobile device DAT logs from the Mini2 is encrypted & can only be read by DJI.

Thank you for the reference! Just what I needed.

Eaglesky77 · Mar 24, 2021

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

Wow. Well you are well versed, no?!! Man, I wish u were nearby to teach me a bit. You must have much flight experience... not just with UAVS..

slup · Apr 12, 2021

Adrian Rusu said:
Al treilea acumulator care a dat critical error, pe coborare pe RTH după 15 minute de zbor. Acumulatorul nu se mai aprinde, este mort. Ajutor

Google Translate --> The third battery that gave critical error, on descent on RTH after 15 minutes of flight. The battery does not turn on, it is dead. Help

That battery manufactured late March 2018 is beyond any help ... cell 2 had a major failure and started to drop & deviate from the other 2 cells already a couple minutes into the flight, it ended up at 1,11V.

The only thing that remains is to dispose of it properly & buy a new one.

LiPo batteries don't last forever ... how they have been stored & used will determine if the life will be short or long, but all batteries end up like this if used too long.

deocder · Apr 29, 2021

Hi! Looking for some info as to why my Mavic Air 2 did an emergency landing with 15% battery on its first flight. No return to home as expected. Trying to understand the logs.

slup · Apr 30, 2021

deocder said:
Hi! Looking for some info as to why my Mavic Air 2 did an emergency landing with 15% battery on its first flight. No return to home as expected. Trying to understand the logs.

Hi there & welcome to the forum ... even though it's due to unfortunate events.

If you in the future needs assistance with crash events it's better to create a new post in this forum area --> Mavic Crash & Flyaway Assistance . Right here it's more general info regarding log analysis.

Your MA2 didn't do any emergency landing ... you initiated the landing by yourself unfortunately.

DJI crafts will initiate landing when the throttle (your left stick) is kept down for ascent when the VPS sensor sense something beneath closer then 0,5m (1,64ft).

Here all shown in a chart ... the blue background color is the landing phase.

The red = barometric height from your HP
The bright green = VPS height from objects directly beneath the craft
The Blue = your throttle stick (value 1024=neutral)
The darker green = battery %

Have placed a marker where it all starts ... you can read out the actual values for the graphs there from the legend under the chart.

(Click on the chart to make it larger)

When this happened you was over a sloping house roof, not a suitable landing spot ...

After it touched down the props probably hit the roof & below is all the excessive pitch, roll & yaw movements shown in a chart. This created the error messages about "Not Enough Force/ESC error" & "Motor is blocked".

deocder · Apr 30, 2021

Hi there & welcome to the forum ... even though it's due to unfortunate events.

If you in the future needs assistance with crash events it's better to create a new post in this forum area --> Mavic Crash & Flyaway Assistance . Right here it's more general info regarding log analysis.

Hi there & welcome to the forum ... even though it's due to unfortunate events.

If you in the future needs assistance with crash events it's better to create a new post in this forum area --> Mavic Crash & Flyaway Assistance . Right here it's more general info regarding log analysis.

Thank you for the welcome and my apologies for posting on the general thread.

I appreciate that you took the time to explain, in detail, what happened. An unfortunate event indeed but in the end no one was hurt and I only lost the 4 props. I noticed significant lag between the controller actions and the drone response (which I will investigate separately). So the combination of that and the proximity of the roof led to the crash.

TigersFan · Jun 11, 2021

Even though I am late in uncovering this information, thank you very much for your work and sharing it with us. I find it very valuable and am taking a few tips away. Congratulations, albeit late.

marcorasi1960 · Jun 12, 2021

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

Thank you so much for this outstanding document on a topic that is so complex and so important when one experiences a serious flight issue. After 27 months of successful, fun and safe flying of a Mavic 2 Zoom, I had a major issue that essentially destroyed my drone. I would like to describe it here in the hope that my description allows an expert like you to give me advice on what to do to figure out what happened. I want to buy a drone just like the one I just destroyed, but before doing so I want to understand how to avoid the issue I experienced. My Mavic 2 Zoom worked flawlessly for over 2 years. I fly very safely and never had a crash nor a 'hard landing', and until the day before the incident my drone behaved properly and did not show any damage or issues. The day before yesterday I was about to take off from the pavement of a street along a beach in Tuscany, Italy. I use a DJI Smart Controller, which was indicating that I had GPS connection and that the ground location had been recorded, just as it always did before every flight in the past. So, as I always do, I touched on the screen the upward arrow for take-off, and the yellow slider asked me to swipe to confirm take-off. When I did, the drone instead of rising up vertically to about 1.2 meters height as usual, flew straight forward. It remained at ground level, flying forward and smashing against the edge of a sidewalk maybe 10 ft from the take-off point. The drone 'survived' this crash, meaning that the only serious damage seemed to be that one of the 'feet' was a bit loose. One of the rotors came off, but it did not break and I was able to reinstall it without a problem. At this point I did a very, very stupid thing, that essentially cost me the drone. I decided that since everything seemed to be ok (and after turning everything off -- and then back on -- the controller indicated that I could fly), I tried to take off again. The drone again did what it had done before, i.e., took off forward instead of upward, smashed again against the sidewalk, and this time, upside down and with two broken rotors, kept trying to fly, and before I could get a hold of it and turn it off, the engine overheated and I could smell something burning. Looking at your list of causes of most flight control problems, I suspect 2. or 6. 1. seems unlikely because I had excellent GPS signal. 3. is certainly not an issue, as there was essentially no wind. 4. seems unlikely because everything seemed in perfect condition, I had flown trouble free the day before, and the drone had not gotten damaged in any way (I keep my drone very well... well... until this double-crash!). 5. seems impossible because the battery was still firmly in place and on after the crash. 2. is my main suspect because sometimes sidewalks have an inner metallic reinforcement, and between the street where the drone was and the beach there was a metallic banister. While it was not very close to the drone, maybe 15 feet away, it was a long banister running several dozen yards parallel to the sidewalk. I don't know about 6. because I really do not understand what those issues are.

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;
Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;
Wind speeds in excess of the design limits of the aircraft;
Lost/damaged props or motor problems, leading to loss of propulsion;
Power interruption due to battery disconnects;
FC/IMU processor issues.

Based on my description of the incident, I wonder if it is possible to make a diagnosis. If flight records are needed, I am pretty sure I have them on the smart controller, although I did not quite understand how to send them (do I need to have a particular device to connect the SD card to my MacBook Pro laptop, or can I simply connect the SC to the laptop with my cable?). I also wonder if the flight records could be of use for there two 'flights' that lasted a couple of seconds each. If they could be useful, would it be possible to point me to the part of this document that is most applicable to my devices and situation?

Thanks so much in advance for any help you may offer. My goal is not to save this damaged drone or try to get some sort of refund. I have kissed my drone goodbye and I am fully aware that the person responsible for destroying it is me. My main goal is to understand enough about what happened that I can have peace of mind that it won't happen to me again with the next Mavic-2 Zoom I am about to buy.

DavidT_ NZ · Jul 31, 2021

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

A fantastic effort. Thanks for posting. Any chance of attaching it as a pdf file, to making saving it a bit easier? I will retain for reference. ????

DavidT_ NZ · Jul 31, 2021

tednol said:
Can I just say how fascinating I’ve found reading threads in this section of the forum. I’m a new MM owner. I’ve had a number of faultless and enjoyable flights, in part no doubt due to some good fortune. I’ve learnt so much from a few hours reading the experiences of people who have been less lucky, and I’m going to be a more thoughtful and considerate pilot going forward. It’s also brought home to me a few home truths about RTH, and what can and cannot be realistically expected of it. I’d probably have tried to rely on it if I ever found myself in trouble prior to reading other people’s experiences. I now understand it is far more an option of last resort. That might save me a painful lesson down the road one day. Thanks again to everyone who has shared stories and all who have worked to make some of the endings happier than they otherwise may have been.

One thing about RTH: I use it regularly and mix it up with automated and manual landings on the final “approach”, simply because it works so well on my Air 2 but also so that I can continue to be familiar with what to expect, during the various firmware updates. In over a year of flying, I continue to be impressed with how well an Air 2 will come home, provided the DJI launch recommendations have been followed correctly. I have never needed to test it in an emergency but at least I have a reasonable idea of what to expect, if I initiate the procedure or if it self-actuates. Safe flying ????

COOKIE 1 · Aug 20, 2021

green light blinks once, not connected to rc. looking for a easy fix

Zbip57 · Oct 17, 2021

During the update process to the latest Fly App version v1.4.12 (Android), I should have paid closer attention, it asked something about permissions to store data on my phone.

The flight logs are no longer stored where they were before in DJI/dji.go.v5/FlightRecord. On my phone (Galaxy S9), the flight records are now stored elsewhere.

The TXT files are still in the FlightRecord folder, and the DAT files are still in the MCDatFLightRecords subfolder, but now located here:

Galaxy S9/Phone/Android/data/dji.go.v5/files/FlightRecord/MCDatFlightRecords

Bountoh · Jan 16, 2022

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord. or dji.go.v5 » Files » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

One of my Mavic 2 Enterprise flew away while video feedback turned black and white. I can see the flight on phone I used that day. I connected this particular phone to my computer and explored the files but I was unable to find the data. On this phone, there is DJI Fly, DJI Go 4 and DJI Pilot installed. Where should I look ? Will DJI support help to this matter. M2E was quite new and just flew about 30km (20 miles). I want to understand what failed. Wind was not strong that day. Thanks for any advice you may give me.

Meta4 · Jan 16, 2022

Bountoh said:
One of my Mavic 2 Enterprise flew away while video feedback turned black and white. I can see the flight on phone I used that day. I connected this particular phone to my computer and explored the files but I was unable to find the data. On this phone, there is DJI Fly, DJI Go 4 and DJI Pilot installed. Where should I look ? Will DJI support help to this matter. M2E was quite new and just flew about 30km (20 miles). I want to understand what failed. Wind was not strong that day. Thanks for any advice you may give me.

Go to DJI Flight Log Viewer | Phantom Help
Follow the instructions there to upload your flight record from your phone or tablet.
That will give you a detailed report on the flight data.
Come back and post a link to the report it provides and someone might be able to analyse it and give you an understanding of the cause of the incident and possibly a likely search area.

You might have to look in the DJI Pilot folder but the file location would be similar.

afalex · Jan 23, 2022

sar104 said:
With the introduction of the Mavic Mini there has been a noticeable uptick in the number of posts requesting help with lost or crashed aircraft. While there is plenty of help and advice available on this forum, and detailed guidance and options on several other websites, I thought that perhaps a single summary of the subject might be useful. If it does prove useful then I'll try to keep it updated, either in this post or followup posts, and perhaps other forum members will contribute additional thoughts on the subject to address errors and omissions.

If you are not interested in long-winded details or are just in a hurry to retrieve log files, then either skip to section 3 or head over directly to either the PhantomHelp or AirData website.

1. INTRODUCTION

Starting back with the Phantom 4, DJI aircraft and control software record an impressive amount of flight data to various log files both on the aircraft and on the mobile control device (phone, tablet etc.) which is extremely useful in determining the cause and outcome of unexpected events. These log files contain far more data than the simple flight summary files that appear in the DJI GO 4 app, but are not as simple to access. Most of them are encrypted, but many can be read using widely available software or web-based converters.

Before discussing the log files themselves it's possibly worth a brief description of how these flight control systems work. Skip to section 2 if you are not interested in this level of detail. I've included some links for optional further reading.

Ignoring fully manual mode, which is only available by changing a firmware parameter, aircraft flight is controlled entirely under the hood by the onboard flight controller (FC). It converts stick input commands to move up/down, forwards/backwards, left/right and CW/CCW into motor adjustments to achieve the requested movement. Sticks centered means hold position, altitude and heading (P-GPS mode) or hold altitude and heading with pitch and roll set to zero (ATTI mode). Stick inputs simply request specific movement relative to those baselines.

Exactly how these flight control systems work is a rather deep and arcane subject. At the simplest level, the aircraft have either one or two MEMS strapdown IMU packages that comprise 3-axis accelerometers and rate gyros, together with 3-axis magnetometers (compass), a barometric sensor, and a GNSS module that receives GPS and GLONASS signals. Anyone with a cursory familiarity with basic mathematics will note that there is, therefore, redundancy in the flight data. In theory, given an initial position and heading, transformation of the accelerometer and rate gyro data into the earth frame of reference followed by integration with respect to time yields velocity and displacement as a function of time - pure inertial navigation. In practice it doesn't work with these kinds of IMUs, due to bias (zero offset errors) and drift (small changes in sensor gain), which lead to errors in the integrated quantities. The result, which is easy to replicate since the raw sensor data are available, is that after just a few tens of seconds of flight the inertial solution ends up noticeably incorrect.

However, the accelerometer and rate gyro data are, in fact, the only data measured fast enough to provide responsive aircraft control, and thus they are the primary data source for the control algorithm. Once the aircraft yaw (heading) is initialized by the compass, the aircraft attitude, velocity, position and height are computed primarily inertially. The IMU sensor drift and bias issues are corrected more gradually using the GNSS, compass and barometer data by a sensor fusion algorithm, most likely a Kalman filter or equivalent, keeping the absolute velocity, position, heading and altitude correct within the accuracy of those sensors. The aircraft attitude is actually not tracked as the derived Tait–Bryan angles (pitch, roll and yaw) since that description becomes indeterminate for certain orientations. Instead the FC uses rotation quaternions which, while a more obscure branch of mathematics, has a number of advantages.

Most flight control problems are caused by:

Loss of GNSS positioning, which will generally lead to the FC switching to ATTI mode unless it has active VPS positioning available;

Disagreement between the IMU and compass yaw values, often caused by taking off from a locally magnetically distorted site;

Wind speeds in excess of the design limits of the aircraft;

Lost/damaged props or motor problems, leading to loss of propulsion;

Power interruption due to battery disconnects;

FC/IMU processor issues.

2. LOG FILE TYPES

Mobile device DJI TXT logs

These logs are created by the standard DJI SDK and run from motor start to motor stop (or signal loss), recording telemetry transmitted from the aircraft to the RC at 10 Hz in a few hundred data fields. These logs don't include any raw sensor data - only the IMU solutions that are the output from the sensor fusion algorithm. They also include battery data, gimbal and camera data, flight status and error flags, but no motor data.

They are often all that is needed for analysis of simple events, but the lack of raw sensor data makes it difficult to identify exact causes if there are IMU problems, and the lack of motor data is a problem when there are propulsion issues. Additionally, the relatively slow data rate and a couple of tenths of a second latency means that events rapidly followed by aircraft shutdown (e.g. many crashes) are not recorded.

The TXT logs generated by the DJI GO 4 app can be decoded as described in §4 below. TXT logs generated by the DJI Fly app are also fully decodable in versions prior to 1.2.2, but starting with Fly 1.2.2 the TXT logs are only readable by the AirData website.

Aircraft DAT files

These contain the most comprehensive data, logged at the highest rates. A DAT file is started at aircraft power up and continued until power down, and includes numerous boot sequence, sensor calibration and diagnostic data in the flight event stream. There are also hundreds of data fields, many of which are flags or diagnostic computations of unknown types, probably understood only by DJI. However, among these are the raw and processed sensor data and the IMU solution for aircraft attitude, position, velocity and heading, together with battery and motor data, recorded at rates varying from 5 Hz to 200 Hz. These data are very valuable for diagnosing flight control problems. The files exist independent of the mobile device control app being used.

Unfortunately, on recent DJI models (Mavic Air, Mavic 2, Mavic Mini and Mavic Air 2 and Mavic Mini 2) the decryption keys are hidden, and so those are not readable except by DJI.

Mobile device DAT files (DJI GO 4 app & DJI Fly app)

These contain a subset of the aircraft DAT files, including most of the raw sensor data, recorded at a lower data rate of 10 Hz. They are also started at aircraft power up and closed at aircraft shutdown, provided that the app is connected - otherwise it will be the subset of that duration when the app is connected. Not as good as the aircraft DAT files, but nearly as good for most needs, and always available if the control app is DJI GO 4. DAT files are not created when using Litchi or other third party control apps.

Mobile device third-party control app log files

Third-party control apps, such as Litchi, create their own custom log files in various formats using the DJI SDK, generally in CSV format. None that I have seen are as comprehensive as the DJI TXT log, let alone the DJI DAT log.

Since Litchi is probably the most common third-party app, it's worth noting that, under iOS and Android, Litchi creates its own CSV log and a standard DJI TXT log in a separate directory. No DAT file though.

Remote Controller logs

Contrary to popular belief, the remote controllers, with the obvious exception of the smart controllers, do not store telemetry from the aircraft. As a result, flying without a mobile device app, either with just a controller or with DJI Goggles, for example, means that there will be no telemetry to aid with flight forensics.

3. LOG FILE RETRIEVAL

Mobile device DJI TXT logs

The log naming convention, based on the date and time of the start of the flight, is: DJIFlightRecord_YYYY_MM_DD_[hr-min-sec].txt.

Instructions to find and upload the files directly, with an option to make them public via a link, can be found on both @msinger's excellent PhantomHelp website or on AirData. Those both allow subsequent download of the original txt logs for third-party analysis.

Alternatively, to simply retrieve the txt logs from the mobile device:

With iOS devices running DJI GO 4 you need to access the app files via computer, either using iTunes or with a file system browser such as iExplorer. The TXT logs are in Apps » DJI GO 4 » FlightRecords. The same method can be used to access DJI Fly files in DJI Fly » FlightRecords, but with DJI Fly they are also accessible using the iOS Files app by selecting Browse » On My iPhone » DJI Fly » FlightRecords.

With Android devices the file system should mount when plugged into a Windows machine, or via various software options on a Mac. With DJI GO 4 the TXT logs are in DJI » dji.go.v4 » FlightRecord. With DJI Fly they are in DJI » dji.go.v5 » FlightRecord. or dji.go.v5 » Files » FlightRecord.

Under iOS the DJI Fly app files are actually accessible directly in the iOS "Files" app, but the DJI GO 4 app doesn't have that option.

If you want help analyzing the data then you can either retrieve the logs and post them here directly, or upload them to PhantomHelp or AirData and post the link back here.

AirData also has automatic log upload (sync) options directly from most of the common control apps.

Aircraft DAT files

These are only readable from the Mavic Mini, Mavic Pro and Mavic Pro Platinum (plus Phantom 3, Inspire 1, Phantom 4, Phantom 4 Pro, Inspire 2, Inspire 2 Pro, Matrice 100, Matrice 200, Matrice 600, and Spark). All except the Mavic Mini record the DAT files on internal aircraft memory, and a guide to retrieving them from the aircraft can be found on @BudWalker's DatCon website. The Mavic Mini maintains the most recent DAT file named fc_log.log on the removeable SD card in hidden folder: MISC » LOG » flylog. Change the file extension from .log to .DAT to read the file with DatCon.

Aircraft DAT files are much larger files than the mobile device files, and generally too large to post directly to this forum. The best solution is to upload them to Dropbox or similar and then post a link.

Mobile device DAT files (DJI GO 4 & DJI Fly)

The DAT file naming convention, based on the date and time of the start of the file, is: YY-MM-DD-hr-min-sec_FLYXXX.DAT., where XXX is the flight recorder file index from the HOME_dataRecorderFileIndex field in the txt log.

These are retrieved by the same method as the TXT logs. Under both iOS and Android they are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs. In some cases, for reasons not fully explained but possibly mobile-device hardware related, and most often under Android, DAT files are not created and that folder is empty. Uninstalling and reinstalling the app sometimes fixes that. One user also found that the process required manual deletion of the app folder (apparently not deleted automatically in the uninstall process) before reinstalling the app.

The DJI Fly app deletes the DAT files if and when it syncs flight records with the DJI servers, and so they are often missing from the MCDatFlightRecords folder. The iOS version of the DJI GO 4 app does the same since version 4.3.24. The Android version of DJI GO 4 does not delete the DAT files as of 4.3.32.

Litchi log files

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord.

On Android devices the Litchi CSV logs are in LitchiApp » flightlogs. Litchi also creates a standard DJI TXT log, which for some reason it stores in a subdirectory in the DJI app directory, DJI » com.aryuthere.visionplus » FlightRecord.

In the case of automated Litchi missions, it's also important to post a link to the flight mission profile.

4. LOG FILE CONVERSION AND VISUALIZATION

There are various options to visualize and examine the contents of the log files, depending on type. Some of the commonly used ones are described below:

DJI TXT logs

The PhantomHelp website will display a summary of the flight with some of the telemetry. You can also download the original TXT log and the full file contents in CSV format. It doesn't provide graphical analysis, but you can open the CSV file in Excel or dedicated data analysis programs. Does not decode Fly 1.2.2 logs.

The AirData website will also read TXT logs, giving a different view of the data. It has a useful condensed view of app notifications, and a fairly advanced analysis of the computed wind field during the flight (subscription only). It doesn't provide a full downloadable version of the log - only a limited subset of the data. It also, by default, allows download of the original TXT log. Fly 1.2.2 logs are readable but AirData doesn't generate the full verbose output - just a limited subset of the data.

The Windows version of CsvView will convert DJI TXT logs using an embedded version of TXTlogToCSVtool, and provides numerous powerful options to visualize the flight data. Does not decode Fly 1.2.2 logs.

TXTlogToCSVtool is another offline Windows program that reads and converts TXT logs to CSV format. In fact the PhantomHelp website and CsvView both use this to perform their conversions. There is now a separate version for DJI Fly logs from the Mavic Mini and Mavic Air 2. There are no visualization options - you simply get the full CSV version of the log that you can open in other data analysis programs. Does not decode Fly 1.2.2 logs.

Aircraft DAT files

Phantom 4 and Mavic Pro DAT files can be converted to CSV format using CsvView or DatCon, which is a Java application that runs under OS X and Windows. These files are recorded at rates up to 200 Hz for some of the data, and contain hundreds of data fields. They are extremely data rich, but not for the faint of heart when it comes to trying to interpret them. @BudWalker is constantly updating the parsing engine, but a partial description of some of the more basic data fields is on his website.

Mobile device DAT files (DJI GO 4 app)

These are converted to readable CSV files using CsvView or DatCon, and can be visualized in CsvView under OS X and Windows. They are recorded at just 10 Hz and are much smaller than the aircraft DAT files, but contain many of the same fields. AirData also reads mobile device DAT files and displays a similar set of data as it does with the TXT logs.

Litchi log files

These logs are recorded as CSV files and so they don't need any conversion. PhantomHelp and AirData will display them, or they can be opened by Excel or data analysis software.

5. LOG FORENSICS

Any attempt at a description of this subject is going to be very superficial - at this point I could write a short book on telemetry data analysis. Over the past few years I've developed a few streamlined approaches to looking at the data, depending on the type of event (crash, flyaway, loss of control, unexpected behavior etc.), but most of them involve significant data processing in the form of frame of reference transformations, quaternion algebra and some calculus. Those all require a significant data analysis package - I use Wavemetrics Igor Pro for which I've written a number of data processing functions. Igor Pro is particularly suited to this kind of work, and since user functions are compiled, rather than interpreted, it chews through huge datasets very fast. To give a few examples:

In cases of flight control issues, I look for discrepancies between the IMU sensor fusion solutions for position and velocity, and check for appropriate correlations between the stick inputs, motor speeds (DAT files only), aircraft attitude, and horizontal velocities and accelerations. Example.

With flyaways (or generally blowaways) in P-GPS the most effective technique is to extrapolate the battery level and solve for the intersection with the autoland, and then extrapolate the aircraft position with drift velocity to determine where it should autoland. Here's a detailed description of that process in practice.

For power loss or FC failure leading to motor shutdown I use an aerodynamic aircraft model together with the computed wind field as a function of height to run a drag-dominated finite-difference numerical solution for the descent path of the aircraft, writing to a KML descent track file. Example.

That said, there are various simple checks that can be performed by looking at the telemetry. The data field names below are from the DJI TXT log, but there are equivalent fields in the DAT files. Some are text fields, while others are numerical.

OSD.flyTime – elapsed flight time;

OSD.flycState – the flight control mode (P-GPS, ATTI, RTH, autoland etc.)

SMART_BATTERY.battery – the battery level in percent;

SMART_BATTERY.goHomeBattery – the computed battery percentage that triggers RTH, based on distance from the home point;

SMART_BATTERY.landBattery – the computed battery percentage that triggers autolanding, based on height above the home point;

OSD.pitch, OSD.roll, OSD.yaw – the aircraft attitude as pitch, roll and yaw (IMU sensor fusion yaw solution - not the compass heading);

OSD.height – height above the home point;

OSD.sWaveHeight – VPS height above the ground;

OSD.gpsNum – number of GNSS satellites locked;

OSD.gpsLevel – navigation health level (1 - 5), which is a measure of confidence in the sensor fusion solution;

OSD.isGPSused – is GNSS used for positioning;

OSD.isVisionUsed – is VPS (rather than GNSS) being used for positioning;

RC.aileron, RC.elevator, RC.rudder, RC.throttle – the recorded stick inputs;

OSD.latitude, OSD.longitude – the sensor fusion solution for position (not the raw GNSS position data, which is only in the DAT file);

OSD.xSpeed, OSD.ySpeed, OSD.zSpeed – velocity north, east and down, respectively;

MC_PARAM.failSafeAction – the failsafe action (RTH, hover or land).

That's just a partial list of some of the most useful data fields when it comes to trying to identify flight problems.

In all but the most simple cases, I recommend posting to the forum a description of the flight together with both the DJI TXT log and mobile device DAT log. There are several forum members who have experience in interpreting these files by various methods. For those who might be interested, the best tutorials for understanding and replicating the analysis methods are probably the forensic threads on this forum, and any questions for further explanation are always encouraged.

Comments welcomed...

EDITS:

12/26/19: Added the full range of DJI aircraft with readable onboard DAT files.
12/26/19: Added the location of Litchi DJI SDK TXT log files.
12/27/19: Added explicit retrieval directions for DJI Fly.
02/10/20: Added that DJI Fly auto deletes DAT files.
04/12/20: Added quick links to upload logs, added note regarding DJI Fly app file access.
04/18/20: Updated the issue of the mobile apps deleting DAT files on sync.
04/24/20: Added note on lack of RC logs.
06/04/20: Updated to include Mavic Air 2.
07/25/20: Updated to include the Mavic Mini aircraft DAT file location.
03/03/21: Updated to include Mavic Mini 2 and TXT files from Fly 1.2.2

Hi,
I couldn't install Itunes on my macOS Monterey, I found a great workaround to be able to access your flight logs.

Check flight log of DJI drone / View flight path | DJI Mavic Mini | How to Fly Hobby Drone | All about iPod/iPad/iPhone

www.apollomaniacs.com

Connect your device to the computer and open up it up in finder>device>files>DJI fly>FlightRecords.

I will delete the post if extraneous.

Poznan · Feb 28, 2022

Howdy,

Was flying my DJI mini yesterday. And out of nowhere it just plummeted out of the sky.

There was no strong wind or bird strike or anything.
When i picked it up i noticed one of my props was missing, I found it about 50 metres away.
Not too sure what happened.
I tried using Airdata to figure out if maybe there was an motor failure or if maybe it would show when the prop detached in midway (Motor rpm going up?) but not much can be seen.
I attached my Dat file.

Cheers