TCAS Fail?
 

Thanks for the chart MM43.

Altitude is fed to the TCAS via the transponder. The transponder looks at only one altitude input at a time. Alternate altitude can be switched in. There is no airspeed input to the TCAS or the transponder.

Altitude out from the ADR is modified by (reportedly) as much as 300 feet as a low airspeed correction. Therefore, you could expect a 300 foot altitude shift if the pitot ram pressure were suddenly blocked while the moisture drain remained open, yielding an airspeed approaching zero.

The BEA assumption is that the TCAS faulted due to internal logic from airspeed approaching zero. The supposed rationale for this logic: "TCAS was inhibited to prevent the potential for mayhem." The only mayhem would be Collision Avoidance being compromised.

If this logic exists, why isn't it in the transponder, instead of in the TCAS? The transponder didn't fail. You don't want a 300 foot error in your altitude reported to other aircraft, just as much as you don't want erroneous evasive maneuvers. The transponder is needed for the TCAS to function. TCAS is not needed for the transponder to function.

Therefore, from the data we have, the BEA explanation for TCAS Fail is mistaken.

The two TCAS antennas are above and below the forward cabin. They are about a foot long, half a foot wide, and about two inches tall.

TCAS Fail?
 

Hi,
Did you meant that the BEA explanation (which is from Airbus experts) is mistaken because there is no link between ADR losses and TCAS?
Have a look at this (now revised) procedure:
http://takata1940.free.fr/ADR1+2+3FAULT%281%29.jpg
http://takata1940.free.fr/ADR1+2+3FAULT%282%29.jpg

Last Commands of Captain Dubois
 

Absturz von Air-France-Airbus: Pilot war in kritischer Flugphase nicht im Cockpit - SPIEGEL ONLINE - Nachrichten - Panorama

Stall led to Rio-Paris Air France crash, says German press

ChristiaanJ,
A possible explanation could be “bus overload”, a temporary and usually benign situation were data could be missing for one or more bus cycles (also depends on the bus protocol used).

New leak
 

New leak, this time from "Der Spiegel" magazine, source is claimed to be an "expert close to the investigation":

- captain Marc Dubois not in cockpit when incident started
- he entered cockpit during incident and tried to help save AF 447
- FDR shows that AF 447 took evasive action to avoid heavy weather and there are no signs of major turbulences
- FDR shows "steep" pitch up shortly after "failure of air speed indicators". Der Spiegel doesn't know if the pitch upwards was initiated by pilots or aircraft computers

Source:
Absturz von Air-France-Airbus: Pilot war in kritischer Flugphase nicht im Cockpit - SPIEGEL ONLINE - Nachrichten - Panorama

TCAS
 

As an SLF with engineering and IT background, I'm surprised that TCAS depends on ADR. 3D coordinates and speed derived from GPS should be reliable data to feed anticollision logic.

Wozzo

I read it that the pilots tried to steer through the various CB's ie not go around it but through, attempting to avoid the worst

The captain Mark Dubois is alleged to being heard shouting instructions to the crew.

I too read that the captain is supposed to have entered the cockpit, however, the fact that his body was found during the first days would suggest to me he was perhaps near the cockpit but not yet "in"

The source is obviously not revealed, and although one would have hoped that the captain was in the cockpit during the CB period, there are no indications in this press document that the cockpit was understaffed.

