P4 Advanced Authorization Zone Mid Flight & Compass Error

[msinger]

I'm also going to apologize for making my initial message so blameful of DJI. It was intended to be constructive criticism in their software programming. Software doesn't get better if people don't talk about it. DJI has not created perfect software and logic and it may never be perfect, in the same way that we are not perfect.

Agreed. However, in this case, it doesn't seem the software caused a problem. Your flight log shows a trail of pilot errors that led up to the disconnection and your Phantom ultimately being lost among the trees.

FYI, when planning your flights in the future (if you decide to buy another Phantom), this map will come in handy. It shows no fly zones and authorization zones. For this flight, you can see your location (the red dot on the map below) was next to an authorization zone.

 

[sar104]

It happened very fast @msinger. I'm trying my best to remember the exact sequence of events on the screen. Communication is very important here so let me try this again to the best of my memory and I'll be the devil's advocate to myself and place doubt in every part of my memory of the events that occurred so we can look at this objectively... The log file paints a pretty accurate picture and I agree with the ascent and the direction it went after it ascended but using the log like the bible is something I don't agree with; especially due to the fact that the log doesn't record the Auth Zone and Auth Zone RTH which I think that DJI should look into recording those actions. If it was able to log the Auth Zone actions I wouldn't have to sit here and try and remember exactly the sequence and order of all the messages and pop-ups and automated Auth Zone RTH.

I'm also going to apologize for making my initial message so blameful of DJI. It was intended to be constructive criticism in their software programming. Software doesn't get better if people don't talk about it. DJI has not created perfect software and logic and it may never be perfect, in the same way that we are not perfect. There are thousands of little things that can go wrong that we cannot determine in the same way that forensic scientists cannot always decisively understand why something happened.

Instead of attacking me and one another, let's try to be scientific and work together? And yes I understand that likely there was magnetic interference, it is very possible. Let's get past that and pretend that we're software engineers and how we can better program the fail-safe procedures. Pretend that it was impossible to foresee the magnetic interference as if there was a giant magnet that was unavoidable or some other unexplainable event and see if we can improve upon the fail-safe... if I more carefully analyze the sequence of events I think we'll find that there are a lot of unknown variables and areas that could have been at fault that the log file nor myself could have recorded.

I think where the confusion lies, even for me, is when the aircraft became disconnected from the controller. The facts that I can 100% remember (including my assumptions about how the software is controlling the drone) are:

1) I turned on the aircraft and waited for green ok status and saw that the home point was accurate, close enough to where it started and was ok with that
- if you look at the satellite photo it was about 5-10 feet SE of the concrete in the grassy area for launch
2) I launched the aircraft and remember it hovering a few feet above and then i pushed it up high almost immediately to get it in position for the route and to not bother bystanders with the propeller noise

3) I then noticed the auth zone message. Not before takeoff but sometime either during the ascent or soon after. The auth zone message was coincided with a RTH message. It said something along the lines of not having authorization to fly in this area and that in the meantime the UAV will return to its home point until it's sorted out. I began trying to deal with the messages and obtaining the auth token. My assumption here is that the RTH command was sending the drone back to me so I continue dealing with the auth message thinking all is ok. This was my error for not checking visually. The spotter thought I was flying the drone in that direction on purpose, he later told me, so he didn't mention anything to me. The most likely thing that happened here is that the UAV was pushed in a direction it thought was home due to the compass error.
- This part of the programming should be looked at (in my opinion). If the UAV detects a compass error, which it did early on it should not allow the UAV to automatically trigger an RTH on its own behalf. The pilot should have to confirm the RTH or trigger his or herself.
- The GPS, assuming it has a decent signal, should hold the position of the UAV until the pilot decides whether to switch to ATTI or continue with GPS mode.
- The log file apparently shows a weak GPS signal which probably triggered the ATTI mode. This action makes sense and I agree with it. The ATTI mode, in conjunction with the automated RTH for those few seconds, may have been the perfect storm for the fly away.

