glob99;
With the forebearance of the forum admins, I would like to take a diversion into dataframes for understanding. Perhaps this may assist others as it will me. The primary goal is to understand this sufficiently to be able to appreciate how sample rates represent realities in the interpretation of flight data for the purposes of determining "what happened". How close can we get and what are the pitfalls?
Not formally educated in physics, I'm on the edge of my knowledge but I wonder if the Nyquist Theorem (rate) would apply to flight data?
I am very prepared to learn here as I initially thought that both fft and the Nyquist theorem could be applied usefully to flight data sampling because they are signals but right now I sense not unless a less formal interpretation is being offered.
The reason I ask is, the "signal" of a parameter while still a recorded voltage, is not a sine wave but a discrete "on-off", a rate-per-second, or a position (degrees), the "frequency"of which is determined not by the signal or the recording equipment but by a fixed data-frame. Flight data isn't a frequency but is a voltage represented by a fixed data state. Flight data (engineering format) cannot be displayed on an oscilliscope for example. However, the source of flight data may possibly be so displayed and that is where the Nyquist theorem may have relevance.
I'm not sure where the term "frequency", and "sampling rate" should be applied. It seems to me that they are in circular reference to one another in flight data, the dataframe supplying, by pure frame design (4x512) both frequency and sample rate. That said, the potential for far higher sampling rates is there and only restricted by the design of the dataframe itself, at least from my point of view all of which goes to prove that a tiny bit of knowledge is a dangerous thing!
Anyway, I understand the inherent inaccuracies behind the notion of "using a yardstick to measure a foot" but I'm not sure there isn't more to your suggestion than first meets the untrained eye?
We measure 'g' at eight times a second, most other parameters at four, two or once per second and those which do not change rapidly over time, once every two or four seconds.
A poster has suggested that recording be "enriched" during the critical phases of flight. I would agree but that represents technical problems in terms of dataframe and software design, not insurmountable but probably more easily resolved in increasing the dataframe to 4x1024 for instance.
Ideally, 29.96 frames-per-second for all parameters (with a search capability equal to such a task!), would be wonderful and maybe we'll see that as cheap memory and processor speeds permit.
In the meantime, those who do data work (and I suspect you're among them), know that estimating the values in between cannot/should not be done. It's a fascinating rabbit-trail and I hope that the admins permit the diversion.