If the stick shaker was going off and airspeed was unreliable, retarding the throttles would be the last thing a half-decent pilot would do.

Lion Air retarded the throttles, they still didn't make it.

You can brag about training in the U.S. as much as you want, when sh*t hits the fan and the stick shaker goes off on take off while you lose multiple instruments and have to ask ATC for their readings, while the aircraft is going on a rodeo, anybody is going to cr*p their pants, whether they logged 200 hours or 20.000 hours, it doesn't matter.

Also, about flight training in the U.S., I've flown a couple of hundred hours GA in the U.S. and I've sseen great pilots and I've seen very bad ones. It's no different than anywhere else so save the patriotism.

If proven that these multiple failures occurred, the pilots should be honored for their sacrifice, as heroes who tried everything in their power to save the aircraft and its occupants.

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

mandala499 wrote:

What I fear is that there is unreliable airspeed from the take off roll, and they were shocked to see stick shaker on from the take off roll, and decided to shallow out the climb to "get out of it"... only to not see it not disappear.... with the increasing speed and confusion with the stick shaker and the unreliable airspeed then comes the next question... did they pull up the flaps at 800' AGL?

As this theory is reasonable for what happend in the air, it does not explain the cause for the stick shaker. Stick shaker is triggered by excessive AOA, as far as I am aware. AOA vanes normaly don‘t break that often. Lionair had some tech history with AOA. That makes an easy explanation. However with ET, no such thing is known so far.

I wonder if someone is looking at the AOA sensor and the electronics behind for hidden features, aka faults. If there is a not known design error built in... that would change the whole picture of both crashes and the grounding.

Does anybody now if there has been a change in AOA design incoorporated with the MAX? I do not mean MCAS, but before the signal is getting to MCAS.

mandala499 wrote:

What I fear is that there is unreliable airspeed from the take off roll, and they were shocked to see stick shaker on from the take off roll, and decided to shallow out the climb to "get out of it"... only to not see it not disappear.... with the increasing speed and confusion with the stick shaker and the unreliable airspeed then comes the next question... did they pull up the flaps at 800' AGL?

Could the flaps have been retracted automatically after reaching certain speeds?

Can anyone calculate how much time they would have during a nose dive from say 2000ft AGL?

michi wrote:

mandala499 wrote:

What I fear is that there is unreliable airspeed from the take off roll, and they were shocked to see stick shaker on from the take off roll, and decided to shallow out the climb to "get out of it"... only to not see it not disappear.... with the increasing speed and confusion with the stick shaker and the unreliable airspeed then comes the next question... did they pull up the flaps at 800' AGL?

As this theory is reasonable for what happend in the air, it does not explain the cause for the stick shaker. Stick shaker is triggered by excessive AOA, as far as I am aware. AOA vanes normaly don‘t break that often. Lionair had some tech history with AOA. That makes an easy explanation. However with ET, no such thing is known so far.

I wonder if someone is looking at the AOA sensor and the electronics behind for hidden features, aka faults. If there is a not known design error built in... that would change the whole picture of both crashes and the grounding.

Does anybody now if there has been a change in AOA design incoorporated with the MAX? I do not mean MCAS, but before the signal is getting to MCAS.

Lionair had issues with AOA, and airspeed.
In this case there was at least an airspeed issue.
Perhaps an issue with the ADIRU or a major configuration deviation outside of the ADIRU's parameters causing it to produce false data.

Is it time to revisit a possible ADIRU failure here, since it would explain why Lion Air couldn't fix their issue after replacing their AOA sensor (AOA, air speed sensors feed into the ADIRU before getting to the SMYD and FCC)? ADIRU would explain erroneous air speed too. More specifically, could a power bus issue to the ADIRUs be the root cause (in addition to a non-redundant MCAS design)?

Edit: I swear I didn't read the above post before posting! Looks like we may be onto something!!

osiris30 wrote:

WIederling wrote:

drajoshi wrote:

Ironic that humans start blaming humans, when their own complex engineering is the culprit.

Going by what is visible Boeing engineers did not write complex software they wrote simplistic software.
Cargo Cult.
Copy the superficially visible of another complex product and expect the copy to perform to the full specs of the complex product.
We saw the same when Boeing tried to copy the manufacturing model from Airbus.

Have you seen the code and do you have any basis on that apart from a Boeing bash? Just curious? Any facts to go with that load of drivel you just wrote?

I am good enough with analysis of software and hardware "blackboxes".
You exercise the item and evaluate the reaction. Think Deep.
I've usually been able to pinpoint the cause of some unexpected behaviour.
( Lots of commercial stuff : you get no traction and have to work around such software bugs.
With OSS software you fix it yourself or lean on the programmer if available. )

