Tech Log The very best in practical technical discussion on the web


Old 15th Jun 2009, 20:56
  #1621 (permalink)  
Join Date: Jul 2002
Location: Confusio Helvetica
Posts: 311
Likes: 0
Received 0 Likes on 0 Posts
Right on, PJ2.

One detail though (and this also addresses PBL's quandary): there is out there a reasonably-sized data set for ACARS messages sent during A330 pitot-tube icing events. Air Caraibes had a couple of cases (although from the report pasted, the principal diagnostic detail was the early rudder travel limiter fault). Air France had something like 6, and they obviously have the ACARS messaging practices that interest us. Presumably, other carriers should have something analogous.

So, while everyone's running around crowing about a cause, I'd suggest that, if that is the cause, someone has a body of information with a good shot at confirming or falsifying the hypothesis pretty quick. While it helps to do the piece-by-piece analysis, it helps even more to associate the whole list of messages with similar cases where the cause is known.

...not that we have access to that sort of information, mind you, but someone who did might find it illuminating.
DingerX is offline  
Old 15th Jun 2009, 21:09
  #1622 (permalink)  
Join Date: Jun 2009
Location: LA
Age: 73
Posts: 50
Likes: 0
Received 0 Likes on 0 Posts
How are AirBus rudder pedals set up?

This is a question from the unknowledgable trying to obtain knowledge by asking those who know. An explanation or a pointer to some available document would be greatly appreciated.

In the kinds of planes I know about the rudder pedals are pretty much at the ends of your legs, and you adjust them so you comfortably have full rudder travel even with the sholder harness and belt tightened.

But I've read here that transport pilots only use the rudder on takeoff and landing, and at any other point using the rudder is stupid and dangerous; you only use ailerons. (If this is incorrect I'd appreciate enlightenment, but I've read this in basically these words at least 3 times in this thread.)

If you don't use the rudder in cruise, are you still using the pedals as footrests? Do you have other footrests you can use instead? Is there a pedal disable button to turn them into footrests?

I'm sure from the kind of responses I see here to questions that many people will read this question as pushing some agenda and get angry about it. I'm not pushing an agenda. I'm asking what you do with your feet in cruise to make sure you don't input rudder movements. Is there anytihng in the design of the cabin and controls to help you, or do you just have to be consious to never move your feet? This isn't a problem with toy planes, because you most often do use the rudder in them.

Thanks, and have a nice day!
WhyIsThereAir is offline  
Old 15th Jun 2009, 21:12
  #1623 (permalink)  
Join Date: Jun 2009
Location: Chelan, WA
Age: 47
Posts: 43
Likes: 0
Received 0 Likes on 0 Posts
FBW, IT, and situation awareness

A couple points about FBW systems (I do some embedded/control sytem work, not FBW, but close enough I feel able to dispel some misinformation here). Personally I don't think FBW-issues are at all likely factors in this accident though autopilot/autothrust might be (However, in non-FBW systems these would be factors too).

The idea that it takes something like a million lines of code to automate flight is based on a number of logical mistakes. I don't doubt that once one starts adding more complex elements of avoinic systems, it might approach a million lines of code, but, this is somewhat meaningless. In short folks assume that airplane avionics control software and Microsoft Windows face similar challenges because they are both "software." Actually, this is not the case. (I have done testing on some versions of Microsoft Windows, and some embedded system design, so...)

The first thing is that software engineers who are going to work on a specific problem are going to have to understand the nature of the problem well enough to have intelligent governsations with specialists as to finer points. Specifications need to be understood in context, and software engineers need to be involved in the specification process. The idea that avionics systems are designed by folks who have no general aviation knowledge is silly (and there would have been a lot more accidents if this were the case).

The second thing is that most of the avionics units are actually going to be reasonably simple matters of sensor input and data output. ADIRU's, the TCAS, VSC, etc. all fit into this category. These systems can be validated both symbolically and via automated testing in ways that general-purpose computer programs can't. A simple rule to bear in mind here is that the effort required to validate software is proportional to 2^n where n represents the compexity of input. Simple input means robust testibility. ADIRU systems for example, would have reasonably simple inputs. Also simple inputs have the advantage in that it is practical to symbolically analise source code here to determine that it WILL handle all sensor input appropriately. Some systems seem less subject to full validation (TCAS systems for example) than others (ADIRU's, for example).

However, since one system's output is usualy an input elsewhere, more restricted output improves testability of the entire system.

Controllers, such as those found in avoinics systems, are remarkably simple, testable, and even verifiable via non-testing methods in a way that general purpose computer software is not. Embedded controllers are everywhere-- in our offices, cars, homes, etc. and have been shown to be reliable. Some elements may still be beyond testability (in particular, you can't protect against sensors inputing consistently incorrect data in this way, nor can you rule out every possible timing issue, but you CAN experientially and even mathematically prove that correct inputs will be acted on correctly).

Now, I do see one POSSIBLE issue with computerized systems in the AF447 incident involving the issues of self-healing systems. Pitot icing detection works on the assumption that there are at least mild differences in severity in the icing in different tubes (hence different stagnation pressures detected). The computers typicaly vote out the outlying system and in this case, this can be dangerous because it is possible that the outlying system is more correct than the two (more consistently iced up) tubes report. In this case, autothrust might have been increased prior to autopilot disconnect and the plane might have been going substantially faster than anyone understood at the time it was handed back to the pilots.

All in all, I think it is possible that self-healing element of FBW systems played a role in this incident. However, this isn't a matter of a bug or a glitch but rather the (human) difficulty in maintaining situation awareness with a computer with which one interacts in limited ways. Such degraded situation awareness may have been a contributing factor. I don't think this means that systems shouldn't be self-healing, but rather that pilots might do well to have more transparent diagnostic information available to them (including outlying readings from instruments).
einhverfr is offline  
Old 15th Jun 2009, 21:22
  #1624 (permalink)  
Join Date: Apr 2009
Location: Petaluma
Posts: 330
Likes: 0
Received 0 Likes on 0 Posts
PJ2 I do not wish to put you on the spot.

Can you direct me to information I can assimilate that will answer a few basic questions re: AB a/p disengage and degrade to Alt Law, and the parallel and exquisitely important well studied and trained for reaction by human crew who, after disc a/p must fly the a/c at a higher skill level than the just abandoned automatics, and do so without aileron, a taste of Pitch trim, and a Rudder that deflects to a predetermined value, however appropriate?

Bear with me. I am understanding that with autos on in cruise, and a programmed set of predetermined limits relative to G, roll, (rate and limit) and protections, there is a point at which the a/c logic abandons a challenging controlled flight regime to pilots whose skills are doubted enough to recommend that a/p not be disconnected, and the computer disconnects due to unreliable airspeed data? It may seem untoward, but I get the distinct feeling that at auto disconnect, the a/c is trying to escape some kind of Blame for what may ensue.
Will Fraser is offline  
Old 15th Jun 2009, 21:53
  #1625 (permalink)  
Join Date: Jun 2009
Location: Eindhoven, NL
Age: 58
Posts: 6
Likes: 0
Received 0 Likes on 0 Posts

Okay, before you read any further: I'm not a pilot. Nor an air crash investigator. Nor is English my native tongue. And this is my first posting here. Feel free to skip.

After reading this forum for some time now (and learning a lot) and since whatever any of us offers as an explanation no one knows the true chain of events, I venture to vent mine. Pure speculation. I would like answers to my four questions though.

Some questions I would like to ask first:

a) What happens when two of three systems monitoring flight parameters break down simultaneously and in a similar manner? What would the flight computers decide? Would the one remaining system deemed defective?

b) How severe can a lightning discharge be? Could it damage (melt) parts?

c) Could severe movements of the plane cause the ISIS gyro to produce an error condition?

