P4 disconnected in flight, found with battery missing

[F3honda4me]

The height you can fly near an airport gets lower the closer you get to the NFZ.

Looking at the screenshot and comparing to the DJI map, DJI is correct. You flew into a yellow restriction zone that requires authorization to fly. So it would first hover automatically in place. It would then return home at a very limited altitude because of being inside and then so close to the zone.

 

[F3honda4me]

For reference, here is the yellow restricted zone and a blue dot where this incident took place.

 

[F3honda4me]

My son received an email, but it did not contain a conclusive analysis. Here is the text:

"After re-reviewing your flight analysis, the conclusion will remain as previously stated.
The aircraft was too close to an airport and the altitude was limited due to safety and regulation concerns.
The Return to Home Function operated normally, however due to the environment and restriction of height distance, the unit struck and object.
However, there were no hardware, software or application malfunctions detected. Based on this data our data analysts were unable to apply warranty.
Please refer to the data attached to this email."​

Here are the two screen shots that they provided, which are from the on-board flight log:

We have several issues with this analysis:

1. As with the previous email, it refers to being in proximity to the airport (circled in red on the first picture) but does not explain what flight rule caused the drone to change altitude. You can see that we were nowhere near the NFZ.
2. The statement that the "Return to Home function operated normally" is wrong. In the second picture, the commanded RTH is circled in the text field below the graph. However, the drone did not return to home. In the low-resolution text at the bottom of the top picture, it indicates "fail-safe action hovering", yet that is not the way my son programmed it to respond to loss of contact. As you can see from the behavior in the first flight of the day, when RC connection was lost, it initiated a RTH.
3. The email also repeats the claim that it flew into an object, yet there is no proof of that (picture, video, etc.).
4. The second picture shows the altitude, and has data showing the drone went into hover at 20 meters, which it held for about 250 seconds. Based on our reading of the wiki page linked in the first post, that is the altitude limit at the boundary of a no-fly-zone (i.e. the red circle in the top picture). We were clearly not anywhere near the no-fly-zone!!!
5. Look at the title of the window in the second screen capture - "Viewer (build v1714) vision 1.25.11 with some unknown bug" - it basically says it all right there...

We would like to learn from this, but we have been given no explanation that we can use to change our future flight plans. This seems to be a blatant attempt to avoid responsibility on the part of DJI. Our understanding of the altitude restricted flight zones is outlined in one of my earlier posts. I'd love for someone to explain how the drone flew into an area that it thought it should be hovering at 20 meters when my son followed the rules and commanded a RTH when he reached the boundary of the Authorized Flight zone. After 4 minutes, were the batteries depleted enough to trigger an auto-land? I could definitely see that causing the drone to strike a tree, since there were trees in the vicinity. The failsafe return to home should have protected from this scenario happening.

1. You were in fact in a restricted zone.

2. Fail-Safe action hovering is correct, this is what the drone is supposed to do when you fly into a restricted zone. If it loses connection to RC and is in a restricted zone, it will hover for a period of time before returning to home. And when it does return to home, it will do so at a lower altitude per the normal procedure when flying near a restricted zone. (the closer you are, the lower it goes, the farther you are, the higher it goes)

3. When the aircraft impacts an object, it knows, and this is put into the text log file. It can also tell if this collision occurs mid air or near the ground, and it will say as much in the log.

4. You were in the restricted zone.

5. That's just a program title... It's not talking about the drone.

If you had gotten the DAT file from the craft we could have also gotten all of this information. When you get the craft back, if the DAT file is still there we could still read it for you, but it will likely just verify what DJI has said.

The lesson to learn from all of this is to make sure you fully understand where the restricted flight zones are, how they work, and to avoid them. Learn more about the DJI GEO system here. DJI GEO System - Up-to-date Information On Where to Fly Personally I would never fly to the west of where you took off from as that takes you right into the restricted zone. It's unfortunate, but at least the drone is repairable!

 

[WBN3]

1. You were in fact in a restricted zone.