sgrow787 wrote:

Is it time to revisit a possible ADIRU failure here, since it would explain why Lion Air couldn't fix their issue after replacing their AOA sensor (AOA, air speed sensors feed into the ADIRU before getting to the SMYD and FCC)? ADIRU would explain erroneous air speed too. More specifically, could a power bus issue to the ADIRUs be the root cause (in addition to a non-redundant MCAS design)?

Talk about synthetic values being handed down stream to the sinks got my attention.

ADIRU not handling brown outs properly?

My current guess is some variables not initialized properly. ( mismatch appears to be variable per power up
but constant through an active cycle.)

ikramerica wrote:

So other than public hysteria and non-scientist government officials claiming a clear connection (or not), its no more logical to assume these crashes had the same cause than it is to blame all 737NG and ground them all, or all aircraft that use that brand if AoA sensor or pitot tubes or what have you.

No more logical? You ignore the most important argument: the evidence of statistics. Two potentially similar cases in the first two years is by several magnitudes of order worse than the NG did. It seems, that the public&social network histeria is able to make that distinction (because the call to ban NG or e.g. 777 after the two MH cases does/did not exist), while you continue to ignore it.
If safety first rules, this distinction cant be ignored...

WIederling wrote:

sgrow787 wrote:

Is it time to revisit a possible ADIRU failure here, since it would explain why Lion Air couldn't fix their issue after replacing their AOA sensor (AOA, air speed sensors feed into the ADIRU before getting to the SMYD and FCC)? ADIRU would explain erroneous air speed too. More specifically, could a power bus issue to the ADIRUs be the root cause (in addition to a non-redundant MCAS design)?

Talk about synthetic values being handed down stream to the sinks got my attention.

ADIRU not handling brown outs properly?

My current guess is some variables not initialized properly. ( mismatch appears to be variable per power up
but constant through an active cycle.)

Yep, and there's a Wikipedia entry for ADIRU that lists about a dozen historical events related to ADIRU issues. A couple of those are ADs (as well as infamous QF72 and AF447 among others):

"FAA Airworthiness directive 2000-07-27
On May 3, 2000, the FAA issued airworthiness directive 2000-07-27, addressing dual critical failures during flight, attributed to power supply issues affecting early Honeywell HG2030 and HG2050 ADIRU ring laser gyros used on several Boeing 737, 757, Airbus A319, A320, A321, A330, and A340 models.[2][12][13]"

"Airworthiness directive 2003-26-03
On 27 January 2004 the FAA issued airworthiness directive 2003-26-03 (later superseded by AD 2008-17-12) which called for modification to the mounting of ADIRU3 in Airbus A320 family aircraft to prevent failure and loss of critical attitude and airspeed data.[2][14]"

sgrow787 wrote:

Yep, and there's a Wikipedia entry for ADIRU that lists about a dozen historical events related to ADIRU issues. A couple of those are ADs (as well as infamous QF72 and AF447 among others):