d) Could a lightning discharge through the plane cause confusion in the TCAS?

I realise that the ACARS messages are not necessarily in exact chronological order. But what about the following sequence. Only logical if the answers to these questions is YES.

1) Auto Pilot switches off because of severe turbulence conditions caused by the lightning storm. More turbulence causes ATHR to switch off as well. Since both are 0210 time stamped I find it hard to believe that the pilot switched ATHR off (unless the pilot switched both AP and ATHR off intentionally).

2) A huge horizontal lightning discharge enters pitot tube on one side of the plane and leaves the plane at the other side by the pitot tube on the other side. Both are fused (partly) closed. Is this possible? Lightning does like sharp points.

3) The pilot flying is startled so much by the lightning discharge that by reflex he puts his feet down stepping hard on one of the rudder pedals.

4) The lightning discharge's induced heat confuses the outside air temperature sensor.

What happens next?
ernst_mulder is offline  
Old 15th Jun 2009, 21:57
  #1626 (permalink)  
Join Date: Jun 2009
Location: Barcelona(Spain)
Age: 49
Posts: 4
Likes: 0
Received 0 Likes on 0 Posts
You keep throwing theories like crazy... Hoping that eventually someone will nail it provided you keep trying long enough.

It won't work! Dont you understand?

You build a theory and then try to match to facts to it and if there are no facts you invent them. Science works the other way, letting the facts tell the story and then explaining why, how, and so on.

