Live data from Hacker News

Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

nytimes.com

81–83 of 83 posts

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#81

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.

This is a great video showing the UI - it makes what is going on much clearer!

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#82
Actual example: Normal takeoff in instrument meteorological conditions (no external visual references, flight by reference exclusive to instruments). The attitude indicator shows proper climb attitude, vertical speed and altimeter show positive rate of climb, airspeed indicator shows speed increasing above target speed. Pilot response? Probably nose up and/or power reduction; OK they do both. Airspeed indication continues to increase. Pilot noses up and powers down. Airspeed increases. Pilot noses up aggressively. Stall. Crash.

What 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

#83

Earlier 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.

While the trim is not too far down, you can still counteract it with elevator (pulling the yoke). But then, MACS kicks in again and pushes the trim further and further down, and if you don't trim up and/or switch the trim cut-out, then you get into the situation where you can't recover anymore using the yoke.
Post reply on HN