QF72 was due unpleasant interaction with a software bug not caught on the ADIRU
and data sanitation on the A330 FBW
AF447 wasn't really an ADIRU issue. One might find a critical word for the stall indication logic.
( I'd have kept the stall warning on when going from airspeed valid to invalid. But that introduces state. pot. undesired.)

Determinations:

What would be visible ( data presentation / effects ) on an NG if the ADIRU produced the same errors?

Was the ADIRU and or its data processing changed for the MAX?

WIederling wrote:

AF447 wasn't really and ADIRU issue. One might find a critical word for the stall indication logic.

From Wikipedia's entry:
"On 1 June 2009, Air France Flight 447, an Airbus A330 en route from Rio de Janeiro to Paris, crashed in the Atlantic Ocean after transmitting automated messages indicating faults with various equipment, including the ADIRU."

sgrow787 wrote:

WIederling wrote:

AF447 wasn't really and ADIRU issue. One might find a critical word for the stall indication logic.

From Wikipedia's entry:
"On 1 June 2009, Air France Flight 447, an Airbus A330 en route from Rio de Janeiro to Paris, crashed in the Atlantic Ocean after transmitting automated messages indicating faults with various equipment, including the ADIRU."

I'd have to go over the report again. ( that was ten years ago )
Wasn't that just the ADIRU telling about having lost airspeed data and such?
ref. https://www.bea.aero/docspa/2009/f-cp09 ... 1e1.en.pdf page 51.ff

and yes:
ADIRU indicates various unavailabilities ( sensors, processed values like MACH... ).
It worked as designed.

Apologies if it has been discussed before. Few questions:
1. So far what we know of Lion Air crash and the recent ET tragedy, were it for the faulty inputs or the MCAS itself malfunctioned.
2. On various online pages, it is mentioned that MCAS is inhibited once A/P is ON. Shouldn't MCAS , if that indeed is the culprit, be out of the loop, assuming that the A/P had been engaged , which normally is the case at this time after take off.
3. If any B737 pilots reading, is .27 deg/sec nose down trim, only a little nudge or a a big nose down rotation, for a pilot to be overwhelmed.
Thanks

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I hope they get you on the investigation immediately since you are able to draw this conclusion without having ANY data for the final 3 minutes of the flight. Until the FDR is read, there is no way to know if MCAS was involved at all.

If the reports of severe altitude changes beginning immediately after takeoff are accurate, MCAS wouldn't have had anything to do with it because surely the flaps would have been deployed for TO.

A bad enough problem to cause those controllability issues certainly could have led to a final nose dive with no MCAS.

For all we know at this point part of the stabilizer broke off after TO (bad tailstrike?) and more broke off from aerodynamic stresses later that caused the nose dive.

It is unbelievable to me that it is taking so many days to read the FDR data. What that data says is critical to a preliminary understanding of this event and could quickly allow a focus on or away from a design issue with the MAX whether MCAS related or not.

planecane wrote:

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I hope they get you on the investigation immediately since you are able to draw this conclusion without having ANY data for the final 3 minutes of the flight. Until the FDR is read, there is no way to know if MCAS was involved at all.

If the reports of severe altitude changes beginning immediately after takeoff are accurate, MCAS wouldn't have had anything to do with it because surely the flaps would have been deployed for TO.

A bad enough problem to cause those controllability issues certainly could have led to a final nose dive with no MCAS.

For all we know at this point part of the stabilizer broke off after TO (bad tailstrike?) and more broke off from aerodynamic stresses later that caused the nose dive.

It is unbelievable to me that it is taking so many days to read the FDR data. What that data says is critical to a preliminary understanding of this event and could quickly allow a focus on or away from a design issue with the MAX whether MCAS related or not.

Apparently they have found the jackscrew that operates the horizontal tail plane and it indicates it was set to push the nose down.

StTim wrote:

planecane wrote:

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I hope they get you on the investigation immediately since you are able to draw this conclusion without having ANY data for the final 3 minutes of the flight. Until the FDR is read, there is no way to know if MCAS was involved at all.

If the reports of severe altitude changes beginning immediately after takeoff are accurate, MCAS wouldn't have had anything to do with it because surely the flaps would have been deployed for TO.

A bad enough problem to cause those controllability issues certainly could have led to a final nose dive with no MCAS.

For all we know at this point part of the stabilizer broke off after TO (bad tailstrike?) and more broke off from aerodynamic stresses later that caused the nose dive.

It is unbelievable to me that it is taking so many days to read the FDR data. What that data says is critical to a preliminary understanding of this event and could quickly allow a focus on or away from a design issue with the MAX whether MCAS related or not.

Apparently they have found the jackscrew that operates the horizontal tail plane and it indicates it was set to push the nose down.

I hadn't seen that news. However, without the FDR readout, it is still unknown why. It could have been MCAS, it could have been the pilots trimming down on purpose. If it was MCAS, it could have been a valid case of MCAS operating because they were in a stall and it was trying to get them out of it.

planecane wrote:

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I hope they get you on the investigation immediately since you are able to draw this conclusion without having ANY data for the final 3 minutes of the flight. Until the FDR is read, there is no way to know if MCAS was involved at all.

If the reports of severe altitude changes beginning immediately after takeoff are accurate, MCAS wouldn't have had anything to do with it because surely the flaps would have been deployed for TO.

A bad enough problem to cause those controllability issues certainly could have led to a final nose dive with no MCAS.

For all we know at this point part of the stabilizer broke off after TO (bad tailstrike?) and more broke off from aerodynamic stresses later that caused the nose dive.

It is unbelievable to me that it is taking so many days to read the FDR data. What that data says is critical to a preliminary understanding of this event and could quickly allow a focus on or away from a design issue with the MAX whether MCAS related or not.

BEA only got the boxes a day ago.

Investigators found piece of stabilizer with trim in unusual position similar to doomed Lion Air jet, according to airlive.net.

Pluto707 wrote:

MCAS is not the cause, but it gave the final blow

There's rarely a single cause, so in that sense you're right.
But all other things being equal, there is reason to doubt that we'd have more than 300 people dead without MCAS.
(Yes, I know, we are not 100% sure MCAS even played a role in ET302, but current satellite data and trim jackscrew findings do suggest this is the case, according to the Canadian and US authorities, at least.)

Regarding MCAS, I'm also wondering how a solution design with the following characteristics even made it past the very fist architectural stages, never mind through certification:
1) uses input from a single sensor
2) has no quorum/sanity check/tie-breaker or similar mechanism in place to determine whether sensor data is valid to begin with
3) has no automatic switch-off mechanism
4) has no limit on the level of trim it can exert
5) has no limit on the number of times it will cause trim input

