GNSS NPA's are dangerous

[WynSock]

As a pilot who regularly uses GPS NPA's in a two-crew RPT aircraft,
I am not alone in finding the chart presentation confusing, difficult to read and easy to misinterpret.
I am not alone in suggesting that these charts and the approach design had crucial significance at Lockhart River, the information to support this lost on the CVR.
I have only asked other pilots about what they think. I haven't asked ATSB or CASA.

I think they need redesigning. Most importantly, the distance to several waypoints must be changed so that the distance to go is related to the last missed approach waypoint only.

This needs to fixed now before it causes another accident.:uhoh:

[WynSock]

duplicate post

[Shitsu_Tonka]

Could not agree more about changing the Distance reference.

[Chimbu chuckles]

This has been discussed here several times.

The certification criteria on which GPS NPA approaches are based alledgedly requires the Foxtrot waypoint.

All that means of course is the original designer had no idea what he was doing.

The Foxtrot waypoint is dangerous...the GPS NPA is essentially the only approach where the final descent profile, in its entirety, is not based on a distance to a MAP.

It is a sick joke...I would bet folding money this is a significant contributing factor in a least one fatal crash I am aware of....there will be more.

If the certification basis for GPS NPA 'requires' this idiocy then CHANGE THE CRITERIA:ugh:

[Jethro]

Gentlemen,

My vague recollection is that the original AsA chart layout did display "Distance to MAP", but this was LESS intuitive because most modern GPS/FMS displays only present "Distance to Next Waypoint" in the primary field of view. Dist to MAP (or any other selected W/P) may be presented in another area of the CDU, if required.

I fall into the same Cat. of Operation you mentioned above. I'd suggest that the Lockhart River accident, as sad as it was, resulted from more than just procedure design.

[404 Titan]

If there isn’t something wrong with the way GPS NPA approaches in Australia are designed then can someone please tell me why there is a ban at my airline (and I assume others) doing such an approach in Airbus aircraft (not sure about Boeing) using “Managed” vertical guidance. This ban is world wide but the problem lies in the design of the approaches in Australia. I have seen one demonstrated in the sim for BNE rwy 19 and the bl**dy thing tries to land you several miles short in the water. I believe there are many other airports in Australia with the same problem. So far no other airports anywhere else in the world have been identified with this same problem.

[clear to land]

There are some FMC coding issues with one major Australian airport approach for the 777 but other than that we have no restrictions ie the FMS flies the approach fine and safely. Have flown a lot of the Aust ones in the 73 ans no problems there either.

[Capn Bloggs]

I agree Foxtrot is a crock. OzExPat blames the manufacturers for not wanting to/not able to remove Foxtrot because of scaling issues but I simply don't understand that.

Now that these approaches have allegedly killed more people than an NDB or VOR for years, it's about time CASA changed the design standard in the light of better technology.

If I understand it, CASA was the world leader in GPS NPA design and the concept is great. However, the waypoint at 5nm was a mistake IMO and that should be designed out post-haste.

