737 Max

torsdag den 4. april 2019 kl. 02.07.47 UTC+2 skrev snipped-for-privacy@gmail.com:

te:

gh?

icated.

e result of a bird strike (or some other foreign object). It seems to me th is is even more troubling for Boeing because in this instance I don't think the disagreement light strategy would have helped. I am thinking that the disagreement light strategy helps on the ground prior to takeoff. If the disabling of the AOA sensor coincides with the plane going bonkers I am not seeing how the disagreement light helps.

ht

ng

hey

tware

s the

hile

it would just show whatever position it was last in. Without a fast air st ream to move it, it just sits there. So the AoA would likely not be valid until at least the plane is moving at some speed.

e incidents was a wash on the ground that should have been done with the Ao A covered. Water got into the AoA that froze once the plane ascended. Tha t would not show up on the ground. Was that the Lion Air flight?

The aircraft's computers received conflicting information from the three an gle of attack sensors. The aircraft computer system?s programming l ogic had been designed to reject one sensor value if it deviated significan tly from the other two sensor values. In this specific case, this programmi ng logic led to the rejection of the correct value from the one operative a ngle of attack sensor, and to the acceptance of the two consistent, but wro ng, values from the two inoperative angle of attack sensors

ese incidents was a wash on the ground that should have been done with the AoA covered. Water got into the AoA that froze once the plane ascended. T hat would not show up on the ground. Was that the Lion Air flight?

angle of attack sensors. The aircraft computer system?s programming logic had been designed to reject one sensor value if it deviated signific antly from the other two sensor values. In this specific case, this program ming logic led to the rejection of the correct value from the one operative angle of attack sensor, and to the acceptance of the two consistent, but w rong, values from the two inoperative angle of attack sensors

That's the one I was thinking of where washing it with the AoA sensor uncov ered resulted in the defect. Wow, two bad AoA indicators. That's hard to deal with. Thanks.

A point to note is that the problems with this flight were compounded by pi lot actions making the issues unrecoverable.

Seeing this sort of thing makes me wonder what will happen as we adopt auto nomous autos. Will there become some base accident rate we can't get below , that we will accept simply because it is better than the rate we have wit h human drivers. Will the resulting law treat all accidents as no-fault th en or will the auto makers and maintenance companies become responsible wit h some manner of a set schedule of payouts eliminating the complications of legal system trials?

snipped-for-privacy@gmail.com wrote in news: snipped-for-privacy@googlegroups.com:

It would have to have been frozen from a previous flight because they were not at altitude long enough for it to freeze that quick.

Sounds like a faulty design if a simple pressure wash invades it.

One thing that puzzles me is that the MCAS problem only starts when they retract the flaps to normal flight configuration and MCAS activates.

Why wasn't the SOP if an obviously bogus stall warning and nose down gets issued at that point to add flaps again and increase engine power (which would automatically take MCAS out of the control loop).

The manual override SOP on the face of it would appear to be too slow when the planes automatic "safety" systems have decided to crash it shortly after takeoff. There is just not enough time or space.

After the first minute MCAS will already have the jackscrew wrapped round its endstop. It is a long way back using the manual trim wheels.

A problem made worse for the Ethiopian guys because they were already starting at 2300m altitude in thin air and surrounded by mountains. Lion Air at least had the benefit of denser sea level air and no obstacles.

This is one of the more interesting recent summaries :

It didn't last long - they soon had to delay it after reviews:

While I was typing this the very latest news is in - preliminary report. The black box shows poor unfortunate Ethiopian pilots followed Boeing's recommended MCAS failure recovery procedure and it *didn't* work.

and

And yet Boeing had dozens of pilots at their facility showing them their new improved software ready to go....just chomping on the bit to get those babies back up in the air.

d-after-review

new improved software ready to go....just chomping on the bit to get those babies back up in the air.

The crash analysis team has stated that the pilots of the plane ( those sam e pilots who many here have disparaged) followed the MCAS disable procedure s that Boeing provided and could not regain control of the aircraft. It se ams to me that no further work on a fix can be done until a complete unders tanding is obtained on why those procedures did not work. I do not see how Boeing can get approval for a "fix" without first answering this fundament al question which could take several months to figure out.

eport/index.html

I raised that point previously too. Since the trouble started just as the flaps were retracted, if they couldn't figure out what to do, what was going on, one logical thing to try would be to just put the flaps back out.

But not using the trim buttons and it doesn't appear that MCAS can get it to max trim if the pilots keep re-trimming. The LA flight that went on for about 10 mins while they did trim it shows that worked.

The reports I saw say they initially followed it, but then turned the electric trim back on. The Ethiopians, as usual, won't release the CVR audio so that we'd know what they pilots were saying as they tried to work through it. We do know that turning off the electric trim and trimming manually worked on the LA flight the day before. One question would be if the trim goes to full, was it possible to use the trim wheels manually to bring it back or is it possible it takes more force than they could apply? The most logical process would be to use the trim buttons to get it back to near neutral and then turn it off and trim manually.

