osiris30 wrote:

flybucky wrote:

I wasn't satisfied with the FR24 charts I had seen because:
1. the x-axis was by data point and not true time interval
2. most of them put several data series that had vastly different number ranges on the same chart, which reduced the "resolution" of the y-axis.

So I made a chart that used true time intervals on the x-axis (seconds elapsed since airborne). This makes it easier to look for time interval patterns. Also, I plotted the Pressure Altitude relative to 7200 ft (which is the first Pressure Altitude reported after airborne). That fits it on the chart better and also gives a good approximation for altitude gained since takeoff. Finally, I used a secondary y-axis for ground speed so you can see the resolution better.

Some observations I had:

• Vertical speed already dropped between 7-10 seconds after airborne, and did not recover until the 20-25 second mark.
• Ground speed increased very steadily, which seems to indicate no engine problems? (Ground Speed should be accurate even if the airspeed sensors on the plane were unreliable, since the Ground Speed is based on GPS).
• I looked for 10 second Vertical Speed decrease intervals. It does look like there could be some at 51-61s, 72-82s, 91-101s. But the Vertical Speed decreases started before 51s. And there were also additional decrease intervals afterwards that were not 10 seconds.

Something was VERY wrong on this flight. IF the FR data is right they rotated at 89kts... Based on what I see in the data they basically took off stalling.

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude.

If this was the case, it is possible that MCAS had nothing to do with the accident, and it was simply unreliable airspeed/pilot error. An airspeed discrepancy during the takeoff roll would in my opinion justify an aborted takeoff. That is why there are “cross check” calls at either 80 or 100 kts between CA and FO airspeed indications.

The FR24 data may very well be inaccurate and they rotated at the correct speed. Still, how would MCAS operate with flaps down? Perhaps a faulty airspeed indicator triggered the MCAS somehow. Is it only the AOA sensor or does MCAS monitor airspeed as well?

osiris30 wrote:

7BOEING7 wrote:

ytz wrote:

I keep going back to those NASA safety reports. Autothrottles not responding. Uncommanded pitch with autopilot. I think there's more to this than MCAS. I suspect some kind of sensor issue or some gremlins in their automation.

I’m guessing these reports are due to poor piloting and lack of system knowledge. After takeoff when you go to engage the autopilot if you’re a little lazy flying the flight director it won’t be a smooth transition as the autopilot seeks the correct flight path.

It might be a bit early to say that. Also, those reports might mean nothing. Too early to say without even seeing the reports ourselves and just vague media references... we all know how often the media gets it right! (never > media getting it right > 0 times in history)

The reporting captain says he/she engaged AP earlier than usual (flaps 0 vs 10000 ft) to preemtively mitigate any possible MCAS problem. If he/she was doing something novel for them personally that could explain why it wasn't 100% smooth.

Having now read the aircrew reports that are cited in the news... I am not seeing much of a pattern. https://www.documentcloud.org/documents ... -max8.html

1. AT system didn't respond as pilot expected - no clear reason why. Pilot was on 2nd flight of MAX and may have made incorrect setting by their own admission.
2. No incident, just someone opining on the lack of some MCAS details missing from manual and seemingly disgruntled about MAX implementation.
3. AP leveled off at 34,000 instead of 36,000 during climb - not clear why as FO seems to indicate correct altitude was entered.
4. AP Pitched down and entered descent during climbout and Flaps retraction, shortly after AP engaged, approx 2,000MSL THIS ONE IS WEIRD. MCAS should be inactive during AP from what we have seen.
5. This is almost certainly the same incident as #4, from other Pilot's perspective. Was a strong crosswind situation also.


From my perspective... there's not the (5) incidents as reported... there's 3 + one pilot giving his 2 cents to the database without any incident to speak of. I am sorry but this all seems like background noise.

In 2019, given the urgency due to a grounded fleet how does it take more than a day to get the FDR somewhere capable of reading it?

Osiris30 wrote:

FR says their ground speed is calculated.. their blog that was posted with the data explained that Mandala (PS: How the heck have you been!)
Edit: Unless I misread their blog post, which is possible 2000+ posts ago.

Calculated yes, FR may calculate their groundspeed for the position displays and replays, but the groundspeed is sent by the ADS-B through the GPS unit's calculation, that capability is there, and the so called "granular data" FR has released, is unclear which groundspeed it is. I tend to go with the latter.
And yes, doing OK, surviving, with the media deluge... I thought I'd check in here once they mayhem reduces...

osiris30 wrote:

This is what I have been saying since the first FR data surfaced, but NO ONE has wanted to discuss it. They have all wanted to talk about MCAS. MCAS may have contributed but it was NOT the root cause.

I was aware of thatb ecause some people on the beginning mentioned that FR data was displaying that the max was airborne at 93kts.

BUT, and here comes the problem: It is very difficult to keep that in mind when this thread got bombared by MCAS fearmongering and grounding requests.

mandala499 wrote:

Osiris30 wrote:

FR says their ground speed is calculated.. their blog that was posted with the data explained that Mandala (PS: How the heck have you been!)
Edit: Unless I misread their blog post, which is possible 2000+ posts ago.

Calculated yes, FR may calculate their groundspeed for the position displays and replays, but the groundspeed is sent by the ADS-B through the GPS unit's calculation, that capability is there, and the so called "granular data" FR has released, is unclear which groundspeed it is. I tend to go with the latter.
And yes, doing OK, surviving, with the media deluge... I thought I'd check in here once they mayhem reduces...

Well regardless it is GPS derived ground speed so not subject to a faulty air speed sensor. And easy enough to cross check based on lat long from the GPS if anyone is so inclined.

Regardless... Take off speed seems very very low. Your thoughts?

Finally:. Glad to hear you are doing well. I miss the old regulars about these parts, especially during these times.

osiris30 wrote:

Finn350 wrote:

osiris30 wrote:

