Boeing 737 Max design error

On 5/6/19 1:26 PM, Lasse Langwadt Christensen wrote:
mandag den 6. maj 2019 kl. 10.12.17 UTC+2 skrev DecadentLinux...@decadence.org:
omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance
the airplane the same way as in the two crashes. Do you want to
fly a plane that only software is used to prevent stalling?
Without software it stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.


and before that there's a stick shaker and the stick pusher

IIRC the whole point of the system is that the envelope between where
the stick-shaker would engage to give warning and the entry point of a
catastrophic stall is not large

The biggest issue to me is that there was no release switch to return
pilot control.

there is, two switches to turn off electric trim and the pilots are supposed
to know how to handle run away trim by memory
 
mandag den 6. maj 2019 kl. 19.44.26 UTC+2 skrev Tom Gardner:
On 06/05/19 13:55, trader4@optonline.net wrote:
On Sunday, May 5, 2019 at 11:25:13 PM UTC-4, omni...@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily.

It doesn't stall so easily. The problem only arises at very high levels
of angle of attack, that a plane would only experience in extreme, very
unusual situations. And then the problem is
that if you let go of the controls, instead of heading back toward a
lower angle of attack, the plane can nose up more, which would stall it.
The plane likely could not have been certified with that problem.
That's what MCAS was put in there to counteract. Granted it's not the
best design and a totally new plane design would have been better.
But then that costs a lot more, both in development and then you have
increased costs for the airlines due to training, type ratings, and now
you have a mixed fleet that adds to maintenance costs, etc.

False.

The problem is that when approaching a stall, the SOP is to
increase engine power. In the 737 MAX (unlike all other 737s)
that causes a pitch up due to the changed engine position.
That pitch up increases angle of attack, thus driving further
into the stall.

afaiu and heard from pilots who fly the things all aircrafts with
under wing engines including the 737 NG will pitch up with power
the pitch up is just stronger with the 737 MAX
 
On 06/05/19 17:07, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 11:40:09 AM UTC-4, bitrex wrote:
On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

One way would be to look at other data, eg airspeed and attitude and see
if that's consistent with a stall. There is going to be a wide range
where the plane couldn't be stalling based on the other data.

Basic training is that you can stall an aircraft at any
attitude and any speed. I've done some :)
 
On 5/6/19 12:29 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 12:09:51 PM UTC-4, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.

The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation. There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on. It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS). The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

IDK what version of reality you're watching, but the first crash was
Lion Air in Indonesia and from that moment on, the focus has been almost
exclusively on the plane, the poor MCAS design and not the pilots.
Which is wrong, because there should be focus on both. We need to
understand why pilots can't identify a very basic thing, runaway trim
and follow the procedure. It's supposed to be a memory item.
There are multiple parties to blame here:

Boeing bad MCAS design
FAA approving it
FAA never informed that the authority of MCAS had been greatly increased
Pilots incapable of identifying and dealing with runaway trim.

It's hard to understand how pilots could watch the electric
trim run the plane nose down, time and time again, with the trim wheels
beside them spinning, showing abnormal trim down, followed by trim up
when you corrected it via the trim buttons. Hello? Get it near
neutral, where you know it belongs, turn off the electric to stop
whatever is causing it to move, and trim manually. In the LA crash
they had almost 10 mins to figure it out. The Ethiopians had much
less time, but then they also knew about MCAS and the previous crash.

I propose a psychological phenomena called "Transient Reactive
Incompetence" - when faced with a combination of unfamiliar situation or
high stress levels, and presented with a set of options, humans will
tend to pick the least advantageous options despite the information they
already know that suggests to do otherwise
 
On 5/6/19 12:29 PM, trader4@optonline.net wrote:

Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

IDK what version of reality you're watching, but the first crash was
Lion Air in Indonesia and from that moment on, the focus has been almost
exclusively on the plane, the poor MCAS design and not the pilots.
Which is wrong, because there should be focus on both. We need to
understand why pilots can't identify a very basic thing, runaway trim
and follow the procedure. It's supposed to be a memory item.
There are multiple parties to blame here:

Sometimes when I'm in a hurry I forget to unplug my car from the
electric charger port which is a thing I've done hundreds of times
before and a totally dick-headed thing to forget, thoughtfully the GM
engineers made it so the gear shift locks in park when the cable is
connected so you can't rip the whole charge port out as you drive away.
Well at least I've never done it at a gas station.
 