4) About 10-15 seconds later, maybe more, maybe less I see the aircraft moving away pretty quickly. It is already pretty far over the trees to the NE. I try to stop it but cannot. This could either have been because - the automated RTH or the ATTI mode and the aircraft being disconnected from the controller. I did not notice a disconnect status at this point but it is possible that the aircraft could have been disconnected due to interference or distance or some other technicality. I should have been more observant of the entire screen instead of paying so much attention to the Auth Zone messages and dealing with unlocking. When things happen this fast sometimes you get tunnel vision and take one thing at a time. I was definitely prioritizing the Auth Zone lock as I thought that was preventing me from controlling the drone.

5) The Auth Zone lock out remains on the screen. I assume that it is locking me because the aircraft continues to move away and I continue trying to obtain a token. I also assume that the aircraft is in a RTH routine when it is possible that it was in an ATTI drift with no connection from the controller. Maybe it was a little of both. We make the lock out assumption due to the message on the screen about the aircraft being sent home because of no authorization. We also assume this due to other users that report the same behavior in Auth Zones; that they are locked out and their UAV is grounded after takeoff. Perhaps poor cell signals are delaying people's Auth Zone groundings to after takeoff?

6) Token is received, auth zone message gone. I try to control the aircraft but it is definitely disconnected at this point as I observed the disconnect message. I attempted to recover the signal by disconnecting and reconnecting the cord. I have had success with doing that many times in the past with previous flights.

Things that are not certain:

1) That there was magnetic interference. It IS possible that the compass failed. Maybe unlikely but possible. How would we even know for sure?

2) The exact point that the craft disconnected from the controller. It had to have happened after ascent, but may have happened sooner than we thought. But it definitely did happen.

3) Why the software thought the UAV was in an Auth Zone when it was in a warning zone, but fairly close to the border of an Auth Zone. Possibly due to the weak GPS signal in the phone itself?

There are a few gray areas here and I think it is very possible that when the aircraft automatically switched into ATTI mode due to the compass error or weak GPS signal that I could not control it due to the aircraft being disconnected. Perhaps me pulling the cord out of the screen may have interrupted further recording of the log. The root cause of that disconnection could be the device I was using or some other reason, we cannot definitively say.

Regardless of all aforementioned the Authorization Zone programming needs to be re-evaluated in my opinion. Weak cell signals may mislead the software. Magnetic interference or weak GPS signals could be present in any number of situations that could misinform the software as to its proximity to Auth Zones or No Fly Zones.

1) How could the system report itself as ready to fly if it isn't sure of the quality of the GPS signal or the compass' reliability? Perhaps the compass didn't encounter an issue until after takeoff? Plausible?

2) Why would the system allow the Auth Zone RTH / Lockout after takeoff? Shouldn't the system make sure it knows where it is before making that decision? And if it isn't sure shouldn't it stay locked until it does know?

3) Perhaps the UAV was actually headed home, to the right place, but the weak GPS signal triggered ATTI and the Auth Zone messages acted as a distraction for just enough time that the pilot could not react in time before disconnection happened. Perhaps disconnection from the remote happened faster than normal due to radio interference in the area or due to the device itself (weak connection in the cable or hardware fault in the screen device).

You still seem to be misunderstanding a number of issues here.

At 4.8 seconds the FC reported the misleadingly named GPS mismatch, normally caused by a compass problem, and at this point you had 14 satellites locked and a home point recorded accurately. It was not a GPS problem, and the log file nowhere shows a weak GPS signal, whatever that means. You started with 13 satellites locked, and you ended with 19.

At 5.3 seconds the FC noted a continuing compass error and 3 seconds after that, as it is supposed to, it dropped out of P-GPS into ATTI, with a message at 9.0 seconds (Exit P-GPS Mode; Compass Error). Its GPS positional data are still fine - it still has 14 satellites locked and is recording its position just fine - rather obviously since its recorded track is correct for the entire flight while connected. But at this point it doesn't even have the option to RTH because it is no longer controlling position

