Finn350 wrote:

osiris30 wrote:

estorilm wrote:

Exactly - there's a specific reason for having more than two. Guess who has used three on all aircraft for over 30 years now?

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.

I was hoping to see more posts about theories of the crash. I know there's not a lot of facts or FDR data revealed yet, but there's still some useful info. In the past, I've found a.net to very good at figuring out which causes are more likely and less likely, well before media and official investigation reports.

I am not an expert, but I enjoy learning about this topic. I have actually scanned through all of the 40+ pages, 2000+ posts. And I've tried to summarize some of the theories and reasons that I've seen in the thread. Please add your insights as well, and I will update the list periodically.

Possible Causes:

• Aerodynamic stall - ?
• Unreliable airspeed - faulty pitot sensors?
• Misconfigured aircraft - flaps?
• MCAS pitch down - Problems started too early (within 7-10 seconds of airborne) for MCAS to be the initial cause. It could have been a secondary cause in a chain reaction though.
• Structural failure / fire / explosion - Some witnesses claimed to see smoke while the plane was still in the air. (Yes, witnesses can be unreliable, but it's a possibility).

Not Likely Causes:

• Engine failure / bird strike - The ground speed was steadily increasing the entire FR24 data, up to 383 knots at the last FR24 data point at 2.5 mins after airborne.
• Intentional crash - The problems started within the first 30 seconds.

dragon6172 wrote:

MCAS gets its signal from the master FCC. The master FCC is set by whichever flight director is turned on first. Typically the pilot flying turns their FD on first. The master FCC only alternates if the pilot flying alternates each leg.

Thanks for the input.

This has been presented differently here. Though it sound in a way reasonable engineering wise.
your source ( a manual, some other authoritative source.) ?

if good info available: Speed trim and such are they fed by the same data path selection?

PixelPilot wrote:

o0OOO0oChris wrote:

Trin wrote:

I wish. All it said was:



So that doesn't tell us anything. I'd be surprised if anything would tell them anything from the images of the crater/lack of large sections of fuselage.

(EDIT: I stand corrected. I have come to understand that they may have found something that indicated to them flap position. Although I fail to see how flap position in the wreckage is indicative of flap position as a variable throughout the entire (short) flight.)

Maybe they found the Jackscrew. If they found the nut fullstop nose-down, it`s pretty much a giveaway that MCAS played a big part in this accident too. I tried to find it on the images available, but it`s probably buried.

And if that is the case then the pilots that were supposedly trained after Lion Air incident on the MCAS didn't do their job well.
Interesting development.

Actually it doesn't mean that at all. It's perfectly possible there are scenarios unknown to Boeing or not encountered in testing, that make it a lot harder to fight MCAS than the simple procedure suggested. This being a new plane - and given we already know they need to fix the software and there are delays in this - there could be all sorts of odd unexpected behaviours in certain scenarios. Together with the instability of the plane in certain scenarios (te reason MCAS is required) and this could all be something no-one had considered.

Or it might not. But we don't know, so best not to blame the poor dead pilots while the world is grounding the plane.I still can't figure out how it was ever allowed that Boeing didn't tell pilots about MCAS. That seems frankly criminal, and both regulators need to hang their heads in shame about that.

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.

I'd be very careful there as it is entirely possible that sampling delay/rates for FR24-data isn't granular enough for this kind of to the second analysis.

Also reason to suspect - they got groundspeed up to near 400kts... indicating at least early on the plane was behaving fairly normally from an acceleration standpoint.

PW100 wrote:

LTC8K6 wrote:

maui19 wrote:

There is something that has been nagging at me about both these crashes. In both cases, the pilots were struggling with the aricraft, but did seem to be overcoming the problem (MCAS) as shown by their continuing to climb, albeit haltingly. But at the end, both planes encountered something that caused them to nosedive. I feel like this is a big piece of the puzzle is yet to be identified. Perhaps the final problem occurs when they try to turn the AC to return to the airport. I think there's more to this than just MCAS and a bad sensor. But who knows.

ET302 only managed to gain about 1,000 feet, so it didn't climb much.

The FR24 data cuts out well before the crash. Therefore we have no indication on the height reached during the short flight. It appears the flight did not reach more than 1000 ft in the initial 3 minutes of flight, but I have not seen any data for the last 3 minutes of flight. Do you have that data?

No, but the last few data points from the FR24 showed them to be in a climb at around 2,800 FPM. Who knows what happened after that.

So what is the "new" information collected at the crash site and satellite data that led the US to ground the Max?

So I can't help but wonder if the investigators found part of the instrument panel that showed the MCAS switched off. This whole accident feels much more complicated than simply the MCAS intervening and pilots being unable to cope with it.

maui19 wrote:

So I can't help but wonder if the investigators found part of the instrument panel that showed the MCAS switched off. This whole accident feels much more complicated than simply the MCAS intervening and pilots being unable to cope with it.

Agreed. Something fundamentally wrong here. Mcas ain't it. It may have caused other issues but this ain't mcas root cause.

I really do not envy the investigators in this case. There is going to be so much pressure from a couple different directions to produce a result

rayfound 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.

I'd be very careful there as it is entirely possible that sampling delay/rates for FR24-data isn't granular enough for this kind of to the second analysis.

Also reason to suspect - they got groundspeed up to near 400kts... indicating at least early on the plane was behaving fairly normally from an acceleration standpoint.

Even if I use the next data point they are below normal take off. Especially for an airport at 7600ft. The fact they got no altitude until speed really improves makes me even more sure of something being way wrong.

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.

Perpaphs either both sensors or the sensor that FR was getting its data from wasnt working properly, or there were windshear conditions on the airport at takeoff, which could somewhat explain the indicator. Either way i have no idea what were the meteorological conditions at T/O.

Etheereal 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.

Perpaphs either both sensors or the sensor that FR was getting its data from wasnt working properly, or there were windshear conditions on the airport at takeoff, which could somewhat explain the indicator. Either way i have no idea what were the meteorological conditions at T/O.

Nope. FR data is GPS delta. It isn't from on board systems and has nothing to do with IAS. It is pure ground speed from delta between two gps readings. This has been clarified many times in both this and the Lion AIr thread.

Edit: Winds at the time were 10kts on the nose according to the weather that was circulating the day of the crash. (go way back to page 1/2)

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?

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.

Whoa, I zoomed in on the first 40 seconds, and if the FR data is right, it is even worse than I thought (from the full chart).

• The aircraft became airborne at 93 knots. Obviously there are lot of factors in takeoff speed, but it should have been around 130 kts? Could this have been due to a faulty pitot / airspeed indicators?
• It only gained +25 ft, before dipping to +0, then later dipping as low as -125 ft! This is possible without crashing because I believe the airport is higher than the surroundings.
• After that, it started climbing, but only reached +25 ft after 40 seconds from airborne.

flybucky 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.

Whoa, I zoomed in on the first 40 seconds, and if the FR data is right, it is even worse than I thought (from the full chart).

• The aircraft became airborne at 93 knots. Obviously there are lot of factors in takeoff speed, but it should have been around 130 kts? Could this have been due to a faulty pitot / airspeed indicators?
• It only gained +25 ft, before dipping to +0, then later dipping as low as -125 ft! This is possible without crashing because I believe the airport is higher than the surroundings.
• After that, it started climbing, but only reached +25 ft after 40 seconds from airborne.

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.

93 kts + 10 kt head wind is still very very low for take off. The loss of altitude after take off is also alarming. There is NO WAY that MCAS was active at that time. Everyone needs to pull their heads out of their a**es and look at what this data is showing. MCAS is a convenient lazy excuse and may have contributed but it certainly did not cause this crash. Something was fundamentally wrong with the aircraft or piloting or both.

osiris30 wrote:

FR data is GPS delta. It isn't from on board systems and has nothing to do with IAS.

How about FR's Altitude and Vertical Speed?

I read that FR's Altitude comes from ADS-B, which is pressure altitude. That means it comes from the aircraft's altimeter, not GPS, right?

Then does it also follow that FR Vertical Speed comes from the aircraft's onboard instruments too, not GPS?

If there was a sensor problem, the FR24 data may not reflect what actually happened.

What data is being used in these plots? Is the source the sensors on the plane?

I was just looking at the preliminary report of Lion Air 610.
Has anyone noticed that the accident flight's flap handle position is indicating full flaps as opposed to the flight previous to the accident flight?

Did they take off with full flaps?
If so, why?

Did the ET flight do this as well?

Perhaps this is the "configuration" that the FAA are talking about?

flybucky wrote:

osiris30 wrote:

FR data is GPS delta. It isn't from on board systems and has nothing to do with IAS.

How about FR's Altitude and Vertical Speed?

I read that FR's Altitude comes from ADS-B, which is pressure altitude. That means it comes from the aircraft's altimeter, not GPS, right?

Then does it also follow that FR Vertical Speed comes from the aircraft's onboard instruments too, not GPS?

FR Alt is ADS-B. So yes it comes from the AC altimeter (ADS-B is the same system that fed the new 'satellite data' everyone was talking about today). Vert speed I think is FR calculated between the two ADS-B readings. Unsure on that one.

Are you suggesting the alt readings are wrong? (genuine question). Given the ADS-B alt data is pretty raw (it isn't pressure adjusted, it's just a raw ALT reading) it would be odd for it to be off.

LTC8K6 wrote:

If there was a sensor problem, the FR24 data may not reflect what actually happened.

What data is being used in these plots? Is the source the sensors on the plane?

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong.

Waterbomber2 wrote:

I was just looking at the preliminary report of Lion Air 610.
Has anyone noticed that the accident flight's flap handle position is indicating full flaps as opposed to the flight previous to the accident flight?

Did they take off with full flaps?
If so, why?

Did the ET flight do this as well?

Perhaps this is the "configuration" that the FAA are talking about?

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

osiris30 wrote:

LTC8K6 wrote:

If there was a sensor problem, the FR24 data may not reflect what actually happened.

What data is being used in these plots? Is the source the sensors on the plane?

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong.

What I read most is that FR24 data is not accurate enough to draw conclusions, and yet...

osiris30 wrote:

rayfound 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.

I'd be very careful there as it is entirely possible that sampling delay/rates for FR24-data isn't granular enough for this kind of to the second analysis.

Also reason to suspect - they got groundspeed up to near 400kts... indicating at least early on the plane was behaving fairly normally from an acceleration standpoint.

Even if I use the next data point they are below normal take off. Especially for an airport at 7600ft. The fact they got no altitude until speed really improves makes me even more sure of something being way wrong.

There were early reports that the speed indication was faulty (I don't know if they have been denied since then). Could a faulty speed indicator provide a higher speed than the actual speed? If yes, this could explain an early rotation of the aircraft. It then got airborne once it finally exceeded the stall speed. Could such a scenario have induced a severe tailstrike and significant damages around the tail of the aircraft to the point that the horizontal stabilizer behavior would have been affected (and to the point that items placed in the cargo could fall out of the aircraft)? I guess that if it had been the case, evidences of the tail strike would have been long found on the runway. A slight variant of this scenario would be that the failure to gain altitude right after the take off could have lead the aircraft to hit some infrastructure on the ground. Even if these scenarios are wrong, one thing that is intriguing me is the absence of eyewitness reports collected in the vicinity of the airport. Per GoogleMaps, the urban area extends several miles east of the runway. A 737 failing to gain altitude cannot have remained unnoticed. Maybe it's just a matter of time before these reports surface in the media?

CBC reporting Aireon supplied info to Transport Canada and FAA

LTC8K6 wrote:

osiris30 wrote:

LTC8K6 wrote:

If there was a sensor problem, the FR24 data may not reflect what actually happened.

What data is being used in these plots? Is the source the sensors on the plane?

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong.

What I read most is that FR24 data is not accurate enough to draw conclusions, and yet...

And yet you want to know more about it?

tomcat wrote:

osiris30 wrote:

rayfound wrote:

I'd be very careful there as it is entirely possible that sampling delay/rates for FR24-data isn't granular enough for this kind of to the second analysis.

Also reason to suspect - they got groundspeed up to near 400kts... indicating at least early on the plane was behaving fairly normally from an acceleration standpoint.

Even if I use the next data point they are below normal take off. Especially for an airport at 7600ft. The fact they got no altitude until speed really improves makes me even more sure of something being way wrong.

There were early reports that the speed indication was faulty (I don't know if they have been denied since then). Could a faulty speed indicator provide a higher speed than the actual speed? If yes, this could explain an early rotation of the aircraft. It then got airborne once it finally exceeded the stall speed. Could such a scenario have induced a severe tailstrike and significant damages around the tail of the aircraft to the point that the horizontal stabilizer behavior would have been affected (and to the point that items placed in the cargo could fall out of the aircraft)? I guess that if it had been the case, evidences of the tail strike would have been long found on the runway. A slight variant of this scenario would be that the failure to gain altitude right after the take off could have lead the aircraft to hit some infrastructure on the ground. Even if these scenarios are wrong, one thing that is intriguing me is the absence of eyewitness reports collected in the vicinity of the airport. Per GoogleMaps, the urban area extends several miles east of the runway. A 737 failing to gain altitude cannot have remained unnoticed. Maybe it's just a matter of time before these reports surface in the media?

And yet some sort of post take off tail strike would bear out eye witness reports of debris and/or smoke coming from the aircraft...

osiris30 wrote:

LTC8K6 wrote:

osiris30 wrote:

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong.

What I read most is that FR24 data is not accurate enough to draw conclusions, and yet...

And yet you want to know more about it?

No, I'm fairly well versed on it in laymen's terms as my participation over the years here mainly concerns accidents.

The question was intended as a reminder that FR24 data can lead you astray.

LTC8K6 wrote:

osiris30 wrote:

LTC8K6 wrote:

What I read most is that FR24 data is not accurate enough to draw conclusions, and yet...

And yet you want to know more about it?

No, I'm fairly well versed on it in laymen's terms as my participation over the years here mainly concerns accidents.

The question was intended as a reminder that FR24 data can lead you astray.

Then say that and don't ask a question that has been answered about 100 times between two threads

Incidentally FRs data is based on GPS and ADS-B. Same as the ""new satellite data" that the CAA and FAA commented on today. So it appears it is about as good as anything going until the FDR is readout.

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.

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.

Probably a batch of bad sensors from a 3rd party manufacturer... things like that have happened before....

What line numbers were the lion aircraft and this one?

[edit] English... sometimes I speak it.. but rarely do I type it!

osiris30 wrote:

Waterbomber2 wrote:

I was just looking at the preliminary report of Lion Air 610.
Has anyone noticed that the accident flight's flap handle position is indicating full flaps as opposed to the flight previous to the accident flight?

Did they take off with full flaps?
If so, why?

Did the ET flight do this as well?

Perhaps this is the "configuration" that the FAA are talking about?

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

Waterbomber2 wrote:

osiris30 wrote:

Waterbomber2 wrote:

I was just looking at the preliminary report of Lion Air 610.
Has anyone noticed that the accident flight's flap handle position is indicating full flaps as opposed to the flight previous to the accident flight?

Did they take off with full flaps?
If so, why?

Did the ET flight do this as well?

Perhaps this is the "configuration" that the FAA are talking about?

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

If your graph is labelled correctly it says 'flap handle position' which would not be automatically deployed or done by the system but rather the human.

osiris30 wrote:

Waterbomber2 wrote:

osiris30 wrote:

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

If your graph is labelled correctly it says 'flap handle position' which would not be automatically deployed or done by the system but rather the human.

As sensed electronically and sent to the FDR.
But the actual handle may have been in the correct position. For instance, a microswitch issue can cause false data to be sent to the flap computer and the flap computer to misinterpret the position set by the pilots, deploying the flaps fully.

Waterbomber2 wrote:

osiris30 wrote:

Waterbomber2 wrote:

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

If your graph is labelled correctly it says 'flap handle position' which would not be automatically deployed or done by the system but rather the human.

As sensed electronically and sent to the FDR.
But the actual handle may have been in the correct position. For instance, a microswitch issue can cause the flap computer to misinterpret the position set by the pilots.

While the microswitch may be a point of being a fault, it would likely not look so 'pretty' in terms of it being moved around (I mean I suppose one could design a series of microswitches that might look like that if one failed closed, but you'd have to go out of your way to do so, and that would be tremendously unfortunate).

I mean the easy solution is listen to the CVR and see if there is a 'flaps full' read out at some point.. then you'd know for sure how it happened.

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.

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)

Waterbomber2 wrote:

osiris30 wrote:

Waterbomber2 wrote:

I was just looking at the preliminary report of Lion Air 610.
Has anyone noticed that the accident flight's flap handle position is indicating full flaps as opposed to the flight previous to the accident flight?

Did they take off with full flaps?
If so, why?

Did the ET flight do this as well?

Perhaps this is the "configuration" that the FAA are talking about?

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

Is the scale the same between the two traces? I recall scales being different between flights when I looked before. Been a long time since i looked though

dragon6172 wrote:

Waterbomber2 wrote:

osiris30 wrote:

The good news (if there is any in this) is IF that is a weird corner case causing these issues, it is a simple advisory to make the fleet airworthy and safe again while more systems digging is done.

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

Is the scale the same between the two traces? I recall scales being different between flights when I looked before. Been a long time since i looked though

This is part of the issue when we deal with data in image format online. Without access to the raw data for all this stuff we are left to make assumptions. The graphs LOOK to contain enough notches to be to the same scale, but that is an eyeball guestimate.

osiris30 wrote:

dragon6172 wrote:

Waterbomber2 wrote:

It looks pretty clear to me.
I isolated the information in the below image, from the data in the preliminary report.

According to this, Lion Air took off with full flaps.
Something causing the flaps to deploy completely uncommanded and undetected?

Is the scale the same between the two traces? I recall scales being different between flights when I looked before. Been a long time since i looked though

This is part of the issue when we deal with data in image format online. Without access to the raw data for all this stuff we are left to make assumptions. The graphs LOOK to contain enough notches to be to the same scale, but that is an eyeball guestimate.

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?

osiris30 wrote:

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong

What data is transmitted by the transponder and what data is calculated by the server CAN differ from aircraft to aircraft.

However, normally...
- Groundspeed is transmitted by the ADS-B using onboard GPS reading and is not server calculated.
- Altitude is sent by the ADS-B using 29.92inHG or 1013.2mb barometric pressure setting on the altimeter.
- Vertical speed is sent by the ADS-B using the same source that is used by the pilot. An aircraft using IVSI will have the vertical speed generated from the aircraft's IRS, non-IVSI will have the vertical speed generated from something else.

There are a load of other stuff that can be transmitted depending on the options taken on the transponder and aircraft, and also the radar environment the aircraft is in... stuff like TAS, OAT, ALTSEL, HDGSEL, etc (the usual mode-S stuff).

mandala499 wrote:

osiris30 wrote:

Please read... even the same page you are posting on... Speed is based on distance between gps fixes. Not sensors. ALT is based on ADS-B data. VS is unknown if read or computed (I BELIEVE) it is computed, but may be wrong

What data is transmitted by the transponder and what data is calculated by the server CAN differ from aircraft to aircraft.

However, normally...
- Groundspeed is transmitted by the ADS-B using onboard GPS reading and is not server calculated.
- Altitude is sent by the ADS-B using 29.92inHG or 1013.2mb barometric pressure setting on the altimeter.
- Vertical speed is sent by the ADS-B using the same source that is used by the pilot. An aircraft using IVSI will have the vertical speed generated from the aircraft's IRS, non-IVSI will have the vertical speed generated from something else.

There are a load of other stuff that can be transmitted depending on the options taken on the transponder and aircraft, and also the radar environment the aircraft is in... stuff like TAS, OAT, ALTSEL, HDGSEL, etc (the usual mode-S stuff).

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.

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)

They linked directly to the ASRS database. Read the article and click the links:

https://www.dallasnews.com/business/air ... afety-flaw

ytz wrote:

osiris30 wrote:

7BOEING7 wrote:

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)

They linked directly to the ASRS database. Read the article and click the links:

https://www.dallasnews.com/business/air ... afety-flaw

Can you link the link please.. not disabling my ad blocker to sate their revenue lust LOL.

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.

That would be a shocking discovery if true.

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.

That might explain the AP. But what explains the autothrottles not responding?

https://www.documentcloud.org/documents ... cument/p10

osiris30 wrote:

ytz wrote:

osiris30 wrote:

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)

