Originally Posted by syseng68k @3650
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...
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.