EXDAC
June 13, 2025, 02:40:00 GMT
permalink Post: 11899938

How can an MCP ALT setting error explain the sequence seen in the videos? If the MCP ALT is set too low the aircraft levels off, reduces thrust to maintain set speed, - AND MAINTAINS MCP ALTITUDE. Sure it will get the crew's attention but it will not result in a uncontrolled descent.

Subjects: None

EXDAC
June 13, 2025, 03:32:00 GMT
permalink Post: 11899955

Quote:

Originally Posted by ZootO

Easy to get tunnel vision on the Flight Guidance cue in the HUD.

I am familiar with that having worked on HUD development. However, what FD/GC mode would be be active that would command a descent after an altitude capture from below? I would expect FD and GC to be in ALT HOLD mode. I don't know the 787 but I would have expected GC to command ALT HOLD until low speed protection activated if thrust had been lost.

If thrust was lost the aircraft is coming down regardless of MCP ALT or GC command.

Subjects: None

EXDAC
June 13, 2025, 20:19:00 GMT
permalink Post: 11900866

Quote:

Originally Posted by EDML

Impossible. The switches are guarded. You need to pull them out to move them to Cutoff.

Exactly like the action of lifting the flap lever out of detent before moving it. What is significantly different is that you would have to do it twice. It is that which makes it improbable unless intentional.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All) Fuel Cutoff Switches Fuel Cutoff Switches (detent) Switch Guards

EXDAC
June 13, 2025, 22:01:00 GMT
permalink Post: 11900957

787 MLG swing here -

Subjects: None

EXDAC
June 14, 2025, 20:03:00 GMT
permalink Post: 11901785

Quote:

Originally Posted by QDM360

The only thing you can say with certainty is that FR24's ADS-B receiver at Ahmedabad has really, really poor coverage...

The independent ADS-B Exchange receiver(s) didn't pick up the signal at all during the departure.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ADSB

EXDAC
June 15, 2025, 16:00:00 GMT
permalink Post: 11902588

Quote:

Originally Posted by D Bru

1. 787-8 LG retraction: doors open, boogies tilt forward before inward:

The caption seems to be in conflict with the video sequence. The caption, which may be all that is read/viewed, should be "bogies tilt, doors open, gear retracts.

Subjects: None

EXDAC
June 15, 2025, 20:56:00 GMT
permalink Post: 11902827

Quote:

Originally Posted by DaveReidUK

One of the two recorders on the 787 is equipped with RIPS (Recorder Independent Power Supply), which will give a minimum of 10 minutes' operation in the event of a power supply failure.

But as previously posted a recorder is only as good as the systems that provide the data to it. If those systems, or some of those systems, are not powered the data is simply not available to be recorded. You need the DFDAU (or equivalent) to be powered and you need the systems that feed data to the DFDAU (or equivalent) to be powered and operational.

Edit to add - RIPS will likely maintain CVR function.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): CVR Digital Flight Data Acquisition Unit RIPS

EXDAC
June 15, 2025, 23:19:00 GMT
permalink Post: 11902949

Quote:

Originally Posted by tdracer

FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC).

DO-178 unless propulsion systems are for some reason different from displays and flight controls.

I have been on the fringes of dissimilar hardware and dissimilar software designs (MD-11 flight controls). Sometimes it is necessary but there is a huge overhead in both development and test.

Edit to add - Even with dissimilar processor and software the requirements for both will trace up to some common high level system requirements specification. There is a non zero probability that those top level requirement were inadequate or included an error.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC FBW

EXDAC
June 15, 2025, 23:19:00 GMT
permalink Post: 11903725

Quote:

Originally Posted by tdracer

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC FBW

EXDAC
June 17, 2025, 02:51:00 GMT
permalink Post: 11903930

Quote:

Originally Posted by Lead Balloon

Back to the subject of the TCMA, in order for the four channels (A and B for engine 1 and A and B for engine 2) to be truly independent, there would have to be, for example, four, separate weight on wheels sensors and two, separate throttle position sensors per throttle. I would be extraordinarily surprised if that's what has been implemented, but will happily stand correct.

Well, I was looking at the drawings of the MD-11 thrust control module and there certainly are two sensors on each thrust lever. The sensors are implemented as a dual resolver on a common shaft. This level of redundancy is well understood by those who specify, design, test, and certify critical aircraft systems.

Edit - tdracer posted as I was typing. It seems 787 has even greater sensor separation.

Last edited by EXDAC; 17th June 2025 at 12:07 .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Weight on Wheels

EXDAC
June 17, 2025, 15:45:00 GMT
permalink Post: 11904410

Quote:

Originally Posted by syseng68k

JPI33600:

Thanks. From that I assume that the thrust resolver signal is fed to the FADEC alone ?. The reason for the clarification was that it was not clear if the signal is fed to other subsystems, which could affect the analysis.

That is certainly typical. The FADEC/EEC/ECU includes the resolver angles in its output data for consumption by other systems such as displays and flight controls.

Last edited by EXDAC; 17th June 2025 at 16:09 .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC

EXDAC
June 17, 2025, 22:42:00 GMT
permalink Post: 11904731

Quote:

Originally Posted by D Bru

Uncommanded high trust on (at least one of) the engines during the TO-roll, in particular past V1, resulting in a discrepancy with the actual (likely derated)thrust settings, could have triggered TMCA on or just before lift-off.

How would the thrust lever idle condition have been satisfied?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): V1

