MM43, thank you for that beautiful readable DFDR trace. Much better than the fuzzy one in the online accident report!!

The A319 is the baby brother of the A330. Much smaller but with a strong family resemblance. As such, many of the design concepts that went into the A320 family are reflected in the A330, but executed or packaged in slightly different ways. If the A319 is showing signs of control rate limiting, then it is likely that the A330 can do the same.

With this in mind, I would like to call attention to some anomalous indications in the DFDR trace.

First, look at the position of the R & L elevators. Wouldn't you expect both elevators to be moving synchronously? But just before 14:48:10, the L elevator (brown trace) follows a stick pulse, but the R elevator (blue trace) does not. Then at 14:48:12, the R elevator responds to a stick input, but the L elevator does not. This split behavior continues until 14:48:17 at which point the aircraft has apparently flown out of the turbulence and is in a recovery phase.

Now look at the blue and magenta traces in the middle of the graphic. This is rudder position(magenta) and rudder pedal position(blue). Wouldn't you expect the two to be nearly synchronized with a slight lag for the hydraulics to catch up with the pedals? But at 14:48:06, before the autopilot is switched off, we are beginning to see the rudder lagging the pedals. (I don't wish to get into a discussion about whether he should have been on the pedals in the first place, just how well the aircraft followed the pilots commands.) By 14:48:15, the rudder acts as if it has a mind of its own and is doing other than what the pedals commanded. Finally by 14:48:23, the rudder starts to follow the rudder pedals (coincident with the aileron trace quieting down).

There are other indications in the aileron traces themselves. Yes the right and left ailerons mirror each other fairly well, but they are lagging the control input by almost a second and the position traces are becoming triangular in shape.

To me, these events in the trace may be the results of hydraulic supply rate limiting, but I realize that yaw damper inputs can superimpose on the pilots rudder inputs. Others on this forum have no doubt seen such DFDR traces before and may have better insight as to the cause, but I am concerned that the hydraulic demand from continually moving ailerons and spoilers could cause a control problem in very turbulent conditions on Airbus aircraft.:suspect:

And if I am definitely barking up the wrong tree, please set me straight.

Hi,

Family associations with the help of some aviation professionals suggested to search first around LKP
I agree with that... but it's make of me a conspiracy accomplice :)
Like those conspirators from one of the family association :

MARNET-CORNUS Henri
MECIFI Amine
TERRACHER Jacques
ARNOUX Gérard

Liste des membres du Conseil d

Methink AF447 go in a irrecuperable stall by all means even if Svetlana Kapanina was in command.

The control surfaces have been smashed off due to the high AoA and high Rate of Descent. Note that attachment spars etc. are all that remains, and the composite components have gone. Early signs that confirmed the BEA's "en ligne de vol" with a high vertical component, were the top of the RADOME was recovered, and an Outer Spoiler showed signs of being punched vertically from its stowed position.

If any hydraulic control system had suffered damage, that would have certainly generated an ECAM and subsequent ACARS message. With the information we have, none of that happened. That doesn't preclude the Outer Spoiler mentioned above from having left in the air, but the visual evidence of its found condition has all the hallmarks of a upward punch by the sea surface, and I suspect the lack of symmetry would have created another warning - before the Cabin Vertical Speed advisory.

Machinbird;
There is an alternate explanation which might help. It comes from the way flight data recording works.

Remember how popular strobe lights were? Let's put two such strobes in a dark room where a lot of people are dancing to disco music...(yes, I remember). Let's point one strobe one way and the other in the opposite direction, (left and right); let's pretend they're shielded so they dont' light up the whole room but just where they're pointed.

Let's then fire one strobe a bit later than the other and film the position of the dancers lit as the first strobe fires, and compare their positions with the dancers lit by the second, later-firing strobe and ask, Are the dancers lit by the second strobe in the same position they were in when the first strobe was fired?

We know by now that they're not. Dancers are always moving!

Are the second group of dancers "lagging" behind the first? Again, no, we just see them slightly later because of the "snapshot" way the data was taken and recorded.

The same happens with digital flight data recorders. The process is sequential, not all at once.

So we know each parameter has it's place and time of recording and it is different than all the others.

All aircraft parameters are also generated and recorded at different rates per second.

Fuel quantity is recorded every four seconds because a faster rate isn't needed to notice change. Heading is recorded once per second, roll is recorded at twice a second, pitch at 4x/sec, while vertical 'g', which changes rapidly, is recorded up to 16x per second and sometimes higher.

