Ahh, the .dat I provided was from the DJI go app folder on my iPhone. I'll try this method in the morning, time for bed noe[emoji106] I really appreciate your help!
Sent from my iPhone using PhantomPilots
Weird behaviour shortly after takeoff...
- Thread starter NiallxD
- Start date
Ahh, the .dat I provided was from the DJI go app folder on my iPhone. I'll try this method in the morning, time for bed noe[emoji106] I really appreciate your help!
Sent from my iPhone using PhantomPilots
Time for bed?
Hahahahaaa...it might 3-4 weeks before any decent free help comes along. You got to appreciate that help and stick with it while it's available to you. Mondays are really tough on data analysis readers. So many hobbyist flyers world wide crash over the weekend and then want to find out what happened during their aircraft's flight like yesterday so they can put a plan together.
Charlie Watson said he tries to let his people know if they are working together on a diagnostics project and if the people have to take a short break to go and let their pets outside, he informs them will need to disconnect and return to the back of the line.
The problem here is you upgraded to a app that they published before they even had the other operating system version completed. You couldn't find a more extreme red flag then that one.
At this point I would do as the others suggested and remove all the old files and install a fresh version. That is at least a good starting point.
Hahahahaaa...it might 3-4 weeks before any decent free help comes along. You got to appreciate that help and stick with it while it's available to you. Mondays are really tough on data analysis readers. So many hobbyist flyers world wide crash over the weekend and then want to find out what happened during their aircraft's flight like yesterday so they can put a plan together.
Charlie Watson said he tries to let his people know if they are working together on a diagnostics project and if the people have to take a short break to go and let their pets outside, he informs them will need to disconnect and return to the back of the line.
The problem here is you upgraded to a app that they published before they even had the other operating system version completed. You couldn't find a more extreme red flag then that one.
At this point I would do as the others suggested and remove all the old files and install a fresh version. That is at least a good starting point.
Thanks for that, I was up nearly 20 hours yesterday and needed to get up for work in the morning.
Is it worth noting I have been flying successfully for months on iOS10?
The point is you should have waited to see if others ran into issues with version 3.0 before installing it on your setup. Now you get to go through all the issues whiles others watch you and fly theirs on the older firmware trouble free.
Btw, I have not updated my aircraft or app in over a year now.
Its not the app. It tried flying with Litchi and saw the same actions.
Sent from my iPhone using PhantomPilots
Personally I would go back to the previous version.
I looked over your txt flight log and nothing stood out other then it did appear as though you may have hit auto launch after it was already off the ground.
Is this .DAT any good, got this from the drone it's self. I believe this is one for the problematic flight.
.DAT on dropbox
I have the exact same issue going on with my P3P!! Thought i was the only one out there.
I am using a Moto Pure for my device, have the most updated app and firmware.
Hoping it was something with the controller i linked my second controller. Sadly nothing. If there is any way i could help with my information i would gladly support you with anything.
Hope we can find a fix!
I am using a Moto Pure for my device, have the most updated app and firmware.
Hoping it was something with the controller i linked my second controller. Sadly nothing. If there is any way i could help with my information i would gladly support you with anything.
Hope we can find a fix!
@NiallxD that .DAT corresponds to the .txt you provided. But, neither of those correspond to the Go App screen shot in your first post. Is that right? Do the two log files correspond to the HealthyDrones screen shot in the first post?
I'm not real confident on this one but I'm going to guess that the root cause of this problem is the uplink signal strength is low. I noticed you mentioned something about switching back to stock antennas in one of your posts.
Looking at the eventLog stream in the .DAT the P3 lost connection with the RC several times begiining at about 208 secs
208.958 : 225193 : 18557 [LED] changed: rc completely lost
209.958 : 225793 : 18607 [LED] changed: normal led
219.198 : 231337 : 19069 [LED] changed: rc completely lost
222.758 : 233473 : 19247 [Ctrl<8>] REQ_RC_LOST AUTO_LANDING_HOLD ctrl_auto_landing
222.913 : 233566 : 19254 Eeprom write offset:330
226.798 : 235897 : 19449 [LED] changed: normal led
234.498 : 240517 : 19834 [LED] changed: rc completely lost
237.098 : 242077 : 19964 [LED] changed: normal led
240.178 : 243925 : 20118 [LED] changed: rc completely lost
243.978 : 246205 : 20308 [LED] changed: normal led
247.058 : 248053 : 20462 [LED] changed: rc completely lost
252.258 : 251173 : 20722 [LED] changed: normal led
261.498 : 256717 : 21184 [LED] changed: rc completely lost
263.618 : 257989 : 21290 [Ctrl<10>] REQ_RC_GO_HOME AUTO_LANDING_HOLD ctrl_auto_landing
At 222.8 the .txt seems to be saying the same thing as the eventLog stream when the autoLand is commanded because of the lost connection.
The following plot shows what the P3 thinks the RC mode switch is set to.
The blue areas are where the P3 thinks the mode switch is in the A position. I don't think it's physically possible for the switch to change positions this fast. There must be some other explanation.
As I mentioned I don't find the foregoing to be very compelling. I suggest that you restore the stock antennas and try the same flight but put some horizontal distance between the RC and launch site. If you still have the same problem I'd ask DJI to look at the log files.
I'm not real confident on this one but I'm going to guess that the root cause of this problem is the uplink signal strength is low. I noticed you mentioned something about switching back to stock antennas in one of your posts.
Looking at the eventLog stream in the .DAT the P3 lost connection with the RC several times begiining at about 208 secs
208.958 : 225193 : 18557 [LED] changed: rc completely lost
209.958 : 225793 : 18607 [LED] changed: normal led
219.198 : 231337 : 19069 [LED] changed: rc completely lost
222.758 : 233473 : 19247 [Ctrl<8>] REQ_RC_LOST AUTO_LANDING_HOLD ctrl_auto_landing
222.913 : 233566 : 19254 Eeprom write offset:330
226.798 : 235897 : 19449 [LED] changed: normal led
234.498 : 240517 : 19834 [LED] changed: rc completely lost
237.098 : 242077 : 19964 [LED] changed: normal led
240.178 : 243925 : 20118 [LED] changed: rc completely lost
243.978 : 246205 : 20308 [LED] changed: normal led
247.058 : 248053 : 20462 [LED] changed: rc completely lost
252.258 : 251173 : 20722 [LED] changed: normal led
261.498 : 256717 : 21184 [LED] changed: rc completely lost
263.618 : 257989 : 21290 [Ctrl<10>] REQ_RC_GO_HOME AUTO_LANDING_HOLD ctrl_auto_landing
At 222.8 the .txt seems to be saying the same thing as the eventLog stream when the autoLand is commanded because of the lost connection.
The following plot shows what the P3 thinks the RC mode switch is set to.
The blue areas are where the P3 thinks the mode switch is in the A position. I don't think it's physically possible for the switch to change positions this fast. There must be some other explanation.
As I mentioned I don't find the foregoing to be very compelling. I suggest that you restore the stock antennas and try the same flight but put some horizontal distance between the RC and launch site. If you still have the same problem I'd ask DJI to look at the log files.
I believe they do match the health drones screen shot.
Thanks for your help, very appreciative. I'll investigate the antenna mod and see where I can get with that.
Thanks again[emoji106]
Sent from my iPhone using PhantomPilots
We cross posted. Can you provide the .DAT and the .txt for a flight with this problem? Go here to see how to retrieve the .DAT. You'll need to provided it via a Dropbox link.
I am at work today until 2 CTZ but once i get home i can provide you with my files.
Here is a link to my post i made just last week on the same problem.
Professional - Random loss of Connection.
I was trying to look into that. to put the old version on do i go thought the same process as i would with putting the latest version on? Or do i have to take the latest off somehow?
- Joined
- May 10, 2014
- Messages
- 3,012
- Reaction score
- 522
Its easy on the app front screen, with drone connected, top right there is a button, press and hold this for a few seconds and the option to put on previous version is there.
- Joined
- May 10, 2014
- Messages
- 3,012
- Reaction score
- 522
It looks like a box with a hat on 
and the screen is the opening where it says
connect to your
>>>>
camera
and the screen is the opening where it says
connect to your
>>>>
camera
It looks like a box with a hat on
and the screen is the opening where it says
connect to your
>>>>
camera
Thank you, will be trying this once i get home today.
The txt version does not show any changes being made in the R/C mode switch. It's almost like it's dropping gps signal. I don't have any explanation for this one.
I was starting to like this idea but then I looked closer at the results of the conversion done by TXTlogToCSVTool. CsvView uses this to do it's .txt to .csv conversion. That .csv has both a RC.mode signal and a OSD.modeChannel signal. Neither of these are included in CsvView 0.9.9. Anyway, RC.mode shows P for the entire flight, as @flyNfrank also observed. But, OSD.modeChannel reflects the value in the .DAT
It's unclear to me what this signal is. The possible values for OSD.modeChannel are F, A, P, S, and unknown.
As I mentioned CsvView 0.9.9 doesn't contain these two signals. But, the necessary change to include them can be obtained via a "field upgrade". Inside the attached .zip is the file txtSignals.xml. Use this to replace the txtSignals.xml in the directory where CsvView is installed (on my system that's C:\Program Files(x86)\CsvView).
