Horrified
 

As a very part time passenger and model plane pilot, I have followed this threads with interest. The CVR and FDR data is horrifying - I would have thought that professional pilots would have behaved very differently in such a situation. I could imagine myself as thrown into that situation and doing no worse than the PF did - perhaps better when it came to stick inputs. That is scary.

On a recent flight I noticed the issue mentioned in a couple of comments - that is the loss of sense of aircraft orientation. I could have sworn the plane was level but when I looked out saw thet the wings were banked and the plane was turnning left. I can only imagine how hard it must have been for these pilots to sense what the plane was actually doing withouit any horizon on a pitch black night, with what appeared to be unreliable instrumentation.

I guess that is when training and professionalism is meant to take over...

For those who have flown the A330:

How many key strokes (steps) does it take to call up the F/CTL ECAM System Page on the SD. This screen shows where the rudder and THS are, and what the spoilers are doing, what spd brks are or aren't doing, and a prim/sec status. It also looks to tell you which hyd system is up or down as related to a given flight control.

Does this screen get auotmatically pre-empted by rising ECAM alerts, or does is stay active once selected?

Background thinking to my question:

About 20 years ago, something as simple as switching Radio Freqs went from a simple manual task of turning a button here or there, to a process which requires opening a screen and typing in freqs. (This was in the SH-60F). As I had never had trouble with switching radios by hand, I looked into this and noticed that it takes MORE time and steps to switch radios via software. From a pilot task loading perspective, this was idiotic. It appeared to me one of many "solutions" looking for a problem. On that aircraft, the sole FBW control surface was the horizontal stabilizer. (Sorta like the THS in A330, but different). A single, small gauge in the lower center of the instrument panel told you where the stab was at all times. (It was mostly controlled by an auto trim feature). This gauge was a cross check instrument, not a primary scan instrument. You only needed it if things were a bit wrong with the electronics. There was also a manual control that overrode the electro-trim and allowed you to fix its position as needed.

Back to THS on an A330.

I don't know if the crew in AF447 would have thought to look at where their THS was ... but ... if the PNF had wanted to, how many steps in sequence would it take to discover where that control surface was positioned?

mm43, HazelNuts39, thanks so much for the informative replies.

Quoting HazelNuts39:-

I read the BEA's Perpignan report (on a accident back in 2008) but missed the point you very kindly brought up. To quote part of the report:-

So, as I read that, in order to get the THS even to start moving back to a sensible angle, the Perpignan pilots (and later the AF447 ones) would have needed to shove the stick full forward and hold it there for quite a while, until the THS 'accepted the situation' and started moving back from 'full up.'

But, of course, on AF447, every time they attempted that, the airspeed increased and they got another 'stall warning.' And presumably thought they were 'doing it wrong' (what, apart from an engine falling off, can be more serious than an impending stall?) and instinctively relaxed the stick pressure.......

It'd be interesting to know whether Airbus, Air France, or the BEA had warned pilots that this sort of 'impasse' could occur; and indeed had occurred, as far back as Perpignan in 2008? I very much doubt it........

Anyway, thanks again - I now know, to my own satisfaction, the primary causes of this latest accident. And, in my view, they weren't entirely, and possibly weren't even mainly, 'pilot error.'

Have the investigators (BEA) stated that the zoom climb was commanded by the pilot (stick) or is the jury still out considering that a computer function did it unrecognized by the pilot?

I focus on this early event as a possible critical causal factor needed to take a benign failure condition (temporary lack of reliable airspeed) to a severe condition.

To me this is a critical finding, because we can'y elliminate all failure conditions (ala loss of airspeed) etc. We are left with strengthening a minimization factor like pilot training. If there is another critical area that can be worked on in this causal chain that would greatly minimize a repeat of the event chain leading to a fatal accident.

Unfortunately, this was an Airbus accident and this thread will no doubt go on for another One Hundred Thirty plus pages ! Had it been a "real" airplane, "case would've been solved" a Hundred pages ago. Naturally, IMHO. :*

The causes are independent of the plane
 

IMHO The causes are :

1 The decision of the PF to climb, yet the PNF has told him the temp. was to high;
2 The decision of the PF to re take control from the PNF without annoucement and to climb again yet the PNF has urged him to nose down.