And even that is far from foolproof. You could have 100 and still have weird corner case failures. Not that I am defending a single point of failure system but one thing that people do have to remember is it's not just the cost of the part. It is all the maintenance that comes with adding even more parts. You could put 50 aoa sensors on an aircraft and have an amazing chance of always having good AoA readings, but you'd have to maintain all 50, which would be a nightmare and very costly. 2>1 at least you can see a discrepancy. 3>2 it allows a bit more trust in the system (but still has well-known failure cases that have ACTUALLY happened). 5>3 your odds improve, but you could get into a situation where you have 2+2+1 readings based on specific conditions I could see happen. Realistically you would need around 10 to get to a point where you could call it 5 9s.

I am quite sure that with 3 vanes we are already well above 5 9s (or failure in less than one in 100,000 flights).

Spent too much time doing 5-9s work, 3 is not 5-9s. This isn't a case where you need 1 system functional. You need a minimum of two functioning. 3 isn't even fully redundant for the minimum number of sensors needed. If one fails hard and one gives erroneous data you are screwed. I can conceive of many situations that would take out two sensors, and in fact we have records of such happening. There is no way from a qualification standpoint 3 sensors is 5-9s.

It is not just the number of sensors; it is also their failure rate. You can get 5 9s even with one sensor provided its failure rate is low enough (less than 1 / 100 000). Three sensors is of course fully redundant, as a single failure doesn't prevent the system providing correct information.

hivue wrote:

Finn350 wrote:

I know they have first made the order and then cooked up the basis, but what could be aircraft's configuration discovered from the wreckage that would be basis for the similarity?

If it was cooked up what do you care?

Good point. It is cooked up better if it is based on facts, though.

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

Indeed. The groundspeed are deemed to be "absolutely correct" subject to variations within GPS position errors... Past experience cross checking this with IRS Groundspeeds show that it is "good enough to use" pending FDR data.
Take off speeds are low, and yes I agree to your statement somewhat... while I think MCAS is likely to have a play in here, I think the root cause is elsewhere.
- Low take off speeds is very suspicious, I think we MAY be looking at Air-Ground switch issues...
- The ground speed where the aircraft's altitude did initially increase beyond runway undulations, makes sense, albeit on the fast side. Whether this is slow or adequate acceleration, I don't have time to have a deeper look into it as yet.
- The initial climb angle appears to be very shallow, with some unstable VSIs indicated, this may indicate crew was dealing with a stick shaker issue.
- The aircraft appeared to be levelling off at 800' AGL, this raised my eyebrow immediately. This is either a reaction to the stick shaker (and subsequent loss of altitude prior to climbout), or that they decided to clean up the flaps at that altitude (well, just look at the bloody groundspeed) and then MCAS played. Which of this? I don't know.
- The last point with the 2 alternatives, MAY point towards signs of confusion and/or poor CRM and/or poor crew training. However, I urge those reading this to NOT make conclusions based on this as they only form a small part of the picture.

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

Although I initially thought that this may have been something else like an engine failure gone wrong, the later climbout rate basically threw this out of the window. When looking at the granular data... yeah, my thoughts were, "oh no, not again!"

Finn350 wrote:

osiris30 wrote:

Finn350 wrote:

I am quite sure that with 3 vanes we are already well above 5 9s (or failure in less than one in 100,000 flights).

Spent too much time doing 5-9s work, 3 is not 5-9s. This isn't a case where you need 1 system functional. You need a minimum of two functioning. 3 isn't even fully redundant for the minimum number of sensors needed. If one fails hard and one gives erroneous data you are screwed. I can conceive of many situations that would take out two sensors, and in fact we have records of such happening. There is no way from a qualification standpoint 3 sensors is 5-9s.

It is not just the number of sensors; it is also their failure rate. You can get 5 9s even with one sensor provided its failure rate is low enough (less than 1 / 100 000). Three sensors is of course fully redundant, as a single failure doesn't prevent the system providing correct information.

3 sensors is not fully redundant if you need 2 sensors to be in agreement for the system to work. In that instance two is treated as one.

Also I would be curious the "correct rate" for these things (I don't want to say failure as we aren't talking about permanent failure here... A transient or temporary issue is failure for these purposes even if the part returns to normal function on its own)

mandala499 wrote:

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

Indeed. The groundspeed are deemed to be "absolutely correct" subject to variations within GPS position errors... Past experience cross checking this with IRS Groundspeeds show that it is "good enough to use" pending FDR data.
Take off speeds are low, and yes I agree to your statement somewhat... while I think MCAS is likely to have a play in here, I think the root cause is elsewhere.
- Low take off speeds is very suspicious, I think we MAY be looking at Air-Ground switch issues...
- The ground speed where the aircraft's altitude did initially increase beyond runway undulations, makes sense, albeit on the fast side. Whether this is slow or adequate acceleration, I don't have time to have a deeper look into it as yet.
- The initial climb angle appears to be very shallow, with some unstable VSIs indicated, this may indicate crew was dealing with a stick shaker issue.
- The aircraft appeared to be levelling off at 800' AGL, this raised my eyebrow immediately. This is either a reaction to the stick shaker (and subsequent loss of altitude prior to climbout), or that they decided to clean up the flaps at that altitude (well, just look at the bloody groundspeed) and then MCAS played. Which of this? I don't know.
- The last point with the 2 alternatives, MAY point towards signs of confusion and/or poor CRM and/or poor crew training. However, I urge those reading this to NOT make conclusions based on this as they only form a small part of the picture.

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

Although I initially thought that this may have been something else like an engine failure gone wrong, the later climbout rate basically threw this out of the window. When looking at the granular data... yeah, my thoughts were, "oh no, not again!"

I will be curious to see the CVR. I am curious if there was a strike of any sort. Damaged systems could behave very much like MCAS.

Assuming the ground switch triggered erroneously then the converse becomes true; the aircraft took off very late. If you discount the first few seconds as erroneous "in air" data then takeoff speed was high and kept going nuts from there.

The engines must have been firewalled the entire time for the FR data. 380kts GS at 800ft all, even when you start at 7600ft ground level is ... Well... You know this better than I do.

My guess is something failed and the crew got confused and made bad decisions. MCAS may have been involved but likely only worsened a VERY bad situation to begin with.

Have you been privy to data that extends beyond the FR24 data set yet?

If there is a congressional hearing (Rep. Dan Kildee currently requesting) into Boeing, FAA and these accidents and this plane, I think they should ask for evidence that the certified design that led to this mess was really a single sensor non redundant design. Then if that is the case, they should ask the FAA how they came to certify a plane with a new stall detection/prevention system that uses only one sensor and no redundancy.

