My initial post on page two of this thread gave rise to a number of queries, so it may not have been clear enough. Here's another attempt. Apologies for the length.
A Refined Theory
The NTSB is laying the groundwork for a belief that perhaps the pilots could have encountered the initial wake turbulence and then
laid into it with a corrective boot (for whatever reason) but thus creating a rudder reversal situation (beyond the provisions of
FAR25) that overloaded the fin. Their theory infers that, perhaps when they hit the second lot of wake, they were in a significant
sideslip with a large rudder deflection. And supposedly they didn't do this just once, but went for a heavy pedal-throw five
"recorded" times during and just after that second wake encounter, with as little as 0.3 seconds between.
Well I'll tell you now that you won't have any more than 0.5% of the qualified pilot population ever believing that one. Multi-engine
pilots just don't go for big boots of rudder at 240 knots (1.9Vs) when they encounter wake turbulence (and, as you point out, that
happens quite frequently). Pilots might be more prone to utilise rudder in order to stop a further wing drop at low (approach type)
speeds (1.3Vs). That remains a recommended course of action simply because trying to pick up a "dropped" wing with aileron/spoiler
when near the wing's stalling angle of attack only serves to exacerbate the situation and can lead to autorotation (incipient spin).
So there has to be another answer - and that's probably why the US pilots flying the A300 have the wind up. They know that this facile
NTSB explanation just doesn't wash. Neither does it accord with the A300's reputation as a tail-wagger, nor with the recorded
instances of uncommanded yaw. You should not lightly dismiss either of those factors.
There are system failure explanations that might encompass the cause and I've mentioned my latest theory (the effect of yaw on the
static pressure sensed by the Air Data Computer and predicating allowable rudder deflections - see below). Another avenue of
exploration might be this one:
<a href="http://www.casa.gov.au/avreg/aircraft/ad/adfiles/over/ab3/ab3-088.pdf" target="_blank">http://www.casa.gov.au/avreg/aircraft/ad/adfiles/over/ab3/ab3-088.pdf</a>
AD/AB3/88 Amdt 1
. .
Rudder Servo Control Desynchronisation 5/98
The desynchronisation check is to be repeated every 1300 flight hours.
Background: This AD is raised to detect and prevent rudder servo-control desynchronisation which
could lead to structural fatigue and adverse aircraft handling qualities. The AD also
mandates structural inspections to detect the onset of fatigue damage resulting from
servo control de-synchronisation. This amendment recognises changes to Service
Bulletin revision status and incorporates a new compliance clause.
The original issue of this airworthiness directive became effective on 2 January 1997.
Unfortunately I don't have the Service Bulletin nor the inside knowledge of the system, so I cannot judge whether it's a valid
connection or not. I'm not sure whether the rudder input actuator rod found on the FEDEX bird had any significance here - but you
cannot discard that either.
. .The NTSB and FAA have disclosed that a previously FAA-accepted NTSB recommendation on the DFDR was not acted upon and so only the
desensitized data was going onto that thoroughly discredited Loral DFDR (in other words, the same as what the pilots were seeing - and
eliminating all the intermediate data-points). When you consider that aspect, and reflect that as little as a quarter of what went on
down back actually went onto the DFDR, I have no trouble seeing those latter tail-end events as "a rattle". And I certainly then
discard any notion that it was the pilots peddling that fast....because they simply couldn't have done so. But the FCS driven system?
Yes, that can move the rudders at a rapid 39 deg/sec.
So, is it a simple 737-type rudder case where the valve is going to full throw and then sticking? No. Something is causing the A300
rudder to fluctuate back and forth - but not rhythmically (an important point). Well we know that there have been prior instances of
the A300 rudder generating uncommanded yaw, some just annoying - but others generating concern, incident reports and flight aborts. So
why didn't they previously cause a fatal fracture of the fin? Easy, it's all about the forces generated on the fin - by both the
rudder's motion and the side-slip angle at the time. For AA587, already in tail-wag mode when they hit the second wake, the overload
was likely caused by the angular velocity of that wake as it hit a deflected rudder's pre-loaded fin. It is most obviously the
combination of those two aerodynamic loads that (for AA587) proved lethal. That is well covered in
<a href="http://www.iasa-intl.com/folders/Safety_Issues/others/aa587/ruddersnapfinoff.html#dornheim" target="_blank">AW&S T's Dornheim article</a>. But
it's not the whole story - it lacks an acceptable cause for the waggle.
OKAY, what could cause the rudder to waggle, (but not rhythmically) and, in the case of AA587, break the fin? Well the answer possibly
lies in the systemic relationship between the ADC and the FCS. The ADC senses pitot and static pressures and provides the speed input
so that the rudder ratio limiter knows how much of the (physically available 30 deg of) full-throw is permitted at any one time. If
you manage to confuse the ADC so that its input to the rudder limiter (owned and operated by the FCS) is a little haphazard, then
every rudder deflection will be inappropriate. Because it is (and proves to be) an inappropriate response, a further corrective rudder
deflection is called for. It too will be incorrect if the speed derived from the ADC isn't near to the actual speed of the aircraft.
The yawing evolution ends up as an over/under-correction followed by yet another over/under-correction and the end result is dependent
upon some other factors. Firstly, if it's not a significantly inappropriate rudder deflection, the massive dampening effect of that
large fin will provide a countervailing restorative moment and the uncommanded yaw will subside. If it is a largish error, then the
inertia of that fuselage swing also becomes a factor, as does the timing of the FCS inputs and any time-lag in the ADC's sensing of
the aircraft's speed.
So why would the ADC tell fibs (to the FCS and rudder limiter) about the aircraft's speed? It might not be the same reason every time
and I covered that in my initial hypothesis
<a href="http://www.pprune.org/ubb/NonCGI/ultimatebb.php?ubb=get_topic&f=1&t=017746&p=2" target="_blank">here</a> ("just another Theory"- "Help me out
here"). But in AA587's case I'd suggest that the initial wake turbulence encounter was enough to set the ball rolling. Normally, in a
yaw, the fact that the port and starboard static ports are Y-connected is enough to iron out (and average) any discrepancies caused
locally at each port (by the venturi effect of yaw angle, air inflow and fuselage curvature). However the design engineers only ever
consider balanced flight and a few different configurations when they decide upon static port positioning and then map the PEC
(position error correction) errors to be fed into the ADC. In yawed flight I'm suggesting that quite large errors can creep in and be
magnified by both the ADC and FCS sampling rate (i.e. how often these gizmos ask for the speed info). As I pointed out in the earlier
article, about a 9mb error (= an 8% error on an ISA day) can cause the airspeed to zero out. I'm not suggesting that that happened,
just pointing out the small magnitude of P.E. error required to cause a largish speed error and an inappropriate rudder deflection.
Remember the 1996 Birgenair 757 that crashed due to static port tape being used to stop water getting into the static system during an
aircraft wash (not being removed)? Well it's a little-known fact that heavy rain and a falling barometer can allow a static port to
suck in water. It's usually not significant because it normally pools in water traps in the system - and gets drained eventually. In a
heated system it's unlikely to freeze and cause the gross errors mentioned in my earlier article. However just consider what effect an
amount of trapped water might have in the static system - particularly upon the timeliness of ADC sensing, and particularly in a yaw?
The water may well flow in an adverse direction, due to the forces of the yaw and inertia, and induce a false static pressure (which
is then picked up by the ADC etc etc). Do you see where I'm going here?
So if you accept my hypothesis, you will see that a clean/dry static pressure system can induce an error into the FCS - and so can a
wet one, but probably a fiercer reaction in the latter case - because of the adverse flow of trapped water during any yawing. Due to
the unpredictable nature of the water-flow and the ADC sensing, rudder ratio changes and resulting erroneous FCS responses, any yaw
meanderings would not be rhythmic, but they could build up and become divergent and gross. Equally likely, the rudder could become
out-of-phase with the aircraft's physical yawing and tend to assist the damping effect of the fin. Luck of the draw I would say - but
in AA587's case I'd suggest that the second wake turbulence encounter came at just the wrong time in the cycle. It can probably
therefore be seen as a once off type accident. But if I am right, then there are things that can be done to resolve any such
discrepancies in the Airbus system's logic and susceptibility to this type of error.
In answer to the question (at the end).
Pitot Pressure (as sensed by a pitot tube facing into the airflow) is a Total Pressure made up of dynamic and static pressure: T =
D + S1. . . .So obviously we need to subtract that S1 (the static pressure – which should be the ambient pressure at that height), because what we
want to see on our Air Speed Indicator is D (dynamic pressure or the pressure due to our forward speed). The formula now becomes D = T
– S1 (a conventional airspeed indicator does this within its internal plumbing but in a glass ship the Air Data Computer obliges).. . . .But where do we source that S1? Well it comes from the static ports (let’s call it S2)…. which live on the port and starboard sides of
the airplane’s aft fuselage (normally two small holes each side / above and below, which are heated against icing but which are open
to the elements inflight and quite often left open and unplugged on the ground). If you park an airplane in the open and there’s heavy
rain and it’s flowing down over those holes then capillary action can cause water to be sucked in, sometimes in fairly large
quantities. I can recall an inflight emergency where I lost all pressure instruments after climbing through freezing level. They
figured out later that, parked in the rain, water had been sucked up the hollow centres of the downward-facing rubber bungs (off which
the water was dripping). When it later froze in the static system, of course I lost the altimeter (it froze at that height), the VSI
went to zero and the Air Speed indicator just wound back to zero (from the 220knot climb speed). It was calculated later that that
will happen (from that IAS) over a climbing height change of 2800feet (about = 9mbs or 8% of the Sea-level ISA pressure). The school
solution is to depressurize and break the glass on the VSI and accept that there will be a fairly gross altitude error (due to using
cockpit static). But that gets your ASI back in the picture (although greatly errored, trends will be good).. . . .Now in an ideal world S2 will always be equal to S1. But we don’t live in an ideal world so there will always be some discrepancies:. . . .
a. When we lower flap and/or change AoA, it tends to speed up the airflow over the wing and down past the static ports - so the
venturi effect drops the pressure there and a correction is required (to the speed that we fly). . .D = T – S2 becomes an errored speed indication because it’s now a greater quantity than D = T – S1.. . . .
b. If we yaw the aircraft, the fact that the port and starboard static ports are interconnected via Y junctions should stop
the error being of any great magnitude (a higher pressure on one side being in theory cancelled out by a lower pressure on the other).
But if we go into a rapidly yawing mode through a significant angle, then all bets are off and the pitot-static system will be
struggling to provide valid data to those flight control systems with a high sampling rate and requiring accurate pick-offs of static
pressure (and consequently any derived speed will be fluctuating). Note here that I said pitot-static systems – because the pitot is
also yawing away and so it’s also subject to some error). Navigation systems and pressure altimeters aren’t as vulnerable to sensed
errors (resulting in momentary speed discrepancies) as would be the flight-control systems (yaw damper and rudder limiter inputs say). . . . .
c. And if we have water trapped in that system and start yawing, then obviously we have to examine the effect of the inertia
of that water on the sensed static pressure (S2). Over a period of (say) five seconds, we might measure (but never see) S2 ± 5mbs
variation. Depending upon the sampling rate of the ADC it may not even record this on the slow-sampling DFDR – but it may provide that
instantaneously erroneous data to the rudder limiter and yaw damper…. With eventual AA587 uncommanded gross yaw type results. . . . .
d. Additionally, if we fly into a wake turbulence encounter, we might accept that a wake vortex has within it some wide
variations of pressure. These can vary from “almost a vacuum” to much greater than ambient pressure at that height. In addition the
angular velocities of the encountered (greatly disturbed) rotating wake vortex airflows may mean that there are components of the wake
at an angle to the static port (on one or BOTH sides of the airplane) – and those ports can take in that air pressure much as a pitot
tube does (leading to even greater errors and flux). . . . .So it is starting to look like a real pakapoo ticket is it not? The business of getting a true S2 just became tantamount to impossible
when we entered that first wake and began the tail-wag. When we entered it the second time, it was with a thoroughly confused system
that was doing the wild thing with the rudder and, as luck would have it, the second encounter just happened to be at the worst
possible angle and at the worst possible time. The rudder was already imposing a high load upon the fin and suddenly the additional
load snapped an attachment lug and started the fin “working”. As the fin started its lateral dance of detachment, the rudder was
excitated into a frenzy of fin-swaying corrections, leading to the death-rattle heard on the CVR.. . . .
Addressing what you’ve asked below:. .“The static pressure drops to zero” isn’t really the case at all. What happens when water freezes in the static system is that the
ambient pressure at that height is trapped and displayed (and that’s why the altimeter freezes at that height, even though the
aircraft continues to climb). 2800ft later, the altimeter reads the same height - but the subtraction of that greater S2 (trapped
pressure) causes the Air-speed indicator to wind back to zero. Over that 2800ft of climb the ambient pressure drops off about 9mbs
(roughly 3mbs Hg/1000ft). So if there was to be a momentary 9mb drop in the S2 (for any reason including the adverse flow of trapped
static system water) at a speed of 220kts, the sensed speed would be nil, zero, zip. Now obviously that’s never the case because it’s
a very dynamic situation we’re talking about here – but it does give you an idea of the magnitude of the pressure errors as sensed at
the static ports – which could drastically influence the airspeeds being fed into the flight-control system. The speeds sensed could
be at any one point of time either above or below the actual aircraft speed – thus causing the continually inappropriate FCS-dictated
rudder responses (in reply to the gyro-detected yawing moments). And there’s the rub.
Question: I don't quite understand one thing in your "Just another theory". It deals with pitot tubes and static ports,
which is to say dynamic and static pressure. If static pressure drops to zero, why would the speed reading decrease? If the speed is
dynamic pressure minus static pressure, then lower static pressure would suggest a greater speed to me than a lesser one. At greater
perceived speed, the rudder would be more (not less) limited in its arc of travel.
<a href="http://www.iasa-intl.com/folders/Safety_Issues/others/aa587/ruddersnapfinoff.html" target="_blank">a link to the theory in toto</a>