About the videos (jcjeant post)
 

2nd video (may 27 2011, before BEA 3rd report, but after BEA "Note":
... [0:53] Personne n'a le droit, pour l'instant, d'émettre une quelconque hypothèse sur ce qu'il s'est passé [0:58] ...
... [0:53] Nobody has the right, for now, to make any assumption about what happened [0:58] ...


1st video, may 29 2011 (just after 3rd BEA report press conference):
... [0:51] bien évidemment le pilotage, en manuel, en haute altitude, dans une (régio...) zone turbulente, en mode alternate, c'est probablement très particulier [0:59] ...
... [0:51] Of course flying in manual, high altitude, in a turbulent (regio...) zone, in alternate mode, it is probably very special [0:59] ...

Knowing the CV of this man ( Air France - Corporate : Eric Schramm, Executive Vice President Flight Operations ), it seems (IMHO) this wording is quite as astonishing than the one of the AF447 crew. Have we to think this "Qualified as Boeing 777 flight captain" doesn't know how flying is like in altitude when external and internal conditions are not smooth???

Is it the same in other compagnies?

Hi,

Maybe it's the reason why they keep this man in the offices instead let him flying ........

@Sensor_Validation (post #1765)

Quote:

Has it been confirmed what AoA sensors were fitted?
Pretty likely the Thales C16291AA given the choice of Pitot tube, if so one could have been suffering an extreme variation of the known fault at low temperature:-

According to La Tribune newspaper, the EASA is about to require the change of about 1,600 Thalès AoA sensors known to have a flaw. It seems the fabrication process might be responsible for some oil to be left unnoticed in the mechanism. With decreasing temp, the oil can slow or even block the sensor movement. This problem happens at random during manufactoring according to the article. Also, it restricts the affected Thalès AoA sensors to A320. But we would need to cross-check that, wouldn'd we ?

Source:
Airbus : des sondes thales de mauvaise qualité

Hey, I've got an idea!.... It just came to me in a flash.... Maybe all airlines should remove anything that Thales built and replace it with something from a reputable manufacturer? :cool::ok:

@vbp.net:
The EASA AD kindly found & linked by sensor_validation in his post #1765 specifically mentions A330 & A340 and not A320?! IMHO the answer we don't yet know, is whether that model of AoA sensor was installed on AF447...

Reading the comments from other contributors here, it seems unlikely that whatever was wrong with AoA sensor #1 had a material impact on the events on this flight, although yet another fault added being into the mix is obviously a worry. Or do you believe the issue with this AoA sensor #1 was significant in the events that occurred?

@3holelover: I was going to apply for a job at Thales. I'm now re-thinking that plan :(

It's not as simple as that - what AoA inst were involved in the Perpignan crash?

Ans:

Thales make a lot of great kit and and its used extensively throughout many aircraft flight control systems - NB all with appropriate Airbus/EASA approval.

I think that David Learmount is right when he talk about the flying skills of old pilots. New pilots apply procedures instead of "flying", that's the way Airbus told us to use his aircrafts to lower the number of accidents.
This new technology has saved many lifes, but new accidents appears and I think that, by applying procedures only, we just transfer human errors from the pilots to human errors from enginers that create those fully automated aircrafts.
If we want to progress in flight safety, we must mix old flying skills with new flying procedures. CPT Shullenberger proved us it works.

AoA 1
 

Diagnostic,

The first worry above all is how the BEA didn't talk a single word about it ...

Second worry is that such oversight is not isolated.

@sensor_validation:
I thought those (Goodrich) AoA probes had been effectively mistreated (due to the incorrect pressure wash forcing water past the seals), so they were not to blame. At least that's how I remember it, from when I read the report years ago... My memory is not perfect, of course.

I take your points, thank you. I try to see the best in people, and so the apparent oversight at this stage, might just be caused by them not having yet added this detail into the latest interim report, and perhaps it may be mentioned (as inconsequential?) in the final report. But, it may not be mentioned even then - and them totally missing something like that even in the final report, would indeed be a worry!

@CONF:
 

-The AOA replacement program was already in progress before publication of the 3rd BEA report.

-They did found the cause: 'machine oil residu left after the fabrication process' and so they know the solution too.

-There was no relationship whatsoever with this case.

@A33Zab:
Understood - but in that case there seems no reason for them not to say "FYI, we saw AoA #1 misreading - but this issue is already known, see EASA AD ...". If they wrote something like that, it would show that they recognised, evaluated, and dismissed that this needed further investigation. By not mentioning it at all, that leaves open (at least in my mind) the possibility that they didn't recognise it, although as I just mentioned a few mins ago, it might become a footnote in the final report - we'll have to wait until then to see if it is mentioned.

Since the BEA went to the trouble of including that parameter in the (very small) subset of FDR parameters that they included in the interim report, it seems very unlikely that they didn't notice such an obvious apparent discrepancy. Why they didn't mention or explain it, however, I don't know.

AoA et al.
 

@ Diagnostic & Sensor_Validation

Quote : Reading the comments from other contributors here, it seems unlikely that whatever was wrong with AoA sensor #1 had a material impact on the events on this flight, although yet another fault added being into the mix is obviously a worry. Or do you believe the issue with this AoA sensor #1 was significant in the events that occurred?

Very hard to tell, but I would say probably not since we know the STALL warning went OFF as soon as the speed was deemed to be less than the prescribed 60 kts. What we are really seeing when looking at the AoA traces of the data is another story, IMHO. Keep in mind, though, that the "speed" (of the falling aircraft-object?) was certainly well above that : only the derived horizontal vector of it was calculated to be less than the trigger. Calculated from the pitot, at an angle out of the normal range... What I mean to say is the following: the AoA sensor was probably giving meaningful output since the flow of air around its actuator was certainly capable of moving it adequately. So, it remains very strange that the STALL warning would be muted in these circumstances when the "system" knows pretty well: 1. the aircraft's altitude and 2. there is no weight on wheels. I have little doubt that, recommendations from BEA or not, Airbus will implement some changes there in the future.

I wouldn't like to seem cynical, but can you imagine the benefits to be derived from the data retrieved from the bottom of the sea? A fully stalled 200+ tons aircraft data during the whole descent. No wonder Airbus did finance some of the recovery costs. To them, this is a goldmine. And they pretty well know how to interpret the data! Future aircraft generations (and even the current ones) will benefit from this disaster, whatever the BEA conclusions and recommendations will be. I'm confident.

This leaves the industry with the problem so adequately pointed to by the excellent video brought to our attention by CaptainGef (post #1867). Captain Sullivan also tried to wake up an almost empty audience in the Congress about the same problem. Trouble is: nobody seems much interested...

@HeavyMetallist:
Agreed. I know from my writing of RCA reports when things go wrong (but thankfully not accident reports), that it is important to mention what data has been considered & dismissed (and why), exactly in order to avoid people spotting things that I did see in the data but were not causal and hence not addressed by a "fix", but they would otherwise think I didn't see them...

I'm sure the BEA have people with much more skill & practice in this area than me, which is why their omission is odd, and leaves open multiple interpretations - from "there wasn't enough time in this interim report to mention it, but of course we saw it, and it wasn't important here", through to "oops, we didn't notice that", and everything in between.

@vbp.net:

Many thanks for your comments. That helps to crystalise some of my own thoughts about what is important. Although discussions about the stall warning logic were removed from this 3rd interim report, like you said, I'll bet that there will be changes implemented in that area!

FDR data
 

That an AoA replacement program was already in progress is one thing, that AoA 1 on AF447 was stuck at 2.1 deg is another.

It may be your call to state that there was 'no relationship whatsoever', I may think differently, but it is BEA duty to touch the subject in a third Interim Report.


1- HN39 had already pondered one of your previous post :
2- There is no such thing as a "FCPC outvote an AoA"
If one AoA sensor is stuck, there is a possibility that its own ADR anemometric value will be rejected.
Now, remember that in the meantime, was taking place an ADR anemometric values rejection process based on pitot unreliable informations.

So, we end up with a very complex situation, maybe unknown territories ...


I can see too much insistance from BEA, media, people here around to put everything on the pilots back, when in the meantime, FDR data analysis is kept to a strict minimum.

Those FDR data are too serious to be left in the BEA and Airbus hands only.
Victim's families must obtain them too. Alternatives ressources for Analysis are available on this planet Earth.

Hi,

This is a judiciary investigation under progress ..
They will have the FDR data .. so it's not left in BEA and Airbus hands only.

takata, #1826

I don't know where this myth came from, but if you look at the side
stick drawing, you can see that the only feedback is from self centering
springs. There is no force feedback from the control surfaces as there
are no motors etc in the side stick to provide this. Genuine "artificial
feel" provides stick feedback from control surface load, whereas the ab
stick is more akin to a video game controller, though I understand that
even some of these have real force feedback now.

A serous dropoff imho and may be compared to the difference between a
good sports car, where you can feel the road through the steering and
something like the old Jags, where over servoed power steering removed
all sense of tyre and chassis loading.

The sidestick transducers are there to sense position, they are not motors...

AoA and ADR-data
 

CONF iture
The following excerpt from the Australian interrim report has already been posted in this thread. However, I will bring your attention to the statement which I have printed in bold.
"From AO2008070_interim, page 40-41
Angle of attack data processing algorithms
There was a potential for the AOA sensors on the right side of the aircraft (AOA 2 and AOA 3) to provide different values to the AOA sensor on the left side of the aircraft (AOA 1) in some situations due to aircraft sideslip. In order to minimise the potential effect of this difference, the PRIMs used different processes for AOA compared with other parameters when determining the value to use for calculating flight control commands. More specifically, the processing of AOA data involved the following:
• As with the other parameters, the PRIMs would continuously monitor the AOA values from the three ADIRUs. AOA data was sampled about 20 times per second.
• To confirm the validity of the AOA data, the PRIMs would compare the median value from all three ADIRUs with the value from each ADIRU. If the difference was greater than a set value for more than 1 second continuously, then the PRIM would flag the ADR part of the associated ADIRU as faulty and ignore its data for the remainder of the flight.
• To calculate a value of AOA to use for calculating flight control commands, the PRIMs would use the average value of AOA 1 and AOA 2. In other words, (AOA 1 + AOA 2)/2. This value was passed through a rate limiter to prevent rapid changes in the value of the data due to short-duration anomalies (for example, as a result of turbulence).
• If the difference between AOA 1 (or AOA 2) and the median value from all three ADIRUs was higher than a set value, the PRIMs memorised the last valid average value and used that value for a period of 1.2 seconds. After 1.2 seconds, the current average value would be used.
In summary, in contrast to other parameters, only two values of AOA were used by the PRIMs when determining flight control commands. However, several risk controls were in place to minimise the potential for data inaccuracies to affect the flight control system."

I have two points that may need clarification.
1. How big should the difference from the median AoA be in order to reject ADR1?
2. Could this be the cause of a) autopilot disconnect, (b) false interpretation as due to pitot problem if ADR1 was permanently rejected due to AoA error.

regards

AoA sensor stuck?
 

If there was some kind of AoA discrepancy due to one sensor stuck, and calculators "saw" that, didn't have to be some ACARS about that? Otherway, except the study of this flight FDR, nobody would know this problem (if any) happened during this flight?

AoA#1 sensor.
 

Hi CONF iture,

Thx for recalling this post, I did reply on that one but at the same time
the forum was 'under maintenance' and I forgot later on.

Each Aoa vane drives 3 identical resolvers, 1 remain unused.
(may drive AoA indicator in future?)
Due to pin programming the other 2 can be used as averaging value or
- as pin programmed in the A330 - 1 is active and the other used as
backup in case of failure of the active resolver.
Resolvers sin and cos are AoAi input for the ADIRU.

ADIRU calculates the AoAc from the AoAi to compensate for position
errors (identical AoA sensors used for all 3 positions) and S/F config.

(BTW: the vanes are dampened by eddy current, no oil based damper is used)

Each ADIRU sends his AoAi (LBL 221) and AoAc (LBL 241) values in ARINC 429 format to all FCPCs.

In normal operation the FCPC uses the median value of the 3 AoA values
BUT if an AoA signal deviates a predetermined value(?) from the median
the FCPC will reject this AoA signal (for remainder of the flight) and will
use the average value of the #1 & #2 sensor.

If the difference between AoA#1 or AoA#2 and the median value from all
three ADIRUs is higher than a set value(?), the FCPCs use a memorized
last valid average value for a period of 1.2s.
After 1.2s the current value is then used.

http://i474.photobucket.com/albums/r.../MedianAoA.jpg



The FCPC uses the AoA value for the protections(limits) in NORMAL LAW.
In ALTERNATE LAW those AoA protections are not available anymore and
FCPC can do without any AoA signal.

They salvaged 800VU rack(FCPC2/3), separate mounted FCPC#1 and AoA sensors.
After investgation of those components they will surely respond to that,
but you are right! they could have made a comment already in the
footnote about this AoA#1 sensor.

I haven't really had much chance to post my thoughts on this accident which is why I may have seemed short - apologies to all. This accident is not a machine driven thing but a human issue. The S and L of SHEL apply. But first some history - I have referred to Clipper skippers and this has a bearing on the accident under discussion. Pan Am during the sixties were one of the dominant airlines and their captains and co-pilots very highly regarded. However, this induced a culture of arrogance and complacency - pilots who were not suited to command were passed and protected by their friends. Checking methods were ignored and training especially with obscure and difficult airports was poor and perfunctory. This led to a series of accidents in the late 60s and early 70s with many fatalities. It also led to a culture change but Pan Am never really recovered from the problems caused. The parallels which struck me were a casual culture and a failure to train properly and address training issues. Air France seem to have developed a similar culture. I am sure that there are many responsible and professional pilots in that airline but reading their safety audit one could see issues that needed to be urgently addressed. Training has been neglected and too much faith placed in automation. To be honest I have no problem with automation - I have never flown an automated plane but would prefer to travel on one. Some of the stuff I have flown has very strange quirks and I am glad when I don't have to deal with it. Learmount totally misses the point when he blames automation - in itself it is not an issue with proper training. If the proper training is lacking then problems arise but as in the Pan Am illustration they are not restricted to automated airliners. Thus we can safely disregard automation or the machine as having any bearing on the accident apart from an initial causal incident.

What impressed me about the CVR transcript (and I do read and understand French well) was the failure to follow procedures and the total lack of CRM. Learmount characterises it as bewliderment but to my mind this is going too far. We have no evidence that the pilots were bewildered - rather that they were inadequately trained and had developed a culture which neglected SOPs. PJ2 in a reply to another correspondent mentioned that SOPs were vital. I fully concur - in the stuff I fly if you miss something you are very soon in trouble. You as a pilot are responsible for your aircraft and for being aware of your aircraft and its features. If you are an airline pilot you have an extra responsibility for your passengers but any pilot carrying extra people has an extra responsibility. This to my mind means you have to be extra careful and be aware that your actions will affect others lives. This means knowing your aircraft and knowing what to do if the aircraft gets into unusual situations. It means training and anticipation - avoidance is better than reaction. None of this happened in the case of AF447. We unfortunately must assign responsibility for this accident to the aircrew and the airline not the aircraft or its automation or its manufacturer. No other conclusion is valid and despite the agendas of some of the other posters this is the reality.

Old Carthusian, thank you for your post, which eloquently confirms from a pilot's point of view what I, as humble SLF, tried to express in an earlier post.

This bit especially jumps out:

Surely pilots must think beyond the parameters of training courses? Especially in a working environment where unexpected problems can kill you, don't pilots ask themselves a ton of 'what if' questions? 'What if the autopilot drops out at night, in cruise, and we happen to be in bad turbulence?' would seem the kind of question I would hope the chaps up front had asked themselves as I strap myself into 12F.

Or are pilots today encouraged NOT to think that kind of thought?

I also thank you, Old Carthusian, for an insightful post.

For other SLFs like myself, the SHEL acronym refers to Software, Hardware, Environment, Liveware, as explained at the following link:

http://www.skybrary.aero/index.php/ICAO_SHELL_Model

Two new articles in Flight today:

AF447's initial altitude drift went virtually unchallenged

and

Airbus clashes with pilots over AF447 alarm

Overthewing, any pilot that doesn't consider every possible failure and how to handle it shouldn't be flying. There is not enough time to train him for every possibility. He needs to think about it himself while he is droning along or driving to work. One of the best ways is to look at accident reports and put yourself in their shoes and decide what you will do if it happens to you. It has saved me numerous times. 23,000 hrs and never making the papers or an accident report was because of that.....and a bit of luck.

SS Feedback.
 

For the guys wondering about the absence of (force) feedback to the stick.

Which F/B signal should be applied, A/C RESPONSE or surface deflection signal. (FEEDBACK SIGNALS)?

http://i474.photobucket.com/albums/r.../FeedBacks.jpg

@Diversification:
 

1/ Don't know, actual values are not given in the documentation.

2/ a) No, all AoAs are within 1 degree of one other @02:10:05
2/ b) No, an AoA error wouldn't reject all ADR signals, its the CAS <60Kts which will invalidate the AoA signal (0 degree and SSM to NCD).

