Requesting P3A log analysis

[Spike Ike]

Greetings fellow pilots. I had a crash recently and have no idea what happened. I have reviewed the logs and googled diligently without success. So I am gonna detail everything I can here in the hopes that a drone guru will read this and take pity on me, and perhaps illuminate my situation. This has nothing to due with warranty, I just want to know what happened to prevent recurrence. I pre-apologize for information overload, but it seems like most help needed posts are followed by many questions, so I want to flesh this out and arm our guru with all the info he needs. Brief history; I have had a few little incidents with my bird, but only one major crash before this. It was not long ago - I hit a tree and Jasper (my P3As name) fell about 40ft. breaking the L shaped gimbal arm and ribbon cable. I repaired him myself, and had several great flights since. All seemed well. Then I got a large new Samsung tablet and took a nice flight around my home. Worked fine, but one time, with DJI Go running but my AC off, I pulled the cable out by accident. My tablet crashed and was completely off, requiring a restart. Odd, as I have never seen that with my phone. Note to self, be cautious with cable. Next morning I went to a nearby lake for some sunrise footage. As I started everything up I noticed some weird blue ... bands of pixilation on my screen. I looked and the camera was kinda sitting in some grass, so I picked it up and moved it. The bands were gone. As Jasper finished warming up I got a warning from DJI Go. "Flight mode restricted to 50m X 30m." Never got that before. In my consequent research I think it was the not logged in to DJI Go thing introduced in a previous patch. I was logged in at my home the day before, so I should still have been, even though I had no wifi and no cell data at the lake. At the time I had no idea why the restriction, but with no other warnings I cautiously took off. I flew around for ~3min. Flight, camera, ect all worked normal except when I reached the distance limit and Go warned me that I could go no further out. Same with height restriction. It was weird to fly into an invisible wall, but otherwise everything worked perfectly fine. I landed and rebooted both AC, con, and Go app. I got no warning this time, and a normal startup. I raised up maybe 12ft. and paused, then took off right over the frozen lake. I went straight ahead, and was throttling up gaining altitude. About 30M out Jasper instantly just went 100% haywire, spinning violently fast on all axis. In a couple of seconds he was smashing down onto the ice. Signal strength, battery... every parameter I looked at seemed fine as far as I could tell. All the charts seem to have nice gentle arcs, then right at the end everything just shoots from one maximum to the other 30 times a second for the two seconds or so it takes until the bitter end. Here is a link to a google drive folder of mine. https://drive.google.com/drive/folders/1uW0IRKUl4h_JktHOgsbtJeVRdZWNYfvo?usp=sharing
DJI Crash - Google Drive
It has the .txt files for both the short flight before, and the crash. It also has the .csv and the .DAT files for the crash flight. Additionally, it contains the controllers video for the crash. Small file, as it is only ~10 seconds long. Here are two more links to Airdata for the same two flights as well.
Airdata UAV - Flight Data Analysis for Drones
Airdata UAV - Flight Data Analysis for Drones
The place where the incident happened seems to be where the "invisible wall" from the previous flight was. Kinda makes me suspicious of the new tablets involvement in this mess. But even if i took a hammer to the tablet, I thought the bird should just lose signal and RTH. But who knows. Jasper broke part of his gimbal. He ejected his battery, and it has a few cracks. I have fired him up as I retrieved his .DAT files, and he mostly seems OK. The camera was clicking and struggling a bit. As I examined it I noticed the ribbon cable was bound up a bit at the point where it wraps around twice. I worked it until it smoothed out, restarted the AC, and the camera did it's normal dance and locked into position normally. I have to replace the gimbal mount plate, then see what happens. Hopefully a few of you wonderful people will chime in here with some expert analysis and advice for me. Thank you for your time and consideration.

 

[LarBear360]

DJI Flight Log Viewer - PhantomHelp.com

DJI Flight Log Viewer - PhantomHelp.com

I could not detect anything in the logs. Links posted above for everyone's convenience.

The video looks like mechanical failure. All I can imagine is a prop flew off or someone took it down with a snow ball.

 

[Fly Dawg]

Just a quick glance at your data. You did not mention this in your post, but according to this data you were flying in Atti, with no GPS lock. Is this true? If so, that explains no RTH. Will look farther assuming you confirm this is correct.

 

[Fly Dawg]

The first chart indicates flying in Atti, as I mentioned. The second one, shows your described out of control tumble. As @LarBear360 mentioned, this looks very much like loosing a prop than anything else, but there is no motor data in the .dat file to analyze that. The tumble began at approx 15.3 seconds.

 

[Fly Dawg]

Sattelite's from the Device Log are different. Unless the .dat file is not the correct file, it indicates no acquisition.

 

[Spike Ike]

