I am slowly getting to grips with all the functionality available via the IFD550 I recently installed and I am enjoying the learning experience as I slowly understand the buttonology and FMS architecture.

I recently came across an oddity on an actual flight which I am sure is just fat finger trouble on my part, but I could not see how to correct it.

Firstly, full disclosure I know the problem is rooted in how my authority/Jeppesen have coded the overlap between the Nakon3A arrival and ILS Z RW21R into VTBD but this occurs often over here in Asia so I want to find out the implications and how to manage the IFD when it happens.

If you see the Nakon3A arrival, it ends in AROKA than BD111 WP’s.

If you look at the actual ILS Z RW21R approach that connects to this, it duplicates the same two WP’s. AROKA being the IAF, and BD111 the IF.

When the arrival and approach are loaded into the IFD, you get this round robin that merrily takes you back the way you came due to this overlap.

This also used to happen in my old GNS units, and I learnt to delete AROKA and BD111 from the end of the arrival to stop this problem. After deleting AROKA and BD111 from the arrival section the IFD still maintains “Gap in route” error with no way to connect back to BD114 the last remaining WP of the arrival, and so to get around that I manually jumped past the gap by going direct to AROKA. Is this the only solution?

Cheers - E

I suspect that you deleted AROKA from the arrival first and then BD111.  There are a few software-related reasons that the FMS wants to keep the first leg of the approach (AROKA) intact.  So, when you delete AROKA from the arrival and then delete BD111, the FMS inserts the gap.  Deletion of that gap would require insertion of a direct between BD114 and AROKA, but the FMS assumes that an arrival is followed immediately by an approach, so that's why you can't close that gap.

However, if you only delete BD111 from the arrival, then you end up with AROKA as the last leg of the arrival, followed by AROKA as the first leg of the approach.  The FMS notices this and doesn't insert the gap.

In 10.3, this will look slightly different because you'll actually see both legs.  When the aircraft reaches AROKA, the FMS will sequence both of them and BD111 will be the active leg.  There were a couple of reasons for this change.  First, the old method of combining the legs at the boundary betweeen the arrival and the approach could cause some ambiguity in subsequent edits because the FMS couldn't know whether the pilot wanted the combined waypoint to be part of the arrival or part of the approach.  Second, the new method allows the pilot to recognize the situation when a common waypoint has differing altitude constraints.  In the picture below, AROKA has an "at or below 5000" constraint, so there's no gap.  However, if the constraints were different, there would be a gap between the two instances of AROKA.  The pilot would then be able to recognize the issue and resolve the issue, likely by changing the constraint on one of the legs.

Short answer: no, this is not the only solution to this arrival issue. 

Since I cannot find a similar example to test in the North American IFD database, I also assume that the IFD will not let you delete BD111 on the arrival without first deleting AROKA on arrival. With this in mind, I’m not aware of any solutions that would eliminate manually intervening to get the IFD navigating on the other side of the persistent gap between the arrival and approach.

Long answer: IMO, your technique works only because the arrival course doesn’t change between DOGVA and AROKA. If you are assigned the ENUU3A transition, your method of solution may not work nearly as well.

My take; you may want to consider doing nothing with the arrival and approach routing as it goes into the IFD leaving both the gap and overlapping routing. Once the aircraft crosses AROKA on the arrival routing, perform a Activate Leg to the BD111 waypoint on the approach side of the gap. This preserves the arrival and overlapping approach routing all the way and will work for any transition used on this arrival. Your example technique actually loses the arrival routing between BD114 and AROKA but works because the arrival course does not change at BD114. With only seven miles between AROKA and BD111, the IFD will probably be reminding you of the gap ahead before you even get to AROKA. The downside of this technique is that before the gap, the IFD will have an extra 14 miles of routing built into it; therefore, along track distance to destination, ETA at destination, and fuel at destination will reflect the extra mileage until the active waypoint is sequenced across the gap.

@chflyer – Thanks for the pointer to pilotsafety.org.  Looks like there is some very useful knowledge in there. The free video on gaps does cover a similar scenario, but Gary’s solution of loading the IAF as a wp before loading the destination/procedures does not work for my particular case.

@aviSteve. Correct, I did indeed delete AROKA first followed by BD111 on the arrival, and trying your suggestion of only deleting BD111 on the arrival using the 10.3 simulator works as you described.   I will try that technique on my actual IFD unit which is running 10.2.6.1 to see if it works there as well, if not @dmtidler’s suggestion is almost what I ended up doing today during the flight.  It sounds like v10.3 will handle it better moving forward.

Cheers - E