This post has reached a point where it is self-sustained. The facts dont matter anymore, just with speculation and debunking speculation there is enough to keep it growing.

Even if no new evidence is ever found and therefore no new fact can be extracted this post will keep growing and growing out of shear speculation.

Joss is offline  
Old 15th Jun 2009, 22:11
  #1627 (permalink)  
Join Date: Jun 2009
Location: Midpines, CA
Posts: 56
Likes: 0
Received 0 Likes on 0 Posts
To those bemoaning FBW your ancestors probably expressed the following:

Why would I want to abandon wing warping for those flappy new hinged control surfaces, what if they fall off?

Retractable gear! No way, what if those darn things won't come down?

Enclosed canopy, what if I need to jump out?

Hydraulics, there is no feel, give me cable all the way!

Like it or not computers are progress and likely inescapable. Ask the B-2 or F-117A pilot who rely upon them even more.

Like any "new" technology there will be bugs, but in the end future pilots will just see them as the way things are, and be busily complaining about wing mounted solar panels, or fusion reactor heat issues.
ACLS65 is offline  
Old 15th Jun 2009, 22:18
  #1628 (permalink)  
Join Date: Jun 2006
Location: Canada
Posts: 94
Likes: 0
Received 0 Likes on 0 Posts
There are 2 places to stick your feet when not in use.

Jetdoc is offline  
Old 15th Jun 2009, 22:23
  #1629 (permalink)  
Join Date: Jun 2006
Location: Canada
Posts: 94
Likes: 0
Received 0 Likes on 0 Posts

I think what you have got there is the AMM references for the maintenance of those components, not fault codes.
Jetdoc is offline  
Old 15th Jun 2009, 22:25
  #1630 (permalink)  
Join Date: Jan 2008
Location: Bracknell, Berks, UK
Age: 52
Posts: 1,133
Likes: 0
Received 0 Likes on 0 Posts
Quite true. But, I have read enough from those that HAVE flown these types to know that I'm glad I never had to. It is utterly amazing to read the differences expressed by those that fly these things as to how various systems operate. There are disagreements everywhere. The manuals are simply too full of information that not even a computer scientist could possibly remember/recall in the time of need. Who ever heard of an aircraft having THREE different flight control laws?!

Whatever happend to AF447, apparently happend so fast, the crew had no chance to sort out all the warnings being displayed on their panel. They probably had no chance to simply FLY their aircraft.
Whenever I read these loooong threads about crashes, and the myriad of people complaining about non-professionals putting in their 2p worth, previously i've wondered if people have too short a fuse. Now however you're talking my specialist subject, and i'm biting my tongue a bit on the relative opinions expressed on computer-related flight systems.

What I will say however is that I agree with this quote - i.e. despite the slow creep of computer systems into flight, it's obvious that the knowledge and workload on the average Captain & F/O are at times still way too high to be able to "just fly the aircraft" when needed.

I will stop short of suggesting that it's human preconception that is stunting the introduction of more computerisation into systems, but i'm willing to bet that those people thinking "computers" are thinking "MS Windows and blue screen of death", and in that sense you couldn't be comparing apples and oranges much harder if you tried.

Granted it's not all there yet, but i'd state it's not far off. For instance, in this day and age it shouldn't be beyond the wit of man to be able to reliably plot where you are on the planet in the X, Y, and Z plane, and given the satellite height data of the globe it's therefore almost inexcusable (IMHO) that we still have interfaces with the terrain. That's a pretty facile example, but you get where i'm coming from.

Maybe in a forum of pilots it's a pretty unpopular stance to take, arguing that computer control could probably do the job in the long run, but step back 50 years and see where we've come from there. Now step forward 20 years and you're probably going to find more and more of your beloved flight controlled by computers. It's something you might hate, but it's a trend that's only going one way IMHO. Thankfully, it's going the same way as the safety figures, and I for one am pretty sure there's more than just a vague relationship between the two.