Boeing also said the software is now being delayed again because of new issues raised in an independent review by those not involved inside Boeing. I wonder if that is the full story or if this new revelation from Ethiopia has something to do with it.

On Thursday, April 4, 2019 at 6:29:08 AM UTC-4, snipped-for-privacy@columbus.rr.com wrot e:

ote:

hey

ion

yed-after-review

rt.

's

r new improved software ready to go....just chomping on the bit to get thos e babies back up in the air.

ame pilots who many here have disparaged) followed the MCAS disable procedu res that Boeing provided and could not regain control of the aircraft. It seams to me that no further work on a fix can be done until a complete unde rstanding is obtained on why those procedures did not work. I do not see h ow Boeing can get approval for a "fix" without first answering this fundame ntal question which could take several months to figure out.

-report/index.html

Here's a continuing, major problem with both of the crashes:

However, experts have criticized the detail contained in the initial findin gs. "The paucity in this report is appalling," said CNN aviation analyst Alasta ir Rosenschein. "I've never seen so little information in a report."

With both crashes the countries civil aviation authorities have been very slow to put out the very basic information that should have been out long ago, eg CVR audio and flight data. The Ethiopians are being coy, saying that the crew followed the procedure, but also saying that the crew then turned the electric trim back on. Where is the audio? If we heard what they were discussing, it would shed light on what was really going on, eg where they trying to move the trim wheels, but they would not move? Or did they turn the electric trim back on for another reason, eg they realized it would take too long to trim by hand, so they wanted to use the trim buttons again to get it back to neutral? If the latter, it's possible they were doing things right, but just ran out of time. Would be interesting to see what happens in a simulator if you run trim all the way to nose down at that altitude and how much time and margin there is to recover.

Any safety critical system that accepts a single input at face value and fails to do basic sanity checks is not fit for purpose. *END OF STORY*

The accident report summary has just been made public. The pilots followed Boeing's recommended procedures for MCAS system fail and the plane still dropped out of the sky before they could regain control.

Time to stick two of Boeing's best test pilots in one at 30000 feet and provoke the MCAS nose down AoA sensor fault under controlled test conditions. Better equip them with parachutes too just in case.

I wouldn't trust the simulator to get something like this right.

It's premature to reach the conclusion that the pilots correctly followed the procedure. The Ethiopians are being coy, won't release most of the information, including the CVR audio. They said that the pillots followed the procedure, but then turned the electric trim back on. That last part is at complete odds with the correct procedure and we don't know why they elected to turn it back on. If the Ethiopians released the relevant data, maybe we would know. For that matter, Indonesian authorities still have not released the CVR from their crash back in October, which borders on criminal irresponsibility. These planes were flying for months, without benefit of knowing what went on in the cockpit on that flight.

Yes, this discussion has jumped the shark! The idea of strapping test pilots into a plane so we can study the failure mode is so absurd as to be not even worth discussing.

I wasn't going to reply further, but now I'm going to stop reading this thread.

It's a better idea than strapping 170 passengers into a plane and doing the same test! But naturally, we'd let Boeing make its software changes first. Relying on two sensors is good, but likely not quite enough, as we have a case where two out of three sensors failed. Limiting the MCAS corrections to a few tries, before letting the pilots have unimpeded full control might be good enough.

Here is a link to the complete Ethiopian preliminary crash report:

The Ethiopians say that the crew followed the procedure for runaway trim/MCAS, but from their own report, that isn't clear. It shows that they identified the trim problem, the first officer indicated they should disable the electric trim and the captain agreed. It was turned off and while MCAS tried to move the nose down after that, it had no effect. After that they continue to fight with the plane, the captain asks the co-pilot if trim is working and he says no and asks if he should use manual. (that's bizarre, as all there is at that point is manual trim, so what did they think they were doing?) A few secs later the co-pilot says that it's not working. Sometime after that someone put the electric trim back on and 5 secs later MCAS shoved the nose down again, 30 secs later, it crashed.

Not answered is what the co-pilot meant by the trim wasn't working when he tried manual trim? Was he trying to move the trim wheel and it would not move? Or was he confused and really trying to use the buttons? And who turned the electric back on, without apparently any discussion? You would think these aircraft would have video recording too by now. That would help show who was doing what.

Also in that report are prior trouble reports logged, there are several prior incidents where pilots reported the plane rolling unexpectedly, strange altitude and other indicators in the cockpit that appeared briefly, etc. Another thing that would not seem to make sense is that if it's just an AOA/MCAS thing, why did the pilots airspeed differ significantly from the co-pilots for much of the flight? Leading one to wonder if the MCAS thing is all that's wrong here. the plane.

Tell me again who the idiot is?

Do you still stand by this comment?

snipped-for-privacy@columbus.rr.com wrote in news: snipped-for-privacy@googlegroups.com:

That would be you. For reiterating more stupid posts in Usenet. Was your stupid response even needed? You need to be vetted, or it is OUT for you, boy.