You continued to control its ascent for another 8 seconds, up to around 210 ft, and then released the sticks. You never touched them again in the following 70 seconds, even as it drifted off. It did not happen really quickly - you did nothing for over a minute. The tablet, or whatever, is irrelevant - the RC has precedence and you can always use the sticks, even if the tablet crashes or you disconnect it. But the log is continuous, with no gaps until the aircraft disconnected from the RC.

Then, at 85.5 seconds, you lost connection. It was still drifting, with no stick inputs, holding altitude and attitude, and by that time it had 19 satellites locked but it was still in ATTI due to the now constant yaw errors.

In terms of the flight, the aircraft behaved exactly as expected given the compass error, which was most likely due to a bad compass calibration (e.g. a calibration in a bad location, magnetically). It switched to ATTI and then waited for you to fly it. Instead you did nothing - just watched it drift away until it disconnected.

In terms of all the authorization stuff that you saw, it's hard to know what that was because you don't seem to remember accurately what the messages said. But, in any case, that situation, whatever it was, was superseded by the compass error and the ATTI transition. After that the result appears to be entirely pilot error. That's clearly not what you want to hear, but there is no point posting here with flight logs and then disputing the analysis of those logs, especially when the log is continous, self-consistent, and also fully consistent with your description of the event. The authorization issue is only relevant if it distracted you so much that you completely lost situational awareness, which may be the case - but that is the extent to which it was involved.

 

[macoman]

You still seem to be misunderstanding a number of issues here.

At 4.8 seconds the FC reported the misleadingly named GPS mismatch, normally caused by a compass problem, and at this point you had 14 satellites locked and a home point recorded accurately. It was not a GPS problem, and the log file nowhere shows a weak GPS signal, whatever that means. You started with 13 satellites locked, and you ended with 19.

At 5.3 seconds the FC noted a continuing compass error and 3 seconds after that, as it is supposed to, it dropped out of P-GPS into ATTI, with a message at 9.0 seconds (Exit P-GPS Mode; Compass Error). Its GPS positional data are still fine - it still has 14 satellites locked and is recording its position just fine - rather obviously since its recorded track is correct for the entire flight while connected. But at this point it doesn't even have the option to RTH because it is no longer controlling position

You continued to control its ascent for another 8 seconds, up to around 210 ft, and then released the sticks. You never touched them again in the following 70 seconds, even as it drifted off. It did not happen really quickly - you did nothing for over a minute. The tablet, or whatever, is irrelevant - the RC has precedence and you can always use the sticks, even if the tablet crashes or you disconnect it. But the log is continuous, with no gaps until the aircraft disconnected from the RC.

Then, at 85.5 seconds, you lost connection. It was still drifting, with no stick inputs, holding altitude and attitude, and by that time it had 19 satellites locked but it was still in ATTI due to the now constant yaw errors.

In terms of the flight, the aircraft behaved exactly as expected given the compass error, which was most likely due to a bad compass calibration (e.g. a calibration in a bad location, magnetically). It switched to ATTI and then waited for you to fly it. Instead you did nothing - just watched it drift away until it disconnected.

In terms of all the authorization stuff that you saw, it's hard to know what that was because you don't seem to remember accurately what the messages said. But, in any case, that situation, whatever it was, was superseded by the compass error and the ATTI transition. After that the result appears to be entirely pilot error. That's clearly not what you want to hear, but there is no point posting here with flight logs and then disputing the analysis of those logs, especially when the log is continous, self-consistent, and also fully consistent with your description of the event. The authorization issue is only relevant if it distracted you so much that you completely lost situational awareness, which may be the case - but that is the extent to which it was involved.