Anyhow, this is drifting about as off-topic as it could get, and so i'll end it here as it's probably a thread in it's own right and I really wouldn't want this to turn into a s**tfight either. In fact, if you want to reply to this one, take it to a new thread - I encourage it
Mike-Bracknell is offline  
Old 15th Jun 2009, 22:28
  #1631 (permalink)  
Join Date: Sep 2008
Location: MI
Posts: 570
Likes: 0
Received 0 Likes on 0 Posts
ACLS65 -

One of the problems with this "progress" is that the only ones benefiting from it are the manufacturers. The airlines are in hock up to their ears buying all this new equipment trying to convince their passengers that they are equipped with the latest. The airlines have to cut costs to pay for all this. Whereas you could pull up to the gate in a DC-3 and people would still get on. FBW has its place, no doubt. But it was NEEDED to control high performance aircraft, not airliners.

As to: "Like any "new" technology there will be bugs..." The 'bugs' were pretty much taken care of with the "old" technology. Why put passengers through yet another learning process?

Whether or not new or old, we still have to get around the "pilot error" issue somehow, don't we? I'm not saying that was an issue with AF447, but there WERE other aircraft in or near that area in the same time frame that seemingly got through with no trouble. So.....was the crew at fault, or their systems, or the weather? Sadly, we will probably never know, as even if the recorders are recovered from, what is it, 12,000 feet?!, the data might not be useble.
DC-ATE is offline  
Old 15th Jun 2009, 22:33
  #1632 (permalink)  
Join Date: Jun 2009
Location: California
Posts: 30
Likes: 0
Received 0 Likes on 0 Posts

And these files are surprisingly small. William Cecil, marketing manager of data acquisition and wireless solutions at Teledyne Controls, estimates that the flight recorder on an Airbus A320 or Boeing 737NG accumulates 1.8 MB of unformatted data per flight hour.

Packets of raw engine data amount to as much for an entire flight. Even so, potentially useful flight data is frequently minimized, postponed or forgotten.

Why are operators so miserly with MRO data? Because ACARS is narrow-band ("an extremely slow, skinny pipe," Teledyne's Schmitz called it) and pricey. Messages are limited to blocks of 220 characters, one block at a time, up to a maximum of 16.

Throughput in VHF mode is 2.4 kilobits per second (kbps), the rate of an antique modem. Even VDL Mode-2, a recently introduced VHF variant with 10 times the bandwidth, clocks in at only 30 to 40 kbps.

Usage charges vary with a variety of considerations, including message size and communications channel, and prices have been falling under pressure from VDL-2 and Iridium's new satcom option. Still, the range is roughly five cents a message (VHF) to between $1.50 and $20 per minute (satcom).

In addition, Bob Bouchard, vice president of technology solutions at The Longbow Group, questioned ACARS's reliability: "A Wi-Fi or cellular connection uses standard TCP/IP. If a file is skipped, it resends it.

If it's missing, you'll know. With ACARS, you send a message hoping there's a ground receiver and really no acknowledgement it was received."
Given these technical limits, the possibility of using ACARS for sizable or continuous MRO data transfers is, William Cecil said, "a dream."

In-Flight Datalinks

Data rate per second, Range

ACARS (Satcom)9.6kglobal
ACARS (VHF)2.4k240 mi
ACARS (HF)0.18k5,000 mi
ACARS VDL Mode-2 (VHF)31.5k240 mi


OverHaul & Maintenance, Jan 1, 2008
Towhee is offline  
Old 15th Jun 2009, 22:34
  #1633 (permalink)  
Join Date: Mar 2009
Location: Phoenix, AZ USA
Age: 65
Posts: 0
Likes: 0
Received 0 Likes on 0 Posts
Like it or not computers are progress and likely inescapable. Ask the B-2 or F-117A pilot who rely upon them even more

The difference is that the FBW software in the above isnt trying to "protect" the airplane from the pilot. I think that one inescapable question in this incident is what role the complexity of the software contributed to the end result. In some ways this reminds me of the conflict between the original astronauts and the NASA. My humble opinion is when in doubt you need better pilots, not more complicated software. When it all goes south the guys in the pointy end still need "the right stuff"...not the "right OS"
SLFinAZ is offline  
Old 15th Jun 2009, 22:40
  #1634 (permalink)  
Join Date: Jun 2009
Location: Chelan, WA
Age: 47
Posts: 43
Likes: 0
Received 0 Likes on 0 Posts

I actually see FBW as being driven by something else entirely: need to save weight and reduce operating expenses.

I don't know of anyone who prefers to fly on an A330 vs a B747 just because the A330 is a more recent model. People choose the flights. Then the airline chooses the plane to match the flight.

One funny experience though flying from Denpasar to Jakarta a couple years ago on Merpati Airlines (shortly before Indonesia tightened age limits on commercial airplanes)... The plane B737) was really late. We got on the plane and I looked out the window. Then I said to my wife, "This plane is older than I am." I knew this because the engines were simple turbojet engines with no fan bypass. It was a different experience than I was used to also. Much more smooth acceleration (probably because turbofan engines provide much more thrust at slow speeds).