EXDAC
June 18, 2025, 01:33:00 GMT
permalink Post: 11904830

Quote:

Originally Posted by Capn Bloggs

Have a look at the latest data from FR24 (from post 439 in the previous thread).

https://www.flightradar24.com/blog/f...rom-ahmedabad/

In the CSV data set that can be downloaded from that link the first point with altitude data is 1630 ft short of the departure threshold. That point is 575. The highest alt recorded in the data set is 625. All the points with altitude data overlay the departure runway. I do not understand how anyone is using this data set to determine the maximum altitude which was way past the departure end.

Edit to add - I have made no attempt to correct the raw ADS-B altitude data. There is no need to make any correction to see altitude gain.

Last edited by EXDAC; 18th June 2025 at 01:54 . Reason: revise image to add missing data point

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ADSB FlightRadar24

EXDAC
June 18, 2025, 13:57:00 GMT
permalink Post: 11905272

Quote:

Originally Posted by Musician

FR24 did do that raw ADS-B data comparison. Remember the GPS position and barometric altitude are sent by the aircraft itself. The altitude is sent in 25 ft intervals, so a shallow curve that is smooth in reality looks janky in the data, due to the rounding of the numbers. From https://www.flightradar24.com/blog/f...rom-ahmedabad/ :

The red line is the accident flight, and it covers approximately 4.3 seconds.
Obviously the altitudes are all uncorrected for barometric pressure, which would've varied with the weather on that day; you kind of have to mentally shift the lines vertically downward.

There seems to be an assumption that, if corrected for local altimeter, the lines all move down toward the runway as a set.

Wouldn't that only be true if the altimeter setting was the same on all the days those flights were made? Isn't that improbable?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ADSB FlightRadar24

EXDAC
June 18, 2025, 15:48:00 GMT
permalink Post: 11905349

Quote:

Originally Posted by PBL

I'd like to stick my neck out and say what I think I know. And I do mean "know", not what I think "likely" or "possible".

3. The FR24 graphic posted by Musician shows that the aircraft became initially airborne "as usual", compared with other TO profiles. (Info from FR24.)

I am not convinced that the FR24 graphic shows that.

The FR24 data shows that, for the accident flight, the first data point received on takeoff was one that included altitude. We know where the aircraft was and we know the uncorrected baro altitude at that point.

We do not know how the altitude of that first point compares to the altitude of the reference flights unless all flights have their altitude adjusted by the prevailing altimeter correction.

Each trace starts in about the same place over the runway but this may not be useful data. I don't think this is the ADS-B ground/air transition. I think it is the point at which reception of ADS-B data becomes possible because of transmission "line of sight". We don't know if data starts being received as a result of increased altitude or because of passing by whatever was blocking the signal.

I'm sure someone could research the altimeter setting for each of the reference flight and produce a corrected data set. That would be interesting and useful data.

That's just my interpretation of the data I have seen. It is not presented as fact.

Last edited by EXDAC; 18th June 2025 at 16:17 . Reason: typo fix

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ADSB FlightRadar24

EXDAC
June 18, 2025, 18:24:00 GMT
permalink Post: 11905450

Quote:

Originally Posted by skwdenyer

True redundancy would require different software on each redundant sub-system.

Perhaps a necessary but not sufficient condition.

Some critical systems are designed with processing "lanes" having dissimilar processors as well as dissimilar code. Each lane is developed from separate requirements that trace up to one high level system requirements specification. If that high level specification has errors the errors flow into all the independent lanes of processing.

Testing may not find such errors since the system works as specified.

Last edited by EXDAC; 18th June 2025 at 18:41 .

Subjects: None

EXDAC
June 19, 2025, 02:31:00 GMT
permalink Post: 11905680

The issue with 5G was the potential for interference with some models of radio altimeter. I think we have been told that RA is used in 787 air/ground logic. We have also been told that air/ground state is used to enable TCMA.

I think it very unlikely that 5G interference was a contributing factor but I can see why someone would be interested in asking the question.

Subjects: None

EXDAC
June 19, 2025, 15:03:00 GMT
permalink Post: 11906094

Quote:

Originally Posted by LGB

So they only got to around 100' height, half the wing span of a Boeing 787? I think it looks higher than that..

The last report received from ADS-B out is 625 ft but, at that point, the aircraft is still over the runway. The video shows the aircraft continued to climb after passing the departure end.

There is no conflict. Simply a lack of ADS-B data.

Edit - Add the ADS-B data points graphic that I had posted June 17.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ADSB

EXDAC
June 19, 2025, 19:37:00 GMT
permalink Post: 11906312

Quote:

Originally Posted by aerobat77

Most other here discussed scenarios are nonsense , e.g the system would simply ignore a cutoff command with thrust levers above idle .

Are you asserting that "the system would simply ignore a cutoff command with thrust levers above idle" is a nonsense statement?
or
Are you asserting that "the system would simply ignore a cutoff command with thrust levers above idle" is a description of how the system behaves?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All) Fuel Cutoff Switches

EXDAC
June 19, 2025, 20:17:00 GMT
permalink Post: 11906333

Quote:

Originally Posted by aerobat77

sorry if it was not clear : when you move the switches to cutoff and the thrust levers are above idle imho the engines would NOT cutoff , the command would be ignored .

Ok, thanks. I wanted to be sure what you intended before I told you it was nonsense.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All) Fuel Cutoff Switches

Posts by user "EXDAC" [Posts: 46 Total up-votes: 0 Pages: 3]