IRIG 106 Chapter 7 - Packet Telemetry Downlink

Introduction:

In recent years there has been a growing demand for flight test instrumentation to acquire and telemeter an increasing quantity and speed of data. This includes high-definition video (often from more than one camera) and high-speed data bus messages alongside traditional analogue measurements such as strain and temperature.

IRIG 106 Chapter 7 defines the standard by which these demands can be met, in particular how the data may be packetized for the telemetry downlink within a Chapter 4 pulse code modulation (PCM) stream.

Chapter 7 is, at the time of writing, a relatively new concept. First defined in 2015, there have been further editions and enhancements in 2017 and 2019. It may take a while for equipment and software manufacturers to implement these revisions in their products, so it worth checking with the supplier with which version(s) their equipment complies.

 

Packet Telemetry (PT):

Let’s start at the shallow end of the pool and define what is meant in IRIG 106 Chapter 7 by a packet.

To make a physical analogy, imagine you have a series of photographs that tell a story. We’ll call this the user data or payload. We want to send this payload to a friend, one photo at a time. So we wrap up each payload and label it with both sender address and destination address. This is referred to as control information, and may also consist of packet length, error detection codes and sequencing information (we want to be sure that the friend looks at the photos in the correct order).

In computer networking the senders address and destination address will be a network address, and the control information on the wrapper will be stored in the header and trailer.

Packets come in many formats, IRIG 106 Chapter 7 defines how to incorporate Chapter 10 packets, integrated Network Enhanced Telemetry (iNET) Telemetry Network System (TmNS) packets, and Ethernet data packets into the pulse code modulation (PCM) stream in accordance with IRIG 106 Chapter 4.

These formats can convey both traditional FTI measurements in addition to modern HD video. Critically the standard defines how these packets of variable length may be contained within the fixed frame lengths of PCM.

 

PCM Format, Minor Frame – IRIG 106 Ch. 7 2015:

The original IRIG 106 Chapter 7 standard of 2015 describes a PCM frame format simpler than that of the latter revisions, so we shall start there and with a diagram visualizing the minor frames of a PCM grid.

Packet Telemetry, PCM Minor Frame
Frm Sync. (bits 31 … 24) Hex FE Bin 1111 1110	Frm Sync. (bits 23 … 16) Hex 6B Bin 0110 1011	Frm Sync. (bits 15 … 8) Hex 28 Bin 0010 1000	Frm Sync. (bits 7 … 0) Hex 40 Bin 0100 0000	Pkt Data Byte 1	Pkt Data Byte ...	Pkt Data Byte ...	Pkt Data Byte N x 223

Fig. 1 – Visualization of Packet Telemetry Minor Frame.

 

Each minor frame begins with a minor Frame Synchronisation pattern of 32 bits.

The IRIG 106 Chapter 7 standard fixes this synchronisation pattern to hexadecimal FE 6B 28 40 (binary 1111 1110 0110 1011 0010 1000 0100 000) when no error correction is used. See Chapter 4, Table of Frame Sync Patterns.

If the optional Reed-Solomon error correction is applied to the PCM stream then hex 1A CF FC 1D (binary 0001 1010 1100 1111 1111 1100 0001 1101) is used instead.

The packet data follows the frame synchronisation pattern in chunks or words of 8 bits (1 byte). The number of data words available for use within a frame is limited to N x 223 bytes, where N is between 1 and 8.

Whatever the chosen limit, each frame must be of a consistent length. The length of a Packet may be longer or shorter than the frame length. Gaps between telemetered packets are not permitted. The IRIG 106 Chapter 7 standard refers to this Asynchronous Packet Multiplexing.

Asynchronous Packet Multiplexing – IRIG 106 Ch. 7 2015:

As previously suggested, some data packets exceed the length of a minor frame and must be spread over several minor frames. Some data packet will fall short of the length of a minor frame.

It’s time to expand upon Fig. 1 and add a Minor Frame Header (MFH). Minor Frame Headers are of fixed length and placed at the beginning of the Minor Frame immediately after the Frame Synchronisation Pattern.

Standard Packet Encapsulation
0	0	0;	0	0	0	0	0
Frame Sync.	MFH Offset 0	Packet N Data
Frame Sync.	MFH Offset 100	Packet N Data continued		Packet N+1 Data (starting at byte 100)
Frame Sync.	MFH Offset 50	Packet N+1 Data continued	Packet N2 Data (starting at byte 50)			Packet N+3 Data
Frame Sync.	MFH Offset 0	Packet N+3 Data continued
Frame Sync.	MFH Offset 50	Packet N+3 Data continued	Packet N+4 Data (starting at byte 50)

Fig. 2 – Visualization of Standard Packet Encapsulation.

 

The Minor Frame header contains an offset pointing to the location of the first byte of the first packet within that minor frame. There is no need for the header to indicate the start of any subsequent packets within the frame because this can be calculated from the length of the packet, stored within the packets header.

The picture is not yet complete however.

Due to the variable nature of a packet’s length, a queue may form before the packet can be encoded into the PCM stream. It is desirable for packets containing important data to be transmitted through the system faster than less important data. A low-latency packet (LLP) mechanism is provided to “rush” such data through, allowing it queue jump in such a way that the transmission of a standard packet may be split at the start of a minor frame.

There are some restrictions. Whilst one or more low-latency packets (LLPs) are allowed to be placed in a minor frame (always immediately following the Minor Frame Header), an LLP may not span multiple minor frames, i.e. the length of the LLP must be shorter or equal to the remaining space in the minor frame. An LLP is immediately followed by an end byte that alerts the decoder if an LLP is following or if it is the last LLP in the frame.