On 06/05/19 16:14, John Larkin wrote:
On Sun, 5 May 2019 20:25:09 -0700 (PDT), omnilobe@gmail.com wrote:

Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily. Software cannot fix that
weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling?

A jet plane is full of software that's critical to flight. The
throttles aren't mechanical any more, they send signals to the FADECs.
And on and on.

I don't think that your "looking at photos" is solid aerodynamic
analysis.

Boeing made some appalling choices with the AOA sensors. Absent those
mistakes, the 737 would be fine.

The Board of Directors didn't design the anti-stall system or decide
to only use one AOA sensor per flight.

Correct, but they did employ the people that set the company
ethos that allowed (and possibly encouraged) the corner cutting.

Marketing pushed for "no new training necessary, because it
behaves the same". We have no idea as to whether engineers
pushed back.

This marketing push and corporate ethos thing is reminiscent
of the VolksWagen diesel fiasco.
 
On 06/05/19 19:15, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 1:05:00 PM UTC-4, bitrex wrote:
On 5/6/19 12:30 PM, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.



I think a "safety" system that is designed to bring the system it's
managing the safety of, out of an error state, via some other action
which in a different circumstance is also an error state and a safety
risk too, has to be able to determine, with high accuracy, whether it's
the overall system or itself that is in an error state.

If I'm understanding what I've read correctly (and I accept that I do
not, I'm not an aviation engineer but it doesn't seem to stop anyone
else from offering their commentary so...) the system relied on one AOA
sensor to determine the overall state of the aircraft with respect to
what action it needed to take.

but I think there's a fundamental information theory problem there in
that with one sensor it doesn't have enough information to determine
conclusively whether it's the overall system or itself that is the one
in error. As long as everything works fine it works fine, but when it
doesn't the system can no longer "reason" conclusively about anything
anymore it's like the thought experiment of sitting in the train next to
another train and figuring out which of you is the one moving.

And it sounds like the patch is to provide more indirect information
from e.g. the airspeed and altimeter but as they don't actually measure
the true parameter of interest it would seem to fall under the category
of "heuristics" or "hacks."

If you know the plane if flying at 300 MPH and is in a level or close
to level attitude, has been that way for X seconds, you can definitively
rule out a stall. And more fundamentally, to address your concerns,
MCAS will now use BOTH AOA sensors and if they disagree, take no action.

What aircraft are (or have you been) qualified to fly?

Have you come across the concept and practice of "mushing"? As in...
https://aviation.stackexchange.com/questions/26932/what-is-a-mushing-glide
Been there, done that.

BTW, Wolfgang Langewiesche's "Stick and Rudder; An Explanation of
the Art of Flying" is /well/ worth reading several times.
 
On Monday, May 6, 2019 at 1:36:50 PM UTC-4, Tom Gardner wrote:
On 06/05/19 15:01, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 5:00:14 AM UTC-4, Sylvia Else wrote:
On 6/05/2019 1:25 pm, omnilobe@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily. Software cannot fix that
weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it stalls.
With software it is low cost.
Nikki Haley is a Trump liar. Do not fly Trump-Boeing death traps. Don doesn't.

The Board at Boeing is packed with dunces and insurance agents who know nothing
about Weights and Balances of aircraft.


The effect of the software behaviour, as was, was to trim the aircraft
forward for no good reason.

The pilots should have treated it as a runaway trim, and acted
accordingly. Then the crashes would not have occurred.

+1

And the Lion Air pilot on the flight the day before the crash, did exactly
that. He wasn't flying, just catching a rid in the jump seat. When the
other pilots couldn't figure it out, he did. This is the most shocking
thing.

The most shocking thing is that the problem occurred so frequently.

And yet in all the reporting, all the discussion, that is rarely, if
ever mentioned. Why is it that we've heard nothing about the root cause
of the AOA failure? Was it actually traced for sure to the AOA itself,
as opposed to wiring, interface circuit, software, etc? You would think
there would be something like there typically is after a crash like this,
where they call for inspections or replacement, etc. But here nothing.
And these were brand new sensors. Also what went on at Lion Air as they
tried to fix it? Supposedly they put in a replacement sensor. So, how
did it fail again or did they replace the wrong one? And there were reports
on the planes that crashed as well as on the flight from the previous day
of airspeed disagreeing between the pilot and co-pilot displays, maybe
altitude display issues too. If it's just this AOA, how is it affecting
airspeed? One of the flights, I think the airspeed was off by like 40 MPH
from one side to the other.





