P4P+ Pano mode, complete lockup, almost lost bird, what should I have done?
- Thread starter island2
- Start date
Meta4
Premium Pilot
- Joined
- Jan 8, 2014
- Messages
- 15,350
- Reaction score
- 9,292
There's something odd going on there.
From 21:24 to 21:33 there's lots of left stick down but the altitude is stuck on 193 ft.
The first thing I checked was the VPS height but there's no problem there.
Autoland after 22:33 had no problem bringing it down.
From 21:24 to 21:33 there's lots of left stick down but the altitude is stuck on 193 ft.
The first thing I checked was the VPS height but there's no problem there.
Autoland after 22:33 had no problem bringing it down.
Meta4
Premium Pilot
- Joined
- Jan 8, 2014
- Messages
- 15,350
- Reaction score
- 9,292
From 17:33 to 18:15 the Phantom responds normally to the left stick down and descends about 190 feet.
From 18:27 to 18:30 it descends but despite the left stick being down, it won't descend further.
What's changed at around 18:30?
It also appears that the rudder input stops having any effect after 18:23.
But the right stick is still moving the Phantom normally.
From 18:27 to 18:30 it descends but despite the left stick being down, it won't descend further.
What's changed at around 18:30?
It also appears that the rudder input stops having any effect after 18:23.
But the right stick is still moving the Phantom normally.
These were all in the same flight. The reason there are three .txt files is that the controller was rebooted.
The flight was being directed by a third party app. The P4 was responding to stick commands but was probably "sluggish" since it was also being controlled by that third party app. This can be seen in the first .txt. where elevator input causes the distance to the home point to change.
In the third .txt the stick inputs were too short to have a noticeable effect. The SMART_BATTERY initiated a goHome at 1354.82 secs. The P4 was too close to the home point and proceeded to land without moving closer to the home point.
- Joined
- Aug 27, 2018
- Messages
- 86
- Reaction score
- 17
- Age
- 27
yes it got completely stuck at 193.9ft. Autoland was triggered by a change in controller settings, I had "hover" and change it into "RTH" in case of link down, as a way to solve the issue. It descended untill I tell him to stop because below were not regular surface to land on and I wanted to do a manual landing which of course I could not do. I grabbed the drone with hands and commanded a rotors off in the controller which the phantom did not trigger, finally I could get the battery off just with a 2% left.
- Joined
- Aug 27, 2018
- Messages
- 86
- Reaction score
- 17
- Age
- 27
The flight was being directed by a third party app
Thank you for your help. Can you explain what does it mean "controlled by a third party app"? I don't want to give details, but we were in a restricted area, like the guy who started this thread. There was equipment in the area not only able to detect a C2 link, but we presume also capable to jam it.
Thank you for your help. Can you explain what does it mean "controlled by a third party app"? I don't want to give details, but we were in a restricted area, like the guy who started this thread. There was equipment in the area not only able to detect a C2 link, but we presume also capable to jam it.
Last edited:
By third party app I meant something like Litchi. Clearly that can not be the case since you have provided the .txt files. A rookie mistake on my part. I had noticed that the flycCommand signal had a value of AutoFly. I think this probably means you were using one of the flight modes and that may have contributed to the control sticks appearing to be sluggish.
EDIT: Also, flight mode switch was in the F position.
It would be extremely difficult to jam just the C2 signal. I checked all three .txt files and none of them showed C2 being activated. Not sure, but I think the C2 signal comes from the RC and not from the AC. I.e., it wasn't the case that the C2 was activated but the AC never received it.
As I mentioned the landing was triggered by the SMART_BATTERY system.
- Joined
- Aug 27, 2018
- Messages
- 86
- Reaction score
- 17
- Age
- 27
By C2 Link I mean standard control & telemetry 2.4 / 5.8 GHz radio link between drone and controller, at least this is how ICAO refers to it. AFAIK live video downlink, "payload" configuration and secondary features do not use the C2 datalink frequency, that's why someone else can jam your C2 link and you still have live video in the controller, which was our case.
Last edited:
I get it now, C2 is not referring to the C2 button. Still, it would be almost impossible to jam the uplink and have a flight as well behaved as this one. The P4A+ responded to stick inputs. It auto landed because the SMART_BATTERY system directed it to go home and it was close enough that it landed in place.
I mentioned that the Flight Mode switch was in the F position. I was thinking that was because a way point mission was being flown? The first .txt file starts at time 625 secs indicating there was a previous flight but the P4A+ had not been turned off between that flight and this one. Had you been flying a way point mission in that previous flight?
- Joined
- Aug 27, 2018
- Messages
- 86
- Reaction score
- 17
- Age
- 27
There was a previous flight we tried on top of a nearby hill but we did not tried any flight mode, just take off and landing, because it was too windy and we wanted to go down a bit looking for less wind. I can't remember whether the battery was switched off between one and the other. Anyway a controller reboot should have make possible taking control of the aircraft.
Last edited:
If you want to determine if the uplink was jammed we can do that by looking at the .DAT file from the P4A. Look here to see how to do that. The .DATs we want are FLY135.DAT and FLY136.DAT.
Am I missing something? How is it at all possible that the uplink was jammed when the telemetry data, including the stick inputs, are continuous? The RC_throttle data, for example, are in the telemetry from the aircraft, not recorded straight from the RC to the app, and so they have to reach the aircraft to be sent back as telemetry. In this flight there are no gaps in those data:
- Joined
- Aug 27, 2018
- Messages
- 86
- Reaction score
- 17
- Age
- 27
hi this is the DAT file of the 4 consecutive flights of the of day of the events:
DJI_ASSISTANT_EXPORT_FILE_2018-08-27_17-38-43.DAT
I hope I did it well. Thank you in advance for your time, maybe we can figure out some kind of reproducible error others can learn from.
DJI_ASSISTANT_EXPORT_FILE_2018-08-27_17-38-43.DAT
I hope I did it well. Thank you in advance for your time, maybe we can figure out some kind of reproducible error others can learn from.
The uplink was close to 100% for the entire flight. But, at time 1547 secs the .DAT shows the RC as being disconnected. After that the control inputs flatlined.
Here is a comparison between the .DAT and the .txt for an interval after the disconnect. I used relativeHeight to align the plots. It's clear the Go App is seeing control inputs not seen by the P4+
Seems odd doesn't it. That the sigStrength was 100% yet the RC was disconnected. Actually, this has happened before with the the P4+. I can't find the incident at the moment. Lemme look some more.
So that is very strange. If not from the aircraft, where did the control input data in the txt file come from? Those stick data look very unusual anyway - they are mostly 1 s or less in duration. I'm not sure that they are even real.
I think that has to mean that the control stick data in the .txt comes directly from the RC. It doesn't make a trip through the AC. I recall now that the control stick data in the .txt is in the range [-1024, 656] and that gets converted by TXTlogToCSVtool to [-10000, 10000]. That was done to make it compatible with the data seen in the .DAT. The [-1024, 656] data likely comes from a 10 bit A/D converter used for the stick control mechanism. The point being that this data doesn't make a trip through the AC before being recorded.
Here is another P4+ incident that kinda like this one.
Need help understanding Phantom 4 Pro V2.0 & Crystalsky Ultra Aircraft Disconnect
The conclusion was that the part of the RC firmware that does the uplink was intact. But, that part of the firmware that handles control stick data has crashed. RC:sigStrength is derived from a frameLost signal in the .DAT. The P4 is still receiving packets from the RC. It's just the control stick data isn't being inserted into those packets.
That does appear to be the implication. I guess that I cannot think of any definitive reason that could not be the case, although it means that the txt and mobile device DAT logs stop recording stick inputs when the downlink is lost, even though they still have the data. It also means that the stick data are going to be out of sync with the telemetry due to the 100 ms or so of latency in both uplink and downlink, which seems at least potentially problematic. Or perhaps there is a master clock signal from the RC reflected from the aircraft that synchronizes the data, and perhaps the loss of that return when the downlink fails is what prevents the log from updating.