Thanks for the replies. I was in GPS for the first trip 100% for sure. Basically I wanted to do a fast reboot to see if that would lift the restrictions. Usually I kinda do a careful pretrip, but I did just do a flight and this was not a normal land, change batteries, assess. ect. I did not give the bird much time to acquire satellites, to be sure. I had the green bar on my display, but can't say if it was GPS or what. But given the short time it is very doubtful. Definitely a dumb mistake. Geez, it is so easy to miss things like that. I see now that in my haste I kinda took this as the same flight, with a pause in it. But every restart is a 100% new flight. Still, even with that, the bird should not have freeked out as it did, should it? It was like it was hit by a shotgun, all at once. I should have it repaired and get a chance to take it out later today. Any other thoughts, insights, or advice would be much appreciated.

 

[Spike Ike]

Also, there was one prop missing the tip. Perhaps the last few centimeters were broke off. I assumed that happened as it hit the ice, but who knows.

 

[Fly Dawg]

Just out of curiosity, what firmware version were you running on the AC? I notice your data files are quite limited in the data they provide. My own personal logs are much more extensive in detail, and I am running very old firmware on my bird. Just curious as to the large discrepancy in available data.

 

[BudWalker]

The first chart indicates flying in Atti, as I mentioned. The second one, shows your described out of control tumble. As @LarBear360 mentioned, this looks very much like loosing a prop than anything else, but there is no motor data in the .dat file to analyze that. The tumble began at approx 15.3 seconds.

View attachment 95184 View attachment 95185

Took me a while to figure out where the first plot came from. It was from the .DAT the OP submitted? Anyway, that .DAT isn't the correct .DAT - there was no motorStart, etc.

 

[Spike Ike]

I have...
App 3.1.28
Version 1.11.20
RC 1.9.2
Flysafe DB 01.00.01.07
Out of curiosity I have added a .DAT file to the google drive folder with my other logs in it.
DJI Crash - Google Drive
It is about 20 flights back. I am curious as to if you see different data available. It should be before both bad crashes I had.
Again thx so much for your interest. I will post tomorrow with details on my next flight attempt.

 

[Fly Dawg]

I have...
App 3.1.28
Version 1.11.20
RC 1.9.2

Hmmm....Then there is something that I don't understand. Both of your device logs, both from Airdata and Phantom Pilots conversions is only 39 Data points ( Columns in the csv). My own logs in comparison, and BTW I am running 1.8.8 on the AC is 90 data points. I don't think this lack of data is previous crash related, but can't be 100% certain of that.

 

[Fly Dawg]

@BudWalker Yes, that plot was from the OP submitted .Dat file. I though it might not be correct when I stated no motor data in my post.

 

[BudWalker]

Thanks for the replies. I was in GPS for the first trip 100% for sure. Basically I wanted to do a fast reboot to see if that would lift the restrictions. Usually I kinda do a careful pretrip, but I did just do a flight and this was not a normal land, change batteries, assess. ect. I did not give the bird much time to acquire satellites, to be sure. I had the green bar on my display, but can't say if it was GPS or what. But given the short time it is very doubtful. Definitely a dumb mistake. Geez, it is so easy to miss things like that. I see now that in my haste I kinda took this as the same flight, with a pause in it. But every restart is a 100% new flight. Still, even with that, the bird should not have freeked out as it did, should it? It was like it was hit by a shotgun, all at once. I should have it repaired and get a chance to take it out later today. Any other thoughts, insights, or advice would be much appreciated.

There wasn't any problem with GPS - gpsHealth was 5 and numSats was 16. As pointed out by @Fly Dawg and @LarBear360 the incident was caused by either a broken/lost prop or a motor issue. Initially the P3 pitched up, rolled left and rotated CCW - all consistent with the leftBack losing propulsion.

 

[Meta4]

The place where the incident happened seems to be where the "invisible wall" from the previous flight was. Kinda makes me suspicious of the new tablets involvement in this mess. But even if i took a hammer to the tablet, I thought the bird should just lose signal and RTH.

The second flight is OK up until 0:15.5 when things go wrong.
Despite the left stick being pushed forward, the Phantom starts to lose height as well as tumbling and spinning.
BudWalker has explained what happened.
This had nothing to do with the tablet and was due to a hardware failure that stopped the left rear motor.
Your Phantom still maintained full signal and full GPS as it tumbled downwards.

 

[Spike Ike]

OK, first off I'd like to thank you all for your help and insight. Like any relationship, the bond between me and Jasper is largely based on trust. I have to admit, mine was a bit shaken. We had our ons and offs, but I was starting to think that he had crossed a line. You helped restore my faith in him, and we have had several long flights together since. It took a little glue to his gimbal base plate, some minor wire reconstruction, and some prop swaps, but all seems well. He still has not accepted any of the blame for his fall, but I have opened my heart and all is forgiven. I now truly understand what people mean when they say love gives you wings. It LITERALLY has.

 

