Day 2 on Mavic - failure and crash

[taus]

Thank you so much BudWalker! I really appreciate you taking the time. It is really tough having waited for 5 months for the drone and then getting 5 minutes of use....

Very strange that there even is a FLY004 if they are written in sequence. I guess FLY004 could have been the result of powering on the drone indoors after the incident? Because no flying is possible after the crash for sure!

So, what do you think it could be?

And can we rule anything out? I know it was not a collision, but is that obvious from the DAT file?

The fact that it goes into GPS Atti mode right before the crash is strange too. Because it had a very strong GPS signal just before.

It loses GPS, then connection to the controller and then falls like a rock...

 

[BudWalker]

Thank you so much BudWalker! I really appreciate you taking the time. It is really tough having waited for 5 months for the drone and then getting 5 minutes of use....

Very strange that there even is a FLY004 if they are written in sequence. I guess FLY004 could have been the result of powering on the drone indoors after the incident? Because no flying is possible after the crash for sure!

So, what do you think it could be?

And can we rule anything out? I know it was not a collision, but is that obvious from the DAT file?

The fact that it goes into GPS Atti mode right before the crash is strange too. Because it had a very strong GPS signal just before.

It loses GPS, then connection to the controller and then falls like a rock...

A .DAT is created every time the battery is turned on. I looked some more at FLY004 and the IMU temp started at 29.4 C indicating that the batteryOn occurred while the Mavic was cool. The IMU temp will rise to 65 C after a couple of minutes.

The end of the recording doesn't show a large acceleration event indicating there was no collision. Also, the Mavic was in GPS_ATTI mode for about 100 secs prior to the end. GPS_ATTI is not the same as ATTI. ATTI is when gps isn't being used. GPS_ATTI is when gps is being used. Maybe you got confused by the AirData presentation? It won't be the first time. There was no loss of GPS in this incident.


What do I think it could be? Don't really know. Doesn't seem to be a loss of power because of a battery coming loose or some internal power interruption. Maybe some kind MC failure. The answer I'm most comfortable with is - don't really know.

Don't let DJI tell you it's not covered under warranty.

 

[taus]

Thanks again. I really do apologize for my ignorance but what is an MC?

 

[BudWalker]

For anybody who wants to look at FLY004 the attached .zip has the .csv at 200 HZ
@Robbyg @Cyberpower678

 

[BudWalker]

Thanks again. I really do apologize for my ignorance but what is an MC?

Sorry. Master Controller. It's the main board where most of the processing is done. But, I just realized if it was fried then you wouldn't have been able to retrieve the .DAT files. So I'm back to I really don't know the cause.

 

[Robbyg]

For anybody who wants to look at FLY004 the attached .zip has the .csv at 200 HZ
@Robbyg @Cyberpower678

I will take a look at this mystery later tonight.
BTW Budwalker the first two factory files probably contain all the movements done during IMU calibration. Can you confirm?

Rob

 

[Cyberpower678]

I would help but can't at the moment. I'm traveling. Sorry guys.

 

[taus]

@Robbyg, did you manage to take a look last night?

 

[BudWalker]

@taus, @Robbyg noticed an anomaly in the .DAT files that I hadn't noticed. FLY002 and later aren't recording some of the battery data in the usual way. FLY001 and before seem to be OK.

FLY001 took place at [2017-4-7]16:53:27 and the activation was done at time:16-55-45. Did you also do a firmware upgrade to 01.03.0550 before or after the activation? And, was there a problem with the firmware upgrade?

 

[taus]

I did the firmware upgrade to 01.03.0550 when I first turned on the drone. It prompted me to do so, so I did it. Then I did calibration (90% sure it was in that order) and went flying.

The firmware upgrade seemed to go just fine. The drone restarted and everything was fine.

 

[Robbyg]

We found something odd but I will let Budwalker explain it as he has a clearer grasp of what it might be than I do.

Rob

 

[taus]

Thanks, I am waiting in suspense!

 

[BudWalker]

Thanks, I am waiting in suspense!

Before I get to the details it should be emphasized that your Mavic needs a trip to DJI repair and that it's a warranty situation. There isn't much that's been said here that changes that. It's a new Mavic that had a catastrophic failure on the first flight. So far, the only thing relevant here is the determination that it was not a mid-air collision. That, and you followed DJI instructions.

There is something odd about the .DAT files. And, it does seem to coincide with the firmware upgrade. But, we really don't much more than that. It could be just a coincidence; a little hard to believe, but coincidences do happen. Or, it could be that the odd .DAT record structure is symptomatic of some issue that is at the root of the catastrophic failure.

The difference with these .DAT files is that the record type 176_36 which contains the battery info doesn't occur. When this happens CsvView/DatCon can get only a subset of the battery info from a different record type (208_35). This was the case with the very early firmware versions where the .DAT didn't have the 176_36 records. And that's the case with your .DAT files FLY002 and higher. I.e., they do not contain any 176_36 records. I've checked my Mavic that I upgraded to 01.03.0550 this morning as well as 4 other Mavics at 01.03.0550. None of those have the missing record type 176_36 problem.

Got all that? It doesn't really add much in trying to determine what went wrong. But, as I said it shouldn't affect the warranty determination in a material way.

 

[Robbyg]

What he is saying for those not familiar with the 176_36 or DAT files is that when we look at the record of the flight we do not see any information being recorded as to how much CURRENT (Amps) is being used by the Mavics motors or any of its systems. This also means that we have no power reading from the individual Mavics motors. The Data is just blank!

I think Budwalker is being cautious because we have never seen this before and we do not know why it has happened. Last night I looked at several other logs and they all had power info but this one was unique.

WHAT DOES IT ALL MEAN?

