GTN Xi Hold Exit Legs

[midlifeflyer]

8 minutes ago, PT20J said:

Yep. I did something similar, only I made the hold entry 5000, hold 4000, hold exit 3000. All were hard "At" constraints. I monitored the altitude of the simulator by setting one of the user fields on the map to GPS Alt (GSL). I started the simulator at 6000 and activated the hold. It set a TOD and descended to 5000. Upon crossing the holding fix I selected SUSPEND and it climbed back to 6000 which I take as a bug in the sim, but I believe that the real system will probably just ignore the hold leg constraint and maintain altitude. Just after passing the holding fix again, I selected UNSUSPEND and it created a TOD and descended to 3000 at the holding fix before proceeding to the BOD at the next waypoint.

That makes sense. Except as you point out, the climb. VNAV only does descents.

[Marc_B]

Agree with above.  If you have a smooth VNAV descent within parameters and only using a HOLD as a course reversal then VNAV works to meet hold entry at the fix the first time, hold leg constraint with TOD on the outbound leg, and hold exit leg constraint crossing the fix the second time. 

However, if you suspend the hold then the altitude constraints and VNAV no longer function.

If you manually load a hold (manually loading hold does not come with "hold exit leg"), VNAV will still act on the hold entry constraint and hold leg constraint as above.  That is if it can meet the constraint and it's a small altitude drop.  But another issue is that it won't flag you that "cannot reach vertical waypoint" until that segment is active.

The quirk I was meaning was that 1) if you actually hold in a holding pattern (hold suspended) VNAV doesn't work, and 2) that if VNAV can't meet the descent within your course reversal it will just blow though the fix above your constraint.  So coming in high and asking ATC for a turn in the hold to loose altitude needs to be done with a VS descent and not VNAV.

[midlifeflyer]

10 minutes ago, Marc_B said:

Agree with above.  If you have a smooth VNAV descent within parameters and only using a HOLD as a course reversal then VNAV works to meet hold entry at the fix the first time, hold leg constraint with TOD on the outbound leg, and hold exit leg constraint crossing the fix the second time. 

However, if you suspend the hold then the altitude constraints and VNAV no longer function.

If you manually load a hold (manually loading hold does not come with "hold exit leg"), VNAV will still act on the hold entry constraint and hold leg constraint as above.  That is if it can meet the constraint and it's a small altitude drop.  But another issue is that it won't flag you that "cannot reach vertical waypoint" until that segment is active.

The quirk I was meaning was that 1) if you actually hold in a holding pattern (hold suspended) VNAV doesn't work, and 2) that if VNAV can't meet the descent within your course reversal it will just blow though the fix above your constraint.  So coming in high and asking ATC for a turn in the hold to loose altitude needs to be done with a VS descent and not VNAV.

I’m not surprised that an altitude constraint in the hold doesn’t get processed. It’s not really a “waypoint.” As we know, the HSI is set to the inbound course. Turning in the hold is basically a GPSS function - a bunch of lateral heading instructions understood by the autopilot. That doesn’t mean Garmin can’t or won’t add vertical behavior for it at some point.

Nor am I surprised that suspending sequencing to the hold Exit also suspends VNAV to the suspended Exit waypoint. That makes sense to me. And if VNAV can’t meet the descent or distance requirements once you unsuspend, I’m not surprised that it doesn’t do it, just like with any other VNAV waypoint, hold or otherwise.  

The important thing to me is to understand the behavior so I can plan for it in flight.

The only quirk I see is, if VNAV doesn’t do anything in the hold, why bother allowing the constraint to be amended. But that may be anticipation for some later change.

 

[PT20J]

4 hours ago, PT20J said:

Yep. I did something similar, only I made the hold entry 5000, hold 4000, hold exit 3000. All were hard "At" constraints. I monitored the altitude of the simulator by setting one of the user fields on the map to GPS Alt (GSL). I started the simulator at 6000 and activated the hold. It set a TOD and descended to 5000. Upon crossing the holding fix I selected SUSPEND and it climbed back to 6000 which I take as a bug in the sim, but I believe that the real system will probably just ignore the hold leg constraint and maintain altitude. Just after passing the holding fix again, I selected UNSUSPEND and it created a TOD and descended to 3000 at the holding fix before proceeding to the BOD at the next waypoint.

I repeated the same test in the airplane on a HILPT with a GTN 650Xi and a GFC 500. The autopilot descended as expected in VNAV to meet the hold entry constraint at the holding fix. After crossing the holding fix, I suspended sequencing. This cancelled VNAV and the autopilot reverted to PIT. I selected ALT to maintain altitude in the hold. After crossing the fix a second time, I unsuspended the GTN with the autopilot in ALT and VNAV armed. The GTN calculated a TOD to reach the hold constraint and VNAV went active at TOD. The TOD was on the outbound leg before the turn. As the autopilot completed the turn inbound, the GTN sequenced from the hold leg to the hold exit leg and the VNAV altitude changed from the hold constraint to the hold exit constraint.