That's just sloppy design and most non-safety-critical systems I've seen implemented first-hand were designed with more care.

It's been mentioned that the ADIRU might also play a role here, which if true compounds any issues with MCAS as it might make erroneous data feeds (and thus erroneous actions by MCAS) more likely.
Still, those MCAS design issues really need to be addressed.
And in fairness, according to Boeing's own statements regarding the planned MCAS changes, they're going to address these exact points:

* Verification of triggering AoA signal, i.e. check that signal is valid (addresses points 1 and 2 above)
* Only one instance of nose-down trim, not indefinite repeated cycles (addresses points 3 and 5 above9
* Limit the maximum trim MCAS can exert, to ensure a pilot can win their fight against MCAS (addresses poiunt 4 above)

As a lot of focus is on the investigations and on Boeing's announced software fix, I think we should not forget that regulators - FAA of course, but also those that basically followed FAA's certification of the MAX, like EASA, and others - should also be subject to some questions. If a design like MCAS makes it onto an airplane, there really should be some sort of certification checklist of whether or not it meets certain redundancy and other requirements.

sgrow787 wrote:

Is it time to revisit a possible ADIRU failure here, since it would explain why Lion Air couldn't fix their issue after replacing their AOA sensor (AOA, air speed sensors feed into the ADIRU before getting to the SMYD and FCC)? ADIRU would explain erroneous air speed too. More specifically, could a power bus issue to the ADIRUs be the root cause (in addition to a non-redundant MCAS design)?

Edit: I swear I didn't read the above post before posting! Looks like we may be onto something!!

I've said it four or five times since the beginning of this thread... It always looked to me like a potential common cause for both incidents...

Muddassir wrote:

2. On various online pages, it is mentioned that MCAS is inhibited once A/P is ON. Shouldn't MCAS , if that indeed is the culprit, be out of the loop, assuming that the A/P had been engaged , which normally is the case at this time after take off.

Yes, it's true that MCAS is off if AP is on. Yes, AP would normally be on for both flights.

But, in the event of bad or mismatched AOA or IAS indications, AP is turned off so the pilots can fly the plane. This seems to be the case for both accidents meaning that MCAS was active.

Is it normal for the primary control surfaces of an aircraft to repurposed (by MCAS) in order to keep an aircraft stable in the air and achieve certification ?
Is this done anywhere else ?

rideforever wrote:

Is it normal for the primary control surfaces of an aircraft to repurposed (by MCAS) in order to keep an aircraft stable in the air and achieve certification ?
Is this done anywhere else ?

Yes in a number of military aircraft fighters in particular.

rideforever wrote:

Is it normal for the primary control surfaces of an aircraft to repurposed (by MCAS) in order to keep an aircraft stable in the air and achieve certification ?
Is this done anywhere else ?

All current production Airbus as well as the 777, 787, etc. Basically any FBW aircraft is using the primary control surfaces to maintain stable flight.

I guess you can say any autopilot does this as well.

The issue isn't MCAS, it is the terrible implementation with no safeguards in the event of erroneous sensor inputs. The autopilot will disengage in that situation.

If MCAS simply disengaged with AoA disagree and had a max trim limit and alerted the pilots that MCAS was inactive so they'd have to manually trim, the system would be fine. As a non-aviation engineer, I am perplexed at how that implementation passed the initial whiteboard sketch, let alone any actual coding.

mandala499 wrote:

Jetty wrote:

It shouldn’t go into effect until flaps are retracted. That doesn’t mean it doesn’t go into effect until flaps are retracted. From the Lion Air crash we know it has gone into effect when it shouldn’t before and there’s no way of knowing if this is isolated to one specific set of circumstances or an wider issue.

What I fear is that there is unreliable airspeed from the take off roll, and they were shocked to see stick shaker on from the take off roll, and decided to shallow out the climb to "get out of it"... only to not see it not disappear.... with the increasing speed and confusion with the stick shaker and the unreliable airspeed then comes the next question... did they pull up the flaps at 800' AGL?

I suspect this is EXACTLY what happened. Stick shaker from take off roll, AP remains off, pilots level off to gain speed, stick shaker does not disengage, they don't trust the speed readings. Eventually, they get the airplane to a climb with Flaps to 13k or 14k feet and think they bought some distance between themselves and the ground, but as soon as they level and retract flaps, MCAS goes into runaway mode while stick shaker is still going off and they are at high speed. They try to turn back to ADD and just like with JT301, by the time they initiate turn, MCAS has been eating into their trim config enough where they can't apply enough nose up input to counteract the effects of trim config combined with high speed. Not that this was unrecoverable, but it is an insanely bad hand to be dealt as a pilot.

Pluto707 wrote:

MCAS is not the cause, but it gave the final blow

Nah - in air crash event sequencing, it's well known that you can remove a single link from the "chain" and prevent the accident. It's the job of manufacturers, regulatory and certification bodies to remove as many "links" as possible.

If, for example, I'm ultimately able to prevent a crash by removing MCAS from the equation, then yes - it's (basically) the cause. Likewise they'll remove other contributing factors as well. Part of my concern is the actual fundamental handling of the aircraft though, which they're obviously going to be unable to change.

sgrow787 wrote:

WIederling wrote:

AF447 wasn't really and ADIRU issue. One might find a critical word for the stall indication logic.

From Wikipedia's entry:
"On 1 June 2009, Air France Flight 447, an Airbus A330 en route from Rio de Janeiro to Paris, crashed in the Atlantic Ocean after transmitting automated messages indicating faults with various equipment, including the ADIRU."

Eh, wiki isn't always God - I think by "faults" perhaps they mean they disabled due to all three data streams being illogical / erroneous. That's basically exactly what they're supposed to do though - I hadn't heard of any actual faults, unless perhaps they went back and changed some of the ways they performed specifically. Triple failure is REALLY rare so it likely provided some unusual insight for engineers. Regardless, upon all reverting to alternate law, both pilots retained full flight control authority over the aircraft - they just decided to pull full-aft for 3+ minutes is all.

edu2703 wrote:

Investigators found piece of stabilizer with trim in unusual position similar to doomed Lion Air jet, according to airlive.net.

Yikes - well at least they have some hard evidence to look at in addition to the FDR/CVR. That should make some of the conspiracy theorists sleep better (you know, the ones who have mental images of guys in Airbus shirts pouring through the crash data as we speak).

planecane wrote:

The issue isn't MCAS, it is the terrible implementation with no safeguards in the event of erroneous sensor inputs. The autopilot will disengage in that situation.

It appears MCAS thinks the plane is stalling and human is not able to handle, so let me help the poor human by trimming nose down for 10 more seconds.

If its sole purpose is to solve unstable flight, they wouldn't have put it in an infinite loop, first human interaction would disable like STS.

This is a case of computer thinks it knows better than humans, which is historical with stall handing,

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

mandala499 wrote:

Jetty wrote:

It shouldn’t go into effect until flaps are retracted. That doesn’t mean it doesn’t go into effect until flaps are retracted. From the Lion Air crash we know it has gone into effect when it shouldn’t before and there’s no way of knowing if this is isolated to one specific set of circumstances or an wider issue.

What I fear is that there is unreliable airspeed from the take off roll, and they were shocked to see stick shaker on from the take off roll, and decided to shallow out the climb to "get out of it"... only to not see it not disappear.... with the increasing speed and confusion with the stick shaker and the unreliable airspeed then comes the next question... did they pull up the flaps at 800' AGL?

Retracting the flaps at very high speeds (400 KTS) of speeds, in relatively thick air(below 10000 ft), what will that do to the aerodynamic trim balance of a 737 Max?
If auto trim is already off (MCAS deactivated / elevator trim cut switches activated), can the change in pitch trim be easily corrected manually?

Waterbomber2 wrote:

Lionair had issues with AOA, and airspeed.
In this case there was at least an airspeed issue.
Perhaps an issue with the ADIRU or a major configuration deviation outside of the ADIRU's parameters causing it to produce false data.

An AOA error can produce unreliable airspeed indication.

Even with the LionAir case, I personally still suspect that the fault may not have been with the AOA vane, but with the ADR itself... we'll have to wait and see.

StTim wrote:

Apparently they have found the jackscrew that operates the horizontal tail plane and it indicates it was set to push the nose down.

Sad and tragic, but even more sad and tragic is that it's not surprising...

As a non-aviation engineer, I am perplexed at how that implementation passed the initial whiteboard sketch, let alone any actual coding.

Exactly this. I work in software development and, from what it seems, the implementation of MACS in terms of redundancy, fail over, alerts for it being on/off, or rather lack of, are absolutely delusional. How ANYONE signed off on this approach just baffles me.

I had the utmost respect for aerospace certification and safety systems on board these planes, seems that the greed for commercials is festering its way in here now also.......the thing is, I dont believe it would cost too much more to make the MACS implementation safer, even if the reality is it is a sticking plaster for a plane that is fundamentally unstable. If the aircraft is safe enough in terms of not being so aerodynamically unstable that it can safely fly 99.9% of the time without MACS then why make an issue of hiding it's presence initially? If MACS is to assist and support the pilot in certain extreme scenarios, then fair enough but it should do so with full visibility and the ability to override and continue without crashing with pilot control (Based on the required training and decision for any given situation).

The root cause here is if MACS is required to simply keep these new planes in the air, then Boeing needs to go back to the drawing board.

My point is, software like this on a plane isn't like sending out a new PS4 or Xbox game knowing it has bugs which people accept get sorted with a 1GB update when they first put the disk in!!

This is taking the lives of people where non-aviation brains can see clearly with the use of 'common sense (maybe now should be called uncommon sense.....) that the way MACS is setup is a disaster waiting to happen, again.

You can brag about training in the U.S. as much as you want, when sh*t hits the fan and the stick shaker goes off on take off while you lose multiple instruments and have to ask ATC for their readings, while the aircraft is going on a rodeo, anybody is going to cr*p their pants, whether they logged 200 hours or 20.000 hours, it doesn't matter.

And, still, put the pitch around 12*-15*, thrust at climb setting, ignore the rest until the PM can shut off the stab trim and the stall warning. I agree it’s a terrible fraught with problems, but basic look out the window flying. The C-5 has occasional false stall warning and the book answer was exactly that—fky plane, turn off the failed system.

GF

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

dtw2hyd wrote:

planecane wrote:

The issue isn't MCAS, it is the terrible implementation with no safeguards in the event of erroneous sensor inputs. The autopilot will disengage in that situation.

It appears MCAS thinks the plane is stalling and human is not able to handle, so let me help the poor human by trimming nose down for 10 more seconds.

If its sole purpose is to solve unstable flight, they wouldn't have put it in an infinite loop, first human interaction would disable like STS.

This is a case of computer thinks it knows better than humans, which is historical with stall handing,

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

You have to dig a bit deeper than that though. For 50 years, normal stall recovery procedures were perfectly adequate on prior aircraft, even when it came time to certify the NG. For some reason, that's not the case with the MAX. It's not really a "feature" Boeing added as an upgrade with the new plane or something - it's a requirement for certification.

I don't understand your comment of "if its purpose is to solve unstable flight, they wouldn't have put it in an infinite loop" - IMO that's exactly WHY they put it in a loop. It's clearly critical to prevent the nose from raising when applying full thrust. If the situation isn't changed, then it still needs to correct the problem - thus MCAS continues. Again I think you're looking at this as more of a feature than a critical component required for safe flight.

dragon6172 wrote:

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

"Tested the procedure" - love it!

Isn't that the flight where the guy in the left hand seat had his stick shaker active for 84% of the time?

I bet it would have been fun to watch him try and eat soup for his dinner.

EDIT; it was 100% of the flying time - the stick shaker was inactive during taxying.

dragon6172 wrote:

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

But we still dont know if the pilots on the crashed planes did that or not, Its just an assumption that the Lion air crew didnt. But that also assumes that the fault was exactly the same.
In the case of the Ethiopian plane, where the pilots where well aware if the issue and if flipping the switch would have solve the problem the crash would probably not have occurred. The reports from other pilots also suggest that there are more into this. It is not impossible that there are a gremlin somewhere in the systems that renders the plane uncontrollable and that that there are certain situations that causes this to happen. With all the attention given to MCAS after the Lion air crash it must have been one of the first things that comes to the minds of the pilots if/when the plane started to pitch down.

anfromme wrote:

But all other things being equal, there is reason to doubt that we'd have more than 300 people dead without MCAS.
Regarding MCAS, I'm also wondering how a solution design with the following characteristics even made it past the very fist architectural stages, never mind through certification:
1) uses input from a single sensor
2) has no quorum/sanity check/tie-breaker or similar mechanism in place to determine whether sensor data is valid to begin with
3) has no automatic switch-off mechanism
4) has no limit on the level of trim it can exert
5) has no limit on the number of times it will cause trim input

That's just sloppy design and most non-safety-critical systems I've seen implemented first-hand were designed with more care.

Refreshing to see someone asking the questions that NEED to be asked, rather than superfluous conjecture about whether the plane was trailing smoke and paper before it crashed.

I've been asking these questions all along since Lion Air and the revelation about MCAS and how it operated. Finding out it relied on a single AOA sensor was one of the most surreal moments I've ever had. Like you, I am trying to sit here and figure out how this system even came into being let alone got certified. It's bad enough to have it begin to control the flight of the airplane based on ONE sensor that COULD BE faulty (it has not way of knowing that or adjudicating), but to ALSO give it what can close enough be described as impunity with when/how often it performs its uncommanded pitches is just insanity. I would like to know very much how something like that ever got approved.

Not to mention there is still the remaining question of how much force the PF would have to apply to the controls to counter the erroneous commands of MCAS, and whether or not those physical forces increase with each cycle of MCAS, and whether or not MCAS would eventually have tightened the jackscrew so far that the forces were unsurmountable to be in the other direction.

Couldn't the pilots in any case of malfunction just turn off all electronic bs? Like you're a pilot. You know how to fly a plane. You have flown thousands of take-offs. You know the right speed, right angle, right altitude. You know how to do it without electronic interference if need be.

So why not hit the kill switch if the computer is having a fit?