These "frame rates" are a matter of design and software programming. QARs, (Quick Access Recorders used in FOQA/FDA programs) often record
many more parameters and at far faster frames per second than DFDRs or SSFDRs.

The key point is, parameters can't be recorded all at once. If there are 1800 parameters (in binary form) coming into the system, the system must have a way of "listening, parsing and recording". The data frame software is how that process is handled.

As the second begins at '0' and proceeds to '1', the data frame runs through all parameters, sometimes "flashing the strobe" 16x a second, sometimes less, sometimes not, and then places the binary data received in the data frame cells (much like a spreadsheet...simple data frames are 4 columns, 64 rows, filled each second), at the programmed recording rate.

Without getting more complicated, (because it has to if we go any further and everyone will be asleep), the nature of recording can give the appearance of a 'lag', when there "may, or may not" have been one.

I say "may or may not", because there is one more thing to know.

As with the strobe light, when the lights are "off", no one knows what position the dancers are in, until the next strobe fires. This is equivalent to the position of the aileron or sidestick, etc, not being recorded, even when these devices will always have a certain position.

Further, one can make absolutely no assumptions whatsoever, about the positions of the dancers, while the lights are off. Similarly, in the time between the snapshots of the left aileron position and the right, one can make no assumptions about what these controls were doing while not being recorded, even as they logically had a position at all times.

If the sidestick (recorded on the A319/A320/A321 at 8x second in most frames) is moved so rapidly that the frame rate can't catch every important position, then what we see in the data may be misleading. A rapid sidestick movement full forward then full aft in about a second will not look like a smooth fore and aft movement and, depending when in the entire recording sequence such motion was made, the data may not show full aft or full forward because "the strobe was off at full deflection"...

So it is with all aircraft parameters.

To introduce what will be a reasonable complexity, there may actually exist some lead or lag in the flight controls. But there is no way to tell as slower frame rates and ground testing is the only process that can answer the question.

I haven't studied the Air Canada traces so can't comment in detail but this kind of explanation is the way recording works.

This isn't to say that the recordings aren't still extremely useful, obviously. But it takes experience and training, and in cases as fine-tuned as these it would be up to the maintenance people and the aeronautical engineers to say whether the positions of the flight controls, as they relate to the side-stick and rudder pedals even with the lag, affected control of the aircraft in a certain way vice another way.

This is why I think, even when the recorders are found and read, (which I am confident they will be), that the real discussion will just be starting.

PJ2...

