Battery Die?

[spirytus]

Ok humor me here as I am confused. .dat file I get it. Now when I go to DJI Assistant to retrieve the files I can see... File Index, Date, Data File. So I know I need the last flight. In what I see that is File Index 3. Now it is uploading and the file is 150.19MB It consists of an FC file and a Vision file. Both make up the .DAT file for that flight correct?

Yes, they're both saved and downloaded in the single compressed .dat file.

The trick is finding the right file for the flight in question since the FC starts recording every time you power up the drone. Make sure the date is correct (there is a timestamp as well). Actual flights are usually the biggest files posted for that date.

 

[Blade4]

Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-07-19_15-20-02.DAT

So here is the file I am pretty sure is the last flight. Finally got it to upload to Dropbox lol

 

[Fly Dawg]

This appears to be the correct file on a quick glance. Will need to look closer, but it does appear to confirm the battery disconnect on this first look. Will get back to you when I get the chance to look closer at the data, so take that with a grain of salt in thee interim.

 

[Blade4]

Awesome!! Thanks so much guys!!

 

[spirytus]

K, so I analyzed it and I'm sorry to say I don't think this is a battery issue;

1. There is no sudden voltage drop like I've seen in previous cases.
   
2. Right before all the motor data flat-lines, the gyro telemetry spikes all over the place (x, y, and z).

See attached screen shot. Gyro event highlighted in yellow.

Magenta are the gyro (primary is gyro0) readings (x, y, z).
Red are the motor speeds.
Black is motor voltage.

The gyro telemetry coincides with Flight Controller commands to the motors/ESC (not in my screenshot). I.E. Your phantom tried desperately to stabilize. If the battery disconnected you would not see these results.

All your motor speeds are relatively stable so that would rule out prop loss.

Based on the data provided, your mission profile and the location I would lean more towards a collision and almost definitely rule out a battery disconnect.

 

[Blade4]

K, so I analyzed it and I'm sorry to say I don't think this is a battery issue;

1. There is no sudden voltage drop like I've seen in previous cases.
   
2. Right before all the motor data flat-lines, the gyro telemetry spikes all over the place (x, y, and z).

See attached screen shot. Gyro event highlighted in yellow.

K, so I analyzed it and I'm sorry to say I don't think this is a battery issue;

1. There is no sudden voltage drop like I've seen in previous cases.
   
2. Right before all the motor data flat-lines, the gyro telemetry spikes all over the place (x, y, and z).

See attached screen shot. Gyro event highlighted in yellow.

Magenta are the gyro (primary is gyro0) readings (x, y, z).
Red are the motor speeds.
Black is motor voltage.

The gyro telemetry coincides with Flight Controller commands to the motors/ESC (not in my screenshot). I.E. Your phantom tried desperately to stabilize. If the battery disconnected you would not see these results.

All your motor speeds are relatively stable so that would rule out prop loss.

Based on the data provided, your mission profile and the location I would lean more towards a collision and almost definitely rule out a battery disconnect.

Very cool. BUT what was the ships altitude when this happened? I was able to google earth the telemetry of the LITCHI route. THEE location where the drone crashed was in an area that was forrested true. But the highest tree in that area above that location was max 30 feet. All the altitudes in the mission were based off the home point which is higher than any of those trees. In other words zero feet at home is almost 100' higher than any tree where it crashed. My 42 foot setting was 42 feet ABOVE HOME. So no way could the drone been that low unless something else was keeping the drone far too low. I had just flown a successful flight just prior to this flight. I watched through the video feed to ENSURE there was ample obst. clearance. Not to mention measuring according to the actual aircraft altitude in relation to home. Then I add at least 10 feet to each area in question. So Im afraid there is something else. I just want to know what happened. The good news is the drone is under DJI Care Refresh. Keep looking. Also can you share with me how you got those graphs and how to read them or where I can learn how to do this annalysis as well? Way cool how you guys can do this. Especially now I know how to get all the flight data. lol