Serious questions need to be asked about the competence of the pilots.
Would a properly trained crew have had any difficulties, even in the
absence of details about MCAS? I rather think not.

The system's entire *purpose* was to *avoid* new *training*.

"No new training" was the *reason* the system was installed.

So the concept of "properly trained" is a complete misdirection,
in the sense that magicians misdirect their audience's attention.

No it's not. I'm not talking about training for MCAS, I'm talking
about training that all pilots go through to get qualified and to
continue to be employed. That's where they would have been trained
on how to deal with runaway trim. And from what we know now, at least
4 out of 7 pilots couldn't deal with it, despite that it's supposed to
be a memory item.
 
On Monday, May 6, 2019 at 10:55:43 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 07:26:28 -0700 (PDT)) it happened
trader4@optonline.net wrote in
bc496342-1823-4eb9-9b07-ab96aae6321f@googlegroups.com>:

On Monday, May 6, 2019 at 5:37:31 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 19:00:05 +1000) it happened Sylvia Else
sylvia@email.invalid> wrote in <gjabcoF495jU1@mid.individual.net>:

The effect of the software behaviour, as was, was to trim the aircraft
forward for no good reason.

The pilots should have treated it as a runaway trim, and acted
accordingly. Then the crashes would not have occurred.

Yes I did read that.


The system could not be turned off AFAIK.


Incorrect. There are two clearly marked cutoff switches for the electric
trim, located right at the large trim wheels that are spinning back and
forth beside the pilots. Turned off, MCAS can't do anything.

If that is so then it is indeed strange the pilots did not use those.
Maybe it had to do with too much flying on auto-pilot and not enough real flight hours,
too much relying on automation, much has been written about that.


It seems likely that Boeing expected that that would happen in the event
that this non-redundant computer system misbehaved.

Yet in both cases the pilots let the aircraft get itself seriously out
of trim. So much so, that in the case of the second crash, when the the
pilots did eventually disable the electric trim, the aircraft was so far
out of trim that the pilots were not strong enough to turn the trim
wheels (or they didn't try - it's rather unclear at the moment).


Have not read all the details, but it seemed they increased speed / engine thrust to prevent a stall.
What th3 stupid system should do it check for altitude and a lot more parameters before doing the fatal trim.

Altitude would not seem to be a parameter in determining if the plane is
stalling or not.