Regards.

Airbus clashes with pilots over AF447 alarm

Sidestick fwd - stall warning
Sidestick aft - no stall warning........


Great design:ugh:

Nicely 'loaded' question , A33Zab....

Don't ask me, I'm an ancient "AFCS", not "AFS" (artificial feel) engineer.....
You have me wondering......but then I've never flown anything 'big' or 'fast' so I doubt I can contribute anything.

In something totally basic as a Piper Cub, your 'stick' cues are stick deflection = surface deflection (minus trim), and stick force = surface hinge moment. I very much doubt that would be what you want for an A330 sidestick?

Whoever did the artificial feel on Concorde obviously got it right.... there are enough comments from pilots on how well she handled. And that was a supersonic airliner, not a subsonic Coke can.

Maybe... not enough was 'fed back' from the early sidestick trials on 'SB, or maybe the issue of 'force feedback' was not yet addressed during those trials. I suppose I'll have to find again the few items of doc on the subject.

Lots of info on AoA sensors and processing for the Perpignan A320 in the BEA report, assume similar for the A330

for example

A33Zab, #1939

Ok, i'll bite: Let's analyse what you have drawn:

Is it a loaded question ?. We have two functional units: The execution
end looks like a standalone feedback servo. Linear demand input
translates to linear control surface deflection, though there are other
considerations, such as rate and travel limits and there may be
non-linear laws involved in the translation. From the way that the loops
are drawn, the execution end just follows demand from the compute end..