[quaddamage]

Could you help me with how to get to the conclusions drawn here? Looks like I lack experience in log analysis, please let me know where are my mistakes.

I'm not looking at CSV, I am using Wireshark to look at the packets. There was a function added recently which exports the flight log to Google Earth. From the export of FLY100.DAT I can see that was a nice flight, lasted from 15:11:04 to 15:22:10. The drone landed by being catched by hand, and during the last 25 seconds I can clearly see someone is carrying the drone towards the road.

Looking at the packets directly, besides the fact that GPS battery must be bad (the drone thinks it is 2013 for a first few seconds), everything looks ok.

For the second flight - FLY121.DAT - the Google Earth export fails to create any meaningful data. But looking at the packets directly, I can see the GPS never gets a single satellite and thinks it's 2013 for the whole flight (I set filter to "dji_p3.rec_etype == 0x0005" to look at it in Wireshark). I can also see that there is no spinning - as soon as the drone starts getting data from IMU, it realizes it is upside down, and there is no movement from that position (filter "dji_p3.rec_etype == 0x000c").

Is the spinning only in txt files?

EDIT: here's the KML, zipped to KMZ, in case someone wants to try Google Earth:
Uploadfiles.io - FLY100.kmz

 

[Meta4]

Could you help me with how to get to the conclusions drawn here? Looks like I lack experience in log analysis, please let me know where are my mistakes.

Upload your .txt file to the Phantomhelp.com log viewer/
Look at the report it provides and the CSV file it gives as well.

 

[quaddamage]

Ahh, I see. So the FLY121.DAT provided is not the one from the crash, as Fly Dawg suggested.
Thanks @Meta4.
I wonder if I can load the txt file to Wireshark.. will try.
EDIT: No, that won't work sadly.

 

[sar104]

Could you help me with how to get to the conclusions drawn here? Looks like I lack experience in log analysis, please let me know where are my mistakes.

I'm not looking at CSV, I am using Wireshark to look at the packets. There was a function added recently which exports the flight log to Google Earth. From the export of FLY100.DAT I can see that was a nice flight, lasted from 15:11:04 to 15:22:10. The drone landed by being catched by hand, and during the last 25 seconds I can clearly see someone is carrying the drone towards the road.

Looking at the packets directly, besides the fact that GPS battery must be bad (the drone thinks it is 2013 for a first few seconds), everything looks ok.

For the second flight - FLY121.DAT - the Google Earth export fails to create any meaningful data. But looking at the packets directly, I can see the GPS never gets a single satellite and thinks it's 2013 for the whole flight (I set filter to "dji_p3.rec_etype == 0x0005" to look at it in Wireshark). I can also see that there is no spinning - as soon as the drone starts getting data from IMU, it realizes it is upside down, and there is no movement from that position (filter "dji_p3.rec_etype == 0x000c").

Is the spinning only in txt files?

EDIT: here's the KML, zipped to KMZ, in case someone wants to try Google Earth:
Uploadfiles.io - FLY100.kmz

I've read your post several times and I cannot figure out what you are doing - I must be missing something obvious. So you have the two DAT files somewhere, but which interface is Wireshark watching and how is watching an interface showing you packets of data from those files? And you mention that a function was added to export the flight log position data to a kml. A function in which application? Which GPS battery is bad? It's been a while since I was that baffled by a post on this subject. Can you elaborate?

 

[quaddamage]

So you have the two DAT files somewhere

I downloaded the DAT files provided by Spike Ike in first post.

but which interface is Wireshark watching and how is watching an interface showing you packets of data from those files?

I'm not watching an interface, i used "open" to read a packet file (.pcap) stored previously.
And to get the .pcap file, I converted .DAT:

./comm_dat2pcap.py -vvv -u 3 -e -d FLY100.DAT

And you mention that a function was added to export the flight log position data to a kml. A function in which application?

Wireshark can't understand DJI protocol by itself. You have to install dissectors:
dji-firmware-tools/README.md at master · o-gs/dji-firmware-tools · GitHub

The export plugin is included in these dissectors. It adds a new option to "Tools" menu.

Which GPS battery is bad? It's been a while since I was that baffled by a post on this subject. Can you elaborate?

There is a button battery on the GPS board. I would conclude that this battery supports real time clock, as most drones are somehow able to know current time even with no GPS lock.
It is just a guess though, I never tried messing with the battery.

EDIT: And in case you'll be wondering if converting/opening/exporting has hanged - no, it really goes that slow. Just let it run in the background and watch some YT.