FMS altitude input error led to autopilot glideslope drift

[torrence]

I select "34" in the ARR page, and can either:

* Just set runway extension distance, but unable to set an altitude at the RW34 waypoint ("INVALID INPUT"). It has an FMC computed altitude of 2500 ft at RW34, and I'm unable to change it

or

* Select VFR APP to the runway and alter the glideslope, but not the extended centerline distance (fixed at 8.0 nm).

That makes no sense to me... Why can I not change the extended centerline distance in VFR APP mode (ARR page), or the altitude in the non-VFR arrival selection?

Several points - which sort of make the case that kluging up the visual arrival per the Virgin procedure has a number of potential pitfalls.  Probably a good call to cancel use of this approach.

First - in the PSX situ that I put together (see earlier post) - I noticed that I also got INVALID INPUT msg when entering threshold.  Reason - the PSX FMC needs a 4 digit input for the altitude constraint.  Try entering 0380 not 380.  And if you enter 0380 in the incorrect runway extension waypoint what you get is a BOLD 380 at FA34 an a non-BOLD 380 computed altitude at RW34.  But just glancing at the screen to check the LEGS page they don't look that different and one could, I assume, assume things were OK since 380 shows up at the threshold waypoint without noticing that VNAV was going to force you to that altitude much earlier. 

Second point - in comparing the charts and databases, note that the incident in the ATSB report occurred in 2013.  In the latest charts on line there is now a named waypoint ASUKI at the position of the runway 2.8 nm extension, making it a little harder to enter the threshold in the wrong place (waypoint name with '34' in it) I guess. 

Cheers,
Torrence

[United744]

Ahh thanks! I didn't try the leading zero.

I saw they added an additional waypoint. Good idea.

Any ideas why I can't change the length of the extended centerline in VFR mode?

[Hardy Heinlin]

A feet value must always have at least 4 digits (leading zeros may be necessary), otherwise the FMC will take it as a flight level value. This is not PSX specific, it's a common FMC rule.

Whether or not the entered value is displayed in flight level format depends on the TA (climb legs) and TL (other legs).


As for the RWY EXT, you have these two options:

VFR APPR>

RWY EXT
--.-NM


VFR APPR is simply a fixed programmed procedure, fixed like every other procedure. It always sets 8 nm and 3.0°. It's a quick setup. If you are not happy with it, just select the line below which is there because the line above is a fixed setup. I.e. you have two options: Pizza with mozarella or pizza with anything you want. If both could have anything you want, i.e. if both options were the same, it would make no sense to offer one and the same option twice.


Cheers,

|-|ardy

[United744]

Hmm... I wanted 2.8 nm and 3 degrees, but could only get 8.0 nm and 3.0 degrees...

It results in the aircraft making an unnecessary left turn to pick up the long final.

Guess I'll take to Boeing about that one!

[Hardy Heinlin]

Hmm... I wanted 2.8 nm and 3 degrees, but could only get 8.0 nm and 3.0 degrees...

Then just don't use the fixed VFR approach. Instead, enter 2.8 in --.-NM and select 6R. This will make a direct-to and open the LEGS page where you need to enter some altitude constraints and close the route discontinuity to the runway. However, there will be no VNAV glidepath capture function for a 3° path; it will go directly from constraint to constraint.

If you could enter any RWY EXT for the fixed VFR approach, while being able to modify the 3° path angle, there would be the risk of messing up the whole approach construction; this fixed VFR approach always sets an altitude contraint of 2000 ft above the runway at the FA fix. If you would shift the FA fix too close to the runway, the path angle had to get steeper than 3° for geometrical reasons. If it were near the runway, the glidepath would be nearly 90°, starting from 2000 ft above the runway.

On the other hand, making a longer leg to the FA fix is always possible by adding another preceeding waypoint in the LEGS page.

[torrence]

I think the glideslope issue was addressed by the Flight Training Briefing paper from Virgin in the ATSB report (Fig - i.e.  put the 0380 hard threshold altitude in RW34 waypoint, then put 1270 as hard altitude in the 2.8 nm centerline extension waypoint (FA34 in our FMC).  This produces a somewhat higher v/s out of SHEED but sets up the 3 deg slope after the turn to final. 

All in all, as a non real world pilot, this seems a lot of work with lots of potential mixups (the reason the briefing paper was released apparently) just to use RW34 this way.  I think this is the gist of the ATSB findings and Virgin's change of procedures.  If long flights coming in to YMML use RW34 routinely, I'd think they would want to put in an ILS - although I know those types of things take time and money.  Or maybe this is Melbourne's version of the old Hong Kong Checkerboard - just neat to fly (until it isn't).  Never been in to there in real life, just YSSY.

Cheers,
Torrence

[ScudRunner]

Folks,

a further incident and flow on-effect for international operations onto RWY34 at YMML concerning this particular approach.

http://www.atsb.gov.au/publications/investigation_reports/2012/aair/ao-2012-120.aspx


enjoy

Scud.