2. Fail-Safe action hovering is correct, this is what the drone is supposed to do when you fly into a restricted zone. If it loses connection to RC and is in a restricted zone, it will hover for a period of time before returning to home. And when it does return to home, it will do so at a lower altitude per the normal procedure when flying near a restricted zone. (the closer you are, the lower it goes, the farther you are, the higher it goes)

3. When the aircraft impacts an object, it knows, and this is put into the text log file. It can also tell if this collision occurs mid air or near the ground, and it will say as much in the log.

4. You were in the restricted zone.

5. That's just a program title... It's not talking about the drone.

If you had gotten the DAT file from the craft we could have also gotten all of this information. When you get the craft back, if the DAT file is still there we could still read it for you, but it will likely just verify what DJI has said.

The lesson to learn from all of this is to make sure you fully understand where the restricted flight zones are, how they work, and to avoid them. Learn more about the DJI GEO system here. DJI GEO System - Up-to-date Information On Where to Fly Personally I would never fly to the west of where you took off from as that takes you right into the restricted zone. It's unfortunate, but at least the drone is repairable!

I've done a LOT of reading about this. There is no Restricted Zone in the area my son was flying. Here is what they say about no-fly zones:

No-Fly Zones are divided into Airports and Restricted Areas. Airports include major airports and flying fields where manned aircraft operate at low altitudes. Restricted Areas include border lines between countries or sensitive institute.​

We are talking about an airport here. From the GEO page you linked, the description of the yellow circle you posted is Authorization Zone, which is the circle described as R2 around an airport in the wiki page on DJI's website where that description of no-fly zones came from. My son flew his aircraft until it reached the warning zone (320 ft./100 m from the boundary), then when the drone reached the boundary of the Authorization Zone, it wouldn't go any further (as described in my previous posts).

Here is the text from immediately above that diagram:

Airport

(1) Airport No-Fly Zone are comprised of Take-off Restricted zones and Restricted Altitude Zones. Each zone features circles of various sizes.

(2) R1 miles (value of the R1 depends on the size and shape of the airport) around the airport is a Take- off restricted zone, inside of which take off is prevented.

(3) From R1 mile to R1 + 1 mile around the airport the flight altitude is limited to a 15 degree inclination.

Starting at 65 feet (20 meters) from the edge of airport and radiating outward. The flight altitude is limited to 1640 feet (500 meters) at R1+1 mile

(4) When the aircraft enters within 320 feet (100 meters) of No-Fly Zones, a warning message will appear on the (screen)​

The point I'm trying to make is the flight software acted like we had reached the boundary of R1 (the red circle on the map DJI sent us). At the boundary of R2, the altitude is restricted to 1640 ft.

 

[F3honda4me]

Your son flew INTO the restricted area, and then hit NO to authorize. This changed his flight altitude limit from 1640 to 0 and effectively made it an NFZ. Please note the wiki page you are referencing is the OLD NFZ system and not GEO. Yellow authorization zones will not prevent you from flying into them, but if you say NO to authorize, you've effectively turned the zone into an NFZ. You can see pretty clearly from the map DJI gave you and the DJI GEO map that he's inside the yellow zone.

My son said he received a prompt from the app asking if he wanted to request authorization when he reached the boundary (presumably after trying to cross it and failing) and he replied "no" then hit the Go Home button.

 

[David Johnson]

I had a p4 for only 3 days it flew away ,the flight records did not come up on the computer ,I did everything to get the records but they are defected and DJI WILL NOT GIVE NOTHING ,ITS LIKE IM OUT $1300 cash !I been fight with them for over 5 mts

 

[WBN3]

Your son flew INTO the restricted area, and then hit NO to authorize. This changed his flight altitude limit from 1640 to 0 and effectively made it an NFZ. Please note the wiki page you are referencing is the OLD NFZ system and not GEO. Yellow authorization zones will not prevent you from flying into them, but if you say NO to authorize, you've effectively turned the zone into an NFZ. You can see pretty clearly from the map DJI gave you and the DJI GEO map that he's inside the yellow zone.

From the low resolution of the maps, it isn't obvious that the bird was in fact inside the Authorization Zone. The map DJI gave us shows a red circle around the airport, which we weren't anywhere close to. If you zoom in far enough, the yellow circle on the GEO map stops short of the drainage ditch we found the P4 in, which makes me think it knew where it was and held short of the Authorization Zone.