Well it means that either something was broken in the DJI software and it just stopped recording the data. That could also mean the the CPU had no idea how much power was being drawn by each motor and that could have triggered a shutdown in mid air.

It could also mean that the Data was being monitored and recorded but not stored in the right places for DATCON to pick them up.

It could also just be a recording issue caused by some kind of firmware glitch and it had no bearing on the crash whatsoever. IMHO it's a little too coincidental that we find this odd log info in a Mavic with a properly latched battery that just shut off in Mid Air and crashed. As Budwalker said this is definitely a case of a defective Mavic and it seems to be a one off incident that is most likely caused by something going wrong with the firmware when it was updated by the DJI software.

Rob

 

[taus]

It sounds like you people really know your stuff! Thanks for investigating.

It is a big contrast to talking to DJI support. I think they are very understaffed. Probably nice well-meaning people, but I tried to write an email to explain a bit more about what happened and they just write back and ask me to fill out forms to return the drone. I explicitly tell them that I already did, but they ignore and ask me to do it again. To be honest, I think they do not really have time to read the emails but just send a reply based on what is in the headline of the email.

It sounds reasonable that the drone would crash if it did not have the means to control power consumption. A glitch in firmware update sounds a bit strange. I would think they had checksums and that the software would fail if installed improperly but I guess it could explain it.

Anyway, on another forum I got in touch with a person who had a very similar story. This is his flightlog: http://app.airdata.com/main?share=rxSTGo. As you can see, it was lost over water so no DAT files from him. However, he also updated to the same version just before first flight.

Grasping for straws, we compared serial numbers:

08QDE3Q01202PQ (Mine).
08QDE3Q01203LL (His).

Then this other person told me about a serial decoder tool http://djiserialdecoder.x10host.com/

It turns out both drones were

1) Produced Friday the 24th of March
2) Updated to the 01.03.0550 just prior first flight
3) Crashed with similar log on the very first flight. (First time it was turned on in order to get airborne to be exact. Min landed twice before the crash and his landed once before the crash, but running on very first battery ever).

I know I am way into conspiracy theory here… but who knows? It might have been a bad production batch of some kind.

Now I have the interesting challenge of how to communicate this to a company whose support staff only read the subject line of support emails. J

Thank you once more!

You guys rock!

 

[Aidi]

Although i have been flying drones for a while, i am new to the Mavic... Being a member of this forum is very inspiring. The time and effort that fellow pilots goto to help each other in general and incidents like this nothing short of amazing.

I know DJI have some faults but it does seem that with the assistance of forum members to assist in log analysis they seem keen to maintain their reputation and if the proof is there, they will assist in replacing lost/damage drones etc.

I have a new faith in some of humanity being a member on here!

 

[JLane]

@Robbyg and @BudWalker, there's another case on the DJI forums where the OP claims his Mavic dropped like a stone, and this is one of the few other cases where the .dat files seem to be available for analysis. Perhaps you'd like to take a look and see if the anomaly also exists in those files.

The thread is here: My Mavic Pro crashed! After updating the Firmware

And the .dat files here: MEO Cloud - Mavic Logs

 

[flipf]

It sounds like you people really know your stuff! Thanks for investigating.

It is a big contrast to talking to DJI support. I think they are very understaffed. Probably nice well-meaning people, but I tried to write an email to explain a bit more about what happened and they just write back and ask me to fill out forms to return the drone. I explicitly tell them that I already did, but they ignore and ask me to do it again. To be honest, I think they do not really have time to read the emails but just send a reply based on what is in the headline of the email.

It sounds reasonable that the drone would crash if it did not have the means to control power consumption. A glitch in firmware update sounds a bit strange. I would think they had checksums and that the software would fail if installed improperly but I guess it could explain it.

Anyway, on another forum I got in touch with a person who had a very similar story. This is his flightlog: http://app.airdata.com/main?share=rxSTGo. As you can see, it was lost over water so no DAT files from him. However, he also updated to the same version just before first flight.

Grasping for straws, we compared serial numbers:

08QDE3Q01202PQ (Mine).
08QDE3Q01203LL (His).

Then this other person told me about a serial decoder tool http://djiserialdecoder.x10host.com/

It turns out both drones were

1) Produced Friday the 24th of March
2) Updated to the 01.03.0550 just prior first flight
3) Crashed with similar log on the very first flight. (First time it was turned on in order to get airborne to be exact. Min landed twice before the crash and his landed once before the crash, but running on very first battery ever).

I know I am way into conspiracy theory here… but who knows? It might have been a bad production batch of some kind.

Now I have the interesting challenge of how to communicate this to a company whose support staff only read the subject line of support emails. J

Thank you once more!

You guys rock!

 

[dbyantis]

@Robbyg and @BudWalker, there's another case on the DJI forums where the OP claims his Mavic dropped like a stone, and this is one of the few other cases where the .dat files seem to be available for analysis. Perhaps you'd like to take a look and see if the anomaly also exists in those files.

The thread is here: My Mavic Pro crashed! After updating the Firmware

And the .dat files here: MEO Cloud - Mavic Logs

Not to be ignorant, but I thought that the "DAT" file was from the device that was running GO4, why does the MP need to be physically located to get the DAT?

 

[flipf]

This is perhaps the best thread i have read on this forum, even when faced with calamitous results, the need to understand the genesis of the problem plagues intelligent and educated people until they get a answer. unfortunately I find myself in this position more often than should be allowed.Thanks to #Robbyg and #BudWalker for their time and efforts and empathy for the fact that this will "Bug" them until it is resolved.
Also to #taus your contribution to this discussion can not be underestimated. You aren't sitting back and hoping others solve your problem. Your research and postings will help immensely. Even though it happened to you it will help us all

Thanks to all