Here's a video from a few years ago of two student pilots handling a trim runaway in a 737 simulator. https://www.youtube.com/watch?v=3pPRuFHR1co&t=154 You'll notice that it's a loud, physical event, with a very simple solution. This happened over twenty times in the accident flight, and the pilots never disabled the problematic automatic stabilizer system.
Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
81–83 of 83 posts
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#82What happened? The pitot tube and drain were clogged. Static port was clear. This turned the airspeed indicator into an altimeter - it was incapable of showing correct airspeed from the moment of blockage.
The cause of the crash is pilot error. The pilot is expected to recognize from other instruments that the airspeed indicator is unreliable, and this is part of training for instrument rating.
If the MCAS in the Lion Air crash made a similar mistake - using a single data point to determine a stall condition. That is an error. It's functionally "pilot error" to have no means of determining if the angle of attack sensor is wrong, and no mechanism for disregarding its data. Further, the corrective action it took, had the flight condition actually been true, sounds excessive. If a human pilot did the exact same thing MCAS did, I expect the human would be blamed - it would be pilot error to so aggressively nose down that you've exchanged a level flight high speed stall (a rare event indeed) for a high speed dive. That is not a competent recovery, in particular that there's apparently no recognition of the danger of high speed dives let alone recovery from them it's probably a really good idea if your stall recovery does not ensue in a dive!
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#83Earlier quoted context omitted.
> That's how it's always worked and you've gotten used to this but still, instead of going trough the full checklist they stopped and tried repeatedly whatever fixed the issue in the past/on the simulator. a more complete analogy: "follow these ten step do diagnose a bug on the software" "but last time it was just a compilation flag, I'll check the compilation flags" "bug persists" "last time it was just a compilatio…
From what I understand, part of the problem was that it helped temporarily... and then the system pointed the nose down again.