Hello,

I lost my Mavic 2 Pro drone and I’m trying to determine what exactly happened. The drone was in an active track mode and as I attempted to rotate the drone around the subject I got a low signal warning at some point, followed by a disconnect. I estimate that I was flying about 15 meters over the ocean, at least 1 km out. I attempted to exit and restart DJI GO application, the controller itself, pressed RTH multiple times but RTH was never initiated. This is the first time RTH didn't work for me but the only difference was an active track mode and I strongly suspect that there is a bug in software that makes the drone continue tracking the subject even after it disconnects. The drone, controller and the battery were running the latest firmware, the compass was calibrated in a new location, the home point was recorded, there were plenty of satellites (~15) and no interference (open ocean).

I followed instructions to retrieve flight logs from my iPhone but I cannot find the log that corresponds to the last flight. I don't see that flight listed in DJI GO app, perhaps because I forgot to record the video (but shouldn't it be listed anyways?). Here are the log/data files that I retrieved from the iPhone that match the day of the crash (2020/03/08):

1) FlightLogs (Tahiti time = New York - 6 hours)

2020-03-08 09_41_51-163DFCT001X2X0.dat
2020-03-08 10_30_20-163DFCT001X2X0.dat
2020-03-08 10_49_39-163DFCT001X2X0.dat
2020-03-08 15_12_22-163DFCT001X2X0.dat

2) FlightRecords (Tahiti time = New York - 6 hours)

DJIFlightRecord_2020-03-08_[09-41-48].txt
DJIFlightRecord_2020-03-08_[10-30-17].txt
DJIFlightRecord_2020-03-08_[10-49-36].txt

3) videoCache (New York time)

2020_03_08_15_25_49.thumbnail
2020_03_08_15_25_49.rec
2020_03_08_15_25_49.mp4
2020_03_08_15_25_49.mapV2
2020_03_08_15_25_49.infoV2

The last flight record (DJIFlightRecord_2020-03-08_[10-49-36].txt) corresponds to the last flight log shown in DJI GO app, timestamped 16:49:36 - which is the local time - New York vs. Tahiti time (6 hours difference). I uploaded the txt file to DJI Flight Log Viewer and verified that it corresponds to the flight log shown in the DJI app.

I don't know what are the files under #1 and interestingly one file (2020-03-08 15_12_22-163DFCT001X2X0.dat) has the most recent timestamp but it is too far apart - the crash occured shortly after the lastly recorded log (15:25).

What are my options here? Wasn't the flight recorded because I was not recording the video or becase the application crashed and the file was not flushed to disk? Thanks.

Hi,

If you upload the last flightlog, you may get some help here.

use this > https://www.phantomhelp.com/LogViewer/Upload/  and post the uploaded link on here.

cheers
JJB

Have you written about this to DJI Support ?

If the controller is disconnected from the drone then attempting to engage RTH will have no effect.

The .DAT file you want ends with .DAT. That's capital D-A-T. The .dat files won't provide any useful info. The .DAT files are located in the FlightRecords/MCDatFlightRecords folder.

even controller disconnect or lost the signal , m2p should autopilot rth . have those options selected in dji go 4 apps?
during active tracking  the sensors turn off and  flying over the water bodies may confuse some sensors  as well

JJB* Posted at 5-4 23:25
Hi,

If you upload the last flightlog, you may get some help here.

JJB, the problem is that the last log available (DJIFlightRecord_2020-03-08_[10-49-36].txt) is not the last one. I already uploaded and confirmed that this is not the one.

Eralp SAYGIN Posted at 5-5 04:39
Have you written about this to DJI Support ?

I thought that DJI support monitors these forums. Do you suggest contacting them via email?

BudWalker Posted at 5-5 05:55
If the controller is disconnected from the drone then attempting to engage RTH will have no effect.

The .DAT file you want ends with .DAT. That's capital D-A-T. The .dat files won't provide any useful info. The .DAT files are located in the FlightRecords/MCDatFlightRecords folder.

That's right, RTH will have no effect but it wasn't initiated automatically.
All dat files in the FlightRecords/MCDatFlightRecords directory have timestamps from the last year (i.e. the most recent one is 2019-08-19_15-39-46_FLY174.DAT).