You can only get out of a stall by putting the nose down gaining speed if you have any altitude at all.
So it the very low altitude situation the system should not interfere in my view (minimum altitude can be calculated I'd think),
but simply sound a warning.

It kind of works that way anyway. MCAS is not active with flaps deployed
which is generally what you're going to have at low altitudes.
That's why with all three of these flights, the trouble started just as
the flaps were retracted. You would think that if they couldn't figure
out what was going on, one of them might have thought that since the
problem started with flaps zero, maybe they should try deploying flaps
again?





It is a bit tricky, you can argue that is just where I need that system.






Where I live in the old days pilot training to get out of a stall was on a little 'Tiger Moth',
little bi-planes:
https://en.wikipedia.org/wiki/De_Havilland_Tiger_Moth
They used to do that next to our house, above the neighbors land .....
Training, yes, and it did not always go smooth.



Serious questions need to be asked about the competence of the pilots.

No, that is Boeing PR shit.

Wrong. A pilot on the Lion Air flight with the same problem the day before
the crash followed the correct procedure. But he was in the jump seat,
not flying. The two flying pilots couldn't figure it out. He told them
the procedure, it worked, the plane flew on to it's destination.

You can get abnormal trim from a short or similar component failure.
That's why those cutoff switches and manual trim wheels are in all
aircraft, not just the Max.

PR shit because Boeing did not even inform the pilots of the system it seems,
and is trying to avoid large damage claims.
All the grounded airlines all over the world that now have less income can sue Boeing.
That could go into the very high numbers of dollars.

It will. And so far, Boeing's response has been pretty poor, IMO.
No acknowledgment that they screwed up badly with a design that never
should have left the drawing board.


That plane is a disaster, it is unstable by its nature.
Pilots were not even informed of that system.
Try reading a 'manual' (having severe deficiencies in it) in the 60 seconds or so you have before the crash.


I agree it should have been in the manual. But even there, pilots disagree.
After the LA crash, the head of United pilot's union said they were OK
with it not being in the manual, that they don't need to know that level
of the inner workings. I found that quite stunning, but that's what he said.
And we have the Ethiopian crash, in which case those pilots knew about the
system and how it worked and it didn't matter. No searching in manuals was
required. The runaway trim procedure is very basic and is one of the
memory items all competent pilots are supposed to understand.


I would not want to fly a plane without knowing what control systems it has.
That is a bit tricky too, does a truck driver need to know how ABS works etc...
or how the fuel injection computer works?
If you say 'no' then having no redundancy is a crime?

I'd say a truck driver doesn't need to know how ABS *works* in detail,
but they need to know it's there and how to work with it. For example,
you need to know what ABS is intended to do and that when it's active,
with the peddle pulsing, you should maintain steady pressure and not
try to pump it yourself. With MCAS, the first pilots didn't even know
it was there. But the second ones did and they knew of the previous
crash and it still turned out the same. Doesn't leave me with a lot
of confidence in pilots, at least foreign ones in dubious countries.
 
On Monday, May 6, 2019 at 1:26:56 PM UTC-4, Lasse Langwadt Christensen wrote:
mandag den 6. maj 2019 kl. 10.12.17 UTC+2 skrev DecadentLinux...@decadence.org:
omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance
the airplane the same way as in the two crashes. Do you want to
fly a plane that only software is used to prevent stalling?
Without software it stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.


and before that there's a stick shaker and the stick pusher


The biggest issue to me is that there was no release switch to return
pilot control.

there is, two switches to turn off electric trim and the pilots are supposed
to know how to handle run away trim by memory

+1

And we had at least 4 out of 7 pilots who couldn't, which is stunning.

two on LA flight the previous day
two on the LA crash

The one who definitely got it right was the LA jump seat pilot

The pilot on Ethiopia we really don't know

The co-pilot on Ethiopia with 200 hours correctly identified it and was following
the procedure, but the trim may have been too nose down and the plane
going so fast that he couldn't wind it back manually. It would have
been much better to use the trim buttons to get it near neutral to
up somewhat and only then turn it off and go manual. And it looks
like that might have been what he or the pilot decided to do, because
someone turned it back on. But MCAS then shoved it down again. Did
anyone have their finger on the trim up? Has anyone tested this in
a plane or simulator?
 
On Monday, May 6, 2019 at 1:10:10 PM UTC-4, Lasse Langwadt Christensen wrote:
mandag den 6. maj 2019 kl. 16.36.21 UTC+2 skrev Joe Chisolm:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.

The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation. There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on. It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS). The aircraft
was already red-line in speed.


yes it does seem strange what the pilots did, but they might have had a
reason for it, I guess we will learn eventually

I saw a 737 pilot show in a simulator that it is possible at high speed
to get so much nose down trim that is near impossible to move the trim nose
up because of the aero dynamic forces, the solution is to dive while trimming but with no altitude to spare that's not an option

In the case of the Ethiopian crash, the solution would have been to turn the
electric trim back on, while holding the trim up button in. It looks like
in the seconds before the crash, they did turn it back on and MCAS pushed nose
down again. No evidence if they were pushing the trim up button at the time.
Or what happens if the pilots are commanding trim up while MCAS is doing
trim down, ie who wins or if nothing happens. The even better procedure
would have been to use the up trim button to first get the trim back to
near neutral and only then turn off the trim switches.

Interesting that it's so difficult to manually trim with full trim and speed.
It also apparently takes some time winding the wheel, it's many turns.
I watched a video of it being done in a simulator. One pilot spent most
of his time adjusting the trim, as needed, while they did a return and
landed. Also interesting, with the LA flight the day before the crash,
when they had the same problem and the jump seat pilot had to tell the
actual pilots what to do, they then continued on to their destination,
using manual trim. Must be different standards over there, in
the US the plane would have returned to the airport, for a variety of
reasons, including that you're not sure what exactly is wrong or going on.
 
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

afaiu and heard from pilots who fly the things all aircrafts with
under wing engines including the 737 NG will pitch up with power
the pitch up is just stronger with the 737 MAX

Every aircraft I have flown and owned changes pitch with power and flaps. You
simply know it's going to happen and expect it and make the necessary trim
corrections automatically. That's what the trim control switch on the yolk is
for.

There is no need for an automatic trim system like MCAS, especially when it
is undocumented.
 
