Earlier in the thread it was mentioned that with an a very nose trim as speed increased it may become impossible to overcome the (large) trim with (small) elevator, even with both pilots using full force (h/tCentaurus, post #826, FCTM air load warning with nose down trim)

*** PURE SPECULATION No data to support ***: The contention would be that at some point the crew actually did use the stab trim cutout switches, leaving them with only manual wound (literally by hand, extremely slow), trim and elevator for pitch control, there was an IAS increase which reached an uncontrollable speed.

As I said, this possible chain of events is purely speculative based upon the previous sector having an AoA anomaly, the Boeing Bulletin, APA MCAS revelation and a little bit of supposition. Thus far the data does not contradict this speculation, but I reserve the right to be wrong as new facts emerge.

Perhaps what is most apparent is that the imbecile Byron Bailey ought be facing a conga line of litigation. This like most accidents are a sequence of events. That idiot is no professional pilot. Just another MSM windbag.

Given Boeing's post factum missives, this accident sequence may well have been far more complicated than the pilots had anticipated given the previous flight history.

The current Lion crash is the only accident I can think of where inaccurate AoA data was (may have been) a triggering event. What are some others?

Can somebody familiar with the engineering of the 737 comment on whether this is representative of the maximum speed that the stab trim moves?



I know from experience that jackscrews, by their nature, don't operate particularly rapidly, but 90 seconds (approximately) from full nose up to full nose down (and presumably vice versa) seems pretty slow.

If that's the case, the crew would have had little or no chance to reverse a THS runway in the height available.

AOA sensors 1&2 were affected.

I think all this is missing the point. The problems mostly occur when AoA data is faulty. So what is displaying the faulty data going to achieve?

As I see it there are two possibilities:

• AoA data is reliable and accurate: are there any accidents that would have been prevented by the provision of raw AoA data to the pilots? How would you know?
• AoA data is unreliable and/or erroneous: In this case displaying the wrong value(s) is going to add to any confusion.

For the first point: if you say "AF447", I find that highly doubtful. They already had (in their mind) the conflicting information of slightly high or neutral (only briefly slightly negative) pitch angle and very high rate of descent, and an intermittent, mostly counter-productive, stall warning. It is a hard argument to make that an AoA gauge would have reduced confusion and lead to the correct decision early enough. A displayed AoA of around 40 degrees would likely have been off the scale and/or be dismissed as "absurd", having never before been experienced by any A330 crew, either in the aircraft or the simulator.

The second point possibly applies here.

Bernd

Thanks. Perhaps it's splitting hairs, but I'm not sure that bad AoA data was a "triggering event" in that accident. In the Lion Air Accident, the current working theory is that bad AoA data caused the loss of control. In the Perpignan crash, If I understand it correctly, the crew caused the crash by commanding excessively slow flight at low altitude, and the bad AoA data caused the expected stall protections to fail to save the airplane from the crews control inputs. My understanding is that they were flying slow for the purpose testing the stall systems at an altitude much lower than the required 10,000 ft altitude required for that test.

If each pilot could see his own AoA they could decide which was faulty whether it read FSD, zero or was erratic. Or the computer could flag one as 'out of range'

Qantas Flight 72, as mentioned before.

Although the aircraft did not crash, it was nevertheless an accident, because there were several serious injuries. The pilots temporarily lost control.

Bernd

If the computer could decide that one was "out of range", it should also decide not to use it as an input to any kind of stall-prevention or stability assistance function, or whatever it is called.

Bernd

The stall warning on AF447 disappeared, because it was "out of range", 60 kts. The stall continued however......

According to the AD bulletin, one of the effects of an AoA sensor failure is 'stick shaker on the affected side only'. So the computers can use 'logic' to determine this.

The stick shaker is simply caused by a high AoA reading, regardless of its validity, which, in this particular case can be a symptom of a faulty sensor, when otherwise there are no indications of a stall. The stick shaker is not used as a fault-condition indicator by design.

So rather than deciding that it is faulty, the stick shaker activating on an erroneously high-reading AoA input means that the stick shaker logic does not decide that it is erroneous, but takes it at face value and activates the shaker. It's probably deliberately a very simple system: fewer things to go wrong.

Bernd

Bsieker, thanks for the correction. Does stick shaker on one side only help the pilots to understand what's gone wrong? And is stick shaker only triggered by AoA?

For clarity, there is no "AD Bulletin" There is an AD (Airworthiness Directive, AD #: 2018-23-51) and a "Flight Crew Operations Manual Bulletin" (TBC-19) The same-side stick shaker is mentioned in the manual bulletin, but not in the Emergency AD. Edit: Actually, it *is* mentioned in the AD, I apparently hadn't read the AD completely. Apologies for that.

That aside, I'm not convinced that this is the computer using logic to determine whcih data is bad. This seems more of a case of of how the problem is manifesting itself with an unintended symptom in a complex system, rather than a case of the Computer, in effect, saying : "Hmmmm, we've determined that the left AoA sensor is giving us bad data, so because we know this isn't really a stall AoA situation, we're only going to activate the stick shaker on the left side instead of both sides"

I don't know if it has been changed for the MAX (probably not), so the following is for the NG:

The stick shaker has multiple inputs. Primarily AoA, but also other ADIRU inputs, thrust, flap/slat configuration, etc.

Although there are two shaker systems, either will shake both control columns because they are mechanically linked by a rather rigid (though frangible) connection.

Stick shaker activation will be recorded on the FDR and can probably be heard on the CVR as well.


Bernd

I doubt it Sax R54
I will believe this statement and several similar ones posted by others that Crew are not briefed about this system, only if one B737 MAX certified pilot tells this forum that he was not aware of it. This mod in MAX is a significant change from previous -800 etc, to protect the aircraft exceeding AOA approaching a stall. I am sure there will also be an EICAS alert when the system is active.
So is there any one with B737 MAX training / Certified in this forum to clarify this matter?