10.6 Data Format Definition

10.6.1 Common Packet Elements.

Data shall have three required parts, a Packet Header, a Packet Body, a Packet Trailer, and an optional part if enabled, a Packet Secondary Header. Single or multiple channel recordings will always conform to the structure outlined in Figure 10-4.

Figure 10-4. Data recording structure.

A packet has the basic structure shown in Figure 10-5. Note that the width of the structure is not related to any number of bits. This table is merely to represent relative packet elements and their placement within the packet. See Figure 10-6 for a diagram of the generic packet format. This figure does not depict the bit lengths of each field. Word sizes of 8-bit, 16-bit and 32-bit are used depending on the data type. To further clarify the packet layout, Figure 10-6 shows the generic packet in a 32-bit, little-endian format, and assumes 16-bit data words and data checksum.

Depending on the data type, the size of the Data Checksum can be 16-bits, 32-bits, 8-bits, or left out entirely. For a 32-bit Data Checksum, the packet trailer would be as shown in Figure 10-7.

For an 8-bit Data Checksum, the packet trailer would be as shown in Figure 10-8.

The size of a single Packet may be a maximum of 524,288 bytes as shown in Table 10-5C. This includes the Packet Header, Packet Body, Packet Trailer, and optional Packet Secondary Header if enabled. The only exception to the packet size limit is the Computer Generated Data Packet, Format 1 Setup Record which may be a maximum of 134,217,728 bytes. Any Packet which requires more than 524,288 bytes may do so by utilizing the packet sequence counter and generating multiple packets. Some packet types allow a single data set to span multiple packets if the data set size or time does not fall under packet maximums. Consult the individual data types for the mechanisms that allow packet data spanning for a given type.

With the exception of Computer Generated Packets all other packets shall be generated within 100 milliseconds whenever data is available. This requirement ensures that a packet shall contain less than or equal to 100 milliseconds worth of data, and that a packet containing any data must be generated within 100 milliseconds from the time the first data was placed in the packet. This strategy will assure packet granularity but save bandwidth by not forcing or marking empty/idle packets.

Packets can not contain only filler or can not be idle or empty. All packets that are generated shall contain data.

All reserved bit fields in packet headers or channel specific data words must be set to zero (0).

With the exception of Computer Generated Data Packets all other packets must be committed to a Stream within 10,000,000 counts of the 10 MHz Relative Time Counter contained in the packet header.

TABLE 10-5C. PACKET REQUIREMENTS
PACKET TYPE	REQUIRED	MAXIMUM PACKET SIZE	REQUIRED PACKET LOCATION
Computer Generated Data Packet, Format 1 Setup Record	Yes	134,217,728 bytes	First Packet in Recording.
Time Data Packet	Yes	524,288 bytes	First Dynamic Data Packet Following Setup Record Packet(s). Reference the Time Data Packet Description for packet rate.
PCM, Mil-Std-1553, Analog, Message, Discrete, ARINC 429, Video, Image, UART, Computer Generated Data Packet, Format 2 Recording Events, Computer Generated Data Packet, Format 3 Recording Index (Node Index)	No	524,288 bytes	After First Time Data Packet and before the first Computer Generated Data Packet Format 2, Recording Index (Root Index) if enabled.
Computer Generated Data Packet, Format 3 Recording Index (Root Index)	Yes, if Recording Events are Enabled. No, if Recording Events are Disabled.	524,288 bytes	If Recording Index Packets are enabled the Root Index Packet Type will be the last packet(s) in a recording.

10.6.1.1 Packet Header.

The length of the packet header is fixed at 24 bytes (192-bits). The Packet Header is mandatory and shall consist of the ten fields, positioned contiguously, in the following sequence:

1. Packet Sync Pattern. (2 Bytes) contain a static sync value for the every packet. The Packet Sync Pattern value shall be 0xEB25.
2. Channel ID. (2 Bytes) contain a value representing the Packet Channel ID. All channels in a system must have a unique value (data channels). Channel value 0x0000 is reserved, and is used to insert computer-generated messages into the composite data stream. Channel values 0x0001 thru 0xFFFF are available.
   
   When a distributed Multiplexer system is used, the setup record will contain a recorder attribute that identifies the number of most significant bits used from the Channel ID field that identifies the channels from each multiplexer. The least significant bits of the Channel ID will provide the unique Channel ID for each data source acquired by a given multiplexer.
