# IRIG 106 Chapter 10 recordings URL: /collect/formats/irig-106-chapter-10 Foxborne reads time packets, PCM, MIL-STD-1553 and ARINC 429 channels from a flight test recording, decoded with its own TMATS setup record. This page also covers how the recording keeps time, per IRIG 106-23 Chapter 11. IRIG 106 is the Range Commanders Council's telemetry standard, and its Chapter 10 is the digital recording standard that flight test recorders follow. Foxborne reads Chapter 10 recordings, `.ch10` files, from the aircraft and from the ground station. Everything on this page about the format itself comes from IRIG 106-23 Chapter 11, the Recorder Data Packet Format Standard, July 2023. ## What Foxborne reads [#what-foxborne-reads] Foxborne reads time packets, PCM, MIL-STD-1553 and ARINC 429 channels, and it decodes them with the recording's own TMATS setup record. Each packet's header names its data type: | Packets | Data type | Chapter 11 name | What they carry | | ------------ | --------- | --------------------------------- | ------------------------------------------------------------------------------------------ | | Setup record | `0x01` | Computer-generated data, format 1 | The hardware, software and channel configuration that produced the other packets, as TMATS | | Time | `0x11` | Time data, format 1 | Absolute time, such as IRIG-B or UTC from GPS, tied to the recorder's counter | | PCM | `0x09` | PCM data, format 1 | Chapter 4, 7 or 8 PCM, minor frame by minor frame | | MIL-STD-1553 | `0x19` | MIL-STD-1553 data, format 1 | MIL-STD-1553B bus messages | | ARINC 429 | `0x38` | ARINC-429 data, format 0 | ARINC 429 bus words | ## How a recording is built [#how-a-recording-is-built] A recording is a stream of packets. Each packet has a header, an optional secondary header, a body and a trailer. The framing is little endian: the least significant byte comes first. The recorded data inside the body keeps its native byte order. ### Packet header [#packet-header] The header is fixed at 24 bytes in ten fields. The byte positions follow from the standard's 32-bit layout in Table 11-2. | Bytes | Field | Content | | -------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 to 1 | Packet sync pattern | `0xEB25` on every packet. Little endian, so the bytes read `25 EB`. | | 2 to 3 | Channel ID | A value unique to each data source. `0x0000` is reserved for setup records and streaming configuration records. | | 4 to 7 | Packet length | The whole packet in bytes, always a multiple of 4 | | 8 to 11 | Data length | The valid data in bytes: channel-specific data, intra-packet headers and data, without filler or checksum | | 12 | Data type version | The release of the standard applied to the data type. `0x0A` is RCC 106-22. | | 13 | Sequence number | A counter per channel that rolls over to `0x00` after `0xFF` | | 14 | Packet flags | Secondary header present, time source of intra-packet time stamps, RTC sync error, data overflow, secondary header time format and data checksum size | | 15 | Data type | The type and format of the data, from Table 11-4 | | 16 to 21 | Relative time counter | The 48-bit value of the recorder's 10 MHz counter | | 22 to 23 | Header checksum | A 16-bit arithmetic sum of every 16-bit word in the header except this one | A single packet can hold at most 524,288 bytes. The setup record is the one exception: it can reach 134,217,728 bytes, and it may span several consecutive packets. ### Packet flags [#packet-flags] | Bits | Meaning | | ------ | --------------------------------------------------------------------------------------------------------------------- | | 7 | 1 when a secondary header is present | | 6 | Time source of intra-packet time stamps: 0 for the 48-bit counter, 1 for the secondary header's time | | 5 | 1 when an RTC sync error has occurred | | 4 | 1 when a data overflow was detected before or during this packet | | 3 to 2 | Secondary header time format: `00` Chapter 4 binary time, `01` IEEE 1588 time, `10` a 64-bit extended counter at 1 ns | | 1 to 0 | Data checksum: `00` none, `01` 8-bit, `10` 16-bit, `11` 32-bit | The overflow flag can mean lost payload, but the standard says it may not. Treat it as a question for the recording, not an answer. ## The relative time counter [#the-relative-time-counter] The relative time counter, or RTC, is the recording's clock. Chapter 11 defines it as a free-running 10 MHz binary counter of 48 bits, common to all data channels. It runs from an internal 10 MHz crystal and stays free-running for the whole session, such as a recording. One count is 100 ns. The counter holds 2⁴⁸ counts, so it wraps after 28,147,497.7 s, about 326 days. Because every channel shares one counter, a PCM frame and a bus message in the same recording sit on one clock. Their order needs no cross-clock bound. What remains is how finely each channel samples and stamps its data. ### Time stamps inside a packet [#time-stamps-inside-a-packet] | Channel | How each item is stamped | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | PCM, format 1 | Each minor frame carries an 8-byte intra-packet time stamp: the counter at the first data bit of the minor frame. Its data header carries `LOCKST`, the frame synchronizer's minor and major frame lock status. Throughput mode has no stamps. | | MIL-STD-1553, format 1 | Each message carries an 8-byte intra-packet time stamp and a 6-byte data header. The time tag bits in the channel-specific data word say which bit is stamped: the last bit of the last word, the first bit of the first word or the last bit of the command word. | | ARINC 429, format 0 | No intra-packet time stamp. The packet header's time is the time of the first word, and each later word is timed from the gap times in the ID words before it. | | Time packets | No intra-packet headers | When packet flag bit 6 is set, the intra-packet stamps hold absolute time in the secondary header's format instead of the counter. ## Time packets tie the counter to absolute time [#time-packets-tie-the-counter-to-absolute-time] The counter says how far apart two packets are. Time packets say what time it was. The standard treats time like another data channel. With a time source other than none, the recorder writes a time packet at least once a second. A time packet is the first dynamic packet of each session: only setup records may come before it. A format 1 time packet opens with a 32-bit channel-specific data word: | Bits | Field | Values | | -------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | 15 to 12 | IRIG time source (ITS) | For an internal IRIG time code generator: freewheeling, or locked to external IRIG, GPS, NTP, PTP or time embedded in a PCM or 1553 channel | | 11 to 8 | Date format | IRIG day, or month and year, and a leap year bit | | 7 to 4 | Time format (FMT) | `0x0` IRIG-B, `0x1` IRIG-A, `0x2` IRIG-G, `0x3` Real-Time Clock, `0x4` UTC from GPS, `0x5` native GPS time, `0xF` none | | 3 to 0 | Time source (SRC) | `0x0` internal, `0x1` external, `0x2` internal from the removable memory module (RMM), `0xF` none | The time itself follows in binary-coded decimal, from the date down to tens of milliseconds. When the recorder loses lock on an external source, SRC reads internal until lock returns. Time format `0x3`, Real-Time Clock, names a format for the time in the packet body, not the relative time counter. Chapter 11 also defines a format 2 time packet, data type `0x12`. It carries absolute time from NTP or IEEE 1588 PTP, tagged with the same counter. NTP time is UTC with leap seconds, and PTP time is International Atomic Time without them. The pairing is what makes the counter useful. The recorder captures the counter into the time packet's header, and the body holds the absolute time that goes with it. For IRIG formats, the capture follows IRIG 200, the serial time code standard. For other formats, it follows the body's 10 ms resolution. ```text title="From counter to clock time" caption="r1 and T1 from a time packet; r from any packet in the same recording" T = T1 + (r - r1) / 10,000,000 s Example: a 1553 message stamped 4,250,000 counts after the time packet T = T1 + 0.425 s ``` A time packet reports its source and lock state, not the crystal's error. Converting a stamp between two time packets assumes the counter ran at exactly 10 MHz. ## The setup record [#the-setup-record] The setup record is a computer-generated data packet, format 1, and every recording must carry one. It describes the hardware, software and data channel configuration used to produce the other packets. Foxborne decodes each recording with its own setup record, so channel maps and bus definitions come from the file itself. | Bits of the channel-specific data word | Field | Meaning | | -------------------------------------- | ------ | ------------------------------------------------------------------------------------------ | | 9 | FRMT | Setup record in Chapter 9 TMATS: `0` ASCII, `1` XML. One session cannot mix the two. | | 8 | SRCC | `1` when the recorder configuration changed since the previous setup record of the session | | 7 to 0 | RCCVER | The RCC 106 release the recorded data complies with, such as `0x0E` for RCC 106-22 | ## Data types in the illustrative jet example [#data-types-in-the-illustrative-jet-example] Illustrative example The [jet-powered UAS example](/platforms/jets) is worked from published standards. It is not a real event and not in the console's example dataset. Its onboard recording carries these channels: | Data type | Channel | In the illustrative jet example | | --------- | ------------------------------------ | ------------------------------------------------------------------------- | | `0x01` | Computer-generated, format 1 (TMATS) | The setup record: channel map, PCM format, bus and label definitions | | `0x11` | Time, format 1 | IRIG-B from the airborne GPS time code generator, locked to external time | | `0x09` | PCM, format 1 | The telemetry stream, including the flight termination monitor words | | `0x19` | MIL-STD-1553, format 1 | Flight control computer, EGI, C2 modem and actuator controllers | | `0x38` | ARINC 429, format 0 | Engine control unit: N1, EGT and fuel flow | | `0x68` | Ethernet, format 0 | C2 modem diagnostics at 10 Hz: signal strength, CRC errors, frame counter | The ground station keeps a Chapter 10 recording of its own. In the example, the decommutator's `LOCKST` status in that recording places the ground's loss of frame lock at 17:42:03.779 and its return at 17:42:06.861. ## Clocks and bounds [#clocks-and-bounds] A recording's channels share one counter, and its time packets say what time source the recorder followed and whether it held lock. The file records both. Read the SRC and ITS fields before trusting any UTC time from a recording. In the illustrative jet example, the recorder, the ground station and the range all run on IRIG-B, so their clocks agree to microseconds. What limits the order of events there is sampling: 1 ms PCM frames, a 20 ms bus schedule and 50 ms radar samples. A status word on a 20 ms bus schedule places its event to ±20 ms, however good the clock. [Clocks, anchors and error bounds](/concepts/clocks) covers the bounds on PX4 and companion logs, where the clocks are the limit instead. ## Chapter 10 or Chapter 11 [#chapter-10-or-chapter-11] People call these files Chapter 10 recordings, and the name has stuck. Since RCC 106-17, though, the packet format lives in Chapter 11. Chapter 11's own note says that references to RCC 106-04 through 106-15 point to Chapter 10, and RCC 106-17 onward to Chapter 11. The setup record's version field shows the history. RCCVER was called CH10VER in RCC 106-04 through 106-15, when it was described in Chapter 10. ## Importing recordings [#importing-recordings] Recordings arrive through file import, by upload, drop folder or removable media. The console's **File import** entry, under **Integrations** and **Ingest**, lists IRIG 106 Chapter 10 with the government suitability **Published formats; IRIG 106-23 for Chapter 10**. Each file is hashed with SHA-256 at receipt and checked against the sender's manifest before it is parsed. **Settings**, under **Import**, lists the formats your deployment reads. The example deployment's **File import** reads **On, 4 formats**, and Chapter 10 is not among them. A recording counts against the import limit: 250 MB per file by default, with 1 GB or 4 GB as an admin's other choices. See [Limits and defaults](/reference/limits). ## Related [#related] * [Jet-powered UAS](/platforms/jets) walks through the illustrative example these channels come from. * [Range records](/collect/formats/range-records) covers radar TSPI, the telemetry receiver log and the flight termination console log. * [Supported file formats](/collect/formats) compares every format Foxborne reads. * [Clocks, anchors and error bounds](/concepts/clocks) explains how Foxborne treats clocks and anchors.