Very thoughtful analysis! The OP is probably upset because it's a lost case. Pilot error meas not support from DJI because they will conclude the same way after reading the flight data log.

 

[minniehill2]

The best of the best have given their honest opinion, now it is up to you to decide if you can accept it.

I for one never calibrate my compass at a flight sight.

 

[journeyfarm]

The logs are very helpful as are you guys in deciphering the logs. You guys are obviously very knowledgable and have a ton of experience doing so. I do have a lot of experience flying DJI UAVs but I do not have experience deciphering log files. I was a computer programmer for over 10 years and I understand how easy it is for programmers to miss things, especially with continuing software updates. Even with better Auth Zone logic this may have still happened but I would not have been distracted for as long and may have recognized that the aircraft was not doing what I thought it was sooner than later.

However, no one has yet to explain the Authorization Zone actions. If someone can do that we'll have reached the next level.

1) The screen clearly stated to me that the UAV was returning to home. I saw this with my own eyes and I will never deny this and many other people have confirmed this is the default behavior of the DJI Drones in or near Authorization zones. (see below)

2) Authorization actions we're never recorded in the log. Hopefully DJI can add these along with any other missing actions (if any).

3) This fly away could have been prevented by many pilots, obviously not by me. This was my first time flying with the new firmware as I had never encountered Auth Zone pop-ups ever before. It caught me by surprise and it distracted me for a short period of time, just long enough to allow the environmental issues to prevent me from regaining control.

4) Please no more attacks. I'm not making this up. Let's all do a little more investigation into the logic behind the Auth Zone programming and see if there's a better way to deal with those situations, considering that even though a pilot may be in a place where he/she should not fly (a gray area both in FAA regulation and in DJI's software) that the pilot should be focused on the flight and not authorizing tokens.

5) Examples of other Authorization Zone pilots who had RTH automatically occur:

a) Yellow Zone Unlocked - Auto (Crash) Landing Initiated (This one is very similar to the frustration I experienced with the Auth Zone messages)

b) Unlocking No Fly Zones

c) Can't take off no fly zone, how do I unlock?

 

[macoman]

The best of the best have given their honest opinion, now it is up to you to decide if you can accept it.

I for one never calibrate my compass at a flight sight.

I am the same way. I calibrated once and never again!

 

[journeyfarm]

Also, I calibrated everything at a different location 24 hours prior after purchasing the drone. I did not re-calibrate at the location where the drone was lost. I know I mentioned calibration in the first post but I was re-iterating that it was calibrated, not that I did the whole compass spin again at the new location just prior to the flight. The only thing I did at the fly away location was turn it on wait for a green status, and checked that the home location was accurate.

 

[journeyfarm]

Very thoughtful analysis! The OP is probably upset because it's a lost case. Pilot error meas not support from DJI because they will conclude the same way after reading the flight data log.

I'm not upset at the lost drone, these things happen. Myself and colleagues I've witnessed have lost drones in the past but in most cases I could fully understand why and see no improvement in process at the time. I am disappointed in the Authorization Zone process and believe it could be better handled.

 

[journeyfarm]

Agreed. However, in this case, it doesn't seem the software caused a problem. Your flight log shows a trail of pilot errors that led up to the disconnection and your Phantom ultimately being lost among the trees.

FYI, when planning your flights in the future (if you decide to buy another Phantom), this map will come in handy. It shows no fly zones and authorization zones. For this flight, you can see your location (the red dot on the map below) was next to an authorization zone.

View attachment 86737

I did use that map as well as a sectional chart that I was trained to use in class. The software on the screen stated that I was approaching an auth zone when I was well into a warning zone. It was not supposed to lock me out, but it did. I think that this is probably an excessive action in the software to enable the lockout in that position, especially when already in flight.

 

[macoman]

I'm not upset at the lost drone, these things happen. Myself and colleagues I've witnessed have lost drones in the past but in most cases I could fully understand why and see no improvement in process at the time. I am disappointed in the Authorization Zone process and believe it could be better handled.