3. Packet Length. (4 Bytes) contain a value representing the length of the entire packet. The value shall be in bytes and is always a multiple of four (bits 1 and 0 shall always be zero). This Packet Length includes the Packet Header, Packet Secondary Header (if enabled), Channel Specific Data, Intra-Packet Data Headers, Data, Filler and Data Checksum.
4. Data Length. (4 Bytes) contain a value representing the valid data length within the packet. This value shall be represented in bytes. Valid data length includes Channel Specific Data, Intra-Packet Data Headers, Intra-Packet Time Stamp, and Data but does not include filler and Data Checksum.
5. Header Version. (1 Byte) contains a value representing the version of the Packet Header for Chapter 10 packets. The value shall be represented by the following bit patterns:
   
   0x00 = Reserved
   0x01 = Initial Release Header Version
   0x02 = TG-78
   0x03 = thru 0xFF = Reserved
   
6. Sequence Number. (1 Byte) contains a value representing the packet sequence number for each Channel ID. This is simply a counter that increments by n + 0x01 to 0xFF for every packet transferred from a particular channel and is not required to start at 0x00 for the first occurrence of a packet for the Channel ID.

   Sequence Number counter will repeat (roll over to 0x00) if more that 256 packets are transferred in a given recording per channel.

7. Packet Flags. (1 Byte) contain bits representing information on the content and format of the packet(s).

   Bit 7:	Indicates the presence or absence of the Packet Secondary Header. 0 = Packet Secondary Header is not present. 1 = Packet Secondary Header is present.
   Bit 6:	Indicates the Intra-Packet Time Stamp Time Source. 0 = Packet Header 48-Bit Relative Time Counter. 1 = Packet Secondary Header Time (Bit 7 must = 1).
   Bit 5:	Relative Time Counter Sync Error. 0 = No Relative Time Counter sync error. 1 = Relative Time Counter sync error has occurred.
   Bit 4:	Indicates the Data Overflow Error. 0 = No data overflow. 1 = Data overflow has occurred.
   Bits 3-2:	Indicate the Packet Secondary Header Time Format. 00 = IRIG 106 Chapter 4 binary weighted 48-bit time format. The two LSB’s of the 64-bit Packet Secondary Header Time and Intra-Packet Time Stamp shall be zero filled. 01 = Reserved 10 = Reserved 11 = Reserved
   Bits 1-0:	Indicate Data Checksum existence. 00 = No data checksum present 01 = 8-bit data checksum present 10 = 16-bit data checksum present 11 = 32-bit data checksum present

