Was the trim wheel not visibly spinning out of their control? Simply because the symptoms are different should mean that stopping it via taking manual control is a recurring option.
Part of the problem is that the MCAS system has a 20-second delay after the last time the pilot touched controls for the flaps, and it adjusts itself to a new position and then stops. There are no other indicators that it's happening, and since it's noncontinuous and has a delay, it would be easy to miss the only visual sign of the trim wheel readjusting itself once, especially since the wheel itself is by the pilot's thigh outside of forward line of sight.
In a normal runaway trim situation, by comparison, the trim wheel continues obviously spinning as long as the problem is going on, so it only takes a single glance at any time to notice it.
I'm not sure that's accurate. Other descriptions of the MCAS system state that it will continually modify the trim on the horizontal stabilizer for up to 10 seconds at a time.
Well, the point is that the experience from MCAS trying to be clever and subtle is very different from what one would expect in an old-school runaway trim situation caused by, say, a stuck relay.
Easy to chase down a wrong line of inquiry when the symptoms only appear sporadically and can be temporarily stopped by a whole range of actions that won't permanently fix it.
To summarise; MCAS will trim the Stabilizer down for 10 seconds (2.5 deg nose down) and pause for 5 seconds and repeat if the conditions (high angle of attack, flaps up and autopilot disengaged) continue to be met. Using electric pitch trim will only pause MCAS, to deactivate it you need to switch off the STAB TRIM SUTOUT switches.
The Lion Air directive has instructions on page 41 of their preliminary report that include:
5. If the runaway continues after the autopilot is disengaged:
STAB TRIM CUTOUT switches (both) ... CUTOUT
If the runaway continues:
Stabilizer trim wheel .... *Grasp and hold*
This may be an overabundance of caution, or to cover other runaway events, but it reads like "you may need to physically fight the computer even when it has been disabled". Not exactly heartening.
EDIT: A comment below points out haptic feedback to disengage as a reason to grab-and-hold.
That's incorrect, these have haptic feedback, once you grasp it, it's not going to fight you. It looks for resistance and if it sees the resistance it doesn't continue.
Really? Here's a video of someone doing it, and it certainly looks like it tries to fight you (and the trim motor continues running) but there's a clutch that starts slipping:
I doubt it would have been "out of control", it would have just been slow changes over time as trim increased. The pilots might not have been fighting it much either, if they thought that airspeed was the problem, and not pitch.
Thanks! Page 23 of the PDF or 14 as printed at the bottom. Sadly it's hard to compare with the previous flight (pg. 25 or 16) as for it they published the graph of the whole flight instead of only the part until the (at the time still secret) MCAS was turned off (or probably more correctly, the motor controlled by the MCAS, which actually steered the "trim").
Yes. The ratcheting sound is deliberate, so the pilots don't need to see the wheels spin to know the trim is running. Also note that there's a white stripe on the wheel so it's easy to see it is running.
You'll note in that video, the left-hand pilot has a headset on, presumably the right-hand pilot does too. Headsets are seen in other videos [1] of the cockpit.
So even if the spinning trim wheels make noise, they may not have heard it.
(My google image search shows some pilots wearing two-ear headsets, some wearing one-ear headsets, some wearing two-ear headsets with side not on their ear, and some not wearing headsets. But some of those are pilots posing for photos, and presumably pilots don't let people visit the cockpit during critical stages of the flight)
I don't understand do you think they're listening to music or something?
Having a headset on doesn't stop you hearing noises in a cockpit. How did you think all the other verbal alarms and callouts worked if they can't hear anything?
Exactly. It was not "runaway" in the sense of "continuously doing the same." Something was happening, from the point of view of the pilot and co-pilot "at random." (Not to mention that on the previous models exactly such pattern was effectively impossible to happen). The faulty non-redundant sensor was producing false reading and that was the input to the to the pilots completely unknown MCAS which then moved the nose down based on the difference between the input and MCAS' expected target, turning "the correction" on only from time to time.
The presence of the third, off-duty pilot on the flight before additionally explains even better how in that case the crash was avoided. While the pilot and co-pilot were at the controls, the third one, looking from behind, didn't have the direct duties to do, so he had enough time to both just observe everything that was going on and the less immediate stress to allow him to come to the solution that worked.
Like when one programmer spends half an hour on something "not working" and complains to the colleague who just takes a look and immediately sees what the first one hasn't for half an hour. Additionally the movement of the trim wheel is actually easier to follow from the place in the back (see https://news.ycombinator.com/item?id=19440045 ).
And there's also a possibility that the false sensor reading and MCAS together produced a slightly different differential signal which resulted in more obvious manifestation of the problem. Possibly both elements contributed to the lucky outcome in that previous flight.
In the old times of civil aviation there was the third person on duty in the cockpit, the "flight-engineer." As the planes got more computerized controls, they started to be certified to fly with two-pilot crews. The computerized systems, when working, do reduce the chance of the crash and overall number of accidents did decrease simply because the humans were on the average less often in control, and therefore there was less chance to do anything wrong.
The problem is when the unreported computerized controls secretly depend on the single sensor that can be faulty. And when they actively confuse the pilot and ruin the flight instead of helping him.
To my understanding, the trim wheels are moving frequently for small adjustments -- and it's possible to switch the wheel movement off if this becomes too annoying.
It's running for 10 seconds at a time for 2.5 units of trim out of a possible ~15. That's quite a big trim change. I find it hard to believe that it's not noticed because of the 'boiling a frog' situation.
It not possible to disable wheel movement. It's mechanically linked to the jackscrew.
Also not a pilot but I don't think you can switch the wheel off. You can, however, disable the electric motors that spin the wheel, which is what the checklist for runaway trim tells you to do, and what was supposed to have been done here.
The spinning wheels are directly connected to the stab trim via cables. If the trim motors fail, the pilots can turn those wheels by hand (there's a folding crank on them) to manually adjust the trim.
In a normal runaway trim situation, by comparison, the trim wheel continues obviously spinning as long as the problem is going on, so it only takes a single glance at any time to notice it.