I kind of agreed that if that area where you flew your bird is a no drone zone it should have warned you and probably return to home automatically.

 

[sar104]

I kind of agreed that if that area where you flew your bird is a no drone zone it should have warned you and probably return to home automatically.

I agree too. RTH is not an unreasonable action in that situation.

But it's still not clear to me though that the OP understands that even if RTH was what the aircraft was programmed to do, it could not do that in ATTI. It can't do anything in ATTI except hold altitude and attitude or auto land, because it is ignoring all location data. So in this case the situation would have been exactly the same with or without authorization zone messages, other than what should have been a very brief distraction. All the talk of being "locked out" (of what?) is completely irrelevant.

Now, if the OP wants to have a discussion about how authorization zones work, or don't work, that's fine, but it's a quite different topic from the original flyaway, and basically unrelated.

 

[journeyfarm]

You still seem to be misunderstanding a number of issues here.

At 4.8 seconds the FC reported the misleadingly named GPS mismatch, normally caused by a compass problem, and at this point you had 14 satellites locked and a home point recorded accurately. It was not a GPS problem, and the log file nowhere shows a weak GPS signal, whatever that means. You started with 13 satellites locked, and you ended with 19.

At 5.3 seconds the FC noted a continuing compass error and 3 seconds after that, as it is supposed to, it dropped out of P-GPS into ATTI, with a message at 9.0 seconds (Exit P-GPS Mode; Compass Error). Its GPS positional data are still fine - it still has 14 satellites locked and is recording its position just fine - rather obviously since its recorded track is correct for the entire flight while connected. But at this point it doesn't even have the option to RTH because it is no longer controlling position

You continued to control its ascent for another 8 seconds, up to around 210 ft, and then released the sticks. You never touched them again in the following 70 seconds, even as it drifted off. It did not happen really quickly - you did nothing for over a minute. The tablet, or whatever, is irrelevant - the RC has precedence and you can always use the sticks, even if the tablet crashes or you disconnect it. But the log is continuous, with no gaps until the aircraft disconnected from the RC.

Then, at 85.5 seconds, you lost connection. It was still drifting, with no stick inputs, holding altitude and attitude, and by that time it had 19 satellites locked but it was still in ATTI due to the now constant yaw errors.

In terms of the flight, the aircraft behaved exactly as expected given the compass error, which was most likely due to a bad compass calibration (e.g. a calibration in a bad location, magnetically). It switched to ATTI and then waited for you to fly it. Instead you did nothing - just watched it drift away until it disconnected.

In terms of all the authorization stuff that you saw, it's hard to know what that was because you don't seem to remember accurately what the messages said. But, in any case, that situation, whatever it was, was superseded by the compass error and the ATTI transition. After that the result appears to be entirely pilot error. That's clearly not what you want to hear, but there is no point posting here with flight logs and then disputing the analysis of those logs, especially when the log is continous, self-consistent, and also fully consistent with your description of the event. The authorization issue is only relevant if it distracted you so much that you completely lost situational awareness, which may be the case - but that is the extent to which it was involved.

I am not denying pilot error here. I'm trying to show that there are things that happened that we're not recorded and that should be looked into for the future benefit of everyone. I did not know exactly what GPS mismatch meant in the log, thank you for clarifying it is a compass issue. I do remember the DJI Go 4 software stating that there was a weak signal, could have sworn it said weak GPS but cannot say for sure now so its pointless to bring up.

The RTH command was probably cancelled at the point at which ATTI was activated (again my assumption here).

I was definitely trying to do something during that time. I remember trying to fight through all the Auth Zone stuff and the aircraft not reacting. The only possible thing I can think of here is that the Auth Zone process prevented control. If the Auth Zone stuff wasn't recorded is it possible that it also prevented stick movements to get recorded?

 

[journeyfarm]

I agree too. RTH is not an unreasonable action in that situation.