mandala499 wrote:

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

Indeed. The groundspeed are deemed to be "absolutely correct" subject to variations within GPS position errors... Past experience cross checking this with IRS Groundspeeds show that it is "good enough to use" pending FDR data.
Take off speeds are low, and yes I agree to your statement somewhat... while I think MCAS is likely to have a play in here, I think the root cause is elsewhere.
- Low take off speeds is very suspicious, I think we MAY be looking at Air-Ground switch issues...
- The ground speed where the aircraft's altitude did initially increase beyond runway undulations, makes sense, albeit on the fast side. Whether this is slow or adequate acceleration, I don't have time to have a deeper look into it as yet.
- The initial climb angle appears to be very shallow, with some unstable VSIs indicated, this may indicate crew was dealing with a stick shaker issue.
- The aircraft appeared to be levelling off at 800' AGL, this raised my eyebrow immediately. This is either a reaction to the stick shaker (and subsequent loss of altitude prior to climbout), or that they decided to clean up the flaps at that altitude (well, just look at the bloody groundspeed) and then MCAS played. Which of this? I don't know.
- The last point with the 2 alternatives, MAY point towards signs of confusion and/or poor CRM and/or poor crew training. However, I urge those reading this to NOT make conclusions based on this as they only form a small part of the picture.

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

Although I initially thought that this may have been something else like an engine failure gone wrong, the later climbout rate basically threw this out of the window. When looking at the granular data... yeah, my thoughts were, "oh no, not again!"

If correct, these all are consistent with what you could expect in a take off with full flaps.
Low lift off speed, shallow climb rate, aircraft not climbing.

sgrow787 wrote:

If there is a congressional hearing (Rep. Dan Kildee currently requesting) into Boeing, FAA and these accidents and this plane, I think they should ask for evidence that the certified design that led to this mess was really a single sensor non redundant design. Then if that is the case, they should ask the FAA how they came to certify a plane with a new stall detection/prevention system that uses only one sensor and no redundancy.

It is. In fact the preexisting STS system is also single sensor based system. However the safety concept is to limit trim command output so that in case of failure, aircraft shall still be controllable.

MCAS requires no more than 2.5deg(one increment) to meet FAR25.203a. If MCAS output is limited to 2.5degree, it is safe.

It is the multiple increments part of the logic that screws the whole thing up and causes so much nose down trim that aircraft is uncontrollable

LDRA wrote:

sgrow787 wrote:

If there is a congressional hearing (Rep. Dan Kildee currently requesting) into Boeing, FAA and these accidents and this plane, I think they should ask for evidence that the certified design that led to this mess was really a single sensor non redundant design. Then if that is the case, they should ask the FAA how they came to certify a plane with a new stall detection/prevention system that uses only one sensor and no redundancy.

It is. In fact the preexisting STS system is also single sensor based system. However the safety concept is to limit trim command output so that in case of failure, aircraft shall still be controllable.

MCAS requires no more than 2.5deg(one increment) to meet FAR25.203a. If MCAS output is limited to 2.5degree, it is safe.

It is the multiple increments part of the logic that screws the whole thing up and causes so much nose down trim that aircraft is uncontrollable

I thought we had a consensus that there were two SMYDs in the previous 737 designs, each receiving ADIRU/AOA data and passing it onto the FCC. But I forget if we determined there were one or two FCCs in those planes. However, if there are two FCCs, and each only sees its onside AOA sensor, then yeah I can see where the 'system' is redundant in that there is a copilot equivalent to what the pilot has, but at the same time, a single sensor failure causes one of the FCCs to kick in MCAS, and so you have a single source of failure (MCAS kicks in, pilots panic, get confused, and fail to recognize the situation as runaway trim).

Question: If they look at the FDR, and they determine it's MCAS situation again, and it's apparent the pilots got confused like the Lion Air pilots did, do they just unground the planes? Or is it time to say technology can do better than this, and do a redundant 2 or 3 sensor design?

sgrow787 wrote:

LDRA wrote:

sgrow787 wrote:

If there is a congressional hearing (Rep. Dan Kildee currently requesting) into Boeing, FAA and these accidents and this plane, I think they should ask for evidence that the certified design that led to this mess was really a single sensor non redundant design. Then if that is the case, they should ask the FAA how they came to certify a plane with a new stall detection/prevention system that uses only one sensor and no redundancy.

It is. In fact the preexisting STS system is also single sensor based system. However the safety concept is to limit trim command output so that in case of failure, aircraft shall still be controllable.

MCAS requires no more than 2.5deg(one increment) to meet FAR25.203a. If MCAS output is limited to 2.5degree, it is safe.

It is the multiple increments part of the logic that screws the whole thing up and causes so much nose down trim that aircraft is uncontrollable

I thought we had a consensus that there were two SMYDs in the previous 737 designs, each receiving ADIRU/AOA data and passing it onto the FCC. But I forget if we determined there were one or two FCCs in those planes. However, if there are two FCCs, and each only sees its onside AOA sensor, then yeah I can see where the 'system' is redundant in that there is a copilot equivalent to what the pilot has, but at the same time, a single sensor failure causes one of the FCCs to kick in MCAS, and so you have a single source of failure (MCAS kicks in, pilots panic, get confused, and fail to recognize the situation as runaway trim).

Question: If they look at the FDR, and they determine it's MCAS situation again, and it's apparent the pilots got confused like the Lion Air pilots did, do they just unground the planes? Or is it time to say technology can do better than this, and do a redundant 2 or 3 sensor design?

The safety concept is that you can have your single point failure, but because ultimantely maximum magnitude of stab trim command coming out of STS or MCAS is limited to a certain value(e.g. 2.5 degrees) that wouldn't cause controllability problem. It is safe

Still so much focus on MCAS. While there is always a chance that MCAS may be involved on some way, if the flaps are extended, MCAS is designed to be disabled...which means that the sensors which trigger MCAS, are irrelevant in this case, as would be their potential failure modes.

If the flaps were down and MCAS somehow activated, that would mean that both the flaps extension MCAS lockout AND the default AOA vane must have failed, which is possible, but seems unlikely.