If you have a reference that explains a flight rule somewhere on DJI's website that forces an immediate landing without a warning, I'd love to see it. There is nothing more frustrating than conflicting documentation. The DJI Go app did not tell him he was going to be forced to land... I think you're speculating, rather than speaking with any real knowledge. I don't need speculation, I need clear written information.

 

[F3honda4me]

I'm not speculating, I'm using what you've posted and what DJI has told you. Also you said the RC lost signal so how do you know there wasn't a forced landing occurring at some point when you had no RC signal? Remember that GPS accuracy is not pinpoint, so there is margin for error here for the drone to think it's in the restricted zone. And it obviously thought it was otherwise it wouldn't have asked you to authorize. That said, DJI knows more than I do because they have the DAT file from the craft, and it quite clearly in the logs shows that the craft thinks it is in a restricted zone, hence the "fly limit airport" warnings in the text file. If I had something that showed DJI was incorrect I'd offer it up so you could fight them on this. :/

 

[AlecW]

My takeaway from this thread and a couple similar threads I've read is to just stay away from airports and other NFZs

 

[WBN3]

My takeaway from this thread and a couple similar threads I've read is to just stay away from airports and other NFZs

My takeaway is that these are really just expensive toys that you've got to be willing to lose if you're going to play with them... The automation that DJI offers makes it easy to look past the fact that these aren't passenger aircraft that get put through regulatory rigors before they ever roll out commercially. These are fancy, mass-produced toys that have been sold at a price-point that makes them very profitable for DJI on the initial sale, but not something they'll really stand behind for long... just look at the warranty coverage if you don't believe me.

 

[WBN3]

Is the Phantom damaged? Were there any nearby obstacles that it could have hit on the way down causing the battery to pop out?

FYI, you could retrieve the internal DAT flight log and view the data using DatCon to see what happened at the end of the flight.

We finally got the P4 back from DJI and I was able to connect to the internal memory using the DJI Assistant 2. I retrieved the .dat file for the flights on Christmas Day, but when I use DatCon to convert those into a log file, they don't end up like the ones that I got off the iPad using iTunes. The program creates a .csv file, two .txt files (FLY048.log.txt and FLY048.config.txt) and a .kml file. Which of those four files am I supposed to upload to the PhantomHelp link you provided?

 

[BudWalker]

We finally got the P4 back from DJI and I was able to connect to the internal memory using the DJI Assistant 2. I retrieved the .dat file for the flights on Christmas Day, but when I use DatCon to convert those into a log file, they don't end up like the ones that I got off the iPad using iTunes. The program creates a .csv file, two .txt files (FLY048.log.txt and FLY048.config.txt) and a .kml file. Which of those four files am I supposed to upload to the PhantomHelp link you provided?

DatCon doesn't produce a file that can be submitted to the PhantomHelp converter. Nor, does it produce a .txt file that is similar to that produced by the DJI Go App. That .kml file can be submitted to Google Earth if you're interested in the P4's path after the RC disconnect. If you're interested in other info I suggest you use CsvView (look here) which can accept the .DAT

 

[WBN3]

DatCon doesn't produce a file that can be submitted to the PhantomHelp converter. Nor, does it produce a .txt file that is similar to that produced by the DJI Go App. That .kml file can be submitted to Google Earth if you're interested in the P4's path after the RC disconnect. If you're interested in other info I suggest you use CsvView (look here) which can accept the .DAT

I guess I was confused by the responses from msinger... the one I quoted was his first reply, and the later comment about uploading to PhantomHelp seemed like a continuation of thought rather than a wholly separate approach.

I used the .kml file in Google Earth and see the path, but haven't loaded the .kml file from the app (pre-disconnect) to differentiate the portion of the flight path that occurred after disconnect. I'm assuming the two .kml files will overlay and it should be obvious where one track extends past the other. I did also open the .csv file and can see the data from after disconnect, but I just skimmed through it since it was late last night. There are events logged which I was hoping to get someone here (yourself or msinger) to explain.