They linked directly to the ASRS database. Read the article and click the links:

https://www.dallasnews.com/business/air ... afety-flaw

Can you link the link please.. not disabling my ad blocker to sate their revenue lust LOL.

This is their extracts from the ASRS.

https://www.documentcloud.org/documents ... cument/p10

ytz 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.

That might explain the AP. But what explains the autothrottles not responding?

https://www.documentcloud.org/documents ... cument/p10

Thank you. The nose down seems interest. The auto throttle less so (those can break and would be an MX issue). It's not like they retarded they just didn't travel fully (from what I read in the report). The other report was interesting. The one about MCAS seems... 'odd'.

osiris30 wrote:

ytz wrote:

7BOEING7 wrote:

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.

That might explain the AP. But what explains the autothrottles not responding?

https://www.documentcloud.org/documents ... cument/p10

Thank you. The nose down seems interest. The auto throttle less so (those can break and would be an MX issue). It's not like they retarded they just didn't travel fully (from what I read in the report). The other report was interesting. The one about MCAS seems... 'odd'.

I’m finding this to be quite an interesting find. On the FR data, do you know if something similar to the FAA SWIM feed is a component of data capture?

https://www.faa.gov/air_traffic/technology/swim/

Not sure their ATM is that advanced, but it would be interesting to know given the collectible data from such a system.

DL717 wrote:

osiris30 wrote:

ytz wrote:

That might explain the AP. But what explains the autothrottles not responding?

https://www.documentcloud.org/documents ... cument/p10

Thank you. The nose down seems interest. The auto throttle less so (those can break and would be an MX issue). It's not like they retarded they just didn't travel fully (from what I read in the report). The other report was interesting. The one about MCAS seems... 'odd'.

I’m finding this to be quite an interesting find. On the FR data, do you know if something similar to the FAA SWIM feed is a component of data capture?

https://www.faa.gov/air_traffic/technology/swim/

Not sure their ATM is that advanced, but it would be interesting to know given the collectible data from such a system.

I have no idea what FRs capabilities are beyond the data they released. I would be surprised if they gathered more than needed for their site. It would add cost and no value. FR24 isn't a system of record for any purpose beyond their own needs.