The only dat files timestamped 2020/03/03 are under the FlightLogs directory and the most recent one (2020-03-08 15_12_22-163DFCT001X2X0.dat) has a strange timestamp (the time is too far away from the time of the crash). It should be close to the previous one (2020-03-08 10_49_39-163DFCT001X2X0.dat), which corresponds to the last successful flight that occured minutes before the fatal one.

Where can I upload the dat files (not supported by the DJI Flight Log Viewer)?

akozc Posted at 5-5 07:00
even controller disconnect or lost the signal , m2p should autopilot rth . have those options selected in dji go 4 apps?
during active tracking  the sensors turn off and  flying over the water bodies may confuse some sensors  as well

This happened for the first time, the drone always RTH when disconnected. Sensors are enabled in active track mode as far as I know.

I estimate that I was flying about 15 meters over the ocean, at least 1 km out. I attempted to exit and restart DJI GO application, the controller itself, pressed RTH multiple times but RTH was never initiated.
If you had no connection, you would never know if RTH was initiated.
If there was control signal, pressing RTH button several times is a good way to cancel RTH
If in doubt, switching off the controller is a good way to ensure RTH is initiated.

This is the first time RTH didn't work for me but the only difference was an active track mode and I strongly suspect that there is a bug in software that makes the drone continue tracking the subject even after it disconnects.
Do you have any information to suspect that loss of signal won't initiate RTH in Active Track?
Since the drone was out of sight, you couldn't have observed it so this is just a guess?

The drone, controller and the battery were running the latest firmware, the compass was calibrated in a new location,
None of those would be at all relevant.

Even if you had the flight data, it's not going to show what happened  after losing signal, but might be useful to eliminate some of the usual  suspects.
RTH is very reliable.
The usual reasons for a drone not returning are obstacles on the RTH path, strong wind and insufficient battery.
Obstacles are probably not relevant, but what do we know about the wind?
Was the battery freshly charged to start?
What was the battery level at the time of the incident?

I would suspect that RTH is normally initiated after signal loss even when in Active Track.
That should be easily tested for someone with an M2.

Without much hard evidence to go on, that leaves us guessing.
How sure are you that the drone was still flying after loss of signal?
It could be that the disconnection was due to a loss of power?

If in doubt, switching off the controller is a good way to ensure RTH is initiated.
This is why I did that based on my past experience. It was the first time RTH didn't work for me and the difference was an active track mode and this is why I suspect that there is a bug in software that makes the drone continue tracking the subject even after it disconnects.  
Do you have any information to suspect that loss of signal won't initiate RTH in Active Track?
Since the drone was out of sight, you couldn't have observed it so this is just a guess?
If RTH was initiated and given the conditions (no wind, obstacles and sufficient power) the controller would be able to eventually reconnect but it didn't happen. So yes, this is an educated guess. I experienced disconnects many times in the past in much worse conditions (further out, wind, mountains, etc.) but the drone always came back within the range and reconnected. The only difference was that this time I had it in active track mode.

>The drone, controller and the battery were running the latest firmware, the compass was calibrated in a new location,
None of those would be at all relevant.

It is relevant for the drone to operate properly, especially a compass calibration after traveling from the US to French Polynesia.

RTH is very reliable.
It had been always reliable for me until the accident.

The usual reasons for a drone not returning are obstacles on the RTH path, strong wind and insufficient battery.
Obstacles are probably not relevant, but what do we know about the wind?
Was the battery freshly charged to start?
What was the battery level at the time of the incident?
No obstacles (ocean), no windy conditions at all and the battery was low (~30%) but it should be well sufficient to came back within the range (100 - 200 meters).

I would suspect that RTH is normally initiated after signal loss even when in Active Track.
That should be easily tested for someone with an M2.
I doubt it was the case but it would be nice if someone could test this.

How sure are you that the drone was still flying after loss of signal?
It could be that the disconnection was due to a loss of power?
I couldn't tell if it was still flying, I can only suspect that the drone continued tracking the subject (I believe Litchi missions suffer from this problem but I wasn't using Litchi). It couldn't be due to the loss of power as there was enough power left. The disconnect was caused by weak signal - I got a warning about weak signal as I attempted to rotate the drone around the subject and shortly after it disconnected. The question is why it didn't initiate RTH as it supposed to do.

I was able to get the previous flight's data on Airdata that occured minutes before the last one. The path of the last flight was similar (along the channel going left) but much shorter and the drone got disconnected in the middle of below picture when in active track.