Let’s expand our diagram again to take the LLPs into account.

Standard Packet Encapsulation
0	0	0;	0	0	0	0	0	0	0
Frm Sync.	MFH Offset 0	Packet N Data
Frm Sync.	MFH Offset 100	LLP M		LLP End Byte	Packet N Data continued (at byte 100)			Packet N+1 Data
Frm Sync.	MFH Offset 150	Packet N+1 Data continued				Packet N2 Data (starting at byte 150)
Frm Sync.	MFH Offset 200	LLP M+1	LLP End Byte	LLP M+2			LLP End Byte	Packet N+3 Data (starting at byte 200)
Frm Sync.	MFH Offset 50	Packet N+3 Data continued
Frm Sync.	MFH Offset 50	Packet N+3 Data continued	Packet N+4 Data (starting at byte 50)

Fig. 3 - Visualization of Packet Encapsulation with the addition of Low-Latency Packets.

 

Golay Code Protection:

The structure described above is very complex. A single-bit transmission error occurring in any of the identification or structural length fields may lead to the loss of a packet or series of packets. Some protection against this is needed, and thankfully a Swiss mathematician called Marcel Jules Edouard Golay pre-emptively introduced a solution back in 1949.

Golays’ extended binary Golay code, hereafter referred to as "Golay code" encodes 12 bits of data in a 24-bit word in such a way that any 3-bit errors can be corrected or any 7-bit errors can be detected.

This code is applied to those structural values mentioned above, and includes part of the Minor Frame Header.

 

The Minor Frame Header – IRIG 106 Ch. 7 2015:

The Minor Frame Header is split into two halves. The first consists of eight unprotected bits, and is constant for each PCM stream.

Minor Frame Header, Unprotected first 8 bits
Bit	Designation	Description
0	Version	Code which version of Chapter 7 is being used. Bit 0 Bit 1 Version 0 0 Version 1 Packet 0 1 Reserved 1 0 Reserved 1 1 Reserved
1
2	Reserved	These should be set to 0.
3
4	Stream ID	The Stream ID is application specific and can identify up to 16 different streams.
5
6
7

 

The second half of the header immediately follows the first half, and consists of 12 bits coded as 24 bit Golay code, and are thus protected.

Minor Frame Header, Protected second 12 bits
Bit	Designation	Description
0	Offset to the first Packet Header.	These bits provide an offset in bytes, to the first byte of the first start packet in the minor frame, providing a new data packet does appear in the minor frame. If there is no new packet in the minor frame, then all the bits shall be set to 1.
1
2
3
4
5
6
7
8
9
10
11	LLP Exists	Indicates the existence of one or more Low-Latency Packets in the minor frame. Bit 11 Meaning 0 No LLP and no LLP end bytes. 1 LLP and LLP end bytes exist.

 

Packet Format – IRIG 106 Ch. 7 2015:

Look inside a packet and you’ll find packet header and the packet data itself.

The packet header consists of 2 x 12 bit parts which are then coded and transmitted as 2 x 24 Golay protected bits. Bit 23 (Golay bit 47) is transmitted first, with bit 0 last, but lets take a look inside the header before the Golay magic, and we’ll do it 0 bit first.

Packet Header
Bit	Designation	Description
0	Packet Length	No mystery here, but for clarity, this is the length in bytes of the data packet excluding the header. The 16 bits provide for a maximum packet length of 0x FFFF bytes. If a longer packet length is required, a packet fragmentation method is supported. We’ll say more on this below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16	Fragment	If a packet is longer that 0x FFFF bytes, it will need to be split and sent in fragments. The first, middle and last fragments are transmitted in the original sequence. They are not mixed with other fragmented packets. Only those important Low-Latency Packets (LLPs) mentioned earlier can be inserted between fragments. Thus packets smaller than 0x FFFF bytes can also be fragmented. Only the first fragmented packet will contain a header. The two Fragment bits are interpreted thus. Bit 16 Bit 17 Format 0 0 Complete Packet 0 1 First Fragment of a Packet 1 0 Middle Fragment of a Packet 1 1 Last Fragment of a Packet
17
18	Content	These bits identify the content or format of the data packet, the four bits indicating the seven options below. Bit 18 Bit 19 Bit 20 Bit 21 Format 0 0 0 0 Fill Packet 0 0 0 1 Application Specific Packet 0 0 1 0 Test Counter Packet 0 0 1 1 Chapter 10 Packet 0 1 0 0 Raw Ethernet Media Access Control (MAC) Frame Packet 0 1 0 1 Ethernet Internet Protocol (IP) Packet 0 1 1 0 iNET TmNS Packet 0 1 1 0 Reserved ... ... ... ... 1 1 1 1 We’ll expand further on these format types below.
19
20
21
22	Reserved	These bits should be set to 00.
23

 

Fill Packets – IRIG 106 Ch. 7 2015:

If no data is available to be transferred, a fill packet is created to maintain the fixed size of the minor frame. Fill packets consist of the bytes 0x AA.

 

Application-Specific Packets – IRIG 106 Ch. 7 2015:

To allow for new or proprietary data packets, set the Contents bytes to 0001. “Application-Specific” packets should not be used to carry Chapter 10, iNET, TmNS message data, nor Ethernet Data.

 

Test Counter Packets - IRIG 106 Ch. 7 2015:

The test counter is defined as a free-running 12-bit counter protected by Golay encoding to create a 24-bit value. IRIG 106 Ch. 7 2015 does not specify the counters usage or transmission rate.

 

IRIG 106 Chapter 10 Packets:

This is the subject of a separate article found here.