FBW is the future. That is fine. But I don't think anyone is in a hurry to retire serviceable, airworthy, and legal airplanes just because a new technology comes out.
einhverfr is offline  
Old 15th Jun 2009, 22:41
  #1635 (permalink)  
Join Date: Feb 2009
Location: UK
Posts: 11
Likes: 0
Received 0 Likes on 0 Posts
Post-mortem teeth colouration

Here's a extract from a scientific reference to show that teeth discolouration in the dead is normally found after prolonged water immersion and is not normally a conclusive indicator of cause of death.

Full abstract is here - Medico-legal aspects of postmortem pink teeth. [Int J Legal Med. 1994] - PubMed Result

Borrman H, Du Chesne A, Brinkmann B. Medico-legal aspects of postmortem pink teeth. Int J Legal Med 1994;106(5):225-31.

"Except for very few and poorly documented exceptions, [pink teeth] develop earliest after 1 to 2 weeks postmortem.

...they are most often associated with water immersion.

The phenomenon is very often seen in victims of drowning where the head usually lies in a head-down position.

Since, there is no obvious connection between the occurrence of pink teeth and the cause of death, it may be concluded that pink teeth are not pathognomonic for a specific cause of death and this is therefore an unspecific phenomenon."

Last edited by Sparelung; 15th Jun 2009 at 22:59.
Sparelung is offline  
Old 15th Jun 2009, 22:54
  #1636 (permalink)  
Join Date: Jun 2009
Location: ARN / STO
Age: 67
Posts: 9
Likes: 0
Received 0 Likes on 0 Posts
Query of temp sensor + footprint link ACARS:

Not a pilot, but I checked all pages and nobody has looked into this before:

Does anyone here know the timing-specs of the temp sensors on an A330 ?

As all temp sensors has an delay-time of x seconds (average 10-40 sec if change is over 20 Celcius directly) before indicating the correct temp when major changes occur in temp, it may could be one more source to the trouble for this flight with all the previous details of this flight such as coffin-corner and flying into a cb area with possible warmer zones.

Edit: Enclosing footprint map of Inmarsat/Satcom were ACARS is used, have a look on the AOR-area, it may be possible that the flight also entered a poor-reception area in itīs final stages.

Last edited by Art-Deco; 16th Jun 2009 at 00:05.
Art-Deco is offline  
Old 15th Jun 2009, 23:03
  #1637 (permalink)  
Join Date: Jan 2008
Location: South East
Age: 54
Posts: 42
Likes: 0
Received 0 Likes on 0 Posts
The Facts So Far Please...

Sorry lost track after 1600+ posts,

So could someone please just outline the actual facts that are known at this point of time please.... what ACARS ECAM/Fault messages have been published (and from the experience i have on Airbuses, don't mean a lot with respect to what systems are actually doing), what remains of the airframe/engines (presumably none for the GE's) have been found, how the location finding is going with respect to the DFDR/CVR and what Airbus/ the Airworthiness authorities have relayed to operators so all the guessing / expert analysis can be put in it's rightfull place....
Alwaysairbus is offline  
Old 15th Jun 2009, 23:14
  #1638 (permalink)  
Join Date: Jun 2001
Location: East of the Sun & West of the Moon
Posts: 286
Likes: 0
Received 0 Likes on 0 Posts

A great explanation, but a wasted effort I think.

This thread has degraded completely and become a contest between those with a long held fixation on finding fault with FBW/Automation/Airbus in general and those that come here without the slightest bit of practical knowledge and post their commentary based on their in depth experience working in scrapping yards or IT departments or what have you. It's even gone so far down hill that I see someone has recently posited that it all may have come down to to X-Rays emitted by a Solar Proton Event and someone else suggests that it's the result of an uncontained engine failure apparently resulting in a failure of the entire aircraft structure. Throw in the previous suggestion that a meteor did it and it all becomes just too much!

