June 19, 2025, 12:25:00 GMT
permalink Post: 11905982
Here we go again.
They are not "ground-only" levers, Why do you and MagPlug have this idea that the PF would not place their hand back on the thrust levers after the gear up call, or at least be guarding the throttles just in case, heaven forbid, they started to roll back?
That would be a stupid design. FYI, the old 787 FCOM I have says "Maximum rated thrust is available in any phase of flight by moving the thrust levers to the full forward positions".
.
Irrelevant. They were doing a single-engine test and completely messed it up; nothing like what this crew would have been faced with. They were ta Idle because the captain pulled the TL back in an attempt to regain control. Nothing like you say.
I'd suggest not but the elephant in the room as far as you and Magplug goes... what are the pilots doing all this time? Just sitting there watching?
Originally Posted by
LGB
I am also thinking that Air India would follow Boeing procedures in that the left seat pilot will move their right hand away from the thrust levers at V1, and thus, at 400', the thrust levers are not guarded or monitored?
Originally Posted by
LGB
Even if thrust levers were pushed forward, is there some kind of logic related to FMC and-or FADEC or other involved systems, which regardless of thrust lever position commands IDLE thrust to the engine?
.
Originally Posted by
LGB
Remember that Airbus accident where the aircraft thought it was landing, while the pilots wanted full thrust, and they crashed into a small forest because some kind of idle is all they were afforded by the system?
Originally Posted by
LGB
If the engines of this 787 thought it was in the rollout or final part of the flare, it might also command thrust levers to idle?
Last edited by T28B; 19th June 2025 at 14:33 . Reason: formatting assistance
June 19, 2025, 13:28:00 GMT
permalink Post: 11906021
Here we go again.
They are not "ground-only" levers, Why do you and MagPlug have this idea that the PF would not place their hand back on the thrust levers after the gear up call, or at least be guarding the throttles just in case, heaven forbid, they started to roll back?
...
They are not "ground-only" levers, Why do you and MagPlug have this idea that the PF would not place their hand back on the thrust levers after the gear up call, or at least be guarding the throttles just in case, heaven forbid, they started to roll back?
...
It is noteworthy that the point that thrust is lost, is very close to 400' AGL, where at least on some other Boeing aircraft, HOLD changes to THR REF. It seems coincident with this height, the thrust is lost. And lost so closely, between the engines, that there seems to be neither yaw nor roll to see in the videos. Does the 787 have a system for asymmetric thrust, like the TAC on the 777? Even if it does, would the aircraft still not show at least a slight bit of yaw/roll before such a system kicked in, unless both engines lost thrust near simultaneously?
If all AC and DC was lost in an instant, then that would be within a split second for both engines, via the FSOVs, rendering FADEC powerless. If anything like birds, bad fuel, lack of fuel, vapour or all other things like that mentioned, the chances of no yaw seem only remotely possible.
Then there is the RAT and the landing gear.
Any indication from known videos as to what height the RAT comes on, around 400' AGL, or well before reaching 400' ?
June 19, 2025, 13:51:00 GMT
permalink Post: 11906035
And add the radio altimeter(s). I think, but don't know, that they provide inputs to the FADEC TCMA function also.
Last edited by T28B; 19th June 2025 at 14:38 . Reason: brackets completed
June 19, 2025, 14:08:00 GMT
permalink Post: 11906053
I have read most of the thread (old and new). As a lawyer working in forensic investigations, I am constantly involved in problem-solving. My field of work also includes complex investigations related to insolvencies, which almost always require an analysis of the causes behind a specific, established outcome. In doing so, I naturally also have to deal with probabilities. However, it often turns out that the most likely or plausible explanation does not reflect what actually happened.
Many of the considerations I’ve read fail because the simultaneous failure of both engines is extremely unlikely, leading to a constant search for higher-order causes. It was suggested that an incorrect altitude setting led to an early thrust reduction. However, this would not explain the deployment of the RAT (Ram Air Turbine), especially since the thrust could have been readjusted. FADEC and TCAM are highly redundant systems, and TCAM failure is unlikely due to WOW (Weight on Wheels) logic, making a simultaneous engine failure after VR equally improbable.
With that said, and with regard to my question concerning the AD that relates to the fuel control switches (FCS), my thought—and it was nothing more than that—was that their activation becomes more probable if it can occur accidentally. That’s how I came across SAIB: NM-18-33.
Another user then brought up an iPhone. That notion would, of course, be dramatic—but how unlikely is it really that after approximately 10,000 actuations between December 2013 and June 2025, the two FCS no longer lock perfectly? Considering all of this, I find it quite conceivable that the A/T slightly reduced thrust in the first seconds after VR (e.g., if an incorrect target altitude had been entered) and that an object lying between the thrust levers and the FCS could have pushed the FCS into the “Off” position. Due to the buttons on top of the switches, which provide some resistance, it’s even possible that the object both pulled and pushed them.
But all of this is speculation. The investigation report will bring clarity.
Even if my theory is not confirmed, I still believe that the positioning and mechanism of the FCS are suboptimal. Switches of such critical importance should be better protected, and movements in the area in front of the switches (like reducing thrust) should not follow the same direction as shutting off the fuel supply. A different switching direction alone would provide more safety—especially considering that the FCS are protected laterally by metal plates.
Many of the considerations I’ve read fail because the simultaneous failure of both engines is extremely unlikely, leading to a constant search for higher-order causes. It was suggested that an incorrect altitude setting led to an early thrust reduction. However, this would not explain the deployment of the RAT (Ram Air Turbine), especially since the thrust could have been readjusted. FADEC and TCAM are highly redundant systems, and TCAM failure is unlikely due to WOW (Weight on Wheels) logic, making a simultaneous engine failure after VR equally improbable.
With that said, and with regard to my question concerning the AD that relates to the fuel control switches (FCS), my thought—and it was nothing more than that—was that their activation becomes more probable if it can occur accidentally. That’s how I came across SAIB: NM-18-33.
Another user then brought up an iPhone. That notion would, of course, be dramatic—but how unlikely is it really that after approximately 10,000 actuations between December 2013 and June 2025, the two FCS no longer lock perfectly? Considering all of this, I find it quite conceivable that the A/T slightly reduced thrust in the first seconds after VR (e.g., if an incorrect target altitude had been entered) and that an object lying between the thrust levers and the FCS could have pushed the FCS into the “Off” position. Due to the buttons on top of the switches, which provide some resistance, it’s even possible that the object both pulled and pushed them.
But all of this is speculation. The investigation report will bring clarity.
Even if my theory is not confirmed, I still believe that the positioning and mechanism of the FCS are suboptimal. Switches of such critical importance should be better protected, and movements in the area in front of the switches (like reducing thrust) should not follow the same direction as shutting off the fuel supply. A different switching direction alone would provide more safety—especially considering that the FCS are protected laterally by metal plates.
June 19, 2025, 14:11:00 GMT
permalink Post: 11906054
It does not follow that MCAS malfunction is a software malfunction.
As far as I know, the software functioned exactly as it was specified/required to function. The problem did not lie in the quality of the software, as you suggest. It lay in the functional requirements for the function, and the hazard analysis of those requirements, and those are manufacturer tasks.
As far as I know, the software functioned exactly as it was specified/required to function. The problem did not lie in the quality of the software, as you suggest. It lay in the functional requirements for the function, and the hazard analysis of those requirements, and those are manufacturer tasks.
In a total electrical failure, when the system switches to emergency battery power, how are input variables like rad alt and wow switches processed? (these were inputs someone mentioned on the 747-8, have the TCMA inputs been identified yet?)
I speculate the gear truck forward tilt is a symptom of a C hydraulic failure caused by a total electrical failure around the time of VR. Once they got 10 deg nose up on the rotation, with a total electrical failure, could the FADEC receive erroneous rad alt or wow inputs, and how would TCMA handle these inputs in the transition from ground to air logic?
What is baffling is the simultaneous nature of the suspected dual engine shutdown. There is no obvious asymmetry, with the flight path or rudder movements. If the engine fuel control switches had been manually cut one at a time, there should have been some visible flightpath change or flight control response. Something happened to both engines at exactly the same time.
June 19, 2025, 14:36:00 GMT
permalink Post: 11906073
I have read most of the thread (old and new). As a lawyer working in forensic investigations, I am constantly involved in problem-solving. My field of work also includes complex investigations related to insolvencies, which almost always require an analysis of the causes behind a specific, established outcome. In doing so, I naturally also have to deal with probabilities. However, it often turns out that the most likely or plausible explanation does not reflect what actually happened.
Many of the considerations I\x92ve read fail because the simultaneous failure of both engines is extremely unlikely, leading to a constant search for higher-order causes. It was suggested that an incorrect altitude setting led to an early thrust reduction. However, this would not explain the deployment of the RAT (Ram Air Turbine), especially since the thrust could have been readjusted. FADEC and TCAM are highly redundant systems, and TCAM failure is unlikely due to WOW (Weight on Wheels) logic, making a simultaneous engine failure after VR equally improbable.
With that said, and with regard to my question concerning the AD that relates to the fuel control switches (FCS), my thought\x97and it was nothing more than that\x97was that their activation becomes more probable if it can occur accidentally. That\x92s how I came across SAIB: NM-18-33.
Another user then brought up an iPhone. That notion would, of course, be dramatic\x97but how unlikely is it really that after approximately 10,000 actuations between December 2013 and June 2025, the two FCS no longer lock perfectly? Considering all of this, I find it quite conceivable that the A/T slightly reduced thrust in the first seconds after VR (e.g., if an incorrect target altitude had been entered) and that an object lying between the thrust levers and the FCS could have pushed the FCS into the \x93Off\x94 position. Due to the buttons on top of the switches, which provide some resistance, it\x92s even possible that the object both pulled and pushed them.
But all of this is speculation. The investigation report will bring clarity.
Even if my theory is not confirmed, I still believe that the positioning and mechanism of the FCS are suboptimal. Switches of such critical importance should be better protected, and movements in the area in front of the switches (like reducing thrust) should not follow the same direction as shutting off the fuel supply. A different switching direction alone would provide more safety\x97especially considering that the FCS are protected laterally by metal plates.
Many of the considerations I\x92ve read fail because the simultaneous failure of both engines is extremely unlikely, leading to a constant search for higher-order causes. It was suggested that an incorrect altitude setting led to an early thrust reduction. However, this would not explain the deployment of the RAT (Ram Air Turbine), especially since the thrust could have been readjusted. FADEC and TCAM are highly redundant systems, and TCAM failure is unlikely due to WOW (Weight on Wheels) logic, making a simultaneous engine failure after VR equally improbable.
With that said, and with regard to my question concerning the AD that relates to the fuel control switches (FCS), my thought\x97and it was nothing more than that\x97was that their activation becomes more probable if it can occur accidentally. That\x92s how I came across SAIB: NM-18-33.
Another user then brought up an iPhone. That notion would, of course, be dramatic\x97but how unlikely is it really that after approximately 10,000 actuations between December 2013 and June 2025, the two FCS no longer lock perfectly? Considering all of this, I find it quite conceivable that the A/T slightly reduced thrust in the first seconds after VR (e.g., if an incorrect target altitude had been entered) and that an object lying between the thrust levers and the FCS could have pushed the FCS into the \x93Off\x94 position. Due to the buttons on top of the switches, which provide some resistance, it\x92s even possible that the object both pulled and pushed them.
But all of this is speculation. The investigation report will bring clarity.
Even if my theory is not confirmed, I still believe that the positioning and mechanism of the FCS are suboptimal. Switches of such critical importance should be better protected, and movements in the area in front of the switches (like reducing thrust) should not follow the same direction as shutting off the fuel supply. A different switching direction alone would provide more safety\x97especially considering that the FCS are protected laterally by metal plates.
June 19, 2025, 15:43:00 GMT
permalink Post: 11906130
Thanks. The next question being: With both engines at idle, will there still be enough hydraulic and electrical power generated ?. Might depend also on aircraft mode, ground / air, takeoff / landing etc.
I guess the underlying point i'm digging at is that not only the fuel shutoff valve and control has authority over the engine. Many a/c subsystems will be connected together via an aircraft data bus, (or local area network, in compute terminology). and will need access to the FADEC for many reasons. Just as home wifi allows multiple users to access a shared resource, most modern complex systems are networked to supervise and share data.
I guess the underlying point i'm digging at is that not only the fuel shutoff valve and control has authority over the engine. Many a/c subsystems will be connected together via an aircraft data bus, (or local area network, in compute terminology). and will need access to the FADEC for many reasons. Just as home wifi allows multiple users to access a shared resource, most modern complex systems are networked to supervise and share data.
June 19, 2025, 16:10:00 GMT
permalink Post: 11906159
The only aircraft inputs to TCMA is air/ground and thrust lever positions - everything else is the FADEC and its sensors (primarily N1). Even if air/ground was compromised somehow, it would take other issues before TCMA could possibly be activated. Possible on one engine (although remote) - but two engines at the same time - almost literally imposssible (unless of course it's software error).
The 'good' news is that even a cursory check of the FDR will indicate if TCMA activated, so we'll soon know.
The 'good' news is that even a cursory check of the FDR will indicate if TCMA activated, so we'll soon know.
In 2019 I think it was, an ANA 787 had a TMCA dual engine shutdown just after landing. There was also a bug that shut down all AC power on 787s powered on for 248+ days (integer overflow causing GCU failsafe) that was supposed to be remedied on 2019. Can\x92t find any information confirming that it was implemented on all 787s. These are just two examples of software bugs. There are placed of others, and it\x92s highly likely there are ones we don\x92t know about, either in the original software or in the updates.
June 19, 2025, 16:52:00 GMT
permalink Post: 11906189
TCMA - first off, I have to admit that this does look rather like an improper TCMA activation, but that is very, very unlikely. For those who don't know, TCMA is a system to shutdown a runaway engine that's not responding to the thrust lever - basic logic is an engine at high power with the thrust lever at/near idle, and the engine not decelerating. However, TCMA is
only
active on the ground (unfamiliar with the 787/GEnx TCMA air/ground logic - on the 747-8 we used 5 sources of air/ground - three Radio Altimeters and two Weight on Wheels - at least
one of each
had to indicate ground to enable TCMA). TCMA will shutdown the engine via the N2 overspeed protection - nearly instantaneous. For this to be TCMA, it would require at least two major failures - improper air ground indication or logic, and improper TCMA activation logic (completely separate software paths in the FADEC). Like I said, very, very unlikely.
I read one post in here of a 747 flaps retracting on takeoff. No Master Caution, no warnings. Apparently, due to some maintenance triggering a software glitch, the computer thought reverse thrust had been activated during a take off. Whether it was still in ground mode I don’t know.
Point is, being a software glitch in TMCA has already shut down two engines on a 787, I don’t see why the same or another software glitch in TMCA or somewhere else couldn’t do the same. Hadn’t this plane just been in for maintenance?
Last edited by T28B; 19th June 2025 at 17:05 . Reason: Formatting assistance
June 19, 2025, 16:54:00 GMT
permalink Post: 11906193
SLF Engineer(electrical -not aerospace) so no specialised knowledge of any kind.
The TCMA discussions on here seem clear that in normal operation the TCMA functions should not
operate in air mode and the TCMA has multiple inputs from various sensors (Rad alts, WOW sensors).
My query is to how these signals are routed to the engines, are they compared/aggregated in or routed through
the EE bays. If they are present in the EE bays then fdr's idea of a water leak at rotate into the EE bays
could generate shorts from the HV buses to the TCMA units.
Are the TCMA units designed to cope with 400V AC inputs where a low voltage input is expected.
I appreciate that the TCMA has to physically power a valve closed but applying high voltage to low voltage
logic circuitry might have unexpected consequences.
The TCMA discussions on here seem clear that in normal operation the TCMA functions should not
operate in air mode and the TCMA has multiple inputs from various sensors (Rad alts, WOW sensors).
My query is to how these signals are routed to the engines, are they compared/aggregated in or routed through
the EE bays. If they are present in the EE bays then fdr's idea of a water leak at rotate into the EE bays
could generate shorts from the HV buses to the TCMA units.
Are the TCMA units designed to cope with 400V AC inputs where a low voltage input is expected.
I appreciate that the TCMA has to physically power a valve closed but applying high voltage to low voltage
logic circuitry might have unexpected consequences.
The sensors and actuators related to that engine (pressure, temperature sensors, various valves etc.) are most likely directly connected to it. The two throttle position sensors per engine are also directly cabled to it according to tdracer. No idea how other inputs like WoW and RADALT are connected. The FADECs don\x92t necessarily need much else, as apparently Autopilot etc. always move the actual thrust lever.
There must also be a communication channel back to the flight recorders. No idea if it gets thrown into a comms bus or there is direct wiring.
In terms of power, each FADEC has its own alternator driven by the engine. But there\x92s a failover connection to the AC bus of the plane. Not sure if there\x92s a physical relay keeping it disconnected in normal operations.
June 19, 2025, 18:05:00 GMT
permalink Post: 11906239
Fuel valves and TCMA software updates?
Commanded engine cutoff - the aisle stand fuel switch sends electrical signals to the spar valve and the "High Pressure Shutoff Valve" (HPSOV) in the Fuel Metering Unit, commanding them to open/close using aircraft power. The HPSOV is solenoid controlled, and near instantaneous. The solenoid is of a 'locking' type that needs to be powered both ways (for obvious reasons, you wouldn't want a loss of electrical power to shut down the engine). The fire handle does the same thing, via different electrical paths (i.e. separate wiring).
As I've noted previously, a complete loss of aircraft electrical power would not cause the engines to flameout (or even lose meaningful thrust) during takeoff. In the takeoff altitude envelope, 'suction feed' (I think Airbus calls it 'gravity feed') is more than sufficient to supply the engine driven fuel pumps. It's only when you get up to ~20k ft. that suction feed can become an issue - and this event happened near sea level.
Not matter what's happening on the aircraft side - pushing the thrust levers to the forward stop will give you (at least) rated takeoff power since the only thing required from the aircraft is fuel and thrust lever position (and the thrust lever position resolver is powered by the FADEC).
The TCMA logic is designed and scrubbed so as to be quite robust - flight test data of the engine response to throttle slams is reviewed to insure there is adequate margin between the TCMA limits and the actual engine responses to prevent improper TCMA activation. Again, never say never, but a whole lot would have had to go wrong in the TCMA logic for it to have activated on this flight.
Now, if I assume the speculation that the RAT deployed is correct, I keep coming up with two potential scenarios that could explain what's known regarding this accident:
1) TCMA activation shutdown the engines
or
2) The fuel cutoff switches were activated.
I literally can come up with no other plausible scenarios.
In all due respect to all the pilots on this forum, I really hope it wasn't TCMA. It wouldn't be the first time a mandated 'safety system' has caused an accident (it wouldn't just be Boeing and GE - TCMA was forced by the FAA and EASA to prevent a scenario that had never caused a fatal accident) - and there would be a lot embarrassing questions for all involved. But I personally know many of the people who created, validated, and certified the GEnx-1B TCMA logic - and can't imagine what they would be going through if they missed something (coincidentally, one of them was at my birthday party last weekend and inevitably we ended up talking about what we used to do at Boeing (he's also retired)). Worse, similar TCMA logic is on the GEnx-2B (747-8) - which I was personally responsible for certifying - as well as the GE90-115B and the 737 MAX Leap engine - the consequences of that logic causing this accident would be massive.
As I've noted previously, a complete loss of aircraft electrical power would not cause the engines to flameout (or even lose meaningful thrust) during takeoff. In the takeoff altitude envelope, 'suction feed' (I think Airbus calls it 'gravity feed') is more than sufficient to supply the engine driven fuel pumps. It's only when you get up to ~20k ft. that suction feed can become an issue - and this event happened near sea level.
Not matter what's happening on the aircraft side - pushing the thrust levers to the forward stop will give you (at least) rated takeoff power since the only thing required from the aircraft is fuel and thrust lever position (and the thrust lever position resolver is powered by the FADEC).
The TCMA logic is designed and scrubbed so as to be quite robust - flight test data of the engine response to throttle slams is reviewed to insure there is adequate margin between the TCMA limits and the actual engine responses to prevent improper TCMA activation. Again, never say never, but a whole lot would have had to go wrong in the TCMA logic for it to have activated on this flight.
Now, if I assume the speculation that the RAT deployed is correct, I keep coming up with two potential scenarios that could explain what's known regarding this accident:
1) TCMA activation shutdown the engines
or
2) The fuel cutoff switches were activated.
I literally can come up with no other plausible scenarios.
In all due respect to all the pilots on this forum, I really hope it wasn't TCMA. It wouldn't be the first time a mandated 'safety system' has caused an accident (it wouldn't just be Boeing and GE - TCMA was forced by the FAA and EASA to prevent a scenario that had never caused a fatal accident) - and there would be a lot embarrassing questions for all involved. But I personally know many of the people who created, validated, and certified the GEnx-1B TCMA logic - and can't imagine what they would be going through if they missed something (coincidentally, one of them was at my birthday party last weekend and inevitably we ended up talking about what we used to do at Boeing (he's also retired)). Worse, similar TCMA logic is on the GEnx-2B (747-8) - which I was personally responsible for certifying - as well as the GE90-115B and the 737 MAX Leap engine - the consequences of that logic causing this accident would be massive.
I seem to remember Fred Dibner talking about how railway cars brake by draining the piston not by pressurising it, so trains will stop when supply lines break.
The electrical system updates to 787s for ADs and SBs - do any of these include software updates? For example the integer overflow causing GCU failsafe rectified under AD 2018-20-15. If so, who is writing and implementing these software updates? The original engineers? Their apprentices who had years long handovers? Or have they been outsourced and offshored? When these updates occur, does the entire system get tested and ratified or just the bit the bug fix is meant to fix? Because I\x92ve seen new bugs introduced by bug fixes in areas seemingly nothing to do with the original problem.
June 19, 2025, 19:18:00 GMT
permalink Post: 11906289
In the history of jet transport aviation, both ETOPS and non-ETOPS operations, exactly how many simultaneous dual engine failures have there been, excluding pilot causal ones? I\x92d venture it\x92s zero. Even the old DC-9/Boeing 727 era had none. ETOPS is 40 years on and zero cases, to my knowledge. Modern twins are systematically divided into two separate and independent planes. My bet is all these neat theories based on arcane questions will boil down to some human causal event, excluding Boeing. They might contributory, as in the Delta 767 where the switch design contributed to pilot misaction, but design fault, vanishingly improbable.
ANA NH-985, a 787-8, suffered dual uncommanded engine shutdown just after air-ground transition. That was a TCMS "feature."
Baltic BT-139 likewise, resulted in an FAA AD to upgrade FADEC software on a whole bunch of P&W engines.
It isn't unheard of. It may not have been seen at rotation before.
June 19, 2025, 20:35:00 GMT
permalink Post: 11906349
slf/ppl here - with a respectable amount of experience in software delivery for real-time/embedded/safety critical systems. Software development in this area really is an engineering discipline and bears no resemblance to common practice in other areas. Couple that with the requirements for function duplication/triplication, harness separation et al then IMHO the chances of FADEC etc software errors are effectively zero.
I'm commenting to make that point but also to link the videos and the FR-24 dataset - (below with my deltas for height/time added)
Extract from FR24 csv dataset
As noted in both threads to date everything was normal until it wasn't - the two values for fpm above are subject to FR24 variance of +/- 25' so even these suggest a normal climb at this stage of flight ca 2,000fpm. FR24 Lat/Longs all follow the centre line.
On this data the climb stops at around 70' AGL and electrical failure around 2s later. Again, as noted in the threads, this aligns with when gear up might have been expected. If the climb stopped because of fuel shutoff then 2s for spool down to electrical failure isn't out of the question.
Looking at the two videos.
The CCTV video indicates a total flight time, from rotation, of about 32s, subjectively levelling off ~14s after rotation.
The rooftop video has a flight time ~14s suggesting the video starts ~18s after rotation.
The rooftop video evidences the RAT as deployed from the beginning - meaning it must have been deployed by at least 16s after rotation - which aligns with the ADS-B indicated electrical failure.
If the forward flight recorder really is being sent to the US for recovery then it's reasonable to assume that the rear recorder contains nothing after the electrical failure and they are hoping the forward recorder captured something from the cockpit in the final 16s.
I don't have any experience of flight deck CRM but I don't see how those timings allow problem identification/misidentification and subsequent action - ie it wasn't down to the crew.
However:
The maximum aircraft height in the CCTV video, as judged by wingspan, appears higher than 71' - though it is certainly less than a wingspan height at the beginning of the rooftop video.
I haven't seen, in the threads, any statement of what happens on the flight deck with a total electrical failure - is it a 4s blackout whilst the RAT deploys and systems restart? - or are there batteries that keep something alive?
I'm commenting to make that point but also to link the videos and the FR-24 dataset - (below with my deltas for height/time added)
Extract from FR24 csv dataset
As noted in both threads to date everything was normal until it wasn't - the two values for fpm above are subject to FR24 variance of +/- 25' so even these suggest a normal climb at this stage of flight ca 2,000fpm. FR24 Lat/Longs all follow the centre line.
On this data the climb stops at around 70' AGL and electrical failure around 2s later. Again, as noted in the threads, this aligns with when gear up might have been expected. If the climb stopped because of fuel shutoff then 2s for spool down to electrical failure isn't out of the question.
Looking at the two videos.
The CCTV video indicates a total flight time, from rotation, of about 32s, subjectively levelling off ~14s after rotation.
The rooftop video has a flight time ~14s suggesting the video starts ~18s after rotation.
The rooftop video evidences the RAT as deployed from the beginning - meaning it must have been deployed by at least 16s after rotation - which aligns with the ADS-B indicated electrical failure.
If the forward flight recorder really is being sent to the US for recovery then it's reasonable to assume that the rear recorder contains nothing after the electrical failure and they are hoping the forward recorder captured something from the cockpit in the final 16s.
I don't have any experience of flight deck CRM but I don't see how those timings allow problem identification/misidentification and subsequent action - ie it wasn't down to the crew.
However:
The maximum aircraft height in the CCTV video, as judged by wingspan, appears higher than 71' - though it is certainly less than a wingspan height at the beginning of the rooftop video.
I haven't seen, in the threads, any statement of what happens on the flight deck with a total electrical failure - is it a 4s blackout whilst the RAT deploys and systems restart? - or are there batteries that keep something alive?
June 19, 2025, 22:31:00 GMT
permalink Post: 11906447
June 19, 2025, 22:44:00 GMT
permalink Post: 11906458
Possibly alluded to earlier, but on many aircraft to prevent an inadvertent shutdown, the Engine Run/Stop switch is effectively ignored by the FADEC if the thrust lever isn't at idle - do we have a 787 driver that can confirm this?
Last edited by Senior Pilot; 19th June 2025 at 22:44 . Reason: Eluded?
June 19, 2025, 23:16:00 GMT
permalink Post: 11906475
If so , the likelyhood of this having anything to do with the switches, their harness, or connectors drops way down. (although most theories are dealing with statistical "impossibilities", what better time than after decades for such to occur.)
The switches are double on's or 4 pole, that means they are (can be) connected to 2 different systems individually. Anyone know how that system looks? Why 2 signals?
June 20, 2025, 03:41:00 GMT
permalink Post: 11906563
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
June 20, 2025, 04:18:00 GMT
permalink Post: 11906574
Just so I have this clear, are you saying that the implementation of the TCMA functionality involved
no
new components being added to the pre-existing FADEC? Are you saying, in effect, that the two switch relays described in the TCMA patent application, which relays and their configuration achieves the described two channel redundancy, were already there as components or are mere depictions of what the software does itself?
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
It uses existing thrust-lever-angle inputs, existing N1 inputs, and (presumably) existing WoW inputs, does software stuff inside the ECU, and if necessary uses the existing overspeed cutout outputs to stop the engine.
June 20, 2025, 04:31:00 GMT
permalink Post: 11906582
That is interesting. I'll wait for ignorantA's or tdracer's confirmation (though not suggesting you are wrong, Someone Somewhere). The 'bottom line' would nonetheless seem to remain that the TCMA software, at least, is common to both TCMA 'channels' in the FADEC on both of the engines. Not one piece of software, but presumably two (or four?) identical copies of the same software. Of course, given the stringency of the DO-170B and C software development process and the brains that work on this stuff, the probabilities of the TCMA software directing a shutdown when the conditions for it do not exist are extraordinarily remote.
June 20, 2025, 04:57:00 GMT
permalink Post: 11906593
Just so I have this clear, are you saying that the implementation of the TCMA functionality involved
no
new components being added to the pre-existing FADEC? Are you saying, in effect, that the two switch relays described in the TCMA patent application, which relays and their configuration achieves the described two channel redundancy, were already there as components or are mere depictions of what the software does itself?
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
That is the implication I have heard all along, particularly from tdracer's posts.
It uses existing thrust-lever-angle inputs, existing N1 inputs, and (presumably) existing WoW inputs, does software stuff inside the ECU, and if necessary uses the existing overspeed cutout outputs to stop the engine.
It uses existing thrust-lever-angle inputs, existing N1 inputs, and (presumably) existing WoW inputs, does software stuff inside the ECU, and if necessary uses the existing overspeed cutout outputs to stop the engine.
The air/ground signal would've already been present as well. It would be needed for switching between ground idle, flight idle, and approach idle. Tdracer has discussed that as well, in past threads.