Originally Posted by WingNut60 (Post 10434040)

My query asks "is it possible to open the AoA vane unit body in the field."
If the answer is Yes, then don't discount the possibility that it could happen, overnight in Jakarta.
It is very possible.

Originally Posted by DaveReidUK (Post 10434051)

"Captain, would you mind testing our unauthorised, undocumented repair to the LH AoA sensor on the next sector?"

"No, we don't have an Overhaul Manual for it - it's not a field-serviceable item - but, hey, how hard can it be?"

"You might find that it reads a bit high (or possibly low) afterwards as we have no idea how to calibrate it, but we can tweak it again if necessary until it's reasonably accurate"

No, I don't think so.

Originally Posted by DaveReidUK (Post 10434051)

No, I don't think so.

Originally Posted by marchino61 (Post 10434073)

Dave Reid, not possible in the UK. But we are talking Indonesia here.

Originally Posted by marchino61 (Post 10434073)

Dave Reid, not possible in the UK. But we are talking Indonesia here.

Originally Posted by ecto1 (Post 10434103)

...............

It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
............

To me the only two explanations that so far match (loosely) are:

- a slipping shaft that slips with the bumps but sticks with aero forces (but two sensors in a row, I don't think so)
- a intermittent electrical connection outside of the probe somewhere in a encoder-like signal which is disturbed by the bumps of taxi and creates an offset. Perhaps at the control module or power to the probe.

I don't think any of them is very probable, though. There must be a better explanation. Although bit corruption or software bug doesn't fit any better to me.

Originally Posted by DaveReidUK (Post 10434113)

If the "replaced" AoA sensor at Denpasar had in fact been the same one that was removed, following an illicit repair, then by definition there would not be a U/S sensor on its way back to the manufacturer, nor any paperwork to show that a serviceable one had been drawn from stores.

Don't you think that the investigation would have established that at an early stage ? In fact, the report states the exact opposite.

Originally Posted by WingNut60 (Post 10434125)

The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Originally Posted by WingNut60 (Post 10434125)

The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.

Originally Posted by WingNut60 (Post 10434125)

The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.

FYI - "Cleaning a connector...." is a really dangerous euphemism in Indonesia.

Originally Posted by Water pilot (Post 10433865)

With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.

Originally Posted by Torquelink (Post 10433243)

From Bjorn Fehrm of Leeham today:

This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.

https://leehamnews.com/wp-content/up...isagree_lg.jpg

Figure 1. The improved Pilot’s Primary Flight Display presented Wednesday. Source: Boeing.

Boeing’s MCAS fix casts light on the original implementation

Boeing presented its fix for the MCAS problems Wednesday. By it, it spotlights what was wrong with the original implementation.

The reliance on a single triggering signal for MCAS

A lot has been written about the MCAS system relying on a single Angle of Attack input. This is unusual for systems involved in the flight control of aircraft. Normally you have three inputs so a voting procedure can sort out one of them if it has a problem (two singling out the third as faulty).

The 737 has only two Angle of Attack sensors, so no voting can be set up between them. Instead, the system relying on the sensors can be switched off if the sensors disagree and the pilot informed about the missing function.

This is the route chosen for the improved MCAS. It will now be disconnected when the sensed Angle of Attack difference is beyond 5.5 degrees when MCAS activates and over 10 degrees for over 10s when the system is in use.

The wide allowed difference shows what I have written about before. The aerodynamics around these sensor vanes, placed at the nose sides, is dependent on how the aircraft is flown. If there is a sideslip the airflow passing the sensors will be affected and the sensor values will differ.

The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.

Was the use of only one signal OK to trigger the original MCAS? No, it wasn’t. But at least there was a rationale for this decision, whatever one might think about the rationale. A deactivation of MCAS was not an acceptable solution as it would trigger a need for an MCAS not available signal and this would mean more difference training for the Pilots migrating from 737ng to MAX.

The design of the original MCAS function

While the reliance on a single sensor is highly questionable, the architecture and implementation of the original MCAS function in inexcusable.

If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!

You make sure it only injects the minimum correction necessary and you limit its total authority to not jeopardize the safe flight of the aircraft.

Where others focus on a single trigger signal, my biggest problem is with the function itself. If you have a weak trigger architecture, you limit the authority of what you trigger!

There was no need for the authority MCAS got. We know this today as the software fix only trims once for each elevated Angle of Attack event and limits the total trim amount to a safe level. This is regardless of the sensors being wrong or the function running wild.

It was just a very, very bad function design, and there was no need for it.

Designed to not show, it became the centerpiece of attention

MCAS was a function put there to cater for a very remote case. The pilot needs to maneuver close to the limits of the aircraft and way beyond normal flying practice, to save the aircraft from some emergency. Then MCAS kicked in to make the aircraft easy to fly close to its limits.

In the life of a commercial 737 MAX pilot he should never experience an MCAS augmentation, its use case was so remote. Instead, it became the most known and explained function of all on the 737 MAX. And for the wrong, very sad reasons.

There are only a few airliner OEMs in the world. There is a reason for this. It’s a challenging product to get right and the stakes are very high for any mistakes. In today’s very safe air transport system mistakes of this scale are non-acceptable.

Originally Posted by WingNut60 (Post 10434125)

The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.

FYI - "Cleaning a connector...." is a really dangerous euphemism in Indonesia.

Originally Posted by Water pilot (Post 10433865)

With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.

Originally Posted by patplan (Post 10434159)

AOA was not touched in Jakarta, as MX suspected problem(s) laid elsewhere in the system. He fixed other things as mentioned by the CAPT of JT043: "IAS disagree & ALT disagree and Feel Diff Press Light".

Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.

Originally Posted by patplan (Post 10434174)

Something of interest perhaps...
By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZA
Sunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.

The Canadian TSB reported the left ADIRU was replaced.

I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.

- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures