Greetings!

I tried to open a service request, but DJI Maintenance or Flyaway services are unavailable for my country ("Your selection is not currently available. Please contact us via www.dji.com/support"). Then I used "Contact Us by Email" form, but didn't get any response.

Well, now there's nothing I can do but share my experience.

So this story is about losing my DJI Mini 3 Pro under very strange circumstances.

Conditions: -2...-1°C, midnight, clear skies, calm wind, rural area, village near light forest and river (flying allowed), DJI Mini 3 Pro with Plus battery, RCN1, battery firmware updated using DJI Assistant.

Shortly after taking off, the drone has lost GNSS connection at 100ft height (why? that's another question..) and went into ATTI mode. I have already experienced such conditions and have already made several manual flights (Mini3pro and some other drone models before), so I was not surprised and continued my flight plan for the next 18 minutes. Then I proceeded with the landing process - it usually takes me 1-2 minutes to aim for the landing point with short maneuvers and slow altitude decrease.

Then something gone wrong.

a) View from the operator's point: the height was about 85ft, I have already made a few maneuvers, the last was a left stick "yaw" trying to aim the tail and continue moving backwards to my landing point, making an eye contact with the drone. Suddenly, the drone began to move horizontally (at "3 o'clock", to the right), with a very fast acceleration. I knew there were trees in that direction, and after a few seconds I pushed the left stick upwards to gain altitude. The drone did not respond, it proceeded to accelerate to insane speed, lost stability, then started spinning and crashed into a river gully trees.

b) After analyzing the log: here is the last 19 seconds of my flight (pic attached). I displayed only significant indicators, as there is no written errors etc..
There are three areas in the table: ATTI mode (white), GNSS reconnection (yellow), P-GPS mode (orange).

So, the chronology is (look at .jpg attached):

• flying at constant height, making a short maneuvers with camera aiming at the ground (-90°) [white table area]
• yaw with the left stick, the horizon level is flat [1]
• the drone starts reconnecting to satellites [2]
• small backwards stick action [3], but at this point, P-GPS mode activates and drone goes crazy. It does not respond to backward action, but instead begins horizontal acceleration at 3 o'clock [4] making a roll to the right [5]. This was not my action (!) as the roll/"move to the right" (RC.aileron) stick was completely free, and this roll angle was maintained until the moment of the crash.
• I'm realizing something is going wrong, all the sticks are released. Drone keeps accelerating [6]
• pushing the left stick upwards, trying to gain altitude [7]
• the drone has reached max specificated speed (35 mph) and continues to accelerate like a rocket [8] while losing altitude
• video cache shows several "flicks" as if something (not me) is twitching the controls
  

• then it loses stability, starts spinning, then hits a first tree branch. I think it happened at about 60 mph. The top speed recorded was 82.5 mph [9]
• the last 4 seconds it fell through the trees into a snow-covered river ravine
  

* another strange moment: the .txt log (like my map during the flight) did not contain the true coords, only the location of the home point. BUT the .dat file contains all the coordinates including the crash site. Then I've built a KMZ track to search that area.

I spent the next two days in 2-ft snowdrifts, trying to find my lovely drone (or at least its parts), with no success. It could break into small pieces, or just be buried in a snow. In any case, now it's lost.

Although I'm not a skillful ATTI mode pilot, I believe that this crash was not my fault: my brief analysis shows that the dangerous behavior of the drone began exactly at the moment of change from ATTI to P-GPS, and possibly due to hardware/software reasons.