The compute end is the clever bit. This translates stick input to an
output, but has the current 3d state of the a/c, other inputs such as ir, baro
and control laws taken into consideration to decide just how much ss
is appropriate. The compute end is only a little box, but it's where
all the complexity lies

Perhaps revise the question to: a/c response, or control surface loading ?..

Hack the above to bits if you like.

Have noticed from your posts that you do seem to have rather eclectic
information sources. For example, the logic diagram in thread #5, Post
#620, with "mod 1139 11/08/06" in the top right corner. Nuff said I guess :-)...

Old Carthusian
 

Helpful and thought provoking post.

The only word of caution that I would add is that we must be very careful before separating "automation" and "training" - the former implies new skills in addition to existing airmanship skills (for when the computer trips out, David's GIGO), not just new skills, and somebody has previously commented that it was a battle for AB's training personnel to maintain even the same level of training in the face of their salesmen arguing cost savings through buying AB and automation costs savings. I fear that the two issues are, or have become, inextricably linked as automation automatically feeds through to training issues.

The CVR so far disclosed is not pleasant reading, from a CRM perspective, and cockpit discipline left something to be desired. I am shocked at how PF got to a stall at FLT380, due to a temporary UAS. The flight should have been immediately stabilised at FLT350, and SOPs should have taken care of the rest, if the pilots had been properly trained. I have previously drawn attention to AF's 3 hull losses (the first for each aircraft type - Concorde/A330/A340), and I see where you are coming from re: an airline culture (your Pan Am example). But I don't think this is a particularly AF issue, and is a much wider problem. AF have many excellent "flyers", particularly those with an ex-military or private aircraft "hobby" background (alas none aboard AF447, to recognise and fly out of the stall once created). So I am broadly, save for this linkage, of the same view as you. Maybe trying to bridge the gap between you and David?

I am always wary of becoming dragged into the Boeing v Airbus debate, not least because I have never flown the latter, but I do believe that AB should never have been marketed as more automation implicitly equals less crew training costs (which their salesmen, at least, did). It should have been that the training costs would go up, as the systems operator skills were added to underlying basic airmanship skills (which would need more simulator honing, as flight crews became increasingly reluctant to - or have been banned from - "hand fly"), and the "saving" should have been marketed as the additional flight envelope protection and reduced risk of a "pilot error" in itself triggering a crash and all the reputational damage caused by an aircrash. Plus the weight/fuel efficiency savings from FBW operation.

It contributed to an "aircraft fly themselves" perception in some quarters (particularly amongst "line" finance directors) , and the number of LOC incidents in recent years is far higher than automation should have permitted if there was not an underlying mischief still to be remedied. So it takes us back to the man/machine interface, and that is heavily training......

Perhaps you, David and I are not so far apart after all (even if we all have a slightly different slant, mine being that training is a sub-branch of automation rather than a separate but linked issue)...?

"STALL!" Qu'est ce que c'est?
 

Pardon my ignorant red neck question :}, I am not a native french speaker.
Obviously I understand the international aviation convention is english.
However is the A330 stall warning obvious to a native french pilot?
Isn't the word "Stall!" in french meaningless?
Is "Caler!" the translation? Would "Stall" always be used in french aviation training or the french word.

