Hi all.
I did several approaches requiring PT or course reversal and I noticed that when I load such approach it looks like it was flipped over in ND. In the example below for VOR D RWY 02 in TGU, the procedure requires to turn right from D7.0 onto heading 243. I loaded this approach in FMC and it looked backwards. It shows I will pass D5.0 VOR then FV02 fix and then right turn to the loop and she was actually flying that way. So basically it won’t be really a PT. I noticed this happens very very often. I asked pilots at work about this issue and they said it should not happen in real world. Any idea why it happens and how to tweak it?
Thanks. 
 

 

 

Any idea why it happens and how to tweak it?

 

Simple answer?  Fly it on your own.

 

If not on your own by hand, use HDG SEL.  I believe there is an FMC software version (in the real world) that has specific programming to fly procedure turns, but the NGX doesn't have it.

 

As I always say:

Don't be a slave to the magenta line and the FMC.  Sometimes it's best to leave it at what it's supposed to be - an aid - and take over for it.  This is especially important at airports like MHTG.  The margin of error is slim, and you don't want to end up in a mountain because the automation didn't behave like you had expected, or because you had your head down trying to get it to do what you think it should be doing.

Agree, do not bother to fix it, just turn off lnav, there are variety of AP mods available with good reason. You can even hand-fly it.

This is not an rnav procedure. You cannot fly it in lnav

You can see how does procedure turns look like on 737 in FCOM vol.2, page 10.40.10 (700 in PDF).

PMDG haven't implemented it yet along with some other RNAV specific functions.

 

This is not an rnav procedure. You cannot fly it in lnav

 

Why can't?

This is not an rnav procedure. You cannot fly it in lnav.

 

That's not entirely accurate, at least in FAA land.  The method used to track a particular course is not mandated in any section of the regs.  Provided you have the equipment (in this case, the ability to fly the course using a nav radio tuned to the VOR, and the specific VOR approach must be in the database), the autopilot mode is not of any consequence.  The only reference to autopilot modes in the FARs is related to minimum altitudes for its use, and requirements for MU-2 ground training.

 

In order to fly an RNAV approach, you would need to have the requisite equipment as specified on the chart, however the inverse is not true.

 

This is all subject to a particular airline's op-spec.  If the writers of the op-spec specifically state "[this] approach requires the use of [this] mode," then that's what needs to be used.  One op-spec I know of allows for the use of LNAV/VNAV for VOR approaches, provided the raw data is displayed on at least one ND.  In the broad regulatory sense (agency-wise), however, there is no such requirement.

Real-world considerations aside, I think it's safe to say that we're dealing with a bug in the NGX code in this particular instance. Whenever conditional waypoints (such as FVO2-4 shown on your ND) and tight turns are part of a procedure, unpredictable routing may ensue. I've seen simple 90 degree turns transform into monstrous 360 degree spirals, witnessed the magenta line "flapping" nervously between two possible routes (both wrong), and -- as happened in your example -- seen turns flipping direction. Let us intersect our fingers and hope for a fix in SP2.

The interesting question is about TNT hold: How to exit that hold and join 198* radial?

 

Real-world considerations aside, I think it's safe to say that we're dealing with a bug in the NGX code in this particular instance.

 

There's a difference between a bug and code that is not implemented.  It has already been stated that this software version does not have procedure turns implemented.  As such, it's not a bug.  A bug produces an incorrect result through mistakes or errors in coding.  Because the omission was intentional, it cannot be a bug.  I know that's semantics, but it's worth noting.

 

 

The interesting question is about TNT hold: How to exit that hold and join 198* radial?

 

Without seeing the vertical profile, it's tough to see the mechanics of the approach fully, but remember that holds are protected zones.  As such, you could fly a teardrop pattern on the protected side of the 198 radial, to proceed back outbound.  You could do this by beginning the teardrop when rejoining the 198 radial inbound and "bounce" off of it to the right to turn back outbound.  You could also do it as you pass over the VOR, simply continuing your right turn past the outbound leg of the hold, to join the 198 radial outbound (I'd argue this would be easier to judge your position).