So, the takeaways are:

1) GTN VNAV will not perform a descent within a holding pattern when the GTN is suspended, and;

2) If you enter the hold with the autopilot in VNAV and do not select ALT before suspending, the autopilot will revert to PIT and likely slowly descend.

[Pinecone]

Sorry, I don't recall this being addressed in the training.

[midlifeflyer]

7 minutes ago, Pinecone said:

Sorry, I don't recall this being addressed in the training.

There is a lot missed in both the manual and the training. You can't cover everything. 

[Marc_B]

I've been to the TXi/Xi Garmin onsite course.  They didn't discuss VNAV and holds at all.  They did cover building a hold, but the scenario we had was basically a roll your own ODP that was given as an IFR clearance as a "hold at X, climb in the hold to 13,000.  Upon reaching 13,000 exit and proceed..."  So you'd be using IAS climb with ALTS armed and 13,000 bugged. 

I also don't remember anything being said about holds with hold exit legs vs without.  In my experience holds with exit legs have been the ones in approaches that were loaded from the system and holds without exit legs have been ones that I've built.  So I'm curious if anyone has seen a hold without an exit leg that was loaded from a procedure...

 

[PT20J]

So, we have learned some things about holding patterns. And, I believe we have established that the only reason for the hold exit leg is to allow an additional VNAV altitude constraint.

Now, has anyone figured out the very confusing distance and time indications on the Flight Plan page for the hold leg while suspended?

[midlifeflyer]

9 hours ago, PT20J said:

Now, has anyone figured out the very confusing distance and time indications on the Flight Plan page for the hold leg while suspended?

Are you referring to this and the associated time entry? And after it goes down to zero, it starts again with another number. And pick yet another one if you unsuspend and then suspend again. The reason it's weird is easy. The unit has no idea  how long you are going to remain suspended. It's just like not descending to a constraint within it.

How or why it chooses that number? Just a WAG. It doesn't know how many laps you are going to do so it's making an assumption you will go around twice, which seems reasonable. The extra 4 NM for this hold is the turns. That's seems consistent: I let it run out completely and it reset the timer for 12, which is one more lap plus the turns. 

(BTW, the Avidyne doesn't make that 2X assumption and just does the 12 each time around)

 

[Jim Peace]

Garmin and all the other avionics companies have the poorest interface with the pilot.  The boxes we use in the airlines  are user friendly and very intuitive..simple and monochrome.  Route page, legs page, and holding page and just a few others for basic information which is all you need.  How many thousands of flights around the globe get from A to B using them and it works.  Would be great to have the same simple interface in all cockpits then everyone is more or less on the same page.  Why do these GA avionics companies all try to re invent the wheel......It's not needed....and makes flying less safe...Even installing an approach is complicated...Install, install activate etc etc etc...

[PT20J]

3 hours ago, midlifeflyer said:

Are you referring to this and the associated time entry? And after it goes down to zero, it starts again with another number. And pick yet another one if you unsuspend and then suspend again. The reason it's weird is easy. The unit has no idea  how long you are going to remain suspended. It's just like not descending to a constraint within it.

How or why it chooses that number? Just a WAG. It doesn't know how many laps you are going to do so it's making an assumption you will go around twice, which seems reasonable. The extra 4 NM for this hold is the turns. That's seems consistent: I let it run out completely and it reset the timer for 12, which is one more lap plus the turns. 

(BTW, the Avidyne doesn't make that 2X assumption and just does the 12 each time around)

 

I set mine up for DIS and ETE. When in a hold with the sequencing suspended, the ETE on the flight plan page doesn't agree with the ETE on the default navigation page and the distance on the the two pages also do not agree although the distance on the default page appears to be the straight-line distance to the fix. I asked Garmin support to explain how these distances and times are calculated.

[midlifeflyer]

1 hour ago, PT20J said:

I set mine up for DIS and ETE. When in a hold with the sequencing suspended, the ETE on the flight plan page doesn't agree with the ETE on the default navigation page and the distance on the the two pages also do not agree although the distance on the default page appears to be the straight-line distance to the fix. I asked Garmin support to explain how these distances and times are calculated.

I wonder what they will say.

[MikeOH]

34 minutes ago, midlifeflyer said:

I wonder what they will say.

"Your guess is as good as ours!?"

[midlifeflyer]

7 minutes ago, MikeOH said:

"Your guess is as good as ours!?"

Maybe :D. 

I'm curious but for now I'm still going with my guess, so I'm not surprised to see a discrepancy with either distance or ETE. 

[Pinecone]

There are some anomalies in how things work.

One crazy thing is, when you use the Flight Planning page, if you choose from Present Position, it doesn't assume the Present TIME.  It assumes power on time. WHY?????