After reading the transcript again and again I realize that my assumption the pilots (under duress) knew the english word "Stall" could be wrong !!!

It is not clear if the PNF cannot translate it (what is that), or cannot make sense (why is that). I suppose he could be ignoring it completely and looking/pointing at an ECAM and exclaiming "Qu’est ce que c’est que ça?". No native english speaking pilot would hear the word stall and say "What is that?". However if I heard the french word "Caler!" I would say "What is that?".

French word for "Stall" is "Décrochage".
And no, there is absolutely no need to translate Alarms/Ecam/Interface in French for the pilots to understand what it means.
Hence, this is due to the French exclamative expression "Qu'est-ce que c'est [que ce bordel]!"which cover a larger range of signification than its litteral translation of its words in English.
That's only an expression of surprise that the stall/décrochage alarm was sounding at this point. Nothing more.

@Takata

Thanks for debunking that.
Isn't that phrase a little nonchalent for the warning of death?
More appropriate for a knock on their door or an accidental release of digestive gas.
I suppose we would need to hear the emphasis of the actual CVR audio.

Actually I'm pretty sure that's an oversimplification. In the early days, Airbus's sales crew did emphasise how simple the automation made flying the aircraft. But I don't think that "lower training costs" sales angle referred to the automation. As I said before, Airbus's ace-up-the-sleeve with training costs is and has always been that the similarity of the flight-deck layout on the A320 up to the A340 (and the A380, despite having more advanced systems in some respects, the general layout is still nigh-on identical) means that conversion training between types is considerably easier and more straightforward than most of their competitors.