If the FR24 data is correct, the Ethiopian flight never reached flaps retraction altitude or airspeed, so it's unlikely, in my opinion, that MCAS would have been triggered.

So if not MCAS related...then what? Weather? Pilot error? Other mechanical problems? Bad fuel? Sabotage?

JoeCanuck wrote:

Still so much focus on MCAS. While there is always a chance that MCAS may be involved on some way, if the flaps are extended, MCAS is designed to be disabled...which means that the sensors which trigger MCAS, are irrelevant in this case, as would be their potential failure modes.

If the flaps were down and MCAS somehow activated, that would mean that both the flaps extension MCAS lockout AND the default AOA vane must have failed, which is possible, but seems unlikely.

If the FR24 data is correct, the Ethiopian flight never reached flaps retraction altitude or airspeed, so it's unlikely, in my opinion, that MCAS would have been triggered.

So if not MCAS related...then what? Weather? Pilot error? Other mechanical problems? Bad fuel? Sabotage?

If what you’re saying is accurate and is confirmed by investigators, this would bring us back to where we were before this crash in my mind, as this grounding seems predominantly based on the belief that MCAS is faulty.

Say that were the case and it was found that there was an act of sabotage, would the 7M8 program be able to regain the trust of regulators to rescind the grounding despite the outstanding Lion Air accident?

JoeCanuck wrote:

Still so much focus on MCAS. While there is always a chance that MCAS may be involved on some way, if the flaps are extended, MCAS is designed to be disabled...which means that the sensors which trigger MCAS, are irrelevant in this case, as would be their potential failure modes.

If the flaps were down and MCAS somehow activated, that would mean that both the flaps extension MCAS lockout AND the default AOA vane must have failed, which is possible, but seems unlikely.

If the FR24 data is correct, the Ethiopian flight never reached flaps retraction altitude or airspeed, so it's unlikely, in my opinion, that MCAS would have been triggered.

So if not MCAS related...then what? Weather? Pilot error? Other mechanical problems? Bad fuel? Sabotage?

FR24 data is 3 first minutes of the flight ADS-B data only. There exists satellite based ADS-B data for the whole flight (on which the FAA Emergency Order is based),but that has not been made publicly available.

https://aireon.com/services/global-air- ... veillance/

SuperTwin wrote:

JoeCanuck wrote:

Still so much focus on MCAS. While there is always a chance that MCAS may be involved on some way, if the flaps are extended, MCAS is designed to be disabled...which means that the sensors which trigger MCAS, are irrelevant in this case, as would be their potential failure modes.

If the flaps were down and MCAS somehow activated, that would mean that both the flaps extension MCAS lockout AND the default AOA vane must have failed, which is possible, but seems unlikely.

If the FR24 data is correct, the Ethiopian flight never reached flaps retraction altitude or airspeed, so it's unlikely, in my opinion, that MCAS would have been triggered.

So if not MCAS related...then what? Weather? Pilot error? Other mechanical problems? Bad fuel? Sabotage?

If what you’re saying is accurate and is confirmed by investigators, this would bring us back to where we were before this crash in my mind, as this grounding seems predominantly based on the belief that MCAS is faulty.

Say that were the case and it was found that there was an act of sabotage, would the 7M8 program be able to regain the trust of regulators to rescind the grounding despite the outstanding Lion Air accident?

The groundings are based on a lack of knowledge. Nobody knows what happened. MCAS was involved in the Lion accident and on the surface, this one looks similar enough for people to draw comparisons.

If the MCAS is not involved, and the unique qualities of the MAX are found to not be significant contributors to the accident, I don't think many will have any issues about putting the MAX back into service...especially given the number of aircraft in service, and the number of uneventful flights on record.

Finn350 wrote:

FR24 data is 3 first minutes of the flight ADS-B data only. There exists satellite based ADS-B data for the whole flight (on which the FAA Emergency Order is based),but that has not been made publicly available.

https://aireon.com/services/global-air- ... veillance/

True...but from reports, the plane was having serious issues almost directly after takeoff. If so, it seems unlikely that the pilots would retract the flaps, while struggling to save the plane...especially if they were flying as slowly as they appeared to be. If they did decide to raise the flaps, then MCAS would be enabled...and would require the failure of a vane, (or perhaps a different failure), to be a contributing factor in the accident.

At the speeds they seemed to be flying...the act of raising the flaps itself would have been more problematic than MCAS failure.

JoeCanuck wrote:

Finn350 wrote:

FR24 data is 3 first minutes of the flight ADS-B data only. There exists satellite based ADS-B data for the whole flight (on which the FAA Emergency Order is based),but that has not been made publicly available.

https://aireon.com/services/global-air- ... veillance/

True...but from reports, the plane was having serious issues almost directly after takeoff. If so, it seems unlikely that the pilots would retract the flaps, while struggling to save the plane...especially if they were flying as slowly as they appeared to be. If they did decide to raise the flaps, then MCAS would be enabled...and would require the failure of a vane, (or perhaps a different failure), to be a contributing factor in the accident.

At the speeds they seemed to be flying...the act of raising the flaps itself would have been more problematic than MCAS failure.

Agree. It looks like a series of failures (like most air accidents), and retracting the flaps (if that is what happened) and MCAS activation was just two steps in it.

Does the 737 not have any safety feature preventing flap retraction under insufficient airspeed?

Takeoff with the flaps down, i.e. not in a certified takeoff setting should result in a takeoff configuration warning. An event that is impossible to overloook.

osiris30 wrote:

3 sensors is not fully redundant if you need 2 sensors to be in agreement for the system to work. In that instance two is treated as one.