SimonL wrote:

But we still dont know if the pilots on the crashed planes did that or not, Its just an assumption that the Lion air crew didnt. But that also assumes that the fault was exactly the same.
In the case of the Ethiopian plane, where the pilots where well aware if the issue and if flipping the switch would have solve the problem the crash would probably not have occurred. The reports from other pilots also suggest that there are more into this. It is not impossible that there are a gremlin somewhere in the systems that renders the plane uncontrollable and that that there are certain situations that causes this to happen. With all the attention given to MCAS after the Lion air crash it must have been one of the first things that comes to the minds of the pilots if/when the plane started to pitch down.

We know the pilots on the Lion Air accident flight didn't flip the switches to turn off electric trim because the FDR shows electric trim was making inputs all the way until the end

WIederling wrote:

osiris30 wrote:

WIederling wrote:

Going by what is visible Boeing engineers did not write complex software they wrote simplistic software.
Cargo Cult.
Copy the superficially visible of another complex product and expect the copy to perform to the full specs of the complex product.
We saw the same when Boeing tried to copy the manufacturing model from Airbus.

Have you seen the code and do you have any basis on that apart from a Boeing bash? Just curious? Any facts to go with that load of drivel you just wrote?

I am good enough with analysis of software and hardware "blackboxes".
You exercise the item and evaluate the reaction. Think Deep.
I've usually been able to pinpoint the cause of some unexpected behaviour.
( Lots of commercial stuff : you get no traction and have to work around such software bugs.
With OSS software you fix it yourself or lean on the programmer if available. )