On 5/6/19 2:55 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 2:23:06 PM UTC-4, Tom Gardner wrote:
On 06/05/19 19:15, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 1:05:00 PM UTC-4, bitrex wrote:
On 5/6/19 12:30 PM, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.



I think a "safety" system that is designed to bring the system it's
managing the safety of, out of an error state, via some other action
which in a different circumstance is also an error state and a safety
risk too, has to be able to determine, with high accuracy, whether it's
the overall system or itself that is in an error state.

If I'm understanding what I've read correctly (and I accept that I do
not, I'm not an aviation engineer but it doesn't seem to stop anyone
else from offering their commentary so...) the system relied on one AOA
sensor to determine the overall state of the aircraft with respect to
what action it needed to take.

but I think there's a fundamental information theory problem there in
that with one sensor it doesn't have enough information to determine
conclusively whether it's the overall system or itself that is the one
in error. As long as everything works fine it works fine, but when it
doesn't the system can no longer "reason" conclusively about anything
anymore it's like the thought experiment of sitting in the train next to
another train and figuring out which of you is the one moving.

And it sounds like the patch is to provide more indirect information
from e.g. the airspeed and altimeter but as they don't actually measure
the true parameter of interest it would seem to fall under the category
of "heuristics" or "hacks."

If you know the plane if flying at 300 MPH and is in a level or close
to level attitude, has been that way for X seconds, you can definitively
rule out a stall. And more fundamentally, to address your concerns,
MCAS will now use BOTH AOA sensors and if they disagree, take no action.

What aircraft are (or have you been) qualified to fly?

Have you come across the concept and practice of "mushing"? As in...
https://aviation.stackexchange.com/questions/26932/what-is-a-mushing-glide
Been there, done that.

BTW, Wolfgang Langewiesche's "Stick and Rudder; An Explanation of
the Art of Flying" is /well/ worth reading several times.

Mushing has nothing to do with what I stated. Explain to us how a 737
that's been going 300 MPH in level flight for 30 seconds can be stalling.
It can't.

So they're gonna let a digital integrator and the system clock make the
final call on whether to pitch the fuckin' plane's nose down? Sweet baby
Jesus!
 
On Monday, May 6, 2019 at 2:23:06 PM UTC-4, Tom Gardner wrote:
On 06/05/19 19:15, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 1:05:00 PM UTC-4, bitrex wrote:
On 5/6/19 12:30 PM, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.



I think a "safety" system that is designed to bring the system it's
managing the safety of, out of an error state, via some other action
which in a different circumstance is also an error state and a safety
risk too, has to be able to determine, with high accuracy, whether it's
the overall system or itself that is in an error state.

If I'm understanding what I've read correctly (and I accept that I do
not, I'm not an aviation engineer but it doesn't seem to stop anyone
else from offering their commentary so...) the system relied on one AOA
sensor to determine the overall state of the aircraft with respect to
what action it needed to take.

but I think there's a fundamental information theory problem there in
that with one sensor it doesn't have enough information to determine
conclusively whether it's the overall system or itself that is the one
in error. As long as everything works fine it works fine, but when it
doesn't the system can no longer "reason" conclusively about anything
anymore it's like the thought experiment of sitting in the train next to
another train and figuring out which of you is the one moving.

And it sounds like the patch is to provide more indirect information
from e.g. the airspeed and altimeter but as they don't actually measure
the true parameter of interest it would seem to fall under the category
of "heuristics" or "hacks."

If you know the plane if flying at 300 MPH and is in a level or close
to level attitude, has been that way for X seconds, you can definitively
rule out a stall. And more fundamentally, to address your concerns,
MCAS will now use BOTH AOA sensors and if they disagree, take no action.

What aircraft are (or have you been) qualified to fly?

Have you come across the concept and practice of "mushing"? As in...
https://aviation.stackexchange.com/questions/26932/what-is-a-mushing-glide
Been there, done that.

BTW, Wolfgang Langewiesche's "Stick and Rudder; An Explanation of
the Art of Flying" is /well/ worth reading several times.

Mushing has nothing to do with what I stated. Explain to us how a 737
that's been going 300 MPH in level flight for 30 seconds can be stalling.
It can't.
 
On 5/6/19 2:51 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 2:46:40 PM UTC-4, bitrex wrote:
On 5/6/19 2:05 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 12:16:51 PM UTC-4, bitrex wrote:
On 5/6/19 12:09 PM, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

   The software was for IF the plane stalled, which it did not.  It was