But it's still not clear to me though that the OP understands that even if RTH was what the aircraft was programmed to do, it could not do that in ATTI. It can't do anything in ATTI except hold altitude and attitude or auto land, because it is ignoring all location data. So in this case the situation would have been exactly the same with or without authorization zone messages, other than what should have been a very brief distraction. All the talk of being "locked out" (of what?) is completely irrelevant.

Now, if the OP wants to have a discussion about how authorization zones work, or don't work, that's fine, but it's a quite different topic from the original flyaway, and basically unrelated.

I think the original analysis by the experts is good enough as to root cause of the fly away. I think it would be beneficial to steer the conversation towards Authorization Zone processes for the rest of the thread. At this point I'm ready to delete the thread and forget I even brought it up.

And for the sake of progress, we can call the fly away pilot error but I'd like to help everyone understand how much of a distraction it was to deal with the Auth Zone messages mid flight. It was similar to driving down a highway in your car and having a flock of birds fly into the windshield. Except in a car you can hit your brakes and know what to expect. In this situation I felt like I didn't have control. The screen was basically taken over by Auth Zone. It was not a sidebar it was front and center.

 

[macoman]

I think the original analysis by the experts is good enough as to root cause of the fly away. I think it would be beneficial to steer the conversation towards Authorization Zone processes for the rest of the thread. At this point I'm ready to delete the thread and forget I even brought it up.

Why u need to delete the thread? The analysis brought by the experts here are sufficient enough to keep this thread open for future reference.

 

[journeyfarm]

Why u need to delete the thread? The analysis brought by the experts here are sufficient enough to keep this thread open for future reference.

No need to. It felt to me that I may have mislead people from my original analysis and I didn't want to do that. I've used up too much energy of too many people. If you guys think it helps then by all means keep it going.

 

[sar104]

I am not denying pilot error here. I'm trying to show that there are things that happened that we're not recorded and that should be looked into for the future benefit of everyone. I did not know exactly what GPS mismatch meant in the log, thank you for clarifying it is a compass issue. I do remember the DJI Go 4 software stating that there was a weak signal, could have sworn it said weak GPS but cannot say for sure now so its pointless to bring up.

The RTH command was probably cancelled at the point at which ATTI was activated (again my assumption here).

I was definitely trying to do something during that time. I remember trying to fight through all the Auth Zone stuff and the aircraft not reacting. The only possible thing I can think of here is that the Auth Zone process prevented control. If the Auth Zone stuff wasn't recorded is it possible that it also prevented stick movements to get recorded?

Fair enough. But what you didn't do was use the controller, rather than the tablet, to fly the aircraft. That was all that you needed to do, assuming that you know how to fly in ATTI, to bring it back. You could have ignored the tablet completely. Are you suggesting that you did attempt to fly it with the sticks?

The log appears to have recorded every other aspect of the telemetry correctly. It recorded correctly formatted stick input data. You really are clutching at straws on that issue, especially since you have not even claimed to have tried to give it stick input. If the app messages record doesn't include the authorization stuff then that's the way it's programmed. It doesn't seem to include the black dialog box that pops up for me asking to confirm that my flight is authorized either. It has no bearing on data that are recorded.

 

[journeyfarm]

Fair enough. But what you didn't do was use the controller, rather than the tablet, to fly the aircraft. That was all that you needed to do, assuming that you know how to fly in ATTI, to bring it back. You could have ignored the tablet completely. Are you suggesting that you did attempt to fly it with the sticks?

The log appears to have recorded every other aspect of the telemetry correctly. It recorded correctly formatted stick input data. You really are clutching at straws on that issue, especially since you have not even claimed to have tried to give it stick input. If the app messages record doesn't include the authorization stuff then that's the way it's programmed. It doesn't seem to include the black dialog box that pops up for me asking to confirm that my flight is authorized either. It has no bearing on data that are recorded.