weather

lukaszj Posted at 5-5 21:32
If in doubt, switching off the controller is a good way to ensure RTH is initiated.
This is why I did that based on my past experience. It was the first time RTH didn't work for me and the difference was an active track mode and this is why I suspect that there is a bug in software that makes the drone continue tracking the subject even after it disconnects.  
Do you have any information to suspect that loss of signal won't initiate RTH in Active Track?

It is relevant for the drone to operate properly, especially a compass calibration after traveling from the US to French Polynesia.
Contrary to what some people might tell you, there is no physical reason to recalibrate your copmpass, even after travelling a few thousand miles.
Really.

I couldn't tell if it was still flying, I can only suspect that the drone continued tracking the subject (I believe Litchi missions suffer from this problem but I wasn't using Litchi).
Litchi doesn't "suffer from this problem" at all.
Litchi gives you the option to return or have a mission complete after loss of signal.

It couldn't be due to the loss of power as there was enough power left. The disconnect was caused by weak signal - I got a warning about weak signal as I attempted to rotate the drone around the subject and shortly after it disconnected. The question is why it didn't initiate RTH as it supposed to do.
Weak signal also means No Signal.
You've latched onto the idea that your drone failed to initiate RTH and continued tracking but there's no evidence that is what happened.
The possibility that the disconnection was caused by the drone losing power, cannot be ignored.
Loss of power can happen because of a loose battery, partially charged battery or a hardware failure.

lukaszj Posted at 5-5 18:57
I thought that DJI support monitors these forums. Do you suggest contacting them via email?

I think you must write them. They must have help you about it when you send your flight records to them

Giving an advise to the guy who fall in the hole could be easy but please watch this video there are some cases may help you..... at least for your next drone …..

akozc Posted at 5-6 02:49
Giving an advise to the guy who fall in the hole could be easy but please watch this video there are some cases may help you..... at least for your next drone …..

https://www.youtube.com/watch?v=ervG0ulRFGc&list=LLGiqM4j-zzXeTgecJ5FoIOA&index=2&t=0s

His drone didn't "fly away", it almost certainly fell into the sea.

Labroides Posted at 5-5 22:11
It is relevant for the drone to operate properly, especially a compass calibration after traveling from the US to French Polynesia.
Contrary to what some people might tell you, there is no physical reason to recalibrate your copmpass, even after travelling a few thousand miles.
Really.

Litchi doesn't "suffer from this problem" at all.
Litchi gives you the option to return or have a mission complete after loss of signal.
That feature ("Exit Waypoint Mission on Signal Loss" and "Signal Lost Behavior for Manual Flying") was only added in the latest version (released in November, 2019).

You've latched onto the idea that your drone failed to initiate RTH and continued tracking but there's no evidence that is what happened.
The possibility that the disconnection was caused by the drone losing power, cannot be ignored.
Loss of power can happen because of a loose battery, partially charged battery or a hardware failure.

As already explained, I have pretty good reasons to "latch" onto that idea. The disconnect didn't happen instantaneously (as if a battery was ejected or the drone crashed into the ocean). As I was flying further away and changing the orientation of the drone I observed weakening the signal strength. While that's possible that something else *could* coincidentally happen around that time, I believe that a disconnect was caused by the drone going out of range. I was flying this drone in the same area for over 70 km along the same paths and experienced signal weakening under similar conditions.


Also, there is a mystery why the last log is not available on iPhone.

lukaszj Posted at 5-6 08:07
Litchi doesn't "suffer from this problem" at all.
Litchi gives you the option to return or have a mission complete after loss of signal.
That feature ("Exit Waypoint Mission on Signal Loss" and "Signal Lost Behavior for Manual Flying") was only added in the latest version (released in November, 2019).

That feature ("Exit Waypoint Mission on Signal Loss" and "Signal Lost Behavior for Manual Flying") was only added in the latest version (released in November, 2019).
Until November, continuing the waypoint mission on signal loss was the normal behaviour in a Litchi mission.
It was never a problem or fault as you've suggested.
As of 6 months ago you also have the option of having the mission abort and RTH on signal loss.

As already explained, I have pretty good reasons to "latch" onto that idea.
Until testing shows that is how the Mavic 2 behaves on losing signal in Active Track, it's still a guess with no evidence to support it.