The data:
- decrypted text log in .csv format (with GPS coordinates removed, as I don't want to share my home location to the whole Internet, and serials too.. just because) + last 20 seconds of flight from video cache: https://files.fm/u/qkhaav9c6
- my log analysis with [%number%] marks (attached)
- kmz track screenshot, just to show the situation (attached)

I can personally provide the original encoded .txt and .dat files to an experienced pilot who wants to dig into them (if he guarantees the confidentiality of my data). Or to DJI Support if they manage to contact me.

Best wishes, and stay safe!

P.S. can I claim for a place in the "Highest horizontal speed records" ranking?

Meaning no offence but I suggest you upload the .txt  flight to
https://www.phantomhelp.com/LogViewer/Upload/log on
and post the resulting URL here.
People may be happier to download the csv from there than an unknown website.

How did you get data from the DAT?

Your description of the incident contains all the elements of a yaw error which might have been caused by the location where you powered up the drone.
The loss of GPS at a certain height is strange, but matches what has been reported a number of times from your country.

If you want a proper analysis of the data to confirm whether it was caused by a yaw error and a more detailed explanation, pm the txt file and I'll get back to you.

It has happened to me (M2P) at night that the vision sensor detects something that does not exist and makes the drone move backwards on its own. I can only recommend turning off the anti-collision (OA) in an environment that is too dark.
But the theory of starting on a surface that has broken the compass calibration also holds true.
Send your file to Labroides, safe bet.

Sean-bumble-bee, I have used CsvView v.4.2.6beta, it returns errors if I try to make certain graphs but it allows to export data to .csv.
Labroides, PMed you the files, thanks for responding!

LV_Forestry, well, there was only a "low lights" warning on my screen, just the same as it was in previous flights. I usually start the flight either from my hand or from the ground, as it was this time.

knowsnow Posted at 1-5 14:53
Sean-bumble-bee, I have used CsvView v.4.2.6beta, it returns errors if I try to make certain graphs but it allows to export data to .csv.
Labroides, PMed you the files, thanks for responding!

Your GPS signal was interfered with at heights above 20 metres and there is no location data after 22 seconds.
This makes it hard to properly analyse the flight data.
From 20:15.3 GPS started to return but the position data it gave during the remaining 10 seconds of the flight was only approximate.
The crash occurred at 20:24.9.

But the description fits with a yaw error.
These are caused by powering up the drone at a place close to steel objects.
The most common is launching from reinforced concrete and the steel in the concrete deflects the compass to make it have false directional data.
The IMU uses the (false) data from the compass to initialise the gyro sensor.
When the drone climbs away from the magnetic interference, the compass reads correctly, but the gyro sensor can't and continues to give false directional information.

That doesn't cause a problem while there is no GPS data, but later when GPS reception is returning, the conflict in directional data between the compass and gyro starts to cause problems.
WHen the drone attempts to correct it moves in the wrong direction and corrects further,.
The flight controller continues to make hundreds of corrections, but with the incorrect gyro heading data, each correction is wrong and this results in very high speed, usually along a smooth curve, with no joystick input.

knowsnow Posted at 1-5 14:53
Sean-bumble-bee, I have used CsvView v.4.2.6beta, it returns errors if I try to make certain graphs but it allows to export data to .csv.
Labroides, PMed you the files, thanks for responding!

Thanks is the right hand side of the exported csv gibberish?

Labroides Posted at 1-5 15:32
Your GPS signal was interfered with at heights above 20 metres and there is no location data after 22 seconds.
This makes it hard to properly analyse the flight data.
From 20:15.3 GPS started to return but the position data it gave during the remaining 10 seconds of the flight was only approximate.

How close does a magnetic object need to be to affect gyro initialization?
The nearest steel thing around was a fence, at least 10 feet away from the takeoff point.
Do I understand correctly that in such a situation we'll not see any errors on the controller screen or in the txt log?
By the way, I have done a calibration process several flights ago...
There's also a repeating message throughout the .DAT event log: "[L-COMPASS]mag_status=1|".

knowsnow Posted at 1-5 16:44
How close does a magnetic object need to be to affect gyro initialization?
The nearest steel thing around was a fence, at least 10 feet away from the takeoff point.
Do I understand correctly that in such a situation we'll not see any errors on the controller screen or in the txt log?

How close does a magnetic object need to be to affect gyro initialization?
It varies with the size of the steel object.
It could be a nail or bolt if very close or a car a few metres away.

The nearest steel thing around was a fence, at least 10 feet away from the takeoff point.
That's probably not of concern.

Do I understand correctly that in such a situation we'll not see any errors on the controller screen or in the txt log?
You don't see an error message or warning in that situation.
Normally the only indication is the drone icon in the map screen not matching the direction the real drone is pointing.
I can't find indications of this in your flight data, but there are enough features of a yaw incident that I think it was the most likely cause.

By the way, I have done a calibration process several flights ago...
Recalibrating the compass makes no difference and won't prevent a yaw error from happening.
Normally there is no need to recalibrate the compass.

Labroides Posted at 1-5 17:23
How close does a magnetic object need to be to affect gyro initialization?
It varies with the size of the steel object.
It could be a nail or bolt if very close or a car a few metres away.

Thank you for taking the time to explain.

It seems that the best decision would have been to land immediately as soon as GNSS connection was lost. I'll try to remember another details, to understand why the other night flights without satellites from the same takeoff point were successfull, unlike the last one.

knowsnow Posted at 1-5 17:58
Thank you for taking the time to explain.

It seems that the best decision would have been to land immediately as soon as GNSS connection was lost. I'll try to remember another details, to understand why the other night flights without satellites from the same takeoff point were successfull, unlike the last one.

If you have had other loss of GPS incidents flying in the same area, I'd suggest flying somewhere else.