Part II: Air Canada, too low on...
In case a330pilotcanada's post wasn't sufficiently clear...or, in case I've missed the boat altogether, we've now seen the second such incident in as many weeks.
AvHerald's report of the latest - with reference to the first: Incident: Air Canada E170 at New York on Dec 9th 2012, descended below safe altitude
Perhaps the cause of the second is written on the bottom line of the first:
AvHerald's report of the latest - with reference to the first: Incident: Air Canada E170 at New York on Dec 9th 2012, descended below safe altitude
Perhaps the cause of the second is written on the bottom line of the first:
The Canadian TSB reported the airline conducts an investigation into the occurrence.
gwillie;
Re,
Internal Safety Investigations done by the airline are usually effective and is the way SMS works in Canada and, I suspect, the U.S. The regulator has oversight responsibilities of course, (assuming the necessary resources are in place...) but in this kind of an incident an internal investigation is reasonable and warranted. Sometimes FOQA data helps in such investigations depending upon the agreements with pilots' associations. Regardless, the airline's safety policy and culture is non-punitive so getting to the bottom of why this happened is only a matter of information-gathering and time.
Re,
"Perhaps the cause of the second is written on the bottom line of the first: Quote:
The Canadian TSB reported the airline conducts an investigation into the occurrence. "
The operator suspects there is a data problem in the navigation database for the non-precision approaches for LGA rwy 04.
Also, no company-checking of database prior to use?
Good Evening Captain Bloggs:
Although retired the S.O.P. is to check that the data base is current ie 01-12-2012 to 31-12-2012. If not select the correct data base if roll over has happened.
In addition in the pre-descent check protocol not only calls for the approach briefing but confirmation that the data matches the approach plate, notams etc
I had a chuckle that previous poster brought up the old saw about metric visibility versus Imperial measurement. Short answer the approach plate visibility limits has to match what is on the ATIS reported visibility etc.
As I stated earlier wait for the investigation to be complete and someone will attach the official finding in a post as opposed to conjecture but I digress
Although retired the S.O.P. is to check that the data base is current ie 01-12-2012 to 31-12-2012. If not select the correct data base if roll over has happened.
In addition in the pre-descent check protocol not only calls for the approach briefing but confirmation that the data matches the approach plate, notams etc
I had a chuckle that previous poster brought up the old saw about metric visibility versus Imperial measurement. Short answer the approach plate visibility limits has to match what is on the ATIS reported visibility etc.
As I stated earlier wait for the investigation to be complete and someone will attach the official finding in a post as opposed to conjecture but I digress
What I was alluding to was procedures/techniques to spot when the aircraft, which is following the box, is going off the rails ie diving below the required profile between waypoints.
Re the company checking, I understand that some check the database before flight use using a checking program.
Is it conceivable that this sort of database error (if it is the problem) could occur on a RNP-AR/SAAAR approach where there is no way of checking the profile altitude/distance down the approach apart from perhaps total track miles to run (if it is displayed somewhere?).
Re the company checking, I understand that some check the database before flight use using a checking program.
Is it conceivable that this sort of database error (if it is the problem) could occur on a RNP-AR/SAAAR approach where there is no way of checking the profile altitude/distance down the approach apart from perhaps total track miles to run (if it is displayed somewhere?).
Thread Starter
Join Date: Aug 2000
Location: formally Alamo battleground, now the crocodile with palm trees!
Posts: 960
Likes: 0
Received 0 Likes
on
0 Posts
Is it conceivable that this sort of database error (if it is the problem) could occur on a RNP-AR/SAAAR approach where there is no way of checking the profile altitude/distance down the approach apart from perhaps total track miles to run (if it is displayed somewhere?).
The VNAV function seems a little buggy: One problem my company encountered with the E190 was with company RNV-F visual approaches into LGA runway 31 and DCA RNV-F 19. Half the time the VNAV would not capture. I heard from some check airmen that Honeywell tries to blame it on Embraer and vice-versa, in other words, the same blame game software companies play.
I learned quickly to not rely on VNAV on this aircraft.
Last edited by Squawk7777; 22nd Dec 2012 at 05:42.
Join Date: Feb 2000
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
G/S Capture
Truth is the G/S was 'captured from above, all the restrictions & heights were checked on the computer against the Jepp Chart, ( as per SOP)......FYI, there has been a software glitch on the Embryo in this regard for awhile now. Once on the path, the A/C does not respect the crossing restrictions.....
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Once on the path, the A/C does not respect the crossing restrictions.....