a sensor error.

   It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

   A stalling plane is pilot error, not airplane error.

   The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation.  There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on.  It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS).  The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

That is to say it also starts to look kinda bad if it begins to seem
like what they're saying in every case of an overseas crash is
"(shithole country) operator error" when most of your sales of a
particular product are to said shithole countries because most domestic
carriers said "no thanks" to the product.


Show us where Boeing ever said anything you claim above.

Bro you act like you're brand new and don't know how huge corps like
Boeing operate. Here's my citation. I use my brain to think of whatever
slimy, underhanded way the 60 and 70-something sociopathic baby-boomer
executives of the company could come up with to shirk liability and
prevent any risk of damage to the company's profits or share prices.



Thank you for the admission that you just made up your accusations.

They're not accusations they didn't do any such thing, or at least
aren't right now. Can't, not with two crashes with what look like
similar root causes.

If it had just been one in Africa we likely wouldn't be here having this
pleasant discussion.
 
On Monday, May 6, 2019 at 2:46:40 PM UTC-4, bitrex wrote:
On 5/6/19 2:05 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 12:16:51 PM UTC-4, bitrex wrote:
On 5/6/19 12:09 PM, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

   The software was for IF the plane stalled, which it did not.  It was
a sensor error.

   It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

   A stalling plane is pilot error, not airplane error.

   The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation.  There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on.  It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS).  The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

That is to say it also starts to look kinda bad if it begins to seem
like what they're saying in every case of an overseas crash is
"(shithole country) operator error" when most of your sales of a
particular product are to said shithole countries because most domestic
carriers said "no thanks" to the product.


Show us where Boeing ever said anything you claim above.

Bro you act like you're brand new and don't know how huge corps like
Boeing operate. Here's my citation. I use my brain to think of whatever
slimy, underhanded way the 60 and 70-something sociopathic baby-boomer
executives of the company could come up with to shirk liability and
prevent any risk of damage to the company's profits or share prices.

Thank you for the admission that you just made up your accusations.
 
On Monday, May 6, 2019 at 1:25:49 PM UTC-4, jrwal...@gmail.com wrote:
On Monday, 6 May 2019 17:22:19 UTC+1, tra...@optonline.net wrote:

Or is it expected to be part of some
flight initialization software, that checks all kind of things on
start up? If there was any checking, nothing notified the pilots that
the AOA was reading 30 deg while on the ground.

The AOA sensors were both operating correctly on the ground and
during take-off. They both developed faults (to differing degrees)
after take-off. This is according to the preliminary accident
investigation report - which I have read.

John

IDK which flights you are talking about, but in the case of the Lion Air
crash, the one AOA, which MCAS relied on, was reading incorrectly on
the ground, it was reading 20 deg, while they were taxiing out. You
can see it on the graph from the FDR.

https://www.seattletimes.com/business/boeing-aerospace/black-box-data-reveals-lion-air-pilots-struggle-against-boeings-737-max-flight-control-system/


Which is why people have been critical that the Boeing software did not
check for normal/abnormal AOA on the ground.
 
On 5/6/19 2:05 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 12:16:51 PM UTC-4, bitrex wrote:
On 5/6/19 12:09 PM, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

   The software was for IF the plane stalled, which it did not.  It was
a sensor error.

   It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

   A stalling plane is pilot error, not airplane error.

   The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation.  There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on.  It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS).  The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

That is to say it also starts to look kinda bad if it begins to seem
like what they're saying in every case of an overseas crash is
"(shithole country) operator error" when most of your sales of a
particular product are to said shithole countries because most domestic
carriers said "no thanks" to the product.


Show us where Boeing ever said anything you claim above.

Bro you act like you're brand new and don't know how huge corps like
Boeing operate. Here's my citation. I use my brain to think of whatever
slimy, underhanded way the 60 and 70-something sociopathic baby-boomer
executives of the company could come up with to shirk liability and
prevent any risk of damage to the company's profits or share prices.

If what seems most apropos and expedient would seem to be covering up a
software fault and instead blaming the filthy African pilots via a
concocted PR story they believe much of the American public will accept
due to that public's intrinsic racial bias then that's what they'll plan
to do. 99% probability.

And US carriers
fly more 737Max than any other country. Southwest has 31, American 22,
United 14 and combined they have another 450 on order. There are probably
more there too, registered to leasing companies.

Their margin on this one ain't gonna be made by selling just to the
what, three or so, domestic major carriers left.
 