These two decisions of the PF are not a reaction to any information from the plane.

They came from his will and only his will.

The first decision leads directly and logically to a stall;

The latter decision prevented the PNF from recovering the plane.

None of these decision should have come from a Professional Pilot.

These decision had nothing to do with training nor CRM, design etc.

Furthermore, the Captain had a nasty feeling proved by his odd question : "Do you have your licence ?" to somebody that had made the journey with him from Paris.

I really think that it should be investigated to understand in which psychological or physical conditions he was.
I believe that the very short time between the entering of the Captain and the level 100, barely allowed him the time to understand that the PF was climbing against all skills. When this was established, then the PNF could took the control again under the Capt. authority. But it was to late.

I believe that tço many people here and in the press don't make the distinction between the period before teh PF re take control of the plane and the short sequence after.
The BEA should have divided the time around this KEY action:

- Because the PNF needed the authority of the Capt to take control except if he were Rambo.

- Because when the Capt. enters, he doesn't see the end of the stall caused by the first decision of the PF. He lives a NEW sequence just after the PF had RE taken the control and that he climbed again, entering in a new stall.
Too short for the Capt to understand.

Hi,

Can anyone explain me this (it's extracted from the BEA report french edition page 23)

http://i.imgur.com/hFfhC.jpg

:confused::confused:

JJFFC
:ok:

The more and more I read the more concrete it seems that the "zoom" was initiated by PF input to the SS not as a result of AP disconnect (which was a point of confusion to me). This is a significant deviation from the previous theory that the AP "wound out" until it reached the end of it's capabilities and handed the plane off in an entirely unstable condition.

Am I correct in my understanding that the climb was in fact initiated by proactive input and that the subsequent trim changes are a result of the auto trim responding to the SS inputs?

Given the very serious issues involved in approaching max altitude even with full instrumentation (let alone under the circumstances involved) any decision to gain altitude would appear to be fundamentally incorrect and display a complete lack of basic airmanship. What pilot would knowingly fly an airplane with degraded systems closer to coffin corner? Did not the senior pilot on the flight deck have a clear responsibility to forcibly (in the verbal sense) take command if required?

I have been unable to find reference to the captain questioning the PF's credentials (was this before the upset? before the flight?). If the captain had enough concerns to actually make a comment then how does he allow this individual to actually be the PF when he retires from the cockpit????

Quoting Lonewolf50:-

Looked it up (can't find the photos again) and the conventional (non-electronic) A330 setup looks pretty good. Big trimwheels either side of the central console, and (I checked :)) they're servo-assisted, and actually move! :)

However, the wheels don't give you the pitch angle; they just have the 'usual' setup, white marks every 15 degrees or so. Apparently there are gauges beside the wheels that give you the angle - how well illuminated they are, and how easily you could read them at night, I just don't know.

Point that occurs to me, though, is that the autotrim was still operating? So, even if the pilots had thought to check the trim settings and maybe wind the wheels forward a bit, presumably the 'systems' would just have wound the things back to 'full up' again?

@SLFinAZ
Page 73 of the BEA Interim report:

What do you want "explained" ?
It's the Honeywell part number and serial number of the FDR memory module.

EDITED

Cross posting :)

English report N°3 page 73

Hi,

Well ... put your spectacles again on your nose (or use binoculars) :8
The SN number of image and txt report are not corresponding (different !!)
Page 23

Of course they are not.

The image is of the CSMU, the memory module. The 'text' P/N and S/N is from the FDR chassis on which the CSMU was mounted.

If you right ... this is odd to the BEA to publish a image and a legend not corresponding ....
That's not serious ...

EDITED
And you no right !

Thanks KBPsen, I thought it was a genuine question, not another effort at a conspiracy theory 'à la Asseline'. I should have known better....

Read my post above !

So they should have published a picture of the FDR chassis that was neither found nor recovered? Who is it that is not being serious here?

related to the thread:

AFP: Rio-Paris jet crash probe 'discredited': relatives

Do we know whether the FDR chassis was retrieved, or only the memory module?

Identifying a part that they didn't recover is confusing. If the identification is really based on an integrated component (the memory module), then additionally reporting the part /serial numbers of the memory module would seem sensible.