I'm not saying they weren't overconfident in the ability of the automatics to handle everything, as well as the ease with which pilots would take to the new systems in the very early days (1988-1994 in particular) - but I've long suspected that reports of "more automation = less training" was two distinct aspects of the new design lost in translation via the press.

Seven seconds after the First STALL WARNING. "What was that?"

Not sufficient exposure of the sensor to the signal, the CRICKET was not triggered.

So, a 'transient' event.

"What was that?"

1. "Was that STALL?"

2. "Was that a Stall Warning?"

3. "IF STALL warning, WHY?"

OTHER:

"What was That?" "WAS IT.........?"

What it was, almost certainly, was a rhetorical interrogatory.

What it likely meant,

"Did you hear, see, feel, sense, understand, smell, or otherwise become aware, of anything you might be able to help me with?"

A guess could be, Buffet, Vibration, or an otherwise unexpected event, of some importance, that could or should be addressed "by the both of us?"

It is likely on the CVR, this...... ".......that" imo.

Since this comment may annoy or upset some, I will acknowledge that a possibilty may be that something broke, snapped, twisted, banged, fractured, cracked, or become unserviceable and created a noticeable sound, or unusual event that had naught to do with Pilot Error.

Otherwise known as something that had to do with the a/c that is impossible, either in fact, or in professional intuition.