some FMC coding issues
read "stuffups by Honeywell/Jeppesen". I wonder when they will ever get their act together. Considering millions of people the world over are putting their lives in the hands of their product every day, it's a wonder they can't do a better job (or the regulator doesn't jump on them).

[404 Titan]

Capn Bloggs

I have been lead to believe the coding issues are a direct result of the design of GPS NPA approaches in Australia compared to the rest of the world. While no one is 100% sure, hence the world wide ban, all indications are something isn’t right with how Australia designs its GPA NPA approaches and it needs to be looked at.

I agree with you on the stuffups by Honeywell/Jeppesen by the way.

[swh]

This ban is world wide but the problem lies in the design of the approaches in Australia.

Does the navigation data have product approval in accordance with ED76/DO200A ?

Would explain a lot if it does not, been problems with data that is not as the FMGC assumes the MAPt is 50ft over threshold stuffing up the whole computed vertical profile.

In any case, before flying the in FINAL APP the operator has to validate the approach in the database.

[404 Titan]

swh

Does the navigation data have product approval in accordance with ED76/DO200A ?
say again in English. :confused:

The notice to crew at our company advising of this problem states the auto pilot will fly the aircraft below the profile and it thinks the thresh hold is well before the real one. Again from my understanding there isn’t any way of really telling if the aircraft is going to stuff up the profile in “Managed” vertical guidance by simply checking what is in the MCDU. It’s a case of eliminating them one by one in the sim which I believe has been done for Auckland when the runway works are in progress.

[Woomera]

This thread is also running in D & G.

Anybody???

[Woomera]

Copied only to Tech Log for input from there!

This thread remains active. :ok:

[clear to land]

Our SOP's require pilot validation of the approach in the FMC, which means:
Approach must be line selectable, No Vertical or Lateral mod of points beyond the FAF (speed constraints OK), Final course and distance tolerances within 1 deg/1nm, No min x-ing alt infringed, App Angle >= charted angle, Alt at RWY/MAPt appropriate, RNP 0.3 or better, and when avail AP/FD coupled.
All this is done as part of the brief and easily checked in about 30 secs in the FMC. Have flown many GNSS/RNAV approaches and never had a problem.
Interesting to note that from previous comments some of this is not possible on Airbus - or have I misinterpreted.

[john_tullamarine]

.. probably more appropriate in D&G .. perhaps it can be joined with the other ?

[alf5071h]

JT I beg to differ; the subject deserves a wide audience as it poses significant threats which all pilots should be aware of.
The Australian theme probably stems from
Perceived Pilot Workload and Perceived Safety of RNAV (GNSS) Approaches. (www.atsb.gov.au/publications/2006/b20050342.aspxATSB Transport Safety Discussion Paper B2005/0342:)

My experience and informal investigations indicate that GPS approaches have been over-sold as an answer to the hazards of NPAs. In general GPS/VNAV approaches are much safer, but to the unwary there are several pitfalls.
The most significant issue is that most (all) vertical profiles depend on QNH, and thus a simple mis-setting or crew error in crosschecking can lead to a hazardous situation. Several EGPWS incidents involving large commercial aircraft were reported in a recent FSF presentation; although none were proven to be due to GPS/VNAV, the circumstances and nature of the errors would apply equally to GPS approaches.

I comment on an interesting incident involving QNH (not GPS) here (www.pprune.org/forums/showthread.php?t=239658), what if the MD 11 was IMC and it was using VNAV?

[Woomera]

alf ... JT concurs .. following liaison with me (simultaneously with your sage advice), we have merged the threads here ... and put a sticky in Tech Log to direct attention to the active thread .. if no other benefit accrues, at least the commentary will be in the one place for convenience.

SE Woomera

[APMR]

GPS NPAs had so much promise so it is a great shame they have turned out this way. But, all is not lost - the deficiencies can be rectified.

I am a professional pilot (not GPS NPA endorsed) and also a software developer. Back in 1992, I had to write a GPS based navigation system for a survey company. The survey "runs" consisted of up to a dozen waypoints that were roughly aligned.

Before the software even flew, it was obvious to all of us that the crew, once established on the run, were not interested in the intermediate waypoints - they only wanted to know the distance to the final waypoint.

So, I altered the software to the effect that the intermediate waypoints were effectively hidden. And, if the track from one segment to another changed too much (requiring a significant turn), extra waypoints could be inserted on either side of the transition so as to "smooth out" the change from segment to segment.

The crew had only an across-track display and a distance to run (to the final waypoint of the run). If we had wanted to, we could have easily added turn guidance info for those moments when transitioning from one segment to another.

All very easy. The end result, for the pilot, was one apparent segment that would occasionally change track slightly. We could have flown perfect figure 8's if we had wanted - all as one apparent segment.

So, don't let anyone tell you that the GPS NPAs we have today must work the way they do.

If I had designed them, the pilot would see only 2 waypoints - the IAF and the MAP. Upon activating the approach, the GPS would guide him to the IAF. After passing the IAF, the guidance would then be to the MAP, via several (invisible) intermediate points, with the displayed distance being the track miles to the MAP. The FAF would just be a published distance from the MAP.

To avoid stepped descents and limiting altitudes, vertical guidance (via a glideslope like indication) would be provided and the descent path would be a constant angle. Tricky terrain around the airport would be accommodated via curving approaches. For altimeter check purposes, the altitude the aircraft should be at would be continuously updated and displayed.

Flying one would feel like flying an ILS that changes heading occasionally.

[bushy]

This is exactly the sort of thing that is needed. If you could get an accurate GPS determined altitude, this would expose and avoid pressure altitude errors.

[Jethro]

From APMR's and other replies, I believe that the problem is less about procedure design and all about aircraft equipment. Aircraft with basic displays do not have any form of vertical representation of glidepath, while the suggestion of a continuous (digital) display of correct procedural altitude would probably add more to pilot workload than a simple glideslope indicator.

Problems associated with incorrect setting of altimeter only strengthens the case for the FAF to remain:
1. To act as a final crosscheck of altitude/glide path and highlight altimeter setting errors prior to the MAP, bearing in mind that altimeter errors are not linear and a final crossheck as close as possible to the MAP is desirable.
2. To provide another critical step for obstacle clearance, where obstacles in the approach path may be limiting.

On both these points, I fail to understand how the FAF in an RNAV/GNSS approach differs from any limiting altitude step in a DME/GPS Arrival procedure or from the FAF/glideslope height check in an ILS approach.

On Point 2, should the FAF be removed from an RNAV/GNSS approach where there are obstacle limitations, the minima may be raised and the benefits of this type of approach unnecessarily restricted.

[Reverseflowkeroburna]

Jethro.........

Point 1 - I don't believe anyone is suggesting we rid ourselves of the FAF, just that it be a distance which is referenced to the same point as all the others. Just like in the ILS or DGA scenarios you mentioned. That's the simple difference, they don't have a distance to run to anything other than the one point during the whole of the approach. Thus, one cannot mistakenly identify one segment for another!!!

Point 2 - FAF or no FAF, as a separate waypoint or otherwise..........Limiting altitudes, obstacles and descent points can occur either before, at, or after the FAF. The manner of representation of this Fix is an entirely independent consideration of the step-down issue.

Hope I've cleared that rather than muddied it. :)

[NavMonkey]

In response to APMR's comments there is no major technical reason why a GPS box couldn't give distance to MAPt. However, unfortunately these issues go back to the start of the product development cycle and require changes to international and industry standards to resolve. Mind you, that is not to say that making the changes would not be a worthwhile endeavour.

Many of the problems go back to DO-208 the industry standard for aviation GPS receivers. It is an engineers paradise, contains 214 pages of acronyms, test procedures and equations of which 1.25 pages are dedicated to 'operational characteristics' - in other words how the avionics should interface to the pilot. :ugh: Neither the FAA/EASA Technical Standard Order (TSO-C129) or the airworthiness requirements (e.g. FAA AC-20-138) required a GPS box to provide anything other than distance to the next waypoint to the pilot. Hence, when the manufacturers have produced their equipment they have complied with the standard. Also any assumptions made by IAP designers are based upon the functional performance outlined in the technical standards which are then reflected in PANS-OPS.

The problem is that even if we go back to sort out the equipment standards there will still be kit around for a long time that only displays distance to next waypoint. So what do you PPruners think we should do to make the best of the situation? In the Australian research mentioned above the specific problems related to workload/confusion seem to be:

1. No flight deck presentation of distance to MAPt (from the GPS),
2. Too many waypoints on the approach too close together with inconsistent leg lengths,
3. Presentation/interpretation of the charts themselves.

Given that (without investment in additional airfield infrastructure - e.g. a DME) the first may take a while to resolve how best should we address the latter 2 points in the IAP design? Also in the opinion of the PPruners would solving 2 & 3 be enough to provide requisite safety levels?

Apologies for the waffling post, but this is something of real interest right now.

Cheers, NM.

PS. As an aside I have sat through and participated in the international standardisation of these units for a number of years and its only recently that I have heard any mention of this distance to waypoint issue being a problem. There was flight crew participation in the standardisation process (albeit limited). I'm not saying that it isn't an issue - because it clearly is, I'm just wondering why no one spotted it before and could it be related specifically to the Australian IAP design?

[Chimbu chuckles]

Surely a programming and database update would resolve the hardware issues in any IFR TSO compliant GPS?

It would then simply be a case of a comprehensive reissue of the required IAL plates sans the Foxtrot waypoint.

The one step of removing the Foxtrot waypoint would bring GPS NPA approaches in line with every other IAL procedure...all of which, in the final descent phase, are referenced to a single point in space, a MAP.

For a GPS which is positioned within the radio stack a remote reading display would be required, as is the case now. The GPS signal is coupled to the HSI/CDI, as is now the case, and above the ADI is a small display with waypoint name and distance to it, as is now the case. On the approach plate would be a table with distance/altitude AND a profile which represents that table. For instance the profile may be 3xGPS distance + 100'= profile altitude.

The PIC has now all the information required to fly a safe final approach...he tracks the CDI the way he would for an ILS, either manually or coupled, and simply looks at the distance to the named MAPt in the window a few cm above his ADI as says to himself "3x6+100' = 1900'...on profile".

3x5+100=1600'..50' high (adjust ROD slightly)
3x4+100=1300'...on profile (adjust ROD slightly)
3x3=1000' on profile, gear down.
3x2=700'..approaching minima.
3x1=400' level..MAPt, not visual going around.

And his/her eyes never leave the instruments until he/she looks for visual reference, his scan and SA are maintained.

As it currently stands he is required to be looking at the chart constantly and comparing his altitude and distance from 'a' waypoint..."Hmm 3 miles from F waypoint (which is probably 8nm from the MAPt waypoint) and I should be..where isn it...ok 2500'..ok now 1nm I should be 1800'...now 4nm from the next waypoint I should be..umm...oh 1300'."

In the first example the PIC has no requirement to reference the approach plate at all after briefing and setting up the navaids in the cruise. The way it is at present he must constantly reference the approach plate, during the most critical phase of flight, to have any chance of remaining situationally aware...when he should just be flying the aeroplane.:ugh:

[Jenna Talia]

Are there any USA counterparts reading this thread that may be able to comment on LPV approaches used in the US with regard to WAAS augmentation capability? This then allows a glideslope indicator to be used for vertical guidance and has in fact lead to lower minimums throughout the US.

I believe AirServices have been considering for some time this method, but are undecided about whether to use the US, Japanese or Euro's augmentation system.

This has got to be a much safer system and we can only hope that the procrastination ends before another tragedy results.:ugh:

JT

[Tinstaafl]

I'm not sure that the Dist-to-next-waypoint issue is really a newly recognised problem. I recall when GPS NPA's were first introduced in Oz all the guidance material implicitly recognised the problem by emphasising the waypoint distance difference.

Perhaps back then it wasn't realised just how much it's at odds with convention?

[hot_buoy]

If there isn’t something wrong with the way GPS NPA approaches in Australia are designed then can someone please tell me why there is a ban at my airline (and I assume others) doing such an approach in Airbus aircraft (not sure about Boeing) using “Managed” vertical guidance. This ban is world wide but the problem lies in the design of the approaches in Australia. I have seen one demonstrated in the sim for BNE rwy 19 and the bl**dy thing tries to land you several miles short in the water. I believe there are many other airports in Australia with the same problem. So far no other airports anywhere else in the world have been identified with this same problem.
the problem with the procedures you've identified are to do with the acft equipment. the honeywell fmc in airbus acft does not comply with the ARINC424 standard [let alone the current standard]. it assumes that ALL missed approach waypoints are at the threshold and as such assumes you want to be at 50' abv thr ht at this point. if your MAPt is not at the THR due ATC or climb or turn requirements then ANY app which is coded as an RNAV will fly the same profile to a point short of the rwy. if it were coded as GPS rather than RNAV [as they used to be] then they will fly correctly!!
The ARINC424 standard states where the MAPt is not coincident with the RWY THR then a calculated xing ht must be inserted at the MAPt. Honeywell FMCs don't do this! Jeppesen have confirmed that they have coded the procedure in accordance with the ARINC standard.

[clear to land]

Can't help myself: Boeing superior to Airbus AGAIN!!! (Ducks for cover :) )

[hot_buoy]

I agree Foxtrot is a crock. OzExPat blames the manufacturers for not wanting to/not able to remove Foxtrot because of scaling issues but I simply don't understand that.
Now that these approaches have allegedly killed more people than an NDB or VOR for years, it's about time CASA changed the design standard in the light of better technology.
If I understand it, CASA was the world leader in GPS NPA design and the concept is great. However, the waypoint at 5nm was a mistake IMO and that should be designed out post-haste.
as you've been told before [and you "simply don't understand that"] the design of GPS NPAs is forced by the US military [the owners of the GPS system] not the manufacturers, nor the procedure designers.

although i personally don't have a problem with the concept of distance to next wpt, i can understand that some might, and would prefer a distance to THR [not MAPt as this can be up to 3km fm THR].

what you are looking for is a presentation which will allow you to do some simple mental math to improve your situational awareness. A laudable concept, lord know when ur bouncing around SP IFR on a dark stormy night you don't want to add complexity to what is a difficult time at best.
this does not equate with the REQUIREMENTS of the procedure design to track you from one waypoint to the next [this is what a GPS receiver does - from the manufacturer] whilst keeping you clear of terrain [what the procedure designer does].

your statements are futile. unless the US military amend their specification, the manufacturers won't change their software/hardware, and procedure designers can't change procedure steps.
if you think there is a way to change the procedure plate presentation such that you will be better able to use that information AS IT RELATES TO THE WAY THE DATA IS PRESENTED ON THE GPS UNIT {this bit can't be changed without telling the USM} then, by all means, talk to CASA.
this means the presentation on the GPS won't change as it is not controlled by AsA nor CASA. the procedure plate, either AsA or Jepp version, can be changed. if you reckon there can be an improvement, let someone who can do something about that know. else stop persisting with ur drivel



read "stuffups by Honeywell/Jeppesen". I wonder when they will ever get their act together. Considering millions of people the world over are putting their lives in the hands of their product every day, it's a wonder they can't do a better job (or the regulator doesn't jump on them).
like all big business, they don't respond to governments just $$$

[hot_buoy]

GPS NPAs had so much promise so it is a great shame they have turned out this way. But, all is not lost - the deficiencies can be rectified.
I am a professional pilot (not GPS NPA endorsed) and also a software developer. Back in 1992, I had to write a GPS based navigation system for a survey company. The survey "runs" consisted of up to a dozen waypoints that were roughly aligned.
Before the software even flew, it was obvious to all of us that the crew, once established on the run, were not interested in the intermediate waypoints - they only wanted to know the distance to the final waypoint.
So, I altered the software to the effect that the intermediate waypoints were effectively hidden. And, if the track from one segment to another changed too much (requiring a significant turn), extra waypoints could be inserted on either side of the transition so as to "smooth out" the change from segment to segment.
The crew had only an across-track display and a distance to run (to the final waypoint of the run). If we had wanted to, we could have easily added turn guidance info for those moments when transitioning from one segment to another.
All very easy. The end result, for the pilot, was one apparent segment that would occasionally change track slightly. We could have flown perfect figure 8's if we had wanted - all as one apparent segment.
So, don't let anyone tell you that the GPS NPAs we have today must work the way they do.
If I had designed them, the pilot would see only 2 waypoints - the IAF and the MAP. Upon activating the approach, the GPS would guide him to the IAF. After passing the IAF, the guidance would then be to the MAP, via several (invisible) intermediate points, with the displayed distance being the track miles to the MAP. The FAF would just be a published distance from the MAP.
To avoid stepped descents and limiting altitudes, vertical guidance (via a glideslope like indication) would be provided and the descent path would be a constant angle. Tricky terrain around the airport would be accommodated via curving approaches. For altimeter check purposes, the altitude the aircraft should be at would be continuously updated and displayed.
Flying one would feel like flying an ILS that changes heading occasionally.
interesting comments.
however i'll tell you that RNAV (GNSS) [aka GPS NPAs] do have to be designed the way they are currently.
whatever programming you have done was not done for any of the current certified RNAV receivers [GPS or otherwise].
as i've stated in other posts today, the US military gave a spec to which manufacturers created their receivers. the procedures are then just following the MINIMUM spec available as TSO129C. ICAO spelt out how that is done and your regulator will insist how that is implemented.
if there had been input in the late '70s when the spec was created, maybe things would have been different. hindsight is wonderful!

[WynSock]

Hot buoy, if you are doing any other approach with a FAF, I agree its a requirement to know where it is and to track over it. You just use a DME distance or a Marker or whatever to give you its position relative to the MAPt.


this does not equate with the REQUIREMENTS of the procedure design to track you from one waypoint to the next [this is what a GPS receiver does - from the manufacturer] whilst keeping you clear of terrain [what the procedure designer does].



:rolleyes:
OK, I new someone would bring this up. Whatever the manufacturer says, whatever the procedure designer wants, whatever the regulator requires, whatever the tea lady prefers....etc etc.

I'll keep it simple...As a pilot of a multi-crew RPT aircraft, regularly conducting GPS NPAs into various airports, in various weather conditions day and night...

In my opinion, they are dangerous - they need to be fixed now.

I don't give a flying f#$% what it takes, just fix it now.

Not later, now.

:*

[Chimbu chuckles]

The US Mil may own the satelites but that is all...how the TSO spec came to be is a completely separate issue.

[WynSock]

interesting comments.

I agree!


maybe things would have been different. hindsight is wonderful!

Are you for real? I get the impression that those in the "technically impossible, too expensive" camp have given up on this one. All the passengers and crew who may have to eat dirt as a direct result of this hazard probably would beg to differ.

[hot_buoy]

The US Mil may own the satelites but that is all...how the TSO spec came to be is a completely separate issue.really?
TSO129C is a direct derivative of RTCA DO-208
TSO145/6 are derived from RTCA DO-229C

[NavMonkey]

really?
TSO129C is a direct derivative of RTCA DO-208
TSO145/6 are derived from RTCA DO-229C

The TSO's are developed by the FAA (and copied by the EASA and others) to augment the requirements in the RTCA docs.

The RTCA docs are developed by (usually large) committees composed of airframers, avionics manufacturers, ANSP's, CAA's and others from around the world.

The only military connection in any of this is that GPS is being used and the performance of the SPS element of the GPS service has been specified by the US DoD. All of the aviation receiver functionality be it the HMI, how integrity is provided, how to generate a nav solution, how to generate guidance for an RNAV route are the product of the RTCA committees, not DoD.

[Chocks Away]

I haven't had any bad experience with them in many years of extensive exposure to them, in all climates.

Situational awareness AND good multi crew support is the key.

Can't comment on jet software (Airbus)...suffice to say Boeings BDFW is good (Box t'Does Fuggin Wonders).

Requests previously did go in to modify the Jepp plates, re distance to MAP not next WPt and graphic MSA floors for better comprehension (Eastern/QF, I believe)... many have been adjusted.

Found them safe and no probs with them myself but interesting to read.

[Sir George Cayley]

UK CAA are currently conducting a GNSS NPA trial which was due to end this month, but I hear is to continue to the end of the year.
I flew a couple a while back and was thrown by the Step Down Fixes (SDW) and tempo lost spatial awareness.
I agree that the presentation of distance to go from GPS and conventional RNAV is an issue that needs to be addressed.
What ever the answer is it should be adopted world wide. Over to you ICAO:rolleyes:
Sir George Cayley
ps Funny in here. All the alcohol rushes to me 'ed:oh:

[Cloud Cutter]

Good thread, this is something I've had a problem with since I started using this type of approach.

The main point seems to be that GPS distance to next approach waypoint can be confusing.

The fix seems obvious: Publish both distances. Not ideal of course, but you could make use of the distance to MAPt and use the distance to next waypoint to crosscheck - this would stop any waypoint confusion.

Most GPS units are able to display total distance to each waypoint, and this page is only required until you reach the final approach fix, where the distance becomes intuitive.

[bushy]

And while you are concentrating on all this, it is easy to lose altitude awareness. I reckon this sort of thing has killed a few already. So far, only in small numbers.
The technology is there to fix it.

[Capn Bloggs]

Hot Boy,
stop persisting with ur drivel
You can call it what you like mate, the fact is that people are having problems with GPS NPAs because of the difficulty caused by Foxtrot and it is likely that the design contributed to the deaths of 19 people. And yes, you'll be pleased to know that I have had quite a lot of success in forcing Jepp/Honeywell to change their database programming, which just goes to make the whole situation more pathetic: it could be done properly but it wasn't.

As you know I have said before (how many Prune guises do you have?), the box doesn't give two hoots about where the waypoints are for tracking or mode changes. One of our boxes starts scaling down to APPR 2nm before it gets to Foxtrot so it's pretty obvious in doesn't need to fly over a waypoint to start doing something different.

IF your theory about the design criteria is correct (and NavMonkey's answer above casts doubt on that) then the design criteria, allowing one waypoint at ~10nm, should be changed and the Foxtrot "point" should become a distance from Mike (as it is with every other non-precision approach). I simply do not accept that the technology to do this cheaply doesn't exist. NavMonkey might have to redraw all the approach charts, but that'll give him something to do! :}

[Feather #3]

Bloggs,

I'm with you 2,000% on this one!!:D

Loss of altitude awareness as you struggle through the segments is a major problem. Not only for a newbie [to this approach], but even a reputable [?] operator at my home GA port; the EGPWS doesn't work in the landing configuration!:uhoh:

G'day ;)

[Cloud Cutter]

Yes, that's the whole point. The way the profile and min alts are published against distance to next waypoint (ie FAF) rather than distance to the MAPt. Alt awareness is the main reason you would be interested in the distances, so you can monitor the descent profile.

[Capn Bloggs]

so you can monitor the descent profile.
Or indeed, as we do, use the ALT/DIST scale to place yourself on, and stay on, the 3° slope to the runway. As it is a straight-in, you need to be AT the MDA right on slope, otherwise you'll be high on the VASI and) depending on your aircraft type and manoeuvring ability) you probably won't get in.

We actually use the 300ft per nm system as it's simpler ot anticipate on the altimeter, but the principle is the same. With a distance-to-run interrupt at Foxtrot, life becomes much more difficult.

[Tinstaafl]

Most of the a/c I fly have 2 x GPS or a GPS that has an additional cursor-on-map function with a display of distance & bearing to the cursor position. I either set the 2nd GPS to fly direct to the Mapt or threshold, or I activate the cursor & position it over the same point - which also gives me a distance display unrelated to the other fixes in the procedure.

[WynSock]

Most of the a/c I fly have 2 x GPS or a GPS that has an additional cursor-on-map function with a display of distance & bearing to the cursor position. I either set the 2nd GPS to fly direct to the Mapt or threshold, or I activate the cursor & position it over the same point - which also gives me a distance display unrelated to the other fixes in the procedure.

That would be a work-around. You can't simply ignore SOPs. Remember the letter that CASA sent us... "pilots shall not operate outside of approved procedures..etc etc." incidentally going on to practically blame the pilots for the last two bad Australian CFIT accidents.

Maybe I am ignorant of all the technical issues in fixing this hazard, but that doesn't stop me from simply stating my opinion about how I find them in the real world, two crew, EFIS, automated, RPT cockpit.

Dodgy to say the least.

[WynSock]

The plates for RNAV NPAs have a distance-to-runway scale at the base of the profile diagram.
Is this an afterthought? What is the point of printing the distance to run if you can't see that anywhere in front of you?
Did the engineers of the whole GPS approach format realise something after they had signed and sealed the design?

You need a distance to the runway for true situational awareness.

Any closer to fixing this? Probably not, it will take a fatal accident with a working CVR to get it fixed.


:(

[Chimbu chuckles]

I would bet folding money CASA and AsA are well aware of the issues...as are their Lawyers.:ugh:

[Wheeler]

In a GNSS RNAV system, we have to have a CDI with a localiser needle wired up to indicate distance off track. Many such instruments I have seen in this type of GPS approach application (E.g. King KNI 520) also have a redundant glideslope needle, sitting there doing nothing. Could the G/S be connected up, using the information from the altitude encoder and GPS distance information to provide a kind of non-precision glideslope? Surely, what we need is some sort of secondary check to make sure we are not getting too low at the wrong waypoint. At the moment, if we do mistake an intermediate waypont for a later one, there is no secondary check to tell us we are getting too low, unless maybe we have a switched on, qualified co-pilot of course.

[bushy]

Wynsoc
There has already been a fatal cfit with a working cvr, some years ago, in a westwind freighter at Alice Springs.
There are a number of lessons that we should have learned from it, but obviously we did not.
A two pilot crew was flying a triple ndb approach, which had a bend in it, but was depicted on the plate as a straight line. I have flown that approach, and it was almost unflyable (within tolerances). The captain had flown that approach on a previous occasion, and had not been happy with his tracking tolerances.

On this occasion (on a clear night) the captain was flying the aircraft, and his pre-approach brief included a minimum altitude, which was correct. But during the approach while the captain was flying, the co-pilot called an incorrest minimum altitude, which was lower than the minimum altitude the captain had nominated himself during the brief. Despite this, the captain descended and the cfit occurred.

Why??

The captain was obviously distracted by something and appears to have lost altitude awareness. I think it is a reasonable assumption that he was concentrating on trying to track within tolerance. The required tracking tolerance was +/- 5 degrees, and the approach had a built in 4 degree error.

The ATSB report criticised the captain for not maintaining the track within 5 degrees.

This approach was fairly new, and was quickly discontinued.

The two pilot crew system did not detect and rectify the altitude error.

It was a clear night, and the appraoch could have been flown safely visually. Alice Springs had a TVASI which is visible from the crash site and beyond.


There are some similarities with the lockhart river accident.

Both were two crew turbine powered aircraft, but did the two crew system work properly during the approach? Was there effective cross checking? The co-pilot at lockhart river was not qualified for the approach being flown. There is some doubt about the clarity of the approach plates, and the possibility of error when reading distances and altitudes, in both accidents.

There are still many unknowns with the lockhart river accident, and I do not pretend to have the answers. But I do believe there are similarities and lessons to be learned from these accidents, and I hope we learn them,.And act on them this time.

[WynSock]

It's been a while since this thread was discussed. Have there been any changes of note?
Like getting rid of the distance-to-run to multiple waypoints for e.g.

What happened to the company involved? Still flying?

[nick charles]

Bushy,

I also heard that, in the Alice Springs prang, the pilots were using different charts. If true, that wouldn't have helped the situation.

[Dick Smith]

Wheeler, the Honeywell GPS system in my Citation Bravo did just that – i.e. it came up with a pseudo-glideslope indicator by simply projecting a 3º glideslope back from the missed approach point using the data from the Jeppesen database and the altimeter.

My current Citation CJ3 with the Proline 21 does even more – it is completely coupled vertically, and you can do the approach to the missed approach point with any GPS approach in Australia coupled to the autopilot.

This is not rocket science. The glideslope indicator is simply taking the information from the Jeppesen database and connects it directly to the autopilot.

I have had a few friends at CASA fly with me in the CJ3 and shake their heads in disbelief – I think they are trying to work out why such a simple system should be allowed!

In the United States they have the Wide Area Augmentation System (WAAS) which provides this coupled glideslope, but as I said, I have it in Australia today – in a standard CJ3 with a current Proline 21. As long as you push the buttons correctly, the autopilot will not make a mistake on the approach. Of course you monitor the approach, as you do on an ILS, to check that everything is working OK. So far, in all of the approaches I have done, it always has been.

[bushy]

And I believe that equipment would have prevented the Lockhart River and Alice Springs prangs.

[megle2]

Dick

Ditto of course for any other aircraft fitted with Proline 21 ie B350 / B200.
Great gear.

Bushy
Exactly, but then Casa insist on such low equipment standards its hard to get the bar raised.

[goddamit]

Now my 2 cents worth. The coupled autopilot is great, but errors do occur even in the database. I am an experienced RPT jet Captain who flies these approaches every week or two. The Boeing/Jep database is sometimes in error & even if it is spot on there is a number of correct inputs some of which may accidently be overlooked by the pilots. I see it in the the sim every so often. Despite what is req'd(ie the FAF waypoint) all data should be referenced the Mapt or runway threshold enroute to the mapt section of the procedure. Some approaches like CBR 35 have waypoints reference off others in this way. Reading & matching FMC/GPS data gives very little situational awareness the way it is now. If reference is given from the airport gross errors will usually be picked up.(ie everyone knows how high they should be at 10nm etc). I believe CASA got off with murder with the Lockhart river crash. The Captain was at fault ultimately & from my knowledge wasn't overly conservative, but...CASA gave him a loaded pistol in the form of the modeled GPS approach depiction. Even with 10,000 hrs & most on RPT jets, in IMC I have a tough time tracking the approach as well as I could an ILS, VOR or even an NDB approach. The way the approach is represented needs to be changed. Everyone in my airline I speak to agrees. Most elect to do the GPS approach as a last resort because of the stated reasons. Please change this format to make it easier on everyone.

[WynSock]

It won't be changed, at least not until it causes a big prang and it's all there on the tape. Then they will change it and give themselves a big pat on the back for being so proactive.


:sad:

[reynoldsno1]

[QUOTE][/it came up with a pseudo-glideslope indicator by simply projecting a 3º glideslope back from the missed approach point QUOTE]

...and if the MAPt is not at the threshold ....what then????

[Capn Bloggs]

Reynolds number, Dick describes the system in it's most simple form. The reality is (provided the database is coded correctly and actually has the capability to do so), the required "glideslope" is coded into the database taking into account the position of all the fixes, step limits and the MAPt.

[megle2]

I should of added that the Proline 21 system continues to provide tracking and height requirements through to the end of the missed approach where you then decide to hold ( all on the autopilot ), re do the approach / fly a different approach or divert.

[Capn Bloggs]

ASA and CASA sat on their hands and did nothing when it was an identified problem.

The real problem is changing the design criteria. These approaches have taken on like wildfire around the world and a change (to say remove Foxtrot) will be resisted by the authorities as being too hard. It's not too hard: just bloody do it! :ugh:

Is that Ozexpat I see coming?? :)

[OzExpat]

Is that Ozexpat I see coming?? :)
Not unless you've been in my bedroom with me and my current girlfriend! :eek:

[Capt Wally]

...very interesting reading indeed on this thread...but what's the very basic idea of an NPA (or any approach for that matter) in the first place?............to get visual from IMC conditions & complete the task at hand, land !
We in aviation have benifited from our flying buddies of years gone by from their unfortunate incidents/accidents, all learnt from having a go. There was no other way.
The NPA although fraught with all sorts of traps for the unaware is basicly a good idea using the most accurate triangulation(& more) format known to mankind. Flying is by it's very nature dangerous (as is sitting at an outside restaurant in SYD only to have the old 'golden mike' spray a few nasty words at you, see Lawsies silly antics). The authorities responsible for the design & format of these NPA approaches are just like us pilots, their human with many faults and without all the answers. It just takes time to get it right by trial & error as awful & silly as that sounds! Sure there will be accidents resulting from perhaps poorly designed charts etc. & even with perfect surveyed/designed charts there will always be deaths from simply the one thing you cannot perfect, & that's US, the boy & girls who have the final say on anything in aviation !:-)
I for one feel that NPA's are good, they do the job at getting us where we need to be & that's what it's all about at the end of the day. There's zillions of these approachs being conducted world wide every day. day in day out, if they where that bad then the evening news would be all sad:-(
Let's learn from our 'brothers' mistakes & do it right, the next time:-)


Capt Wally-)