PJ2 Wrote:
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.
I don't know where acars comes into this, because I understood from your
post that the context was flight data recording ?.
From your original post 3640:
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.
And then:
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.
Which is what I was disagreeing about. A few general data logging and
comms system basics may help here, but apologies if preaching to the
choir :-).
To start, there may be many sources of data/parameters to log, in different
formats (ie: "language") and at different sample rates, (ie: how often a
parameter is examined). The data format, sample rate and accuracy of
measurement depend, of course, on the requirements of each parameter to
be measured.
Sampled data is typically sent across high speed data buses (ie: highways),
at microsecond rates, encapsulated in frames, or "packets". A fair data bus
analogy is a road full of houses, each with a unique address, containing
people with different names. A fair analogy for a frame is a posted letter,
which will have a destination address, the sender's address, perhaps time
and date, with the measured "data" on the page inside the envelope. For
frame based data comms, all the above information would normally be
included in one form or another, as well as checksum data to allow
detection of errors in transmission. (ie: a torn envelope) Where letters can
take an indefinate amount of time to deliver, avionics buses are designed to
provide guaranteed delivery within very strict time limits.
Between the data source and recorder there may be, depending on the
application, a "data aquisition unit". The function of this is to provide a
central "clearing house" for the various sources and to measure and / or
translate to a common format, or language, to send to the recorder. It may
also timestamp the incoming data, and filter or manipulate it in other ways.
In some systems, acquisition and logging are combined into a single
physical unit, but the functionality remains the same. Such systems often
use queueing techniques to avoid date loss at peak rates, but the data
would be timestamped *before* insertion into any queue. This avoids time
displacement errors where the actual data is stored some time later. By
“some time”, I mean milliseconds, not seconds or minutes.
The key thing i'm, trying to get across here is that accurate timestamping
is fundamental to any data logging application such as this. It is always
designed to have sufficient accuracy in terms of measured value and timing
to meet the needs of the application...