 |
|
|
|
So there I was at 10,500 feet, when suddenly my pax was feeling sick (not just airsick) and needed to get on the ground, fast.
"No problem" I thought, I'll just used NRST and go Direct. (Kinda like you would do in a Emergency.)
I picked the 2nd airport on the list, since we were so high. (And even then I had to throttle back a lot and circle to get down.)
At first, iFly did its duty, drew a line to the airport Direct. Yea!
But the next time I looked at iFly, it had returned to my Previous Flight Plan.
"What's going on?" I thought. Did I do something wrong. "Did I tap the wrong thing? " So I did NRST again.
Same thing happened again. At first, iFly showed Direct. And then it went back to my Flight Plan.
I certainly didn't need this happening in a pseudo-emergency. And there was no easy way to stop this from happening. I finally gave up using iFly for this.
Can anyone figure out what was happening?
It turns out that I had Flight Plan sharing enabled between my two tablets. I had used my "Master" tablet to send my Flight Plan (and subsequent changes) to my "Slave" tablet.
If you recall, Brian had changed the sharing protocol so that the Master tablet retries sending Flight Plan changes to the Slave over and over again. This was to make sure that changes got thru if collisions. I guess it keeps sending the Flight Plan? (Might be special case in my case, as below.)
And so, even tho I purposely changed the Flight Plan on my Slave, apparently my Master kept over ruling my Slave!
I suppose, in a normal case, doing NRST Direct would have overwritten the Master tablet? (Should it?)
I don't know because it turns out that my Master tablet does not receive multicast. It can only send them. So my Master tablet can send a Flight Plan to my second tablet (my "Slave"), but my Slave cannot send a Flight Plan change to my Master. (If my Slave sends an "ACK" that it got the Flight Plan or Flight Plan changes, I presume my Master cannot see that. So maybe it tries forever?)
Regardless of how it works normally, I am thinking after this experience that iFly should change its behavior for Flight Plan sharing.
I suggest the safest protocol is that any Slave tablet should always pop up an window "Accept change" whenever a Flight Plan is modified on the fly. (No pun intended.) And if it's not accepted within, say, 15 seconds, it is automatically declined.) As I write this, I might already have the option to disable "auto accept." Which, from now on, I will do.
Second, it might be necessary that Flight Plan sharing is automatically disabled whenever a Direct is entered from NRST.
I dunno. In an Emergency, do you want all your iFly clients changing to the new NRST Direct Flight Plan? On only the one you tap?
Anyway, this was a particularly frustrating experience, especially since it was a such a critical time.
|
|
|
|
 | |
|
|
|
When you initially shared the flight plan from the master, you had "Auto share changes" selected. So the master periodically resent the plan, which overwrote the NRST. You can either unclick that option when you initially share the plan, or when you decide to stop sharing the plan, you can disable it from either tablet. I've played "what if" on the slave only to have it overwritten, like you had. But I think we just need to be aware of the behavior, and not change it. Typically, the master is the one in front of you and where you'd be entering the NRST anyway.
Jeff Nokomis Clark,
Mooney M20G,
iFly app on ASUS ZenPad Z8s,
ASUS ZenFone AR,
ASUS Windows 10 tablet,
Stratux ADS-B w AHRS
|
|
|
|
| |
|
|
|
Yeah, Auto-Share off for sure in the future. This was a bad unintended consequence to learn about at a bad time.
|
|
|
|
| |
|
|
|
This is a great bug report Mike, thank you!
I believe the easiest/best thing to do is that whenever a slave self-modifies it's flight plan (for whatever reason, even DirectTo on existing waypoint, or Fly Direct To, as you did)... I'll just reset the "Accept FlightPlan" flag, so that it will prompt you the next time a Flight plan is sent to overwrite your changes.... it'll simply say "Accept flight plan?" and await you saying "Yes/No" before dialog goes away.
Sure, you'lll have an extra button to tap (i.e. "No") but at least it'll be clear, and won't overwrite your flight plan. I see no downsides to this approach (except for a single button tap to say "no"), and am planning to fix this bug in this fashion.
Brian Knox,
Sr Software Engineer
|
|
|
|
| |
|
|
|
OK done with this fix. Easy change. If you modify the flight plan on a slave, it simply forgets that you said "Accept Flight plan", and the next time the other flight plan is transmitted (even if not changed) -- the slave device will prompt you to accept the plan again. Just tap Yes/No, as appropriate.
Brian Knox,
Sr Software Engineer
|
|
|
|
| |