Another possibility (that can only be guessed at without flight data) is that you could have flown into the water?
It wouldn't be the first time that's happpened.

Labroides Posted at 5-6 04:11
His drone didn't "fly away", it almost certainly fell into the sea.

Did u watch the video to the end?
Sure not ,
Please carefully watch to the end before  judging the title of the video.

akozc Posted at 5-6 19:19
Did u watch the video to the end?
Sure not ,
Please carefully watch to the end before  judging the title of the video.

I didn't watch any of it but I'm familiar with whatever he might have suggested in the 22 minutes of video.
What do you think was in there that might have made a difference in this case?

Labroides Posted at 5-6 15:33
That feature ("Exit Waypoint Mission on Signal Loss" and "Signal Lost Behavior for Manual Flying") was only added in the latest version (released in November, 2019).
Until November, continuing the waypoint mission on signal loss was the normal behaviour in a Litchi mission.
It was never a problem or fault as you've suggested.

Until November, continuing the waypoint mission on signal loss was the normal behaviour in a Litchi mission.
It was never a problem or fault as you've suggested.I disagree. I would never want my drone to continue any automated flight once it disconnects and that includes the active track mode. In the absence of these 2 options ("Exit Waypoint Mission on Signal Loss" and "Signal Loss Behavior for Manual Flyinhg") the default should be to initiate RTH immediately.

As of 6 months ago you also have the option of having the mission abort and RTH on signal loss.
This feature was added in November, 2019 and for the very good reason.


Another possibility (that can only be guessed at without flight data) is that you could have flown into the water?
It wouldn't be the first time that's happpened.

It is very unlikely that I flown into the water - if that was the case the disconnect would be immediate. As I already stated, I was observing a weakening of the signal strength prior to a disconnect and the altitude didn't change.

lukaszj Posted at 5-7 08:31
Until November, continuing the waypoint mission on signal loss was the normal behaviour in a Litchi mission.
It was never a problem or fault as you've suggested.I disagree. I would never want my drone to continue any automated flight once it disconnects and that includes the active track mode. In the absence of these 2 options ("Exit Waypoint Mission on Signal Loss" and "Signal Loss Behavior for Manual Flyinhg") the default should be to initiate RTH immediately.

I disagree.
I noticed .. you do that a lot.

I would never want my drone to continue any automated flight once it disconnects and that includes the active track mode. In the absence of these 2 options ("Exit Waypoint Mission on Signal Loss" and "Signal Loss Behavior for Manual Flying") the default should be to initiate RTH immediately.
You might think that but Litchi waypoint missions allow drones to safely fly out of contact and work perfectly as long as the flyer is careful in designing the waypoint route.
There are often situations on a waypoint route where to RTH would fly the drone into obstacles and result in a crash, possibly in inaccessable terrain.

This feature was added in November, 2019 and for the very good reason.
And although you don't understand why, there are also very good reasons to allow a mission to carry on after signal loss.
But arguing about Litchi doesn't make any difference in the case of your incident.

It is very unlikely that I flown into the water - if that was the case the disconnect would be immediate. As I already stated, I was observing a weakening of the signal strength prior to a disconnect and the altitude didn't change.
Yes .. so you said, but (in the absence of any confirming data) I'm not sure what you mean or sure that your recollection is accurate.
I added that possible explanation because the drone did not do as it is programmed to and without data, all possibilities need to be considered.
Yes, if you were fully aware, had good liveview and were paying attention, it's unlikely that you flew into the water.
But without data, there is no evidence that you didn't do something unlikely.
I've seen several cases where competent flyers did that.

As you can't find any data to show what actually happened on your flight,  I don't think there's much reason to continue like this.
I've listed what might happen and discounted some things that probably didn't happen.
You can't come up with data to support what you think happened or disprove what I've suggested might have happened.
Stalemate.

If you find data, I'd be happy to analyse it to see what clues it has, but until then ......

Labroides Posted at 5-7 15:11
I disagree.
I noticed .. you do that a lot.

I noticed .. you do that a lot.Look, I'm trying to understand why my drone crashed and not to debate with you who is right or wrong.
You might think that but Litchi waypoint missions allow drones to safely fly out of contact and work perfectly as long as the flyer is careful in designing the waypoint route.
There are often situations on a waypoint route where to RTH would fly the drone into obstacles and result in a crash, possibly in inaccessable terrain.
These are very specific use cases for advanced users, who are willing to take certain risks. For the most situations, RTH should be the default option on a disconnect. Letting the drone to continue after it disconnects, possibly flying even further away is asking for trouble.