What I hope that the many who read this thread looking for facts, informed insight and considered speculation will have realized is that, with the exception of a few noble efforts such as PJ2's, the thread has been taken over by individuals who for the most part don't know one end of an A330 from the other but seem intent on sleuthing their way to an answer to this accident that fits their preconceived notions about the aircraft. With so few facts available and just enough "clues" trickling in to power any form of fantastic supposition they are having a field day.

There is a valuable discussion that we could be having about the few things we do know, the implications they suggest about what this flight might have experienced and how those with experience have overcome similar circumstances in the past. We're not having that discussion and those who've followed enough PPRuNe threads will recognize that most of those who have contributed knowledgably in the past are absent from this thread. The reason for this is that it's become basically impossible to carry on any degree of informed discussion when it gets lost under the random speculations of anyone capable of registering a user name, or becomes fodder for the various "Captains" and other self-annointed experts who sieze upon any crumb of actual technical knowledge as a lever to forward their own pet theory about how the automatics, fly-by-wire, composites or just the French in general are responsible for this accident and the ensuing cover-up which they presume is under way.

There was a time when PPRuNe was a valuable venue for discussion of professional issues, particularly when events such as AF447 occurred. Unfortunately that time has passed, and the informed discussion is now more likely to occur elsewhere.


With apologies to our hosts who I know are trying their best.
ELAC is offline  
Old 15th Jun 2009, 23:16
  #1639 (permalink)  
Join Date: Jun 2009
Location: Midpines, CA
Posts: 56
Likes: 0
Received 0 Likes on 0 Posts
One of the problems with this "progress" is that the only ones benefiting from it are the manufacturers. ... Whereas you could pull up to the gate in a DC-3 and people would still get on. FBW has its place, no doubt. But it was NEEDED to control high performance aircraft, not airliners.
The DC-3 was a great plane in its day, if we were all using it today we would be doing 130kn at FL24, and taking the China Clipper overseas. Not sure if that would "fly" with the public today.

Give it some time and airline pilots may end up working from home, as today's Predator and Global Hawk pilots are getting closer to doing now.

In terms of AF447, I suspect there will be an old bug (like pitot icing), a current bug (like how the flight controls handle multiple lost inputs), some human error or confusion (information overload), an act of god (the storm), and quite possibly something that none of us have even imagined yet. There could even be a spilled cup of coffee involved.

The key is that we learn the most we can from this very expensive lesson, and I am not talking dollars.
ACLS65 is offline  
Old 15th Jun 2009, 23:32
  #1640 (permalink)  
Join Date: Jul 2002
Location: california
Posts: 35
Likes: 0
Received 0 Likes on 0 Posts


"So why wasn't there an ADR Fault transmitted at 0210, if that were the source of the TCAS Fault as you say?"

First, we are not sure of the sequencing logic of the faults on the ACARS messages. Is it really time sequence? or perhaps does it reflect the ECAM logic ?

Second, the sequencing logic of the ECAM is not a time sequence but an order of priority.

It seems to me that it is very possible that the ACARS sequencing logic follows the ECAM logic (to be confirmed by an engineer)
AP OFF, the first message one at 2:10 is a Master warning, and would be on top of the list on the ECAM !

Flags on PFDs would show up early on.

In other words, if the ACARS messages are listed as on the ECAM, at 2:10 all the secondary faults show up, the NAV ADR DISAGREE would be on top of the master cautions, as it is the "deepest fault", reporting on the ACARS message in the end !

It's a bit puzzling but the whole thing points to a pitot failure of all pitots at the same time practically. (which makes sense if they are all of the same making, all with the same design problem, all fail within the same conditions)
Including STBY for the ISIS !

ALT Law requires failures of 2 ADRs That's also when you get flags on PFDs.

Lastly, only a failure of ALL ADRs will trigger the associated TCAS inop. !!

On this: ADRs feed ATC box "w/ airspeed, Mach and V/S upon ground request" (from FCOM)

What's missing is the "WINSHEAR Prediction system Fault" and GPWS TERR Fault!! what happend to those ?? Because they should be right there along with the other faulty stuff associated....

Anyway, as you can understand by now, I don't buy any stuff about TCAS antenna broken and so on.

captainflame is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.