I've had many many successful flights with my old P4 where the aircraft became disconnected but then reconnected. I became accustomed in that situation to unplug the cable from the screen and re-plug it. I'd say 8 out of 10 times that works and the drone re-reconnects. I remember trying that during this flight. The only thing I can think of is that in the frenzy of trying to deal with Auth Zone and get the drone back I may have made the error of doing so with the cord out (or maybe I thought it was in but it wasn't in completely). The cord was well used.. similar to how the lightning cords say "accessory not supported" after a while when trying to charge your tablet. That is the only reason I could think of as to why the stick movements we're not recorded. I wouldn't let a drone just drift away but I will admit the Auth Zone stuff had me assuming I was locked out of the system the whole time. So many issues seemed to be popping up at once that I probably made it worse. Even though the system was aware the drone went into ATTI mode, I was not aware. And yes I know how to tell when it is in ATTI but again priority #1 at the time was getting rid of the Auth Zone stuff as I was under the impression that was preventing me from doing anything.

I do make mistakes as we all do and I'm sure I made a few during this flight but the one thing I can say for sure is that most of those mistakes we're driven by the authorization processes being new to me and happening mid flight at the worst possible time.

 

[sar104]

I've had many many successful flights with my old P4 where the aircraft became disconnected but then reconnected. I became accustomed in that situation to unplug the cable from the screen and re-plug it. I'd say 8 out of 10 times that works and the drone re-reconnects. I remember trying that during this flight. The only thing I can think of is that in the frenzy of trying to deal with Auth Zone and get the drone back I may have made the error of doing so with the cord out (or maybe I thought it was in but it wasn't in completely). The cord was well used.. similar to how the lightning cords say "accessory not supported" after a while when trying to charge your tablet. That is the only reason I could think of as to why the stick movements we're not recorded. I wouldn't let a drone just drift away but I will admit the Auth Zone stuff had me assuming I was locked out of the system the whole time. So many issues seemed to be popping up at once that I probably made it worse. Even though the system was aware the drone went into ATTI mode, I was not aware. And yes I know how to tell when it is in ATTI but again priority #1 at the time was getting rid of the Auth Zone stuff as I was under the impression that was preventing me from doing anything.

I do make mistakes as we all do and I'm sure I made a few during this flight but the one thing I can say for sure is that most of those mistakes we're driven by the authorization processes being new to me and happening mid flight at the worst possible time.

I don't know how to say this any clearer. The log is complete. Your tablet was not disconnected from the RC and the RC was not disconnected from the aircraft until the end of the record. Are you now saying that you definitely attempted to control the aircraft with the RC by stick input, or are you just saying that you think you probably did because you would surely not have just left it drift off?

 

[journeyfarm]

I don't know how to say this any clearer. The log is complete. Your tablet was not disconnected from the RC and the RC was not disconnected from the aircraft until the end of the record. Are you now saying that you definitely attempted to control the aircraft with the RC by stick input, or are you just saying that you think you probably did because you would surely not have just left it drift off?

I guess my perception of time was way off. Dealing with the auth zone messages must have been 70+ seconds long. That's the only explanation. I definitely used the sticks to try and get it back and I could still see it but it must have been longer than 15 seconds. That would explain why I have 2 auth token text messages. The poor cell reception probably had me repeat the process a few times at 15 seconds per attempt.

This returns me to my original message about Auth Zone. The system should not prompt the Auth Zone messages while a pilot is already in flight. This should either happen before flight or comes up as a warning if already in flight. The system should not allow automated RTH commands if the system senses errors with Compass or other navigational equipment. And after more analysis we have seen that perhaps the aircraft did behave in this way as it may have detected ATTI and blocked that command since there is no record of it in the log. And I need to be more careful with the new firmware.

 

[mark99]

Locking the drone whilst already in flight is totally unacceptable, operator must always retain control, no warning or token request should override control, not ever, not never.