Page Links: Index Page
JustusW
2025-06-13T16:31:00 permalink Post: 11900677 |
Correct, but if they retract flaps while the engines are producing takeoff thrust and they are somehow losing altitude they definitely should speed up.
There are strong reasons to doubt the flaps had anything to do with the accident, I agree with the following sentiment completely: I was taught (only as familiarization for my job as ATC) that during takeoff the pilot flying should have their hand on the throttle levers. Is that generally correct? If yes, will changes to throttle settings always be reflected in the actual physical position of the throttle levers or are there situations where the actual commanded throttle could differ from the physical lever position? The interaction with the TCMA in particular is of interest to me. Regards, Justus Subjects: TCMA (All) 1 user liked this post. |
JustusW
2025-06-16T09:42:00 permalink Post: 11903330 |
Im a layman who knows nothing and am just a PPL and am fascinated by the technicals.So does the computer store the recommended flap setting given all the information entered and then decide whether the actual setting used is appropriate and spits out a warning of checklist complete?what would happen if use of the full runway was entered into the computer, but actually they entered at an intersection, surely the info would be wrong ?...
In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end. Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground. Subjects: ADSB Flap Setting Flaps (All) FlightRadar24 1 user liked this post. |
JustusW
2025-06-16T09:42:00 permalink Post: 11903756 |
Im a layman who knows nothing and am just a PPL and am fascinated by the technicals.So does the computer store the recommended flap setting given all the information entered and then decide whether the actual setting used is appropriate and spits out a warning of checklist complete?what would happen if use of the full runway was entered into the computer, but actually they entered at an intersection, surely the info would be wrong ?...
In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end. Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground. Subjects: ADSB Flap Setting Flaps (All) FlightRadar24 |
JustusW
2025-06-20T17:45:00 permalink Post: 11907155 |
1/Would the recorders lose access to aircraft data streams when engine power is lost, at least temporarely making the cockpit area mic recorded by battery power on the front recorder the only source of information ?
2/The recorders only draw 20W, why is it the front with reserves only for 10 minutes? Can you even buy a battery that small giving 28VDC? Why is such a limited solution selected? ( For reference, This battery gives about 9 times that: <url removed> ) Regarding the recording feature, there's three types of microphone commonly used nowadays: Condenser and Ribbon type are somewhat fragile and require power to record audio while Dynamic type is basically a reverse speaker and is considered rugged. There's an off chance that a Piezzo microphone would be used here as they are basically indestructible but usually reserved for recording while in contact with a large sound transducer. My guess based on that is that we're looking at a dynamic microphone with a run of the mill preamp. Depending on the actual electric setup this would yield a handful of different possible installations: 1) The "Cockpit Area Microphone" (hereby christened CAM because I like abbreviations) is a self contained unit consisting of a Microphone, a preamp and AD converter. This would mean while provided power the digital recording could be passed to either EAFR. 2) The CAM is a self contained unit consisting of a Microphone and a preamp. This would mean while provided power it could send an analog audio signal to the forward EAFR no problem, but would potentially struggle generating enough of a signal to be picked up by the rear EAFR. 3) The CAM is just a Microphone. This would mean it requires either no or very little power (even Condenser Mics usually require only Milliwatts) but the signal would be very hard to send over long distances and would require the EAFR to have a preamp. In general it is audio engineering 101 to place a preamp as close to the source as possible to avoid noise. Thus I would rule out 3. It has both ups and downs to convert the analog signal to a digital signal, and there is a possibility they'd do both. In either case I am confused from an audio engineering standpoint why the rear EAFR would not pickup audio from the CAM if the forward EAFR does. Unless the rear EAFR is fed (audio) data only via BUS, which would be an interesting choice. Also keep in mind that historically the CVR was also located in the tail section and very much received an analog signal over the entire distance. There's really no technical reason this wouldn't be possible, I routinely use far longer cables when running audio signals at concerts and those can't use compression because it would dumpster sound quality. So, yeah, I don't understand why there would be a mismatch between the recordings of either EAFR, unless there was something else preventing all signal transmission towards the rear EAFR. The CVR in the rear has been a thing for 80 years now. Regards, Justus Subjects: Air Worthiness Directives CVR EAFR 2 users liked this post. |
JustusW
2025-06-21T17:04:00 permalink Post: 11907907 |
When we say "Software" we mean things like this:
if ( happy == true ) {
print("I'm happy!" } In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with. In a normal computer we simply translate code like above into something less human readable but instead interpretable by a microchip or the like. This "machine code" is then run sequentially and does whatever it is meant to do (hopefully). If we were to expand our little happy check above with another condition then our computer would sequentially check these conditions. This opens up a lot of hoopla about timing, especially when interacting with the real world. Let's say you want to track N1 and N2 in an engine. You'd have to make a measurement, that value would have to go through an AD converter, which writes it to some (likely volatile) storage, where it is then accessed by some sort of (C)PU, transferred to yet another piece of volatile memory and then used in the computation. This takes time because you can't do those things within the same clock cycle. Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine. Enter the FPGA. While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check. This is very useful for our Turbine Engine, because now we can verify that N2 is smaller than X without delaying our check that the Throttle Control Lever setting is within acceptable distance to N1 and N2, while also creating the appropriate output for all the different bypasses and bleed valves in a modern engine, and so on. The Safran FADEC 3 does this "up to 70 times per second" as per the vendor. In order to be manageable the actual FADEC consists of multiple different pieces, many of which are FPGAs. At least two are used for so called "input conditioning". This is where we deal with converting messy real world values from sensors subject to real physics into nice and clean numbers. Here our values from the Throttle Control Levers come in, the signal from our N1 and N2 sensors, WOW signal, and on, and on, and on. This is then changed into logic level signals provided to a different set of FPGAs. Lacking an actual schematic I suspect that this is what sometimes is referred to as "channels". The channel could consist of both a signal conditioning stage and then a logic stage or (more likely) redundant signal conditioning stages feed separately into separate FPGA "channels" are evaluated and then the end result is likely put into yet another FPGA for control output generation. Why is this important? Because it is basically impossible for a "bug" to exist in this system. These systems are the epitome of a dumb computer. They do _precisely_ what they are meant to do. The TCMA is simply a set of conditions evaluated just like any other condition in those FPGAs. If there is an "error" then it is in the requirements that lead to the truth table used by these devices but never in the truth table itself. In fact these types of computation device are used precisely because of that very property. So when people say "the FADEC software" (ie TCMA) has "failed" or "has a bug" what they're really saying is:
The conditions that were experienced in the real world by the system were incorrectly assessed in the system requirements and lead to an undesired output state when taking into account the real world result we would have preferred.
A bit of a mouth full, granted, but an important mouth full. This simply wouldn't be someone missing a semicolon somewhere in a thousand lines of code.
Regards, Justus Last edited by T28B; 21st Jun 2025 at 17:25 . Reason: Formatting making this easier to read for the layman. Nice post. Subjects: Air Worthiness Directives FADEC TCMA (All) 26 users liked this post. |
JustusW
2025-06-21T20:40:00 permalink Post: 11908040 |
Sadly I'm unable to post links or I would have done so in my original post.
![]()
I ask because when I look for info about FADECs generally and FADEC 3 more specifically, I find this kind of documentation (notice the mention of FADECs in the lower left corner):
... which is part of a larger Powerpoint presentation by Ansys, explaining that these products are developed with SCADE development workbench, generating either Ada or C code, and that the resulting code runs under a microkernel realtime operating system:
Now, obviously enough, a CPU can be embedded in an application-specific FPGA, but it would still execute machine code. And from my experience in other embedded systems development, current CISC or RISC CPUs have more than enough computation power to implement command and control on a modern turbofan.
But maybe I should explain how I've arrived at the post above. I've basically spent the past few days on and off scavenging anything I could find on the 787 FADEC specifically. It was mentioned in this thread or the old one that the 787 uses the Safran FADEC 3, so my primary jumping off point was the Safran website and the information available on it. That plus a couple of press releases namely by Actel about their flash-based ProASIC3 and ProASICPLUS FPGAs was the evidence I used to arrive at my conclusions above. I can't for the life of me find the quote about the dual signal conditioning FPGAs anymore, but they are in there as far as I can tell. Overall information on the actual inner workings of these things are so sparse that outside of a few patents (keyword: configurable CPU) I was hard pressed to find anything at all to be honest. This all not being helped by me now finding references to my own post, thus having created my very own Woozle. Hooray.
Whilst you\x92re right to highlight the type of software in a FADEC, it should also be recalled that after the dual uncommanded engine shutdown event on the Baltic CS300, the FAA mandated updated FADEC software for all of a family of P&W engines. FADEC s/w can contain what we\x92d call bugs (whether they\x92re mistakes of coding or mistakes of logic in the design assumptions).
"it is basically impossible for a "bug" to exist in this system." This is not my experience.There are a lot of bugs in hardware and FPGAs. The guys doing this are real experts and bugs are less common than in software. But they do exist and they can be difficult to reproduce and subtle to diagnose. For someone new to FPGA it can be very intimidating because everything is parallel. It requires a different way of thinking. You can execute 1000 instructions simultaneously.Then various tricks to speed things up or reduce glitches add complexity. For example you may want to count in gray code or one hot instead of binary. Writing bug free FPGA code is very challenging. We cannot assume the FPGA code is free of bugs.
Now, in normal "everyday" usecases I'd fully agree with you, but in case of the FADEC we're talking about an FPGA with logic condition tables where every line is likely to have its own separate binder of engineering notes, discussions and recommendations. It is there where any "error" or "bug" is most likely to reside by a considerable margin.
Now, I am sure that the state of the art has moved on a lot since I was heavily involved in this sort of engineering but I can say that when my colleagues were prototyping ASICs (which are application specific devices that are not programmable like an FPGA) using FPGAs because it can be reprogrammed to cure bugs found in the code that created it I am absolutely sure that it is possible for a latent bug to exist in what has been built despite extensive testing being carried out. I well remember sitting down with an FPGA designer and a software engineer and showing them a situation where one of my radio devices was not being commanded to transmit, they refused to believe me until we captured their output signals in the failed state and I was thus able to prove to them that it was their logic and code that was failing and that my radio system was fully working except it couldn't possibly transmit when its enable line was inactive.
I would therefore never state that an FPGA-based FADEC is infallible. The devil will be in the detail of the functions contained within the devices and how they interact with each other and how the original logical functions are described and specified and then coded and checked for logical errors before getting on to the actual physical reality of the FPGA manufacturer's design and development system that bolts on to the back of the source code. If the FPGA devices are being pushed anywhere near the edge of their performance envelope, just like an aircraft things can go wrong. If a design begins with a device that is only just large enough in terms of how many logic blocks and routing channels are available for the logic required it's almost a certainty that development will take it to this area of its performance and a lot of tweaking may be needed which means that even more testing will be needed to be reasonable sure that it does what it is supposed to. In the end I hope it was useful for understanding where the reluctance of apportioning blame to these systems originates and ​​​​at the same time talk about some pretty nifty tech that I know few Software Engineers will ever deal with in their entire career. I do still find the idea of a fault (with the understanding above of where that fault originates) in the FADEC a convincing possibility, it's merely the nature and location of that fault that I felt could benefit from some more specifics in regards to the nature of how they were most likely to actually happen. I would love to actually hear more about how the FADEC 3 is structured internally and which components it uses, but I suspect that those who know are under NDA. Regards, Justus Subjects: EDML Engine Failure (All) Engine Shutdown FAA FADEC 3 users liked this post. |
Page Links: Index Page