Yes, that's what I read also (and maybe translated in a bad way, re: "go around" not an option given the size of weather build-up); except that I don't think that captain being in the cockpit (but maybe not strapped in) excludes the possibility of his body being found (don't think the cockpit survived in one piece).

Since even the most basic Mode C transponder transmits altitude information based on the standard pressure setting, any receiving TCAS-equipped aircraft needs to measure from the same datum.

Hi,

Possible pitch up......

From HMC blog:

http://i.imgur.com/9mNNj.jpg

TCAS
 

Altitude mode (both ATC and TCAS) is dependant on ADRs.
Triple ADR fault rev.19 (compare with rev.16 above); see ATC ALTI MODE and TCAS inop:
http://takata1940.free.fr/ADR1+2+3FAULT%283%29.jpg

and TCAS scheme:
http://takata1940.free.fr/TCAS.jpg

one of the first skills that is lost is what is known as "fine motor control," especially in the hands

gums has made some comments on the F16 stick. I recall from a course years ago (so it might be scratchy) that the initial test article had a zero break out stick arrangement which was unflyable due to low level muscular tremors. If I recall correctly, the initial mod was to introduce a 4lb break out load to get rid of the non-commanded small perturbations.

Without wishing to appear too mechanistic, another factor that should
govern design is perhaps the resolution of the shoulder/arm/hand
assembly, which can apply quite large forces full scale, but will have
limited resolution, or granularity, at low force levels. If the initial
force is low, small variations in that force will be difficult to
control, because of resolution limits and signal to noise ratio. If the
initial force is high, then small variations will be much further up the
linearity curve and thus easier to control. If there is position as well
as force feedback, then so much the better. As in mechanics, the human
body has many compound servos, which have limited resolution, response
times and signal to noise ratio.

Not really my field, but isn't this what artificial feel systems are designed
to address ?...

jcjeant: In that scenario, an aft CG would certainly make things worse.

The demands placed on avionics computers have increased a lot since the
early days, and current systems do in fact use much more powerfull
processors, some of which are pipelined, have extensive cache memories,
as do current desktop computers. Without appearing complacent, I
don't see any real problem with this as avionic systems have arguably
the most rigorous development processes applied to them than any other
development activity. It's very unlikely that any fundamentally serious
bugs would ever be found in the software. By bugs, I mean noncompliance
with original spec. Of course, all this becomes toast if there were
holes in the original spec that failed to recognise and cater for corner
cases, or assumed that they would never occur.

To demonstrate one aspect of how rigorous the whole process is, take the
example of redundant systems. Very often, where a system is say, dual or
triple redundant, both the the hardware and software will be designed
and built to the specification by separate development teams who are
forbidden to collaborate or talk to each other. Often, different
programming languages and hardware processor architectures will be
chosen as well. For example, team A may use Ada on PowerPc, team B, C on
68K/Coldfire, team C, Jovial on Intel x86 etc. The whole point of this
is to enforce separate thinking, different algorithmic processes and a
unique approach to development. Once the development and testing to spec
is complete, the different finalised systems are again rigorously tested
against each other, ie: compared to ensure that they all agree. Afaik,
no other industry, with the exception of nuclear uses these extreme and
very costly development processes and there is much more to it than the
above brief description.

I worked on avionics in Basingstoke in the mid 80's and even in those
days, the process was quite rigorous. Much of the less critical software
was still being written in assembler, with fadec software catered for by
custom in house control languages. Most of the modules were quite short,
not more than a page or so of assembler and it was designed to be clear
from inspection what the code was doing. For testing, every module was
tested on a simulator running on a Vax or HP mini, with module input
data set up to ensure that every path through the code was executed and
that expected or sane output values appeared for good and bad input
data. Once this was complete, the modules were linked to final code
image and tested to the original product spec, again with normal and bad
input data and with a variety of hardware failures injected for good
measure.

While I have almost complete faith in the avionic systems design, i'm
not so sure about items like pitot probes, which may have been certified
20 years ago and are now perhaps working well outside their original design
limits at least some of the time...

Control breakout forces
 

Salute!

Good point John the Moderator.

I'll try to talk with some of those guys in the demo program, but I can't help thinking that GD had the 1 pound breakout force.

The "stiff" stick in the first few dozen jets didn't feel like it took much pressure to "breakout". The Block V jets with the small movement felt "squishy" at first, but might have helped with formation flying. Didn't do a thing for A2A fights. You will note that our force-versus-command plot was not linear ( roll command gradient graphic posted earlier). Wonder what the plot looks like for the 'bus? Same question for pounds per degree of control stick deflection - is it constant?

+++++++++++++++++++++++++++++++=

Sadly, a new leak points to a "pitch up" and ensuing loss of control. Makes me cry.

more on this later.

A330 FCOM Bulletin 09
 

Hi,
This is no news, a bulletin inserted in each A330 flight manual (3.08.09). Note that this bulletin was published 10 years before AF 447:

http://takata1940.free.fr/FCOM09%281%29.jpg
http://takata1940.free.fr/FCOM09%282%29.jpg
http://takata1940.free.fr/FCOM09%283%29.jpg
http://takata1940.free.fr/FCOM09%284%29.jpg
http://takata1940.free.fr/FCOM09%285%29.jpg

That the unnamed source doesn't have a clue about the one thing that really matters, reduces his credibility to virtually zero, IMHO.

takata, I suspect some of the data will remain sealed "forever" in the interests of the victim's privacy.