3 sensors is single error save.
After you have lost one sensor it no longer is a 3 sensor system
( never done flight savety. Only ever had close contact with railway/transport safety wrappers.
one interesting issue: If you have proven your system to be single error save
( railway save: i.e. expose a single error and stop on that.)
If you switch the system off for longer than 2 consecutive fault probability has crept over the acceptable rate horizon
you have issues activating into a save start state ( you could have two errors in parallel and did not prove that this leads to a save stop. outch. )

FlapsOne wrote:

Spiderguy252 wrote:

The likes of Southwest (and maybe RyanAir) have held the 737 program hostage for too long. We're seeing the dark side of free market economics with Boeing still prattling around the 737 in the 2020s at the behest of these carriers unwilling to spend the dime to look forward.

How many more incidents will it take to make this right?

I see. Interesting how dozens have ordered them, Southwest don’t have that many and Ryanair have the grand total of 0 MAX aircraft. Free market economics are leading product innovation in industries throughout the globe. Tell me comrade, how would the People’s 737 look like if it wasn’t for the likes of Southwest?

It doesn't matter how many SouthWest or RyanAir have in their fleet at the current time - it is well known that SouthWest are to the 737 program what Emirates are to the A380, and were the primary reason why Boeing decided to push ahead with an update over a new frame in the first place. And RyanAir got a custom model of their own - the 737 MAX 200.

Free market economics is quite clearly the way to go in the global economy - I was merely alluding to the fact that it's not without its dark side, as we have seen with this hodge podge airframe update that has resulted in a toll of 340+ deaths so far.

glideslope900 wrote:

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude. The FR24 data may very well be inaccurate and they rotated at the correct speed.

osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

I kept trying to make sense of the FR24 data where it seemed to indicate that it went airborne at 93 knots (based on FR24's blog post saying "All altitude data when the aircraft is ‘on ground’ is reported as 0. Airborne altitude values are report as stated above.") The first data point where the FR24 Altitude jumped from 0 to 7200 was 93 kts Ground Speed. And then the altitude increased by 25 ft, then decreased by 25.

Well, after further analysis, I now believe the FR24's "airborne" point is wrong, because I looked up the GPS coordinates for that point, and it is less than 2000 ft from the start of the takeoff roll. However, notice that spot is 22 ft higher than the start of the takeoff roll, so I'm guessing that was enough altitude change for FR24's computer to consider it "airborne". (The altitude resolution is 25 ft).



Then I looked at the elevation profile of the entire runway 07R. It's crazy. From the beginning of the displaced threshold to the middle, it increases to a max of +32 ft. Then drops -57 ft to the end of the runway. So I think that the first 20s of my chart (which was considered "airborne" by FR24), it was on the ground the entire time because the Altitude kind of matches the ground elevation profile. I think the real airborne point was at 25s, which was 174 knots, and when the Vertical Speed started to increase significantly. I can't explain the Altitude drop at 27s—it does not make sense since Vertical Speed was not negative. I would probably disregard the Altitude data prior to 40s, which is when the plane passed the end of the runway.

Spiderguy252 wrote:

FlapsOne wrote:

Spiderguy252 wrote:

The likes of Southwest (and maybe RyanAir) have held the 737 program hostage for too long. We're seeing the dark side of free market economics with Boeing still prattling around the 737 in the 2020s at the behest of these carriers unwilling to spend the dime to look forward.

How many more incidents will it take to make this right?

I see. Interesting how dozens have ordered them, Southwest don’t have that many and Ryanair have the grand total of 0 MAX aircraft. Free market economics are leading product innovation in industries throughout the globe. Tell me comrade, how would the People’s 737 look like if it wasn’t for the likes of Southwest?

It doesn't matter how many SouthWest or RyanAir have in their fleet at the current time - it is well known that SouthWest are to the 737 program what Emirates are to the A380, and were the primary reason why Boeing decided to push ahead with an update over a new frame in the first place. And RyanAir got a custom model of their own - the 737 MAX 200.

Free market economics is quite clearly the way to go in the global economy - I was merely alluding to the fact that it's not without its dark side, as we have seen with this hodge podge airframe update that has resulted in a toll of 340+ deaths so far.

That's a bit hyperbolic, don't you think? MCAS was a contributing factor in the Lion accident, (the final report hasn't been released so we don't know how much it contributed), and so far, there is no evidence that the aircraft, (much less the MAX mods), was responsible in the Ethiopian accident at all.

What I don't get here ... and perhaps someone has an explanation for me...

If this is the same MCAS error as on the Lion Air flight, why didn't the pilots use the runaway trim cutout switches (or whatever is the actual term)?

From my view as an outsider the whole things looks like this:
1) MCAS is designed very badly by Boeing, because it can act faulty by a single error (faulty AOA vane on pilot side), also Boeing apparently didn't tell all airlines about it and didn't mention MCAS in their MAX FCOMs
2) Lion Air crew on the evening before the crash already had the same error as the crew the next morning, but somehow managed to land the plane safely (DID THEY USE THE CUTOUT SWITCHES?)
3) Repair in the night by LionAir botched (why did they fuck this up?)
4) Lion Air crew of on the next morning takes off with not-repaired aircraft, this time has no clue how to handle the faulty MCAS and crashes
5) A few months later they find CVR and FDR, we get to know about the reason of the Lion Air crash
6) By now I would expect every MAX pilot in the world to have heard about the Lion Air crash, its reason and MCAS (right?)
7) Ethopian crashes (with what is assumed now, another MCAS related issue)

8) And here comes the most important question: How could the Ethopian pilots not know how to handle a faulty MCAS related downtrim? Why didn't they use the cutout switches and trim manually?
8A) Or are we looking into something completely different here?
8B) Might we have a way bigger problem with the MAX, that is not only related to a failing MCAS in case of a faulty AOA sensor?

decoder wrote:

Does the 737 not have any safety feature preventing flap retraction under insufficient airspeed?

If you have unreliable speed input from sensors/computers, the system would’t know that the speed was too low, even if I imagine the indicated speed, if inaccurate, would mostly be too low. If sensors disagree too much, I think speed isn’t at all available.

CARST wrote:

What I don't get here ... and perhaps someone has an explanation for me...

If this is the same MCAS error as on the Lion Air flight, why didn't the pilots use the runaway trim cutout switches (or whatever is the actual term)?