So the answer is no. Thank you.

PW100 wrote:

WIederling wrote:

Elementalism wrote:

This is the equivalent of hiring a college grad to perform a senior level position. Nobody in their right mind would do such a thing due to the lack of experience.

the requirements shift from 250 to 1500 hours came about in 2013.
Under the pretext of increasing safety ( ref Colgan, both pilots had hours to no end.)
with a designed in intention of advantaging military pilots transfering into civil life:
https://www.faa.gov/news/press_releases ... wsId=14838
( its in the catalog presented in the link )

Could you please show the resultant significant increase in commercial flying safety?

Only thing visible is pilot shortage and thus airlines having to scrape the bottom coming up with
pilots that have the hours but are apparently sub par in effectively gained competence.

Not only that; the majority of the current 5000+ hrs pilots in the USA built their experience (going from 250 and 1500 hrs), in the right hand seat of a commercial jet. Was that so unsafe?

And just to remind, JT610 pilots had 6000 and 5000 hrs too.

dragon6172 wrote:

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

That is just a theory because previous flight didn't crash. It could be just MCAS trim down did not reach a point of no return and crew could recover.

dtw2hyd wrote:

dragon6172 wrote:

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

That is just a theory because previous flight didn't crash. It could be just MCAS trim down did not reach a point of no return and crew could recover.

We know from their briefing that they hit the cutoff switches and flew manual trim. We don't necessarily know that it was MCAS that was causing the runaway trim condition in the flight prior to the accident, but I think we can say with more certainty that was the case than we can say that the ET crash was related to MCAS. (To clarify my previous statement - I think we can say with a higher level of confidence that the flight prior to the lion air accident experienced an MCAS issue than we can the ET accident flight). In fact, it's the account given by that Lion Air crew that leads us all to believe the lion air crash was related to MCAS.

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I'm with this too. They had issue right from the take off roll from the looks of it.

dragon6172 wrote:

dtw2hyd wrote:

Also, everyone claims pilots need to flip two cut-off switches and they are good. Did anyone test this theory with MAX/MCAS (or) just based on runaway stab procedures?

The Lion Air crew prior to the accident flight tested this procedure and it worked as advertised.

You forgot to add "by luck"! They had no idea what was going on but happened to guess correctly that trim could be involved. THERE WAS NO PROCEDURE.

GalaxyFlyer wrote:

You can brag about training in the U.S. as much as you want, when sh*t hits the fan and the stick shaker goes off on take off while you lose multiple instruments and have to ask ATC for their readings, while the aircraft is going on a rodeo, anybody is going to cr*p their pants, whether they logged 200 hours or 20.000 hours, it doesn't matter.

And, still, put the pitch around 12*-15*, thrust at climb setting, ignore the rest until the PM can shut off the stab trim and the stall warning. I agree it’s a terrible fraught with problems, but basic look out the window flying. The C-5 has occasional false stall warning and the book answer was exactly that—fky plane, turn off the failed system.

GF

I'd be interested to know how this works in the simulator. You would think with a few thousand feet of altitude on a clear daytime flight your theory should work. Basically turn off everything and if throttle controls, engines and control surfaces are still working you should be able to keep the plane flying. Of course, that's easy to write from a desk.

As an aside, my last boss was a retired naval aviator. We of course talked aviation a lot. He thought that over the last 20 years there has been an ever expanding gap in "manual" flying skills between military and civilian pilots. He would say "You can't dogfight on autopilot." It's just human nature to revert to what you are comfortable with/know. Someone with a lot of actual stick time would be much quicker to turn off autopilot/other electronic aids and take over complete control than someone with less manual flying experience. From your handle, I'm guessing you are/were military?

ec99 wrote:

GalaxyFlyer wrote:

You can brag about training in the U.S. as much as you want, when sh*t hits the fan and the stick shaker goes off on take off while you lose multiple instruments and have to ask ATC for their readings, while the aircraft is going on a rodeo, anybody is going to cr*p their pants, whether they logged 200 hours or 20.000 hours, it doesn't matter.

And, still, put the pitch around 12*-15*, thrust at climb setting, ignore the rest until the PM can shut off the stab trim and the stall warning. I agree it’s a terrible fraught with problems, but basic look out the window flying. The C-5 has occasional false stall warning and the book answer was exactly that—fky plane, turn off the failed system.

GF

I'd be interested to know how this works in the simulator. You would think with a few thousand feet of altitude on a clear daytime flight your theory should work. Basically turn off everything and if throttle controls, engines and control surfaces are still working you should be able to keep the plane flying. Of course, that's easy to write from a desk.

As an aside, my last boss was a retired naval aviator. We of course talked aviation a lot. He thought that over the last 20 years there has been an ever expanding gap in "manual" flying skills between military and civilian pilots. He would say "You can't dogfight on autopilot." It's just human nature to revert to what you are comfortable with/know. Someone with a lot of actual stick time would be much quicker to turn off autopilot/other electronic aids and take over complete control than someone with less manual flying experience. From your handle, I'm guessing you are/we're military?

GF flies and trains people to fly the C5 so yeah.

ytz wrote:

Pluto707 wrote:

After 47 pages of posts, my conclusion: MCAS was not the cause, but it gave the final blow

I'm with this too. They had issue right from the take off roll from the looks of it.

What is still sticking with me is that ET's CEO has stated (authoritatively) that the pilots were trained on MCAS and how to handle it.

planecane wrote:

The issue isn't MCAS, it is the terrible implementation with no safeguards in the event of erroneous sensor inputs. The autopilot will disengage in that situation.

If MCAS simply disengaged with AoA disagree and had a max trim limit and alerted the pilots that MCAS was inactive so they'd have to manually trim, the system would be fine. As a non-aviation engineer, I am perplexed at how that implementation passed the initial whiteboard sketch, let alone any actual coding.

I assume they just recycled a piece of autopilot code for MCAS - without realizing that autopilot routine performs a lot of checks for data validity before launching that code.
However, that brings a question of overall airplane code quality and if anything was verified by the third party - at least FAA.
Infamous Toyota unintended acceleration was traced down to problems with the code - and their code was called uninspectable and unmaintainable since basic design approaches were violated. Toyota did a lot to remove that info from the web, but you can still find some.
I hope for external inspection of Boeing code, but I am afraid it will bring up a lot of dirty laundries...

Trin wrote:

[

Like you, I am trying to sit here and figure out how this system even came into being let alone got certified. .

Given this sentiment about this system is being echoed my quite a few on the av boards right now, this brings a follow up issue.

Because it already would be concerning enough that an aerospace company designed and approved such a solution, and that one national aviation authority certified it. But obviously all the other major aviation authorities around the world also approved it as safe for real world utilization.

What does this mean? To an outsider like me, this suggests either blind trust in the airplane designer and manufacturer, and or in the national authority that certified it. Otherwise it suggest they don't particularly bother to take time and resources to independently scrutinize and go over the engineering, schematics, architecture, and features of new equipment or systems being introduced into the airspace they oversee.

That's puzzling and worrying.