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.
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.
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.
https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
This is the future I look forward to. AI/ML/Autopilot/Companies moving fast and breaking things.... Boeing took that one literally.
[0] https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
The trim wheels moving also makes a sound?
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)
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?
I wear earplugs all day in a metal fabrication workshop.
The earplugs certainly don’t prevent you from hearing anything.
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.
It not possible to disable wheel movement. It's mechanically linked to the jackscrew.