IRIG 106 for people who live in PX4 logs

If you can put a PX4 flight log on UTC, you can read the clock in a range recording. Both files stamp data with a free-running counter, and each can tie that counter to absolute time through a separate record.

What differs is the counter’s rate, who shares it, and how the file writes the tie down. This post walks the recorder side in terms that a ULog reader already uses.

Chapter 10 records, Chapter 11 defines the packets

The Range Commanders Council publishes its telemetry standards as IRIG 106, and the release posted on its public site is 106-24R1.¹ The range commanders recommend that telemetry equipment in programs that need range support conform to it.²

Chapter 10 is the digital recording standard. It began when test ranges started fielding high-rate recorders without tape, most of them solid-state.³ The chapter names on-board recorders as its basis and original justification.³

Since RCC 106-17, the packet format lives in Chapter 11. Section 10.6.1 says that data shall be formatted in accordance with Chapter 11.³ Under the data type version field, Chapter 11 notes that RCC 106-04 through 106-15 refer to Chapter 10, and 106-17 onward to Chapter 11.⁴

So what people call a Chapter 10 file is Chapter 11 packets inside a Chapter 10 recording. Every recording opens with a setup record packet, and a time packet follows as the first dynamic packet.³

Every packet opens with the same 24 bytes

A packet has a header, a body and a trailer, plus an optional secondary header.⁴ The framing is little-endian, while the recorded data keeps its native byte order.⁴ The header is fixed at 24 bytes in ten fields:⁴

• a 2-byte sync pattern, always 0xEB25;
• a 2-byte channel ID, unique for each data source;
• a 4-byte packet length and a 4-byte data length;
• one byte each for data type version, sequence number, packet flags and data type;
• a 6-byte relative time counter;
• a 2-byte header checksum.

The relative time counter, or RTC, is the clock. Section 11.2.1.1 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 recording.⁴

One count is 100 ns. The counter holds 2⁴⁸ counts, or 281,474,976,710,656, so it wraps after 28,147,498 seconds, about 326 days. Chapter 10 also caps every packet except computer-generated ones at 100 ms of data, measured on the RTC.³

The flags byte carries an RTC sync error bit.⁴ An optional secondary header adds a second time to a packet: Chapter 4 binary time, IEEE 1588 time or a 1 GHz extended relative counter.⁴

Data inside a packet carries its own stamps. Each MIL-STD-1553 message gets an 8-byte intra-packet time stamp that holds the RTC at a set bit of that message.⁴ If the flags select it, the stamp uses the secondary header’s time format instead.⁴

What rides in a recording

The format was written for mixed inputs: PCM, MIL-STD-1553, time, analog, video, ARINC 429, discrete and UART serial data.⁴ Chapter 11 defines data types for all of those and more:⁴

• PCM in Chapter 4, 7 or 8 formats, data type 0x09;
• MIL-STD-1553B bus data, one bus transaction per message, 0x19;
• ARINC-429 words, timed from the packet header and the gap times between words, 0x38;
• MPEG-2 or H.264 video, 0x42;
• Ethernet MAC frames, 0x68, and UDP payloads, 0x69;
• UART data from RS-232, RS-422 or RS-485 channels, 0x50;
• CAN bus, Fibre Channel, IEEE 1394, analog, discrete, imagery and GPS NMEA-RTCM.

For a small UAS, a serial telemetry link fits the UART type. UDP traffic fits Ethernet Format 1, which takes any UDP packets.⁴

Time is just another channel

Chapter 10 treats time like any other data channel. With a time source in use, the recorder writes a time packet at least once a second.³ A Format 1 time packet opens with a 32-bit word that says what kind of time follows:⁴

Time Format (FMT). Bits 7-4 indicate the time data packet format.
   0x0 = IRIG-B
   0x1 = IRIG-A
   0x2 = IRIG-G
   0x3 = Real-Time Clock
   0x4 = Universal Coordinated Time (UTC) time from GPS
   0x5 = Native GPS Time
...
   0xF = NONE (time packet payload invalid)
Time Source (SRC). Bits 3-0 indicate the source of the time in the payload of each
time packet.
   0x0 = Internal (time derived from a clock in the recorder)
   0x1 = External (time derived from a clock not in the recorder)
...