add. IMO I don't think it had to do with the WARNING. They both knew what that meant. Because of the timing, I think it may point to a noise, or event, that may be associated with rapid change in aspect of the a/c. A chair rail creaking? A food trolley falling over behind the CD? Perhaps a FA falling? Maybe to do with Turbulence.

xcitation. This STALLSTA... happened at 2:10:04? How can Autopilot produce a STALLWARNING?

0210:11: PNF: - Qu'est-ce que c'est que ça?
Look, it is 6 seconds after A/P disconnected... It is a very common reaction in French in such case. Don't you really think that they could not be quite surprised to hear this alarm sounding, considering that, before this point, they might never have heard a single stall warning during a real flight?

Your "warning of death" will certainly add a lot of drama into it... with 100% hindsight. What most other crew did, in the very same circumstances, was to disregard the alarm as spurious. It did not last long enough, only few 10th of second, as it was due to very short flight spikes exceeding alpha treshold.

Additional note for any conspiracy theorist still unable to read what is reported:
- AP disconnected at 2:10:05
- 1st Stall Warning is recorded exactly (CVR) at : 2:10:10.4
- PNF comment is recorded at : 2:10:11
Comment was made with a 0.6 second interval (not 3 hours later) and was obviously due to this alarm, not because he heard aircraft structures falling appart.
And, of course,... everything (SW+comment) happened 5-6 seconds AFTER autopilot disconnected. It's perfectly clear from the report for anyone sober enough, or one not reading it up side down on purpose.

DozyWannabe
 

I have come late to this crash thread, and apologies if I repeat what has been said before, but when Airbus were trying to induce my airline away from Boeing and McDonnell Douglas use in the late-1980s, their sales pitch was very much that automation would also save flight crew training costs (this was long before the entire AB family became a reality, and easy conversion training thereafter became important). Whether this was intended at the corporate boardroom level is another matter altogether but, to be fair, the previous post did say "implicit". It wasn't the main thrust of their sales pitch, but it definitely was in the mix. Overconfidence in automation (can easily) = underconfidence in crew training needs. Two sides of the same coin, which is how I interpreted the previous post........