IRIG 106 Chapter 10, explained

Why flight test needed a common format

A flight-test installation is almost never single-vendor. Sensors come from one supplier, the acquisition units from another, the recorder from a third, and the ground station and analysis software from two more. Every one of them has to agree on what a recorded second of flight looks like.

Before a common digital format, each recorder wrote its own. That meant a bespoke reader for every box, data effectively locked to one toolchain, and an archiving problem that only grows: a programme that flies for thirty years has to be able to reopen a file recorded on hardware that no longer exists.

IRIG 106 is the telemetry standard published by the Range Commanders Council Telemetry Group, and it is the reference across test ranges. Chapter 10 is its digital recording chapter: a single container that any compliant tool can open. The practical consequence is the one that matters — your recorder and your analysis software no longer have to come from the same supplier.

What Chapter 10 specifies — and what it does not

It specifies

• A packet-based container: how heterogeneous data (PCM frames, avionics buses, video, analog, discretes, serial links) is wrapped, identified and time-stamped inside one stream.
• Channel identification, packet sequencing and integrity checks.
• The setup record (TMATS) that describes what the recording contains.
• How time is represented and tied to an external reference such as IRIG-B or GPS.
• The interfaces used to download or stream the data.

It does not specify

• How your parameters convert into physical units — calibration lives in your instrumentation database, at best partially mirrored in TMATS.
• Compression or encryption schemes: those remain vendor territory.
• What a well-organised file looks like. Recording indexes and event entries are useful but optional.

Inside a Chapter 10 packet

Everything in the file is a packet, and every packet opens with a fixed-size header. It starts with a sync pattern (0xEB25) so a reader can lock onto the stream even mid-file, then carries the channel ID, the packet and data lengths, a sequence number, flags, the data type, and a 48-bit relative time counter (RTC) clocked at 10 MHz. A header checksum closes it.

An optional secondary header carries absolute time. Then comes a channel-specific word holding the parameters that only make sense for that data type, and finally the payload. For message-oriented types — a 1553 bus, ARINC 429, a serial link — each message inside the payload is preceded by its own intra-packet header carrying its individual time and status. Filler and an optional data checksum close the packet.

That two-level timing is the heart of the standard. A 1553 message and a video frame recorded in different packets can still be replayed in their true relative order, because each one carries its own instant rather than relying on its position in the file.

The data types you will meet

The exact set of types and sub-types evolves between editions of the standard. A reader must honour the header version it finds rather than assume one edition — and a file may legitimately mix a vendor-specific type with standard ones.

TMATS: the recording that describes itself

TMATS is a plain-text set of attribute/value pairs, organised in groups covering the recording in general, the recorder itself, PCM frame structures, buses, and vendor-specific extensions. It is written as the first packet of the recording, which is what makes a Chapter 10 file self-describing: which channels exist, how the PCM frame is built, what the sample rates and ranges are.

In practice TMATS is only as good as the setup that produced it. The classic failure is a mismatch: a channel renamed after the setup was exported, a sample rate changed on the flight line, a parameter list that no longer matches the frame. A good analysis tool shows you the TMATS and flags inconsistencies instead of silently trusting it.

Time: the part everyone underestimates

The 48-bit RTC at 10 MHz gives sub-microsecond resolution over roughly ten months of continuous counting. It is the recorder own clock, and on its own it says nothing about UTC. Absolute time packets and secondary headers are what tie it to an external reference — IRIG-B, GPS or PTP.

Two recorders on the same aircraft only agree if both are locked to the same reference. If they are not, you inherit a fixed offset that is invisible in each file taken alone and obvious the moment you overlay them — and finding it usually costs a campaign.

The same logic applies on replay. Everything must be reconstructed from the recorded time, never from the order in which packets happen to be read or received. A tool that draws each channel up to its own latest sample will show phantom offsets between traces that were in fact acquired at the same instant.

From onboard recording to the ground station

1. Onboard, the acquisition units digitise sensors and buses, and the recorder writes Chapter 10 packets to an internal SSD or a removable cartridge.
2. During the flight, a subset is usually transmitted over RF telemetry so the ground can watch the test live.
3. The same packets can also be streamed over Ethernet, which lets a ground station act as a real-time receiver on a test bench or in an integration hall.
4. After the flight the file is downloaded over Ethernet or by swapping the cartridge, then decommutated, visualised, exported and reported on.
5. Because the container is standard, that file stays readable long after the recorder is out of service — which is the real reason programmes mandate it.

Common pitfalls

• Treating "Chapter 10 compliant" as "interchangeable". Check the edition, and check which data types are actually used.
• Ignoring TMATS, then rebuilding the parameter description by hand months later.
• Mixing time references between recorders, or between recorder and ground station.
• Relying on vendor-specific data types without checking that your analysis chain reads them.
• Very large recordings with no index: every seek turns into a full-file scan.