A superb explanation -- as usual.
(However I was a tad worried at one point that you were going to introduce Schroedinger's cat onto the dance floor...) ;)

Parallel data recording, et al
 

Salute!

PJ has some great points about digital recording on a serial bus.

Working with flight test recorders in my previous life, we had several "channels" of data streams, all synched with time stamps. Even the analog data. The biggest difference between test profile recording and day-to-day maintenance and such recording for the big jets is the update rate. If we sample at 100hz or faster, we can build very accurate relationships between all the inputs. But then we need a huge storage capacity.

Looks to me that the stuff we see from the "maintenance" recorders and transmissions from the AF jet was only "blips" of all the data that still resides in the flight data recorders.

There are several independent "channels" on the flight recorders, and just look at some of the traces for various accidents/mishaps. We can see all kindsa things that happened at the same time.

and now back to the experts and regular program.

Thank you PJ2 for the excellent reminder about the vagaries of data collection and an interesting presentation of the concept.:ok: Just because a point is plotted on a DFDR chart does not mean it is not an interpolated or smoothed point seems to be a key element of your message.

There is one more factor to be considered in analyzing flight control data. The maximum uncertainty of position for those items that are moving (such as control surfaces and actual controls). Real objects move at characteristic rates. A control stick will not move from full left to full right in a millisecond. Even if it could, and then immediately returned to its original position, could a hydraulically driven control surface follow such a short signal?
Suppose a rudder surface takes a full second to go from neutral to full right at maximum control input. If sampled 4 times a second, you may not know exactly when it reaches maximum deflection or exactly when it reversed its direction of motion, but you can still know it moved at close to its maximum rate and achieved approximately full travel. Estimates can be made for the uncertainty and approximate behavior determined.

The AA587 investigation had real problems with the DFDR data because the low sampling rates masked the dynamic nature of the oscillations. Lets hope that more rapid sampling rate recorders were mandated as a consequence.
If data is recovered from AF447's recorders, will the sampling rates be high enough to definitively show dynamic behavior of the aircraft and its controls? Let us hope so.

Meanwhile, does anyone have knowledge of the sampling rates on the Air Canada A319 aircraft we were just discussing?

grizz;

That's why it's called a PFM box... you never know for sure.

gums;
The mistake some made in the early discussion was treating the 24 ACARS messages as the same kind of information as flight data recorder information - most on the thread now know that inferences from the messages is a mug's game.

There are data recording solutions which come close to resolving the timing issues, but "granularity" becomes an issue if important parameters, (especially in older equipment) are not recorded at sufficient rates-per-second, (and can't be precisely coordinated with others which aren't recorded at the same rate. If the sidestick is recorded at 16x/sec and the elevator rate, for example, is recorded at 4x/sec, how does one match each side-stick data point with the 4 existing elevator points? And this is quite different than the problem of "filtering", which the FAA has addressed, (and towards which I do not wish to divert the thread).

Not sure what you mean by "sampling at 100hz" or how such a parallel system would work, but there is a lot of variations on a theme.

Machinbird;
No, I would specifically wish to avoid this interpretation of my note. "Filtering" can be used to smooth data as we know, but I don't see how it can be so smoothed when "the strobe is off", so to speak. Notwithstanding your very reasonable statement regarding logical assumptions (which I do not necessarily disagree with), the issue is decideability...by what means and by what justifications in data work is smoothing decided and for what parameters, some, all, none? I have seen both the raw, (very lumpy) data and smoothed data and both work for various purposes, but the only way to resolve the issues raised by AA587 are, as the FAA has indicated, finer granularity, (higher sample rates, larger storage capacity). A variation on the issue trivially arises when using lossy JPG formats in digital photography, which is why so many who know what they're doing prefer a form of RAW; - the information in the spaces in between is real, not derived.

I believe the places where the symbols are placed on each parameter's line represents each sample point for that parameter.

I don't think there is anything in the A319 event that relates to the AF447 event. The AC event was wake turbulence...quite different than TCu's.

FDR and filtering etc:

Filtered Crash Data on AA587 Surprising and Disappointing to NTSB

Indeed - you also have to allow for wind speed, and if you calculate distances between the history of 10 minute locations you get about 80nm per 10minutes - so the initial +40nm position was 5 minutes of forward flight, or 4min + dive slope. There was some confusion about the pedigree of this report in initial days after crash see Air France 447 - AFR447 - A detailed meteorological analysis - Satellite and weather data for example. Much discussion here about possible location - including turn back and south of LKP, and expectation of 10nm radius - but rather than change it seems BEA stuck with the initial determination 'most likely within 40nm'.

Looks like a blind one...
In order to estimate the impact location (in case when the recorders are destroyed) one can consider an INS equipped bathyscaphe starting from the position of the plane's remains and compensating on-line ocean currents when climbing up.
Such a procedure is - to some extent - a reverse of the Monte Carlo approach described by lomapaseo in http://www.pprune.org/tech-log/39510...ml#post6393355.
For the sake of precision: the information in color RAW files is real but not complete anyway due to the presence of the Bayer color filter preceding a sensor.
All images - when retrieved from a RAW data - need to be transformed by a so called demosaicing procedure (which is a kind of interpolation algorithm).

Sorry to disagree, but the recorders would not affect the time relationship between messages. A much more likely scenario would be for each message to be timestamped as it arrives at the recorder, then queued for writing. The queue would be of a length to ensure that no messages are lost.

Although messages may not be written in real time, or perhaps even in strict sequence of arrival is irrelevant, since each message will have it's own timestamp...

Way back in post #3262, Lonewolf wrote "caveat, it may be a load of rubbish if the gyros in the A330 are not prone to tumbling ..."

This has been rumbling around since day 1 and I'm not sure I've noticed an answer. I was under the impression that the notified failures were all ADC related?

Do we have any indication that the IRS attitude was faulty?

Apart from the Standby AI (which I am guessing is gyro driven?) what other 'gyros' could 'tumble' to promote this thought?

Irrespective of data interpolation points versus timing interval, be it at 8Hz, 16Hz, 32Hz or as PJ2 queried 100Hz, a smoothing curve can ultimately be provided to cover the slower data rates. As PJ2 has pointed out, the side stick may be moved at a very high rate and not be recorded, however the reaction time of the hydraulics will normally reveal something that has been missed and show it as a potential overshoot/undershoot.

The feedback loop in the hydraulics system will have a gain that makes it track the inputs fairly accurately, but inevitably it will have some lag, as anticipation is not built into it by design. Rather, in the case of the rudder, a damping action to avoid excessive yaw is provided, and it is evident when looking at the TSB of Canada's A319 trace. The lateral 'g' records provide a guide as to how that correction is being applied.

The disparity on the left/right elevator positioning is rather disconcerting, but I am sure there is a valid reason for it - part of which could be PJ2's reasoning.

Back to reality.... Does the A319 have a PTLU (Pedal Travel Limiter Unit) in the system, and is there an acceptable rate of change built in that further limits the commands to the rudder? From what I have seen in these traces, I suspect not.

As has already been suggested, the A319 example will not be valid with what is recorded by AF447 - it certainly wasn't wake turbulence that brought it down.

Not that I'm aware of.
I think the tumbling referred to tumbling due to excessive maneuvering of the aircraft.
However, I have serious doubts that the IR part of the ADIRUS are prone to tumbling like a classic gyro although I don't know for sure.

And the standby AI in this case was a Laser Ring Gyro if I remember correctly which should also not be prone to tumbling.

That said, I could well imagine that recovering a tumbling airliner in turbulence and complete darkness only by the instruments after having been taken by surprise and with a plethora of ECAM message popping up might not be quite as easy as in an aerobatic aircraft in good visibility during a planned and well trained maneuver....

trim-tank .... CG
 

@ Chris Scott, if one reduce the speed in view of turbulences, is it feasible (or generally used) to transferre the CG again to the front somewhat, or did one trust into the steering system, and deside the risk of stall vs reduce of energy, even in this case, in the same way as in normal cruise flight and let the CG aft as before ?

In the company I was working for it's SOP to shift CG fwd in turbulence.

grity,

I see what you mean, but am afraid I can't answer that one. Never flew the 330/340. Perhaps PJ2 will when he gets up (GMT -7), or CONF_iture (if he's not flying).

Thank you, to henra and BOAC in re attitude reference systems. Not familiar enough with what is used in big metal to have any intuitive feel for how they respond during upset. Your point on "no system fault" transmitted may have been the answer to my question in the first place.

Also a big thank you to PJ2 for the analogy in re data sampling, although I did cringe at the memory of strobe lights and the disco era. (At least you didn't meantion leisure suits and polyester shirts! :eek: )

For syseng68:
Good point.

Anyone have any links to the schedule of the recovery effort? The vessel named in the prior news articles appears moored at Las Palmas.

Stalled?
 

According to the ATSB incident report: Stall protection activated, stall warning and stickshaker activated, and indicated AoA reached 10.5 degrees.

The report doesn't say that the airplane actually stalled, but maybe we can take the AoA as an indication that it did, or came very close?

PS:: The airplane was pitching down at the time (17:03:52 - 17:03:59) the AoA was recorded. Therefore the vane AoA may have been greater than the airplane AoA.

Salute!

BJ and mm43 have cracked the code.

The info I can find on the DFDR's reveals very slow sampling rates, and I am not sure if the data is time-stamped at the sensor or by the "black box" when it receives the data.

My background was in military testing, and we sampled the digital data at 50 hz or better. Our analog data from accelerometers and pots were recorded on old-fashioned tape! However, the digital stuff was parallel on the tape (7 channels), so we had a mechanical means of synchronizing the data.

As the referenced report by BJ states, the sampling rate was too slow to get an accurate replay of the rudder reversals by the 587 jet.

For my business we needed to see very good parallel data streams of control position, force inputs, and aircraft/missile attitude, gee, etc.

The serial data recorder using a single memory device has to use various update rates depending upon the parameters of interest. And I agree with the observation that filtering the data as it is being recorded is not a good thing. Our data reduction facility could filter as necessary, but we captured the "spikes" and such as raw data.

Quote from JD-EE (posted Apr18/2341z):
"...If the accident happens in a third world area, the report quality is poor because of the untrained and inexperienced investigators. If the accident is not politically charged and is in a "first world" nation the reports tend to be pretty good..."

Apologies for slight thread-drift. As a BBC Radio4 addict, I recommend this fairly balanced programme on the problems of accident investigation in third-world countries – strictly only for those who can manage without pictures...

Lazerdog

Ile de Sein is due to leave las Palmas april 21st to start the search. Apparently, the ship has been doing sea trials yesterday off the coast. (Testing new equipment?)

mm43

With most respect, I tend to disagree re: your studious conclusion about the found spoiler, and by inference other composite panels. The spoiler was found on the surface beaten up badly, and fractured, but retaining its full size and shape. Given the scope of the destruction to metallic forgings and extrusions evident in the seabed photos, I have to say the spoiler without doubt was removed by air loads, extreme airloads. The actuator attach was badly fractured, but the damage was tight to its location, and gave way to a retention of integrity just inches into the panel's skin surrounding the fasteners. In my experience, FRP has a signature failure in high energy impacts that is unmistakable. It explodes. I believe that if the spoiler panel (#4??) had been on the wing at water impact, there would be virtually nothing left to find. This has also to do with my admittedly stubborn conviction that the Vertical Stabilizer and Rudder were not on the fuselage at impact. The Radome is even money, I think it is likely to have left the airframe prior as well, perhaps in overspeed, or due to hail damage.

I am thrilled at the location of the aircraft's site, and my optimism is high. I think that here on PPRuNe, this thread is as incisive and academically brilliant as any accident report I've seen. You and the others are absolutely brilliant in your knowledge, logic, and utmost respect for one another.

kudos, and back to read....

lonewolf :I strongly suspect (but don't have doc's to qoute) that the data arrives at the black box at a much higher rate than it is recorded and that the recorded sampling rate is set by the black box.

What could be done to help with correlation is to snap-shot all the data at relevant frame boundries, to use PJ2's analogy synchronize the strobes. The data could then be saved over the frame time.

This would avoid artifacts such as phantom splits in control surfaces due to "sampling lag"

On the other hand there may actually be more value in sampling the data as it is recorded, helping to fill in gaps using semi-related parameters.

To put it in engineering terms "no matter how hard you try Nyquist wins". (And wagon wheels will continue to go backwards in movies)

You're talking about two completely separate systems. Flight data recorders have nothing to do with the ACARS messages - that's been the point all along. The recorders don't see these messages, don't/can't record these kinds of messages, don't "timestamp" data and don't hold them in memory. That's not how flight data recording works.

grity;

Fuel transfer and the CG is managed by the FCMC [Fuel Control and Monitoring Computers]. There are no procedures established to move the CG forward to "guard against stall" - in fact, no airplane which would require such an intervention should be flying as a commercial transport. The aircraft is certified to be loaded and fueled in certain ways and CG limits are established as part of the design and certification process.

Procedures are in place to handle the abnormalities.

If for any reason the CG ends up too far aft, an ECAM message comes on requiring the forward transfer of the fuel. This is different than "deciding that the CG is 'too far aft' " all on the crew's own. You can get into an equal pile of trouble with too forward a CG, so even though the method is available, (by transferring the trim tank fuel forward, (requires a 3-deg ND pitch to do so)), you wouldn't do it without the ECAM message, just because you thought it would be a good idea.

Thanks gums, understand now. For clarification, flight data is not "timestamped". It is recorded, using synchro words for each parameter when recorded in the data frame. This enables each parameter to be synchronized in time.

The process you're describing would be great for event and accident investigation, but many here, perhaps even yourself, have seen how slow the FAA (and TC in Canada) are in keeping up with available recording technology. "Mandating" the recording of 88 parameters is actually embarrassing.

Back to the subject at hand.

The BEA Report indicates that AF447 had an SSFDR that records about 1300 parameters. AF also runs a FOQA Program and as I have mentioned before, at least a search for the QAR, (in the EE Bay underneath the cockpit) should rule-in/rule-out it's availability and use, although the way the forward section is understood to have impacted, the survival of the electronic gear (and their memory cards) may be questionable.

MurphyWasRight;

Re "arriving at the 'black box' at a higher rate than is recorded" there is no mystery or magic to this stuff - it is in its essence, bread-and-butter digital data transmission and recording, (which, aside from what I've commented on, I know unbelievably little about), so no, there is neither "higher rate" or "more" data, not, at least without the original equipment such as the sensors, the DFDAU [Digital Flight Data Aquisition Unit] software and data buses [ARINC 537, 429 standards etc) to support the designed and intended installation.

I really don't want to divert the thread into the minutae of recording. My comments were intended as a caution about too loose an interpretation on what is seen in the traces regardless of airplane, recorder sophistication and so on.

For those who would really like to understand this further, (and frankly, without some understanding of how data is generated, interpreted and recorded one cannot make comments that are relevant to the very simplified way I've outlined a couple of characteristics), I recommend the two sites below - they're great for a good understanding of the process; the third site is on FOQA in general, by the FAA.

Please see Appendix B of http://www.caa.co.uk/docs/33/CAP731.PDF , and pages 9-13 of the BEA document at http://www.bea.aero/etudes/use.of.fdr/use.of.fdr.pdf , and perhaps the following FAA document which is excellent on FOQA Programs in general,
http://www.ihst.org/portals/54/Attac...D_AC120-82.pdf

ChristiaanJ;

You're right in the sense that it would be the FDIMUs or DFDAUs, (which receive the incoming data from sensors all over the airplane, and change either the analog or digital/binary information into engineering units such as rates, discretes, positions, degrees, etc etc. It would be here that the DFDAU software could "filter" any and all data depending upon programming. It's these boxes that do the heavy lifting...the SSFDR and QAR where installed, are just the recording mediums.

The notion of "filtering" is perhaps another way of saying "manipulated". I would characterize it this way, because where there is no information, ie, no digital signal because the process is "in-between" signals, one has no information to say anything with, and so if one says something, (ie, the DFDAU "fills in the places in-between), one has manipulated the data; that is an entirely legitimate process providing one knows the basis upon which the data is thus manipulated, and providing the holes in the data aren't too large and that rates of change are not incommensurate with the rate of data capture. In standard flight data animation products, such smoothing is necessary, otherwise a series of images based solely upon the data rates with no smoothing, would be very jerky and difficult to interpret. This comes down to "why videos?" in the first place. They are a contextual tool, not a diagnostic tool and as such have great use, but, (for those who have read these cautions before), those who create such videos very often do not have an understanding of how the animation is possible and can draw some seriously incorrect conclusions from just watching the video. That is why this stuff does not belong in non-trained hands...it can badly mislead and the consequences can be serious. But in trained and experienced hands and eyes, it can tell a very accurate story, because the warts are seen and understood.

One can, as has been suggested, make some reasonable inferences from other systems, (mm43's hydraulic example is a good one). But I don't think this is merely a philosophical point: Where there is no data, "smoothing the data points to manufacture datapoints in the in-between, regardless of the mathematical methods used, is not "data" - it is inference, however conceived.

Such inference can be quite reasonable to the point of appearing to be accurate in, for example, a video or film, where our mind "knows" what the changing motions on the screen are "about" and we intuitively make those connections without difficulty, and with a high degree of accuracy.

However, in reading data points which are far enough apart for other things to occur that are beyond the capacity to measure, (like using a yard-stick to measure a foot...it can't be done "accurately" even though it could be inferred, if for example the object being measured is four feet long, which is "a yard and a bit"!),, those events will not have occurred so far as interpreting the data is concerned. They may be so-recorded in other parameters, which is mm43's excellent point, but in the end, one cannot make up data where it doesn't exist even though smoothing in some cases is a legitimate process.

I'll take the risk of confusing the story....
Isn't most of the 'filtering', etc. done in the FDIU or FDAU (Flight Data interface or Acquistion Unit)?
Been there, done that, but too long ago to really be able to contribute anything useful. And no doc to hand....
Not even sure how and when the tme-stamping was done.

bearfoil:
The spoiler's condition is consistent with it being pushed up and off the wing from below by the much larger flaps.


In my experience (aerospace and motorsports) one signature does not fit all! Depends largely on which Fiber(s), the amount and direction of Reinforcing, and the type of Plastic.


Please make an argument as to how the VS and four of its entire forged lugs were together ripped up and forward from the tail section by loads achievable while in the air.

Sorry for diversion - having seen Ewa Ewa sucked into storm and lives to tell - National - smh.com.au interviewed in the documentary 'CloudSpotting' again recently, and heard an explanation on how such big heavy clouds stay up - they don't they are continuously falling in their terminal velocity against the updraft - I believe vertical wind more likely to have been an issue. And then we are back to the effect of speed calculated from frozen pitot tubes and real altitude rise with working static ports...

Brazilian Air Force
 

According to reporter Nadia Guerlanda Cabral (Folha.com), the Commander of CENIPA (Center for Investigation and Prevention of Aviation Accidents) assured today (19th) that Colonel Luiz Claudio Lupoli will be on board the ship Ile de Sein representing the FAB (Brazilian Air Force) on the rescue mission.

Colonel Lupoli said that it is difficult to estimate how long the rescue will last, since this depends on how many trips the "equipment" will have to make.
This equipment needs three hours to reach the bottom (@3.900 meters).

It seems to me BEA kwows exactly where to go with this "special mechanism" and bring up only the "essential"...

Not sure what you mean by "real altitude rise with working static ports" - I'm aware of the effects of blocked pitots and statics on airspeed and/or altitude information - just trying to see your point.

That said, loss of airspeed information does not automatically result in loss of control as, (say) loss of attitude information would. So something else happened, and these points have been made throughout the thread. But my point remains, it has no relationship with the A319 event which was "local" and mostly roll not pitch related as someone has already keenly observed. BTW, they changed the VS on the aircraft.

"Ile de Sein" - Recovery Operation update
 

"Ile de Sein" departed Las Palmas 2011-04-19 1540z and ETA Dakar is 2011-04-22 0700z.

@PJ2 thank for your detailed explanation!

shurely no commercial airplane should fly into a CB....

I did not mean a "guard against stall" just the few percent less risk, if one lift the aerodynamic stability on a truly higher level in case of expected turbulences, using existing technics......

I wonder, but it shows again the trust into the control system

sensor validation, I'd say "most likely within 40nm" is something a little less conservative than saying "most likely the Sun will not have gone out when it should rise in the morning." I'd use most likely for that annulus I described rather than for the entire region. The rest of the 40nm region is less likely but not utterly unlikely - erm, with the exception of the area +/- 30 degrees of the reverse course. To the rear the region would be punched in. That's why I always sorta head scratched over their nice perfect circles.

Nothing new, just referring back to much discussed effect of locked in pressure (ram and drain hole blocked *) - the 'apparent indicated airspeed' rises with altitude. Obviously most dangerous under take-off climb, which will likely be the design case for pitot tube heating/draining and procedures. Possibilities to climb under 'pitch and power' at cruise height include updrafts and that discussion that the Airbus/AF recommended pitch too high? Higher altitude, lower real air-speeds = lower margins?

* Note linked to your other discussions on sampling/filtering - it is possible to detect this by 'listening to the noise' and there are patented and commercial pressure instruments in the process industries that do "impulse line blockage detection".

Exploding FRP
 

Hi Bearfoil...

Just humour me here, please.

What's your experience?... and can you point me to a Youtube video of this stuff exploding please. I'd love to see it.

I drove a Reliant Robin into a wall once, but that just cracked.

SD666 drove a Reliant Robin into a wall once, but that just cracked

The speed they went, I am surprised it didn't just bounce off the wall with a scratch or two.:D

ACA190 versus AF447
 

Quote from PJ2 (Apr19/0714z, currently post #3646):"I don't think there is anything in the A319 event that relates to the AF447 event. The AC event was wake turbulence...quite different than TCu's."

PJ2 is absolutely right to remind us that wake turbulence is a very different phenomenon from turbulence in towering cumulus (or Cb storm-cells). I reckon he has experienced both, as I have.

For whatever reason, posts have been coming thick and fast over the last two or three days, and it's possible that even PJ2 may have missed something here. There are arguably at least four points of similarity between ACA190 (the Air Canada A319 wake-turbulence encounter that sensor validation kindly reminded us about) and AF447:
1) both involved Airbus FBW aircraft, whose artificial handling qualities are deliberately similar;
2) both occurred at medium subsonic-cruise altitudes;
3) both involved the PF suddenly and unexpectedly having to "hand-fly" the aeroplane, using the sidestick (the use of rudder pedals in ACA190 is another matter);
4) in both cases, for one reason or another, control laws were degraded.

Few line pilots dispense with the autopilot for regular handling practice at cruise altitudes, even in smooth conditions. Passenger comfort is our main priority. As for deliberate degradation of control laws (by selecting one or two of the 5 flight-control computers off, as someone once wanted to do on a flight with me in the early months of A320 operations), that is definitely taboo on the line.