8. Data Type. (1 Byte) contains a value representing the type and format of the data. All values not used to define a data type are reserved for future data type growth:

   Packet Header Value	Data Type Name	Data Type Description
   0x00	Computer Generated Data, Format 0	(User Defined)
   0x01	Computer Generated Data, Format 1	(Setup Record)
   0x02	Computer Generated Data, Format 2	(Recording Events)
   0x03	Computer Generated Data, Format 3	(Recording Index)
   0x04 - 0x07	Computer Generated Data, Format 4 - Format 7	(Reserved for future use)
   0x08	PCM Data, Format 0	(Reserved for future use)
   0x09	PCM Data, Format 1	(IRIG 106 Chapter 4)
   0x0A - 0x0F	PCM Data, Format 2 - Format 7	(Reserved for future use)
   0x10	Time Data, Format 0	(Reserved for future use)
   0x11	Time Data, Format 1	(IRIG/GPS/RTC)
   0x12 - 0x17	Time Data, Format 2 - Format 7	(Reserved for future use)
   0x18	MIL-STD-1553 Data, Format 0	(Reserved for future use)
   0x19	MIL-STD-1553 Data, Format 1	(Mil-Std-1553B Data)
   0x1a - 0x1F	MIL-STD-1553 Data, Format 2 - Format 7	(Reserved for future use)
   0x20	Analog Data, Format 0	(Reserved for future use)
   0x21	Analog Data, Format 1	(Analog Data)
   0x22 - 0x27	Analog Data, Format 2 - Format 7	(Reserved for future use)
   0x28	Discrete Data, Format 0	(Reserved for future use)
   0x29	Discrete Data, Format 1	(Discrete Data)
   0x2A - 0x2F	Discrete Data, Format 2 - Format 7	(Reserved for future use)
   0x30	Message Data, Format 0	(Generic Message Data)
   0x31 - 0x37	Message Data, Format 1 - Format 7	(Reserved for future use)
   0x38	ARINC 429 Data, Format 0	(ARINC429 Data)
   0x39- 0x3F	ARINC 429 Data, Format 1 - Format 7	(Reserved for future use)
   0x40	Video Data, Format 0	(MPEG-2 Video)
   0x41	Video Data, Format 1	(ISO 13818-1 MPEG-2 Bit Stream)
   0x42 - 0x47	Video Data, Format 2 - Format 7	(Reserved for future use)
   0x48	Image Data, Format 0	(Image Data)
   0x49 - 0x4F	Image Data, Format 1 - Format 7	(Reserved for future use)
   0x50	UART Data, Format 0	(UART Data)
   0x51 - 0x57	UART Data, Format 1 - Format 7	(Reserved for future use)
   0x58	IEEE-1394 Fire Wire Data, Format 0	(IEEE-1394 Data)
   0x59 - 0x5F	IEEE-1394 Fire Wire Data, Format 1 - Format 7	(Reserved for future use)
   0x60	Parallel Data, Format 0	(Parallel Data)
   0x61 - 0x67	Parallel Data, Format 1 - Format 7	(Reserved for future use)

9. Relative Time Counter. (6 Bytes) contain a value representing the Relative Time Counter.

   This is a free-running 10 MHz binary counter represented by 48-Bits common to all data channels. The counter shall be derived from an internal crystal oscillator and shall remain free running during each recording session. The applicable data bit to which the 48-bit value APPLIES unless defined in each data type section shall correspond to the first bit of the data in the packet body.

10. Header Checksum. (2 Bytes) contain a value representing a 16-bit arithmetic sum of all 16-bit words in the header excluding the Header Checksum Word.

10.6.1.2 Packet Secondary Header (Optional).

The length of the Packet Secondary Header is fixed at 12 bytes (96-bits). The Packet Secondary Header is optional and when enabled shall consist of the three fields, positioned contiguously, in the following sequence:

1. Time. (8 Bytes) contain the value representing Time in the format indicated by bits 2 and 3 of the Packet Flags in section 10.6.1.1g.
2. Reserved. (2 Bytes) are reserved and shall be zero filled.
3. Secondary Header Checksum. (2 Bytes) contain a value representing a 16-bit arithmetic sum of all Secondary Header bytes excluding the Secondary Header Checksum Word.

10.6.1.3 Packet Body.

The format of the data in the packet body is unique to each channel type. Detailed descriptions of the type-specific data formats found in packet bodies are described in subsequent sections of this document.

1. Channel Specific Data. (Variable Bytes) contain the number and contents of the Channel Specific Data field(s) depending on the Data Type field in the Packet Header. Channel Specific Data is mandatory for each data type and channel. The occurrence of Channel Specific Data is once per packet and precedes packet channel data.
2. Intra-Packet Time Stamp. (8 Bytes) contain Time in either 48-bit Relative Time Counter format (plus 16 high-order zero bits) or 64-bit absolute format as specified in the Packet Flags in the Packet Header. The Intra-Packet Time Stamps are only mandatory where defined by the data formats.
3. Intra-Packet Data Header. (Variable Bytes) contain additional status and format information pertaining to the data items that follow. The Intra-packet Data Headers are only mandatory where defined by the data formats.
4. Data. (n Bytes) contain valid data from a particular channel as defined within the data formats contained within this standard.

The Intra-Packet Time Stamp and the Intra-Packet Data Header are collectively called the Intra-Packet Header. In some cases an Intra-Packet Header may only have a Time Stamp (zero-length Data Header), while in other cases, the Intra-Packet Header only has a Data Header (zero-length Time Stamp). Some data types have no Intra-Packet Header. The Intra-Packet Header requirements are specified separately for each Data Type.

