// RESOURCES
Understanding the subjects behind our systems.
Anonymised case studies and in-depth articles written by our engineers on the standards and techniques of airborne acquisition and recording — no filler, no sales pitch in disguise.
Case studies
As a matter of principle we do not name our customers. The configurations described are real; the identities are not.
Over a thousand parameters, live, from one aircraft
A new variant of a high-performance light aircraft, a full flight-test installation, and a constraint that decides the architecture before anything else: all of it live, on one time reference.
A test track, six units and one megahertz
Sampling at a megahertz is not difficult. Doing it in six places spread over several kilometres, and having every channel land on the same timeline, is the whole problem.
A secure audio recorder that changed nothing on the aircraft
Sixty-four audio channels, an encrypted medium, full TEMPEST certification — and the hardest requirement of all: fit inside the envelope and the interfaces of the system being replaced.
Instrumenting a production trainer without freezing the configuration
A European airframer needed instrumentation that could ship with every aircraft and still differ from one customer to the next. The answer was not a bigger unit — it was one that could be assembled differently.
Design & architecture
Airborne data acquisition systems, explained
An airborne data acquisition system turns what happens on an aircraft — strains, temperatures, pressures, bus traffic, video — into time-stamped data that engineers can trust on the ground. Every flight-test campaign, equipment trial and certification flight starts with one. Here is what it is made of, how the parts fit together, and how to compare one system with another.
Designing a flight-test instrumentation chain: from sensor to report
Nine stages, one time reference and a single governing rule: every stage can lose information and no stage can add any. A guide to the whole chain, and to knowing which link is your weakest.
Sizing an airborne acquisition system: a worked example
Four budgets have to close at once — bit rate, storage, telemetry and mass — and they are coupled. Here is the arithmetic, done all the way through on a real-shaped installation.
Centralised or distributed: where to put the acquisition units
The question looks like an architecture debate. It is mostly geometry: how far your sensors are from each other, and who owns the mass of the harness.
Time and synchronisation: IRIG-B, GPS and PTP
Every other measurement can be repeated. A timing error cannot: it is discovered months later, during analysis, and it invalidates every comparison that was built on it.
Ethernet and PTP on board: a flight-test network that keeps time
Ethernet has replaced most point-to-point links in flight-test installations: one cable per zone, every unit reachable for configuration, the same data sent to the recorder, the telemetry and the screens at once. Such a network is easy to build and easy to get subtly wrong, mostly on time. Here is what to design, what to buy, and what to check.
History & heritage
From the sea to the aircraft: how ETEP began
ETEP started in 1979 in Toulon, with an electronics engineer, Jean-Patrick Caille, and with the sea: hydrophone acquisition units, sonar recording and computerised test benches for the French Navy. Alongside, a second field taught it to record the faint signals of the human body. Everything ETEP builds today — recorders that fly, survive crashes and keep their data — grew out of those two schools.
Why D.T.MUX?
Three letters and a few dots, inherited from the age of magnetic tape. D.T.MUX stands for Data Tape Multiplexed: the name described the job, putting every channel onto one tape, and the format that carries it has outlived the tape itself. Where the name comes from, what the tape era left in the format, and why ETEP kept it on every product.
A brief history of the flight recorder
Before it had a name, the flight recorder was a beam of light on photographic film, in a workshop at Marignane. Eighty years later it is a solid-state memory inside an armoured orange module and, more and more, a stream of data sent off the aircraft. Almost every step was triggered by an accident that could not be explained. Here is the story, from the first recorders to ED-112B.
Why is the black box orange?
It is called a black box, and it is painted orange. The paradox has a simple answer: the colour is there so that the recorder can be found, in wreckage, in a field or under water, and the name is older than the recorder itself. Here is where both come from, and the other details — lettering, reflective tape, beacons, position in the aircraft — that turn a protected memory into a recorder investigators can actually recover.
Thirty years in service: keeping airborne equipment alive
An aircraft flies for twenty, thirty, sometimes forty years. The memory chip inside its recorder may leave its manufacturer's catalogue after three. Between the two calendars sits a discipline nobody mentions at the kick-off meeting, and it decides whether an installation can still be maintained in year fifteen. Here is how it works, with examples from our own fleet.
IRIG-B: a 1950s time code still on board
Designed for the tape recorders of test ranges in the late 1950s, IRIG-B still time-stamps flight-test data today, in aircraft that also carry GPS receivers and PTP networks. It is a hundred pulses a second, three pulse widths and one frame per second, and its simplicity is exactly why it has lasted. Where it comes from, how it works, and where it still fits.
MIL-STD-1553 at fifty: why a 1973 data bus still flies
It runs at one megabit per second, carries 16-bit words and was written before the personal computer existed. Fifty years later, MIL-STD-1553 still links the computers of the International Space Station, the flight controls of a recent airliner and the avionics of tens of thousands of aircraft. Its longevity is no accident, and it says a lot about what an onboard bus is really for.
Standards & formats
IRIG 106 Chapter 10, explained
Why flight-test data ends up in a .c10 file, what the standard actually specifies, and what it deliberately leaves to the vendor — a practical guide for engineers who record, download and analyse airborne data.
The D.T.MUX format, and how it compares to Chapter 10
Why a recorder still has a house format, how a D.T.MUX recording is built, and where it lines up with — and deliberately departs from — IRIG 106 Chapter 10.
Choosing Chapter 10 analysis software: what to check before you commit
Most Chapter 10 tools look alike in a demo. The differences show up on your own recordings: an edition the reader only half supports, a time reference it ignores, a 200 GB file it cannot seek. Here is what to check, and how to check it, before a tool becomes part of your process.
Reading an avionics bus: MIL-STD-1553 and ARINC 429
Two buses designed half a century ago, still being installed on new aircraft — how they work, what it takes to record them honestly, and why the hard part is never the recording.
ARINC 717 and 573: reading the frames that feed a flight data recorder
Airliners and many helicopters send their flight data to the recorder in the same slow, rigid format: twelve-bit words, four one-second subframes, a sync word at the head of each. Recording that stream is easy; making sense of it is not. Here is how the frame is built, what the data frame layout adds, and where decoding goes wrong.
IRIG 106 Chapter 4: what the PCM telemetry standard actually requires
Chapter 4 is the oldest working part of IRIG 106, and still the one every telemetry range implements: the rules of a PCM stream, from the bit code to the frame. Most of it fits on a page. The part that matters most is the line between Class I, which every range accepts, and Class II, which the range must agree to first.
IRIG 106 Chapter 7: sending packets, Ethernet and video down a PCM link
Telemetry links were built for PCM: fixed frames, fixed rates, and decades of receivers, bit synchronisers and decommutators on every range. Modern installations produce packets — Chapter 10 packets, Ethernet frames, compressed video. Chapter 7 of IRIG 106 carries those packets inside an ordinary PCM stream, so the radio link and the ground equipment stay the same. Here is how it works, and what to watch when you use it.
Telemetry
PCM telemetry: frames, sync and link budget
How several hundred sensors end up as a single serial bit stream, how a ground station finds its way back into that stream, and how far it will actually reach — the practical mechanics of PCM/TDM telemetry.
Satellite links and telemetry: what Starlink actually changes
A low-orbit constellation will not replace the range telemetry link. It replaces the absence of a link everywhere else — and it brings something telemetry has never had: a way back up.
Anatomy of a telemetry ground station
Six stages between a radio signal and a decision, and a hard deadline: the test conductor has to be able to say continue or abort while the aircraft is still on the point.
Acquisition & recording
Sampling, quantisation and aliasing: how not to record a false measurement
Most defects in a measurement chain announce themselves. Aliasing does not: it produces a clean, plausible, entirely fictitious signal, and it is the only error in the chain that cannot be repaired afterwards.
Sensor conditioning: strain gauges, thermocouples, IEPE and LVDT
Everything upstream of the converter decides the ceiling. A guide to what each sensor family actually demands, and to the errors that survive all the way into the report.
Onboard video: H.264, bandwidth and staying in sync
Video is the cheapest witness on a test aircraft and the easiest data to get subtly wrong — a practical look at compression, bit rate, timing and installation.
Debriefing flight training: what recording the flight changes
A lesson is usually debriefed from memory — the instructor's and the student's, which rarely agree. Recording the flight replaces two recollections with one timeline. What to record, what it takes on a light aircraft, and how to keep it a teaching tool.
Onboard memory: SSD, cartridges and erasing for real
The specification that matters is not how fast the memory can write, but how slowly it is allowed to write on its worst millisecond — and what happens to the data when the campaign is over.
Data integrity: detecting losses, drifts and truncated recordings
The file exists, it opens, and the curves look plausible. None of that is evidence. Here is the list of things that can be wrong with a recording, and which of them you can actually detect.
Recovering data after a power cut or a corrupted recording
A recording that was never closed is not a recording that is lost. What decides how much comes back is a design decision taken long before the flight — and a few rules about what you do in the first hour.
FDR, flight-test recorder, mission recorder: what actually differs
They all record flight data onto solid-state memory in an aircraft. Beyond that they have almost nothing in common — and the differences are not technical, they are about who is asking.
Crash-protected recording
Crash-protected recorders: what ED-112A and ED-155 require
What "crash-survivable" actually means, test by test — and how a handful of numbers written in a EUROCAE document decide the shape, the mass and even the write strategy of a recorder.
ED-112B: what changed since ED-112A for crash-protected recorders
For ten years, ED-112A was the reference for crash-protected flight recorders. Its successor, ED-112B, keeps the crash envelope everyone knows — 3 400 g, an hour at 1 100 °C — and changes much of what surrounds it: longer sea tests, longer cockpit audio, new recording functions, flight data sent off the aircraft, and rules for the tools that read a recorder after an accident. Here is what changed, and what it means for a programme.
Qualification & environment
DO-160 and MIL-STD-810: what qualification actually involves
Two standards, two philosophies, twenty-six sections and a great deal of lab time — a practical guide to what environmental qualification does, what it proves, and what a compliance claim is really worth.
MTBF: what the number says, and what it cannot tell you
Every datasheet has one, and it is one of the most misread figures in engineering. An MTBF of 100,000 hours does not mean a unit will run for eleven years, nor that it will not fail next week. It is a statistical statement about a population, built on assumptions that are rarely printed next to it. Here is what MTBF really says, where it comes from, and why no figure — and no method — can tell you when a given unit will fail.
Coming next
- Decommutation and calibration: from raw counts to engineering units
- Onboard Ethernet: IENA, iNET-X and real-time acquisition
- Writing the specification for an airborne recorder: the checklist
A subject you would like us to cover?
Tell us what is missing — our engineers write these articles from the questions they get asked.
Suggest a subject →