From my view as an outsider the whole things looks like this:
1) MCAS is designed very badly by Boeing, because it can act faulty by a single error (faulty AOA vane on pilot side), also Boeing apparently didn't tell all airlines about it and didn't mention MCAS in their MAX FCOMs
2) Lion Air crew on the evening before the crash already had the same error as the crew the next morning, but somehow managed to land the plane safely (DID THEY USE THE CUTOUT SWITCHES?)
3) Repair in the night by LionAir botched (why did they fuck this up?)
4) Lion Air crew of on the next morning takes off with not-repaired aircraft, this time has no clue how to handle the faulty MCAS and crashes
5) A few months later they find CVR and FDR, we get to know about the reason of the Lion Air crash
6) By now I would expect every MAX pilot in the world to have heard about the Lion Air crash, its reason and MCAS (right?)
7) Ethopian crashes (with what is assumed now, another MCAS related issue)

8) And here comes the most important question: How could the Ethopian pilots not know how to handle a faulty MCAS related downtrim? Why didn't they use the cutout switches and trim manually?
8A) Or are we looking into something completely different here?
8B) Might we have a way bigger problem with the MAX, that is not only related to a failing MCAS in case of a faulty AOA sensor?

There are definitely things that points towards a bigger problem. The reports of pitch down with Autopilot engaged for example. At this point we dont know what it is or how serious it can be. Since the Ethiopian crew where aware of the MCAS issues and im quite confident that one of their first action was to disable the auto trim. But what if there are another issue? We dont know and if thats the case one can imagine the confusion and stress on the flight deck. At this point we dont know if there are certain circumstances that causes the plane to be uncontrollable, or at least too hard to control to fly safely. And that in itself is a reason for grounding.

flybucky wrote:

glideslope900 wrote:

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude. The FR24 data may very well be inaccurate and they rotated at the correct speed.

osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