lukaszj Posted at 5-7 16:50
I noticed .. you do that a lot.Look, I'm trying to understand why my drone crashed and not to debate with you who is right or wrong.
You might think that but Litchi waypoint missions allow drones to safely fly out of contact and work perfectly as long as the flyer is careful in designing the waypoint route.
There are often situations on a waypoint route where to RTH would fly the drone into obstacles and result in a crash, possibly in inaccessable terrain.

You don't use Litchi
You don't understand waypoint flying
What happens in Litchi has no bearing on your incident.

We reached the point where further discussion of this is pointless a while back.
Goodbye

lukaszj Posted at 5-7 16:50
I noticed .. you do that a lot.Look, I'm trying to understand why my drone crashed and not to debate with you who is right or wrong.
You might think that but Litchi waypoint missions allow drones to safely fly out of contact and work perfectly as long as the flyer is careful in designing the waypoint route.
There are often situations on a waypoint route where to RTH would fly the drone into obstacles and result in a crash, possibly in inaccessable terrain.

"These are very specific use cases for advanced users, who are willing to take certain risks. For the most situations, RTH should be the default option on a disconnect. Letting the drone to continue after it disconnects, possibly flying even further away is asking for trouble."

This is the opinion of someone who obviously has not used Litchi, and has no idea of the advantages of this feature. There are literally hundreds of situations you could encounter with a planned waypoint mission where the aircraft could fly out of range and disconnect. But an experienced pilot could very often plan and execute a flight that flies out of range intentionally, but can fafely complete the mission and return home. You might look up the posts by Dirty Bird, who is quite accomplished at this sort of mission. Just because it does not suit you does not make it a feature failure.

Geebax Posted at 5-7 18:01
"These are very specific use cases for advanced users, who are willing to take certain risks. For the most situations, RTH should be the default option on a disconnect. Letting the drone to continue after it disconnects, possibly flying even further away is asking for trouble."

This is the opinion of someone who obviously has not used Litchi, and has no idea of the advantages of this feature. There are literally hundreds of situations you could encounter with a planned waypoint mission where the aircraft could fly out of range and disconnect. But an experienced pilot could very often plan and execute a flight that flies out of range intentionally, but can fafely complete the mission and return home. You might look up the posts by Dirty Bird, who is quite accomplished at this sort of mission. Just because it does not suit you does not make it a feature failure.

This is the opinion of someone who obviously has not used Litchi, and has no idea of the advantages of this feature.There are literally hundreds of situations you could encounter with a planned waypoint mission where the aircraft could fly out of range and disconnect. But an experienced pilot could very often plan and execute a flight that flies out of range intentionally, but can fafely complete the mission and return home. You might look up the posts by Dirty Bird, who is quite accomplished at this sort of mission. Just because it does not suit you does not make it a feature failure.
You don't know me and what I know and frankly your self-righteous judgement is irrelevant here. I flew many complex, long distance missions in difficult environments myself and never said that such feature is not warranted so you are making a point out of nothing. All I said that such feature shouldn't be enabled by default as it is not safe or expected by most users. Accept it or not, I don't care and will not continue this pointless discussion.

lukaszj Posted at 5-7 18:47
This is the opinion of someone who obviously has not used Litchi, and has no idea of the advantages of this feature.There are literally hundreds of situations you could encounter with a planned waypoint mission where the aircraft could fly out of range and disconnect. But an experienced pilot could very often plan and execute a flight that flies out of range intentionally, but can fafely complete the mission and return home. You might look up the posts by Dirty Bird, who is quite accomplished at this sort of mission. Just because it does not suit you does not make it a feature failure.
You don't know me and what I know and frankly your self-righteous judgement is irrelevant here. I flew many complex, long distance missions in difficult environments myself and never said that such feature is not warranted so you are making a point out of nothing. All I said that such feature shouldn't be enabled by default as it is not safe or expected by most users. Accept it or not, I don't care and will not continue this pointless discussion.

"All I said that such feature shouldn't be enabled by default as it is not safe or expected by most users. Accept it or not, I don't care and will not continue this pointless discussion."

Yet you have not provided any proof that this actually happens. So how can you label it a 'feature'?