The source field reads external when time comes from a clock outside the recorder. If the recorder loses lock on that source, the field reads internal until lock returns.⁴ For IRIG formats, a second field says whether the time code generator is freewheeling or locked to IRIG, GPS, NTP, PTP or embedded time.⁴

The time itself follows as BCD digits, from the date down to tens of milliseconds.⁴ Format 2 packets carry NTP or PTP time instead.⁴ Chapter 11 notes that NTP time is UTC with leap seconds, while PTP time is TAI without them.⁴

From counter to clock time

A time packet is a pair. Its header holds the RTC value that the recorder captured, and its body holds the absolute time that goes with it.⁴ Every channel shares the counter, so that one pair converts any other stamp in the recording.⁴

For a stamp r after a time packet with count r1 and time T1, the time is T1 + (r - r1) / 10,000,000 seconds. A 1553 message stamped 4,250,000 counts after that packet happened 0.425 s after its time.

Mind the precision of the pair. For IRIG formats the capture follows IRIG 200, the serial time code standard.⁴ For every other format, including UTC from GPS, Chapter 11 ties the capture to the body’s 10 ms resolution.⁴

Interpolating between time packets assumes that the crystal ran at exactly 10 MHz. A time packet reports its source and lock state, but not the crystal’s error.⁴

The same idea in a ULog

PX4’s clock is hrt_absolute_time(). Despite the name, it counts microseconds from an arbitrary point shortly after boot:⁵

/**
 * Absolute time, in microsecond units.
 *
 * Absolute time is measured from some arbitrary epoch shortly after
 * system startup.  It should never wrap or go backwards.
 */
typedef uint64_t	hrt_abstime;
...
/**
 * Get absolute time in [us] (does not wrap).
 */
__EXPORT extern hrt_abstime hrt_absolute_time(void);

The ULog header carries an 8-byte timestamp, which the spec describes as the time logging started, in microseconds.⁶ The logger fills it from the same boot clock:⁷

void Logger::write_header(LogType type)
{
	ulog_file_header_s header = {};
...
	header.timestamp = hrt_absolute_time();

So the header is not UTC. Message timestamps are in microseconds as well, and the tie to UTC rides inside the GPS samples:⁶⁹

uint64 timestamp		# time since system start (microseconds)
...
int32 timestamp_time_relative	# timestamp + timestamp_time_relative = Time of the UTC timestamp since system start, (microseconds)
uint64 time_utc_usec		# Timestamp (microseconds, UTC), this is the timestamp which comes from the gps module. It might be unavailable right after cold start, indicated by a value of 0

The sum timestamp + timestamp_time_relative is the boot time of the UTC stamp, and time_utc_usec is the stamp itself.⁸ It reads 0 when the time is unavailable, for example right after a cold start.⁸ The conversion has the same shape as the recorder’s, in microseconds rather than counts.

Same arithmetic, different clocks

• Rate and width: the RTC counts 100 ns steps in 48 bits and wraps after about 326 days.⁴ hrt_abstime counts microseconds in 64 bits and should never wrap or go backwards.⁵
• Scope: one RTC serves every channel in a recording, so bus traffic, video and PCM share a clock.⁴ hrt_absolute_time() is the flight controller’s own clock.⁵
• The anchor: a recorder writes it as a packet type of its own, with source and lock state.³⁴ A ULog carries it inside GPS samples, and the UTC field reads 0 while the time is unavailable.⁸
• Time scale: Chapter 11 lists UTC from GPS and native GPS time as separate formats.⁴ time_utc_usec is UTC by its definition.⁸

Lining up a ULog with a recording

With both conversions in hand, the two files can share one axis. The figure shows the chain, and the steps below follow it.

1. In the recording, read every time packet. Note the format and source fields, and any packet that flags an RTC sync error.
2. Convert each packet or message stamp to absolute time from the nearest time packet.
3. In the ULog, keep the sensor_gps samples where time_utc_usec is not 0. Add timestamp_time_relative to each timestamp.
4. Convert the flight log’s timestamps to UTC from the nearest such sample.
5. Confirm that both sides use the same time scale. Only then compare an event in one file with an event in the other.

What each file proves about time

Each file orders its own events on its own counter. Across the two files, you get only as far as their anchors go.