PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 26th Apr 2019, 13:52
  #789 (permalink)  
meleagertoo
 
Join Date: Mar 2018
Location: Central UK
Posts: 1,641
Received 139 Likes on 67 Posts
Originally Posted by gums
Salute!

Well, PEI, I am surprised that Boeing does not have to do some aero model work and not use a kludge doofer to meet the cert requirements for back stick force and aircraft pitch moment versus AoA near the stall portion of the envelope.
Worse, one reference we have seen here states that MCAS was directed toward the other end of the envelope than right after takeoff. So any inquisitive pilot might have seen an MCAS reference and didn't relate a problem if the thing went ape**** right after takeoff.
And then not realizing that a bad AoA vane would trigger both the stall shaker and the unreliable speed warning and then the ........ GASP!!
I flew three really neat new planes in their first year of operational use, and we were "test pilots" as a matter of course. Realize that some dweebs have to be the first folks who are not "golden arms" from Edwards are gonna fly the things. . Regardless of all the great engineer work, the planes and the pilots found new things that needed work. But this Boeing implementation takes the cake, and I am still not sure what I would have done other than the flight preceding the fatal Lion one. i.e. if my stick trim worked, I prolly would have eventually turned off the electric trim. But would I have known that the "runaway" trim was due to MCAS plus a bad vane? I don't think so. But in my old, shriveled brain I feel I would have eventually turned off stuff. Then again..... Whole thing sucks, and that's my story and I am sticking to it.

Gums sends...
Do you consider the Speed Trim system to be a "kludge doofer"? If not why not - it has considerably greater authority than MCAS and in the same part of the flight envelope. Why aren't you deriding this too, especially as it seems Boeing regarded MCAS as a fairly minor componnet within the speed trim system?

The MCAS didn't go apesh!t "right after take off". It ran away after flap retraction. That's quite an important distinction, don't you think?

What possible use - let alone imperative as you seem to imply - is it to know what caused the runaway, be it MCAS or Uncle Tom Cobbley's sandwich wrapper in the works? Runaway trim is runaway trim, so just carry out the memory items. Let the engineers worry about the whys and wherefores.
meleagertoo is offline