Magenta are the gyro (primary is gyro0) readings (x, y, z).
Red are the motor speeds.
Black is motor voltage.

The gyro telemetry coincides with Flight Controller commands to the motors/ESC (not in my screenshot). I.E. Your phantom tried desperately to stabilize. If the battery disconnected you would not see these results.

All your motor speeds are relatively stable so that would rule out prop loss.

Based on the data provided, your mission profile and the location I would lean more towards a collision and almost definitely rule out a battery disconnect.[/QU

 

[spirytus]

Very cool. BUT what was the ships altitude when this happened?

I don't know man, accurate altitude is tricky business in drones because it's derrived from the barometer (measures change in air pressure) and it's reset to 0 at homepoint. Downward VPS is accurate to about 7meters and can miss outlining branches.

The terrain in this area is clearly sloped so who knows what the actual altitude was from ground at the time of the event. However, you can clearly see the drone slowly descending with terrain when it heads out to the clearing, then ascending back again when it was heading back.

You said you have the video feed for this flight? Post it on YouTube and share a link...

To analyze the data yourself open the day file in CsvView, select a blank graph an start selecting the data signals you're interested in.

 

[Timinator]

I don't know man, accurate altitude is tricky business in drones because it's derrived from the barometer (measures change in air pressure) and it's reset to 0 at homepoint. Downward VPS is accurate to about 7meters and can miss outlining branches.

The terrain in this area is clearly sloped so who knows what the actual altitude was from ground at the time of the event. However, you can clearly see the drone slowly descending with terrain when it heads out to the clearing, then ascending back again when it was heading back.

You said you have the video feed for this flight? Post it on YouTube and share a link...

To analyze the data yourself open the day file in CsvView, select a blank graph an start selecting the data signals you're interested in.

This is why I love this forum. There is always an interesting story and I almost always learn something. It's like participating in an episode of Mayday.

 

[Neon Euc]

Can we also rule a bird strike by any chance ? Maybe a bird went into the back of it trying to attack it. Just a thought. However well pleased at how the OP is not blasting DJI for a "useless" product like so many have done. Well done to the OP for handling this well and also to the other members jumping in to help. Wish I could help but I have no understanding of reading the files and looking at the charts

 

[Blade4]

Hey thanks! It be nice to get at least down to two theories on this it be wonderful if we could all agree on the causes totally.

No the birdstrike theory I had never thought about.

I've seen birds go after the drone all the time when it's down in this valley. The houses up on the hill that's true and the whole area was sloped that parts true but when I look at the Google earth version of my flight path it shows the flightpath definitely clearing all vegetation.

I'm traveling I'm out here in Denver getting set up and I'll look for that picture.

 

[Neon Euc]

I really do hope it's as battery latch issue mate. Then DJI will repair or replace it for free. At first they may argue against it. If so then fight it. I had the same situation and it dropped out the sky and DJI wanted to charge me £550 for it. I asked if they could relook at the log... They did... And fixed it for free

 

[spirytus]

I really do hope it's as battery latch issue mate. Then DJI will repair or replace it for free. At first they may argue against it. If so then fight it. I had the same situation and it dropped out the sky and DJI wanted to charge me £550 for it. I asked if they could relook at the log... They did... And fixed it for free

The FC logs certainly doesn't support this theory.

As I've said, in previous cases there was a rapid voltage drop right before the end of recording. In this case the gyro records what looks like a collision and keeps recording for some time further. Checking other signals right now (accelerometer, composite altitude, etc) You can clearly see that after this apparent collision the drone then remains relatively stationary for some time (likely stuck/struggling in the branches) before dropping to the ground at the end of the recording.

Can we also rule a bird strike by any chance ?

Yes, certainly a possibility, as is being hit by a projectile. Is it likely? nope.

Also, there's one more thing to be said here; You guys guys need to remember that the pilot was NOT in control here - Litchi was.

The OP stated that he set his waypoints relative to home point plus 42ft.

All the altitudes in the mission were based off the home point which is higher than any of those trees. In other words zero feet at home is almost 100' higher than any tree where it crashed. My 42 foot setting was 42 feet ABOVE HOME.

Yet looking at the original logs posted (link) you can clearly see the drone starting at 100ft (above home point) and descending with terrain as he moved away from the home point. Contrary to his statement, the drone is now below 100ft and descending, at its farthest point the drone was (relatively) at the same height as his home point (scroll down to 1m45s) of 0ft. The drone than moves north a bit and starts heading back from a different angle, slowly ascending with terrain.

I haven't used Litchi waypoint mission planner but to me it looks like it set the height of his waypoints relative to the terrain height rendered in google maps (good approximations but not reality).

To me it looks like this was a user error in mission planner. The drone, and likely litchi performed it's mission as instructed - and plowed into terrain as a result.

Edit: Corrected height values to coincide with what was said, and what was logged.

 

[spirytus]

One more thing I want to mention not to put all the blame on the user...


The solidstate barometer DJI uses is not a precise instrument and is prone to some erroneous readings.

I remember helping one guy whose Inspire 1 and phantom 4 were unable to stay level in forward flight after he flew them both in the desert.

His drones would bleed altitude and would end up a foot from the ground if he flew them in a straight line for a mile or so. The barometer reading would spike when he flew forward so the FC adjusted to compensate thinking it was flying level, were infact it was descending.

That's what I mean about drone altitude readings being tricky business. The Flight controller is quite oblivious when it comes to reality and sensors can be erroneous without giving a warning.

 

[BudWalker]

....... You can clearly see that after this apparent collision the drone then remains relatively stationary for some time (likely stuck/struggling in the branches) before dropping to the ground at the end of the recording.

.......

This didn't actually happen. But, it's a little tricky to see why. There aren't any data between 226.479 secs and 457.065 secs. (CsvView could be better in showing this.) The reason is that there was an abnormal abrupt end that occurred while recording the .DAT. This can happen when there is an abrupt power loss.

The reason for the gap is that the .DAT is recorded in a sequence of blocks with each block containing several records. When the .DAT isn't closed properly the last block in the .DAT will contain records from a previous .DAT that has been deleted.

To see this better I like to run DatCon at the highest sample rate and then use CsvView to look at the .csv generated by DatCon

So while this tends support the theory that it was a battery disconnect it's also true that there is no apparent voltage collapse. The gyro data in the last sec certainly makes it look like it was hung up in some branches.

 

[spirytus]

This didn't actually happen. But, it's a little tricky to see why. There aren't any data between 226.479 secs and 457.065 secs. (CsvView could be better in showing this.) The reason is that there was an abnormal abrupt end that occurred while recording the .DAT. This can happen when there is an abrupt power loss.

The reason for the gap is that the .DAT is recorded in a sequence of blocks with each block containing several records. When the .DAT isn't closed properly the last block in the .DAT will contain records from a previous .DAT that has been deleted.

To see this better I like to run DatCon at the highest sample rate and then use CsvView to look at the .csv generated by DatCon
View attachment 101516

So while this tends support the theory that it was a battery disconnect it's also true that there is no apparent voltage collapse. The gyro data in the last sec certainly makes it look like it was hung up in some branches.

Thanks Bud, was wondering what caused that large data gap and why it rendered.

I'll stick to my guns though; Root cause is not due to a battery disconnect.

By the way, what's the best signal to check for altitude? I see several and none of these jive with the app log.

Also, if I can make a suggestion for CsvView; Can you add the SI units used in the axis labels (if known)?

 

[BudWalker]

Thanks Bud, was wondering what caused that large data gap and why it rendered.

I'll stick to my guns though; Root cause is not due to a battery disconnect.

By the way, what's the best signal to check for altitude? I see several and none of these jive with the app log.

Also, if I can make a suggestion for CsvView; Can you add the SI units used in the axis labels (if known)?

By the way, what's the best signal to check for altitude? I see several and none of these jive with the app log.

General:relativeHeight should match the altitude seen in the app.

Also, if I can make a suggestion for CsvView; Can you add the SI units used in the axis labels (if known)?

Poof. It is done.

Try this

 

[BudWalker]

...

By the way, what's the best signal to check for altitude? I see several and none of these jive with the app log.
...

GPS:heightMSL can be useful sometimes.

 

[spirytus]

By the way, what's the best signal to check for altitude? I see several and none of these jive with the app log.

General:relativeHeight should match the altitude seen in the app.

Also, if I can make a suggestion for CsvView; Can you add the SI units used in the axis labels (if known)?

Poof. It is done.

Try this
View attachment 101517

There it is, easy to miss, thanks. The x axis could use one too (Time [seconds]) and 0 = motor start (for those times when you post a screenshot and the uninitiated read the graph). Final two cents.

Keep up the great work.

 

[BudWalker]

There it is, easy to miss, thanks. The x axis could use one too (Time [seconds]) and 0 = motor start (for those times when you post a screenshot and the uninitiated read the graph). Final two cents.

Keep up the great work.

The time axis offset isn't always the same. It's chosen by DatCon which tries to be smart. The choices, in order are
1. The same as what is is seen in the Go App. This makes it easy to compare a converted .txt to a converted .DAT for the same flight.
2. Motor start, if there is one.
3. BatteryOn

 

[Blade4]

Wow Gents!! What great data analysis!!! We need to send in our info here with resumes for the NTSB!! LOL Way cool.

Ok. The reason I am not completely on board with the Terrain Strike Spyritus is due to the video feed image, for one. For two, the drone went out and did not hit anything. For three, on the way back which you analyzed PERFECTLY, the drone would have been high enough due to the last images I have, that it would have been above the HIGHEST trees on the mission. ok...

Those trees in my mission that the drone were about to clear right before (power loss and or collision) were about 80 to 90 feet high. The exact location of where I recovered the drone was no way near those 80 foot trees. Those trees which is not depicted on Satellite imagery are exactly and precisely under waypoint two and five. The trees that were at the location I recovered the drone were only 25 feet high max. So the only thing that would lend it self to a collision with those trees would have been some kind of altitude error with the drone.

What I was going for was a nice close flyby of the 90 foot trees. This mission objective was a potential real estate shot to bring to a realtor friend.

Finally the drone had flown this mission JUST Prior to this collision or battery loss. With no problems.

I did adjust the altitude of waypoint 5 to the lesser value but the trajectory just does not support hitting a 25 foot tall tree between waypoint 4 and 5. The drone would have had to have flown nearly level between 4 and 5 then it would have had to pull a massive climb from the point of lost data where it shows on the map, and waypoint 5. Could that have been a programming issue with me. 80% chance of no. But it could have been.

Here is more. I had a Right Rear Sensor Camera that was not functioning. That issue took out ALL ability for the P4P to have any collision avoidance. So I had a local drone repair shop put in a new camera. That did not fix the problem. I had noticed on testing that the P4P would vary altitude low to the ground. By about two feet. So whatever altitude information going to the flight controller was quite possibly a factor in this. I do not think it was accurate, but not enough to cause the above collision. I tried to calibrate sensors on DJI Assistant to no avail. The tech who did my repairs was suspect of the 3 in 1 board. I was planning on using my DJI Care Refresh to have that fixed since that is a $300.00 board as well as an additional control board the tech had said was about $400.00 to replace. Too much for me to spend on a $1500. drone considering that whole bunch of repairs may have lead to more rabbit holes maintenance wise. So I figured I would simply fly without the sensor working. Those sensors do not see trees without leaves so they are only useful if you are heading for something big and solid which I am fairly good at avoiding. LOL. Who knows. I would REALLY LOVE to know the most accurate data available at the time of impact/power loss. Thanks for the help on this guys.