I kept trying to make sense of the FR24 data where it seemed to indicate that it went airborne at 93 knots (based on FR24's blog post saying "All altitude data when the aircraft is ‘on ground’ is reported as 0. Airborne altitude values are report as stated above.") The first data point where the FR24 Altitude jumped from 0 to 7200 was 93 kts Ground Speed. And then the altitude increased by 25 ft, then decreased by 25.

Well, after further analysis, I now believe the FR24's "airborne" point is wrong, because I looked up the GPS coordinates for that point, and it is less than 2000 ft from the start of the takeoff roll. However, notice that spot is 22 ft higher than the start of the takeoff roll, so I'm guessing that was enough altitude change for FR24's computer to consider it "airborne". (The altitude resolution is 25 ft).



Then I looked at the elevation profile of the entire runway 07R. It's crazy. From the beginning of the displaced threshold to the middle, it increases to a max of +32 ft. Then drops -57 ft to the end of the runway. So I think that the first 20s of my chart (which was considered "airborne" by FR24), it was on the ground the entire time because the Altitude kind of matches the ground elevation profile. I think the real airborne point was at 25s, which was 174 knots, and when the Vertical Speed started to increase significantly. I can't explain the Altitude drop at 27s—it does not make sense since Vertical Speed was not negative. I would probably disregard the Altitude data prior to 40s, which is when the plane passed the end of the runway.

Excellent research! I saw the runway on Google Earth and thought that it looked weird, but discarded it as an artefact in GE. I have also suspected that FR24 data was sort of inaccurate in that the 25 ft jump up and down (interpreted by some as a "go-and-touch" to paraphrase the common touch and go) was a data inaccuracy instead of a real altitude change. After your post it seems the alt change was real, just that it was due to runway elevation, fooling FR to mark it as airborn too early.

So, takeoff was at a relevant speed, and I believe FR24 data shows it increased speed quite a bit but not altitude. We must remember that FR24 data may be completely off if the data was supplied by defective systems. In this case, I think it is established that altitude was never more than some 1000 ft above ground, or do we really know that?

Have you had the time to plot the FR24 data and calculate GPS speed? I was meaning to do so, but it seems customers and my employer stubbornly claims I need to do other work than to calculate FR24 GPS data on my working day

/Fredrik

mandala499 wrote:

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

This is, I am pretty sure, the key point to look at.

MCAS actually did what it was supposed to do: Bring down the nose (away from some stall) and keep the rudder pressure for the pilot "high". It did so because it received some wrong (?) information about extreme AoA. Where did this come from? The AoA-sensor or the computer that translates it's data?

sgrow787 wrote:

If there is a congressional hearing (Rep. Dan Kildee currently requesting) into Boeing, FAA and these accidents and this plane, I think they should ask for evidence that the certified design that led to this mess was really a single sensor non redundant design. Then if that is the case, they should ask the FAA how they came to certify a plane with a new stall detection/prevention system that uses only one sensor and no redundancy.

as far as i have understood they say the redundance have been the pilots
one sensor
two pilots

so three sources of input
so perfectly redundant

Are there any accounts of what the air traffic controllers observed?

In case that there is a systemic reason for the crash: Is it possible that noone could build a plane with few enough defects (also missing redundancy) in the parts and software, because the plane is already too unstable because of its optimized airodynamics at the engines? And is the fuel efficiency of the MAX-8 higher than that of the 320Neo? I just think, it could be a coincidence that Boeing hits the "end of efficiency possibilities" first, or they were just not conservative enough and wanted to achieve too much.

flybucky wrote:

Well, after further analysis, I now believe the FR24's "airborne" point is wrong, because I looked up the GPS coordinates for that point, and it is less than 2000 ft from the start of the takeoff roll. However, notice that spot is 22 ft higher than the start of the takeoff roll, so I'm guessing that was enough altitude change for FR24's computer to consider it "airborne". (The altitude resolution is 25 ft)

---

I think the real airborne point was at 25s, which was 174 knots, and when the Vertical Speed started to increase significantly. I can't explain the Altitude drop at 27s—it does not make sense since Vertical Speed was not negative.

As suspected. It just didn't make sense for the aircraft to be airborne at such a low speed.

Angle of attack during the rotation can produce these altitude deviations, and incorrect AOA correction... the VSI didn't show this because it's based on the inertial reference system...

The airport elevation is 7500ft or so, but with barometer pressure at 1029mb at the time of the accident, the altitude showing 7200ft would indicate the numbers used was based on the altitude on a 1013mb barometer setting. The pilots would have used 1029, but the default ADS-B altitude transmitted uses 1013mb...

lexiion wrote:

mandala499 wrote:

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

This is, I am pretty sure, the key point to look at.

I'm glad people are finally starting to consider what I've been saying all along.

Also, nice to see the thread turn a corner towards adult discussion about relevant data.

glideslope900 wrote:

osiris30 wrote:

flybucky wrote:

I wasn't satisfied with the FR24 charts I had seen because:
1. the x-axis was by data point and not true time interval
2. most of them put several data series that had vastly different number ranges on the same chart, which reduced the "resolution" of the y-axis.

So I made a chart that used true time intervals on the x-axis (seconds elapsed since airborne). This makes it easier to look for time interval patterns. Also, I plotted the Pressure Altitude relative to 7200 ft (which is the first Pressure Altitude reported after airborne). That fits it on the chart better and also gives a good approximation for altitude gained since takeoff. Finally, I used a secondary y-axis for ground speed so you can see the resolution better.

Some observations I had:

• Vertical speed already dropped between 7-10 seconds after airborne, and did not recover until the 20-25 second mark.
• Ground speed increased very steadily, which seems to indicate no engine problems? (Ground Speed should be accurate even if the airspeed sensors on the plane were unreliable, since the Ground Speed is based on GPS).
• I looked for 10 second Vertical Speed decrease intervals. It does look like there could be some at 51-61s, 72-82s, 91-101s. But the Vertical Speed decreases started before 51s. And there were also additional decrease intervals afterwards that were not 10 seconds.

Something was VERY wrong on this flight. IF the FR data is right they rotated at 89kts... Based on what I see in the data they basically took off stalling.

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude.

If this was the case, it is possible that MCAS had nothing to do with the accident, and it was simply unreliable airspeed/pilot error. An airspeed discrepancy during the takeoff roll would in my opinion justify an aborted takeoff. That is why there are “cross check” calls at either 80 or 100 kts between CA and FO airspeed indications.

The FR24 data may very well be inaccurate and they rotated at the correct speed. Still, how would MCAS operate with flaps down? Perhaps a faulty airspeed indicator triggered the MCAS somehow. Is it only the AOA sensor or does MCAS monitor airspeed as well?

Waterbomber2 wrote:

mandala499 wrote:

Osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

Indeed. The groundspeed are deemed to be "absolutely correct" subject to variations within GPS position errors... Past experience cross checking this with IRS Groundspeeds show that it is "good enough to use" pending FDR data.
Take off speeds are low, and yes I agree to your statement somewhat... while I think MCAS is likely to have a play in here, I think the root cause is elsewhere.
- Low take off speeds is very suspicious, I think we MAY be looking at Air-Ground switch issues...
- The ground speed where the aircraft's altitude did initially increase beyond runway undulations, makes sense, albeit on the fast side. Whether this is slow or adequate acceleration, I don't have time to have a deeper look into it as yet.
- The initial climb angle appears to be very shallow, with some unstable VSIs indicated, this may indicate crew was dealing with a stick shaker issue.
- The aircraft appeared to be levelling off at 800' AGL, this raised my eyebrow immediately. This is either a reaction to the stick shaker (and subsequent loss of altitude prior to climbout), or that they decided to clean up the flaps at that altitude (well, just look at the bloody groundspeed) and then MCAS played. Which of this? I don't know.
- The last point with the 2 alternatives, MAY point towards signs of confusion and/or poor CRM and/or poor crew training. However, I urge those reading this to NOT make conclusions based on this as they only form a small part of the picture.

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

Although I initially thought that this may have been something else like an engine failure gone wrong, the later climbout rate basically threw this out of the window. When looking at the granular data... yeah, my thoughts were, "oh no, not again!"

If correct, these all are consistent with what you could expect in a take off with full flaps.
Low lift off speed, shallow climb rate, aircraft not climbing.

Wasn't there a report from an other pilot on the ground that was also listening the frequency, that the takeoff seemed normal? It is in this topic somewhere

That does not match with the trying to rotate, aircraft not climbing, etc

EDIT: found it:

777 crew behind ET302 at holding point report observing normal takeoff followed shortly by declaration of emergency. They heard ET302 on tower frequency transmitting “Wrong airspeed indications and difficulty controlling aircraft.”

Which other systems are disabled if the crew toggled the cutoff switch as per the procedure to disable MCAS?

Appie88 wrote:

glideslope900 wrote:

osiris30 wrote:

Something was VERY wrong on this flight. IF the FR data is right they rotated at 89kts... Based on what I see in the data they basically took off stalling.

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude.

If this was the case, it is possible that MCAS had nothing to do with the accident, and it was simply unreliable airspeed/pilot error. An airspeed discrepancy during the takeoff roll would in my opinion justify an aborted takeoff. That is why there are “cross check” calls at either 80 or 100 kts between CA and FO airspeed indications.

The FR24 data may very well be inaccurate and they rotated at the correct speed. Still, how would MCAS operate with flaps down? Perhaps a faulty airspeed indicator triggered the MCAS somehow. Is it only the AOA sensor or does MCAS monitor airspeed as well?

Waterbomber2 wrote:

mandala499 wrote:

Indeed. The groundspeed are deemed to be "absolutely correct" subject to variations within GPS position errors... Past experience cross checking this with IRS Groundspeeds show that it is "good enough to use" pending FDR data.
Take off speeds are low, and yes I agree to your statement somewhat... while I think MCAS is likely to have a play in here, I think the root cause is elsewhere.
- Low take off speeds is very suspicious, I think we MAY be looking at Air-Ground switch issues...
- The ground speed where the aircraft's altitude did initially increase beyond runway undulations, makes sense, albeit on the fast side. Whether this is slow or adequate acceleration, I don't have time to have a deeper look into it as yet.
- The initial climb angle appears to be very shallow, with some unstable VSIs indicated, this may indicate crew was dealing with a stick shaker issue.
- The aircraft appeared to be levelling off at 800' AGL, this raised my eyebrow immediately. This is either a reaction to the stick shaker (and subsequent loss of altitude prior to climbout), or that they decided to clean up the flaps at that altitude (well, just look at the bloody groundspeed) and then MCAS played. Which of this? I don't know.
- The last point with the 2 alternatives, MAY point towards signs of confusion and/or poor CRM and/or poor crew training. However, I urge those reading this to NOT make conclusions based on this as they only form a small part of the picture.

I still suspect that the problem is not the MCAS itself (other than that being a possible single point of failure), but something somewhere within the ADR system...

Although I initially thought that this may have been something else like an engine failure gone wrong, the later climbout rate basically threw this out of the window. When looking at the granular data... yeah, my thoughts were, "oh no, not again!"

If correct, these all are consistent with what you could expect in a take off with full flaps.
Low lift off speed, shallow climb rate, aircraft not climbing.

Wasn't there a report from an other pilot on the ground that was also listening the frequency, that the takeoff seemed normal? It is in this topic somewhere

That does not match with the trying to rotate, aircraft not climbing, etc

EDIT: found it:

777 crew behind ET302 at holding point report observing normal takeoff followed shortly by declaration of emergency. They heard ET302 on tower frequency transmitting “Wrong airspeed indications and difficulty controlling aircraft.”

I thought research showed there was no 777 in that position at that time?

flybucky wrote:

glideslope900 wrote:

At 89 kts the airplane would probably not be capable of producing the lift to takeoff. They would have kept rolling nose up (trying to rotate) until the airplane gained enough speed to lift off. Then they would have been on the edge of a stall in a very unstable flight regime at low altitude. The FR24 data may very well be inaccurate and they rotated at the correct speed.

osiris30 wrote:

Regardless... Take off speed seems very very low. Your thoughts?

I kept trying to make sense of the FR24 data where it seemed to indicate that it went airborne at 93 knots (based on saying "All altitude data when the aircraft is ‘on ground’ is reported as 0. Airborne altitude values are report as stated above.") The first data point where the FR24 Altitude jumped from 0 to 7200 was 93 kts Ground Speed. And then the altitude increased by 25 ft, then decreased by 25.

Well, after further analysis, I now believe the FR24's "airborne" point is wrong, because I looked up the GPS coordinates for that point, and it is less than 2000 ft from the start of the takeoff roll. However, notice that spot is 22 ft higher than the start of the takeoff roll, so I'm guessing that was enough altitude change for FR24's computer to consider it "airborne". (The altitude resolution is 25 ft).

Then I looked at the elevation profile of the entire runway 07R. It's crazy. From the beginning of the displaced threshold to the middle, it increases to a max of +32 ft. Then drops -57 ft to the end of the runway. So I think that the first 20s of my chart (which was considered "airborne" by FR24), it was on the ground the entire time because the Altitude kind of matches the ground elevation profile. I think the real airborne point was at 25s, which was 174 knots, and when the Vertical Speed started to increase significantly. I can't explain the Altitude drop at 27s—it does not make sense since Vertical Speed was not negative. I would probably disregard the Altitude data prior to 40s, which is when the plane passed the end of the runway.

I believe it was said earlier that the air/ground determination comes from a weight on wheels switch on the nose gear. So the point on FR data that shows airborne just means the nose was in the air, or at least "light" enough to trip the switch to show airborne.

Finn350 wrote:

ilovelamp wrote:

Finn350 wrote:

That is referring to number of cockpit displays only. All 737 MAX have dual AoA sensors and the same MCAS implementation.

APA is saying US MAXes have dual, independent AoA vanes, one on each side of the nose. These vanes are compared to each other and if they don’t compare equally the AoA Disagree message is displayed on the PFD. The Lion Air CEO stated they don’t have the system that compares the two vanes. So, in their case, MCAS only had one stream of data to work with essentially.


ILL

I know it is confusing but here are the facts:
- every 737 MAX has dual, independent AoA vanes, one on each side of the nose
- every 737 MAX has an MCAS implementation that uses input of only one of the AoA vanes, alternating side between each flight
- what is an option on the 737 MAX is AoA Disagree messages, but even with this option MCAS implementation is as above; only one of the AoA vanes is used for the MCAS (and even if you have disagreement between different vanes, how do you know which one is correct? That is something Boeing is trying to figure out as a software fix).

Does each PFD have an AOA display linked to the AOA sensor of that side of the aircraft? Or is the value of only one AOA sensor visible during flight?

Are there known flight profiles (during normal climb? reverting to basic pitch and power and known settings?) where AOA values can roughly be validated?

chicawgo wrote:

I’m not understanding why the scale matters. Clearly the previous flight had a normal flap profile with low flap setting for takeoff then retracted all flight, then I crmentwl flaps for landing. The accident flight has flaps full from the start and then retraction then deployment again. I remember there was lots of talk about why they didn’t put flaps back down when retreating fixed the MCAS issue. Is this in line with that?

The scale matters because it changes what the FDR line is telling you. At the very least you know there is some difference between the FDR trace scale of the two flights because on the accident flight the trace has 5 tick marks above zero, and the previous flight has 6 tick marks above zero.

So I read the FDR trace for the accident flight as each tick mark above zero being 1 degree. This would show Flaps 5 takeoff, reduction to flaps zero, extension to flaps 5, reduction to zero.

For the previous flight I read each tick mark above zero being 5 degrees. This would show Flaps 5 takeoff, reduction to flaps zero, then normal incremental extension to flaps 30 for landing.

*Edited for clarity

*Second edit

I went back through some files I have saved on my computer. There are FDR traces that were put out in a slide show that have the scales properly marked and show that the accident flight had flaps 5 selected.

France Has Black Boxes (7:47 a.m.)

The voice and data recorders from the crashed Ethiopian Airlines Boeing 737 Max have arrived in France, a spokesman for the French BEA air-accident investigation office said.

so airbus now has the blackboxes

downdata wrote:

so airbus now has the blackboxes

Cheeky. Min 7 days before we hear anything about content?

musicrab wrote:

downdata wrote:

so airbus now has the blackboxes

Cheeky. Min 7 days before we hear anything about content?

I would guess "data not recoverable"

felipekk wrote:

Which other systems are disabled if the crew toggled the cutoff switch as per the procedure to disable MCAS?

All automatic pitch trim functions stop and the pilots would have to manually trim the aircraft - something they are trained to handle.

I'm just going to say it--I'm not keen on how the Ethiopians have handled this. Not a timely disposition of critical post-crash evidence. Not accusing them of chicanery, but I don't think they're facing enough scrutiny for these unacceptable delays.

Thankfully, the NTSB will be a party to the investigation.