On Monday, May 6, 2019 at 10:44:25 AM UTC-4, gnuarm.de...@gmail.com wrote:
On Monday, May 6, 2019 at 5:00:14 AM UTC-4, Sylvia Else wrote:
On 6/05/2019 1:25 pm, omnilobe@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily. Software cannot fix that
weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it stalls.
With software it is low cost.
Nikki Haley is a Trump liar. Do not fly Trump-Boeing death traps. Don doesn't.

The Board at Boeing is packed with dunces and insurance agents who know nothing
about Weights and Balances of aircraft.


The effect of the software behaviour, as was, was to trim the aircraft
forward for no good reason.

The pilots should have treated it as a runaway trim, and acted
accordingly. Then the crashes would not have occurred.

I have not seen anything clear or athoritative, but it appears the situation is not so simple to diagnose as was initially indicated. When you have a cockpit full of instruments and controls and "something" is wrong and the plane is behaving very erratically, it seems not so simple to do the right thing and know that it was right in the face of the airplane continuing to fly improperly.

It is simple. The trim wheels are spinning right next to your leg.
Something is pushing it way nose down. You push it back up with the
trim button. Five seconds later, *something* is pushing it back down
again. How hard is it to identify that as a problem with the electric
trim? That the plane can;t fly with full nose down trim, but it flies
every other day with small trim? Hello? It doesn't matter what is
causing the electric trim motor to turn and do something abnormal.
It could be a stuck switch, a short, it doesn't matter that it was MCAS.
And the procedure is to turn
it off using the switches right above the trim wheels and then trim manually.
We know it works, because that's what the pilots on LA did the day before.
This is very, very basic flight principles and training that is supposed
to be committed to memory, precisely because in an emergency, with runaway
trim, you have to do the right thing and do it quickly.




It seems likely that Boeing expected that that would happen in the event
that this non-redundant computer system misbehaved.

Yet in both cases the pilots let the aircraft get itself seriously out
of trim. So much so, that in the case of the second crash, when the the
pilots did eventually disable the electric trim, the aircraft was so far
out of trim that the pilots were not strong enough to turn the trim
wheels (or they didn't try - it's rather unclear at the moment).

There is the main point. It is too early to be making judgements.

I agree it's too early to make final judgments, but there is plenty out
there already to make some judgments, including that the pilots bear
some of the blame. It's similar to most of these, which is why crashes
are so rare. It's rarely just one thing, it's a whole series of things
that have to go wrong for it to result in a crash, all of them low
probability. Speaking of probabilities, I'm still mystified as to why
there has been nothing about the root cause of the incorrect AOA reading.
You'd think they would have said, we think it was a manufacturing defect,
incorrect installation, damage to it, etc. And then some kind of order
to inspect, replace, etc. But so far, nothing that I've heard. Which
makes me wonder, are they sure it's the AOA and not something else,
eg software bug?



> I like that some consider the problem to be software failures that could have been prevented by using pilots to write code. lol

That makes no sense to me. We'd never get software for many of the
complex systems out there if one had to actually be a user of one to
write the code. Space rocket code, you have to be an astronaut?
Code for a nuclear sub, you have to be a nuke reactor operator or sub captain?







Serious questions need to be asked about the competence of the pilots.
Would a properly trained crew have had any difficulties, even in the
absence of details about MCAS? I rather think not.

Serious questions need to be asked about the process that allowed this system go so wrong that so many people died in two accidents. This investigation should be no less rigorous than the investigation into the Challenger accident.

--

Rick C.

-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Sadly with the Ethiopians and Indonesians driving it and controlling it,
that probably isn't going to happen.
 
On Monday, May 6, 2019 at 3:04:19 PM UTC-4, Steve Wilson wrote:
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

afaiu and heard from pilots who fly the things all aircrafts with
under wing engines including the 737 NG will pitch up with power
the pitch up is just stronger with the 737 MAX

Every aircraft I have flown and owned changes pitch with power and flaps. You
simply know it's going to happen and expect it and make the necessary trim
corrections automatically. That's what the trim control switch on the yolk is
for.

There is no need for an automatic trim system like MCAS, especially when it
is undocumented.

There apparently can be if you want to get the plane CERTIFIED to fly
under the same type rating, which was a prime objective. Would FAA
certify it if it knew that at high AOA it behaves differently and
differently not in a good way?
 

Welcome to EDABoard.com

Sponsor

Back
Top