Thanks.

 

[BudWalker]

I guess I was confused by the responses from msinger... the one I quoted was his first reply, and the later comment about uploading to PhantomHelp seemed like a continuation of thought rather than a wholly separate approach.

I used the .kml file in Google Earth and see the path, but haven't loaded the .kml file from the app (pre-disconnect) to differentiate the portion of the flight path that occurred after disconnect. I'm assuming the two .kml files will overlay and it should be obvious where one track extends past the other. I did also open the .csv file and can see the data from after disconnect, but I just skimmed through it since it was late last night. There are events logged which I was hoping to get someone here (yourself or msinger) to explain.

Thanks.

If you use CsvView you'll be able to see where the disconnect occurs. Start the GeoPlayer and a SigPlayer. Then add the "connectToRC" signal to the SigPlayer.

 

[WBN3]

If you use CsvView you'll be able to see where the disconnect occurs. Start the GeoPlayer and a SigPlayer. Then add the "connectToRC" signal to the SigPlayer.

Will try that this evening when I get off. I downloaded DatCon but not CsvView. Would also like to know the best way to share the file and get feedback here.

 

[BudWalker]

Will try that this evening when I get off. I downloaded DatCon but not CsvView. Would also like to know the best way to share the file and get feedback here.

Use Dropbox (or Google Drive, etc) and provide the Dropbox link to the .DAT.

 

[WBN3]

Use Dropbox (or Google Drive, etc) and provide the Dropbox link to the .DAT.

I haven't used Dropbox much, so see if this works:

Dropbox - FLY048.DAT

 

[BudWalker]

That's not the correct .DAT. This one looks like.

I suspect the correct flight is the flight after this one. FLY049.DAT perhaps. You could use DatCon or CsvView to view the geo path to confirm you have the right one.

 

[WBN3]

That's not the correct .DAT. This one looks like.
View attachment 76402

I suspect the correct flight is the flight after this one. FLY049.DAT perhaps. You could use DatCon or CsvView to view the geo path to confirm you have the right one.

That's the first flight contained in the .dat file, but there is a second take-off shortly after that one in the same file. The DatCon documentation says the file begins capture the moment the battery is turned on, and my son flew it to the west shortly after landing this one. The file on my computer says it's 435,392 kb in size, and on Dropbox it shows to be 425.19 MB (same size) ... does that match what you got when you downloaded it? Here's what the .kml file looks like on mine...

 

[BudWalker]

That's the first flight contained in the .dat file, but there is a second take-off shortly after that one in the same file. The DatCon documentation says the file begins capture the moment the battery is turned on, and my son flew it to the west shortly after landing this one. The file on my computer says it's 435,392 kb in size, and on Dropbox it shows to be 425.19 MB (same size) ... does that match what you got when you downloaded it? Here's what the .kml file looks like on mine...

View attachment 76422

You're right. You're .DAT stimulated 2 bugs, one in DatCon , the other in CsvView. Independently they each don't cause a problem. But, together they are a problem. Anyway, I'll be fixing those bugs. I've attached a .zip containing a .csv that can be fed to CsvView and a FLY048.txt.log. These include the second flight you referred to.

At time 980 APP_AUTO_GOHOME was initiated at the direction of the pilot. Following at time 1007 connection with RC was lost and the go home action changed to OUTOF_CONTROL_GOHOME.

It's worth noting, according to the eventLog stream, that the AC was aware of the airport restriction at time 927. See the attached FLY048.txt.log. I haven't looked closely, but it doesn't seem that the AC's flight path was ever affected by this.

Not much changed as a result of the RC disconnect. The AC had already entered a GoHome and had turned towards home. It then flew sideways (to the left) and started descending.This continued after the disconnect but the descent stopped at 20 meters.

Just for grins I took a closer look at the the very end of the recording. To do this I ran DatCon with a sample rate of 200 hZ instead of the default 30 hZ. Then looked at the volts being applied to the motors by the ESC. This is much higher speed data than the battery data.

I'll speculate that the voltage fluctuation at the very end was the result of the battery coming loose.