10.6.1.4 Packet Trailer.

The packet trailer may contain filler, a data checksum, both filler and a data checksum, or neither filler nor a data checksum. In the latter case, the packet trailer has zero length. The reason a packet trailer would have a zero length is best explained by understanding the reason for inserting filler. The purpose of the filler is twofold:

1. Keep all packets aligned on 32-bit boundaries (i.e., make all packet lengths a multiple of 4 bytes), and
2. Optionally keep all packets from a particular channel the same length.
   
   If both of the above requirements are already met without adding filler, then filler will not be added.
   
   The inclusion of the data checksum is optional as well and is indicated by the Packet Flags setting. When included, the packet trailer contains either an 8-bit, 16-bit or 32-bit Data Checksum. Depending on the Packet Flags option selected, the Data Checksum is the arithmetic sum of all of the bytes (8-bits), words (16-bits) or long words (32-bits) in the packet excluding the 24 bytes of Packet Header Words, Packet Secondary Header (if enabled) and the Data Checksum Word. Stated another way, the Data Checksum includes everything in the packet body plus all added filler.
3. Filler. (n Bytes/Bits) All filler shall be set to 0x00 or 0Xff
4. 8-Bit Data Checksum. (1 Byte) contains a value representing an 8-bit arithmetic sum of the bytes in the packet (includes Channel Specific Data, Data and Filler). Only inserted if Packet Flag bits 0 and 1 = 01.
5. 16-Bit Data Checksum. (2 Bytes) contain a value representing a 16-bit arithmetic sum of the words in the packet (includes Channel Specific Data, Data and Filler). Only inserted if Packet Flag bits 0 and 1 = 10.
6. 32-Bit Data Checksum. (4 Bytes) contain a value representing a 32-bit arithmetic sum of the long words in the packet (includes Channel Specific Data, Data and Filler). Only inserted if Packet Flag bits 0 and 1 = 11.

add a comment User Contributed Notes and Comments

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 88

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 89

05/30/2007 03:36 - Yigal Zayfman (yigal_z at elbit dot co dot il)

It seems that the way of Header Checksum calculation has been changed from 106-04:
"10.6.1.1.10 Header Checksum. This field (2 bytes) contains a value representing a 16-bit
arithmetic sum of all header bytes(!!!-YZ) excluding the Header Checksum Word."

to 106-05, 10.6.1.1:
"j. Header Checksum. (2 Bytes) contain a value representing a 16-bit arithmetic sum of all 16-bit words(!!! - YZ) in the header excluding the Header Checksum Word."

but it has no reflection in changes history description document

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 88

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 89

02/05/2007 10:34 - Bob (bob dot baggerman at gatech dot edu)

For secondary header time format = 0x00 see IRIG 106 Ch 4, section 4.7, and especially Figure 4-3. This time format is a 48 bit binary format. The most significant 32 bits (Secondary Header Time MSLW) are a binary representation of relative time with the least significant bit = 0.01 seconds. The remaining 16 bits (the most significant 16 bits of Secondary Header LSLW) represent microseconds with the least significant bit of the 16 bit word (i.e. bit 16 of the LSLW) = 1 microsecond. The least significant 16 bits of Secondary Header LSLW should be zero filled. This relative time representation has enough bits to run for over a year.

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 88

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 89

01/15/2007 12:56 - Bob (bob dot baggerman at gatech dot edu)

10.6.1.1.7 Packet Flags.

Bit 5: Relative Time Counter Sync Error
Bit 4: Indicates the Data Overflow Error.

What do these mean exactly?

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 88

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 89

01/15/2007 12:55 - Bob (bob dot baggerman at gatech dot edu)

10.6.1.1.5 Header version

Beware of different header versions. To be complete, must have all Ch 10 versions. It would be nice to have a table of what changed between versions.

This field definition changes some in the 2006 version.

Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 88

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in /web/irig106/comments/show.inc on line 89

01/15/2007 12:52 - Bob (bob dot baggerman at gatech dot edu)

Note that Ch 10 Channel ID seems to be the same as Ch 9 Track Number

add a comment