Without seeing the vertical profile, it's tough to see the mechanics of the approach fully, but remember that holds are protected zones.  As such, you could fly a teardrop pattern on the protected side of the 198 radial, to proceed back outbound.  You could do this by beginning the teardrop when rejoining the 198 radial inbound and "bounce" off of it to the right to turn back outbound.  You could also do it as you pass over the VOR, simply continuing your right turn past the outbound leg of the hold, to join the 198 radial outbound (I'd argue this would be easier to judge your position).

Here is full chart:

 

It's kinda ridiculous. Indeed I can do all of your three suggestions and follow vertical profile. As I understand, I should keep 9000ft until I capture 198* outbound? Next thing, there is no way to exhaust ~2300ft in 1.7nm in normal landing configuration. Maybe with flaps 40 but I really doubt.

Real-world considerations aside, I think it's safe to say that we're dealing with a bug in the NGX code in this particular instance. Whenever conditional waypoints (such as FVO2-4 shown on your ND) and tight turns are part of a procedure, unpredictable routing may ensue. I've seen simple 90 degree turns transform into monstrous 360 degree spirals, witnessed the magenta line "flapping" nervously between two possible routes (both wrong), and -- as happened in your example -- seen turns flipping direction. Let us intersect our fingers and hope for a fix in SP2.

 

It's not a bug - the navadata syntax doesn't support procedure turns, so the FMC looks at something like the original picture and sees that the shortest path from (FVO2-4) to 50VOR is a right turn, not a left one and that's what it draws. You can fly a procedure turn completely using the ND VOR mode or the RMI just like a Cessna would - that's what I'd recommend doing.

 

Procedure turns are going to be a pretty rare thing to see in any real life airliner flying though by the way.

As I understand, I should keep 9000ft until I capture 198* outbound?

 

Yes.

 

 

Next thing, there is no way to exhaust ~2300ft in 1.7nm in normal landing configuration. Maybe with flaps 40 but I really doubt.

 

Note the visibility mins, though.  They're requiring 3.7km of vis, which is just about 2nm.  While that's not much more than 1.7, 1.7 only refers to the missed approach point (MAP), and not that you should maintain 5620' until that point.  As soon as the runway environment is in sight, a visual approach should be conducted to that airport.  Also note that there are no straight-in mins, which means that it assumes you're not going to be able to dump yourself right onto the extended centerline, despite the VOR being aimed nearly in line with it.  Its only purpose is to get you lower, into that area of high terrain so that you can acquire the field, circle around it to drop altitude, and then land on Runway 2 (but also note that you're required to avoid a prohibited area because of the military side of the field).

 

Man...this airport is a real PITA...

Well, here's an approach, but other than getting you in the vicinity, enjoy dodging mountains and P airspace!  GOOD LUCK!!!

Yes.

 

 

 

Note the visibility mins, though.  They're requiring 3.7km of vis, which is just about 2nm.  While that's not much more than 1.7, 1.7 only refers to the missed approach point (MAP), and not that you should maintain 5620' until that point.  As soon as the runway environment is in sight, a visual approach should be conducted to that airport.  Also note that there are no straight-in mins, which means that it assumes you're not going to be able to dump yourself right onto the extended centerline, despite the VOR being aimed nearly in line with it.  Its only purpose is to get you lower, into that area of high terrain so that you can acquire the field, circle around it to drop altitude, and then land on Runway 2 (but also note that you're required to avoid a prohibited area because of the military side of the field).

 

Man...this airport is a real PITA...

Well, here's an approach, but other than getting you in the vicinity, enjoy dodging mountains and P airspace!  GOOD LUCK!!!

Ok, that's just great, I actually overlooked that straight-in is NA. I have to admit I heavily underestimated this APP. 

 

There is RNAV approach that cannot be used with NGX because there is some retarded RF portion I cannot rebuild.

 

In my country, actually in whole region, there is no such tricky approaches, we have to practice in FNPT sim, I'm gonna discuss and try this approach with instructor.

The margin of error is slim, and you don't want to end up in a mountain because the automation didn't behave like you had expected, or because you had your head down trying to get it to do what you think it should be doing.

This is exactly what happened. Twice. :( It makes more sense now. 

Thank you for advice.  

Thanks a lot for your responses. When I get a chance I will ask pilots at work how they fly down there. One of my co-worker jump-seated over there, she made a nice video. I'll check if it is still available. Will share then.   :rolleyes: