Designing a flight-test instrumentation chain: from sensor to report

What "chain" actually means

An instrumentation chain runs from a physical quantity on the airframe to a sentence in a report. In between there are perhaps nine stages, and they obey one rule that decides everything else: each stage can lose information, and no stage can add any back.

Two consequences follow, and both are routinely ignored. The first is that the quality of the result is set by the weakest stage, so the useful engineering question is never "how good is my recorder" but "which stage is my ceiling". The second is that over-specifying any single stage buys nothing: a twenty-four-bit converter behind a sensor accurate to half a percent produces a very precise measurement of an imprecise thing.

There is one exception to the per-stage view, and it is the reason this article exists as a whole rather than as nine separate ones. Time is not a property of a stage. It is a property of the chain, shared by every channel, and it is the only thing that cannot be fixed afterwards by a better instrument somewhere.

The sensor and its conditioning

Everything upstream of the converter sets the ceiling. The sensor accuracy, the stability of its excitation, the cable and its shielding, the bridge completion, the amplification, the filtering, the galvanic isolation: by the time a value reaches a converter, its quality is already decided.

And each sensor family brings its own problem. A strain gauge needs a stable excitation and a completed bridge, and it will happily report the temperature of its own cable if you let it. A thermocouple needs a known type and a cold-junction reference. An IEPE accelerometer needs a constant-current supply and has a high-pass limit that quietly removes the low frequencies you may have wanted. An LVDT needs AC excitation and synchronous demodulation.

Digitising: rate, range and resolution

The sample rate is a budget decision disguised as a physics one. Twice the highest frequency of interest is a theoretical floor; five to ten times is what produces a curve an engineer can read and leaves room for filtering later. And whatever rate you assign, the anti-aliasing filter has to match it — aliasing is the only defect in the whole chain that cannot be detected after the fact, because the corrupted data looks clean.

Range and resolution work together and are usually mismatched. Sixteen bits is standard, but what matters is the effective number of bits and the fraction of the input range you actually use: a ±10 V input recording a signal that never exceeds ±0.5 V has thrown away four bits before the first sample. Conversely, a range chosen too tight produces clipped samples — and a clipped sample is worse than a missing one, because it looks perfectly valid.

Multiplexing and time stamping

Multiplexing is what lets one medium and one radio link carry hundreds of channels: each one gets its slot in a repeating structure. The structure is a contract, and it has to be identical onboard and on the ground — a mismatched format does not produce visibly broken data, it produces plausible data, which is far more expensive.

Time stamping is where campaigns are quietly lost. Every acquisition unit, every recorder and the ground station must be locked to the same reference — IRIG-B, GPS or PTP. Two units on independent clocks inherit a fixed offset that is invisible in each file taken alone and obvious the moment you overlay them, and finding it usually costs more than the instrumentation did.

The refinement that separates a good chain from an adequate one is recording something about time itself: which source dated each block, and whether that source was healthy at the time. Reconstructing a GPS dropout afterwards from memory and logbooks is a bad use of an engineer week.

Writing: the medium and the container

Two independent decisions sit at this stage. The medium decides whether you keep every sample: a recorder needs sustained determinism, not peak throughput, and the specification that matters is the worst millisecond rather than the average second. The container decides what survives an interruption: a file whose index lives at the end turns a power cut into a total loss, while a stream of self-contained, self-dating blocks degrades to exactly what was written.

Both decisions are cheap to get right in advance and expensive to revisit. Both are also easy to validate: run the chain at full rate for hours and count the samples, then pull the power in the middle and see what you can read.

Transmitting: what goes down live

The telemetry link never carries everything, and it is not supposed to. What goes down is the subset that lets the flight-test engineers watch the point, judge it and call the next one — a few megabits per second of parameters, and often one video channel at reduced quality. What is recorded onboard is what answers the question afterwards.

How much you can send is decided by a column of decibels, and the weak line in that column is almost always the airborne antenna rather than the transmitter. Doubling the bit rate doubles the occupied bandwidth and costs three decibels, which is why bit rate should be tracked as a configuration item over a campaign rather than discovered at the edge of the range.

On the ground: from data to an answer

The ground segment has two jobs that are often confused. During the flight it receives, demodulates, decommutates and displays, so that somebody can make a decision within seconds. After the flight it downloads, applies the calibration, aligns every channel onto one timeline, extracts the segments that matter and exports them to whatever the analysis actually runs in.

A good ground chain has three properties worth specifying explicitly. It reconstructs the timeline from the recorded time rather than from arrival order. It checks integrity instead of trusting it — missing packets, sequence breaks, sync losses, checksum failures, a setup record that does not match the data. And it exports without a fight, because the report is never written in the acquisition vendor tool.

The chain is not finished when the file exists. It is finished when the question has an answer that somebody else can check.

What actually breaks a chain

• Time references that are not common. This is first because it is the most frequent, the most expensive and the least visible in each individual file.
• A configuration that drifted: a frame format, a bus interface document or a calibration that no longer matches the recording it is applied to. The data looks plausible and is wrong.
• Margin eaten silently. Bit rate creeps up as parameters are added, storage fills, the link budget is never reopened, and everything works until the day it does not.
• A chain never exercised end to end, at full rate, for a realistic duration. Bench tests at a tenth of the rate prove nothing about a recorder.
• The environment. A chain that works on a desk and not at −40 °C, or that fails an EMC scan with the harness routed the way it will actually be routed.
• And the one nobody writes down: nobody owns the chain. Each supplier answers for their box, and the interfaces between them belong to no one.

The remedy for most of that list is a single day, spent once, before the campaign: inject a known signal at the sensor, follow it through every stage, and produce the report from it. It is the cheapest day in the whole programme, and it is the only test that measures the chain rather than the boxes.