IRIG106wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
~~ODT~~
===== COMPUTER GENERATED DATA =====

==== Type 0x00, Computer Generated Data, Format 0 ====

Computer Generated Data, Format 0 
packets are used to store data generated internally by a recorder. The data packet begins with the 
CSDW shown in Figure 6-8. The data portion of the data packet is undefined and left to the 
discretion of the recorder manufacturer. 

<code> 
struct SuCompGen0_ChanSpec 
    { 
    uint32_t uReserved; 
    }; 
</code> 
 
<html><center><b>
Type 0x00 Computer Generated Data Format 0 (User) CSDW
</b></center></html>

==== Type 0x01, Computer Generated Data, Format 1 (Setup Record) ====
Computer Generated Data, Format 1 packets are used to store the TMATS recorder configuration record. The data 
packet begins with the CSDW shown in Figure 6-9. 
 
<code> 
struct SuTmats_ChanSpec 
    { 
    uint32_t    iCh10Ver      :  8;         // Recorder Ch 10 Version 
    uint32_t    bConfigChange :  1;         // Recorder config changed 
    uint32_t    iReserved     : 23;         // Reserved 
    }; 
</code> 
 
<html><center><b>
Type 0x01 Computer Generated Data Format 1 (Setup) CSDW
</b></center></html>

Note that this structure definition for the CSDW first appeared in IRIG 106-07. Since 
unused fields are required to be zero filled, data files prior to IRIG 106-07 will have a value of 
zero in the iCh10Ver field. 
 
The first data packet in a Chapter 10 data file must be a TMATS setup record. Under 
certain conditions, TMATS setup records may also be found later in the same recorded data file. 
In particular, subsequent TMATS records may occur during network data streaming of 
Chapter 10 data to allow network data users to learn the recorder configuration after recording 
and streaming has begun. The bConfigChanged flag is used to indicate whether this TMATS 
setup record is different than the previous TMATS setup record (i.e. the recorder configuration 
changed) or whether it duplicates the previous TMATS setup record. 
 
During analysis of previously recorded data, it is useful to be able to quickly locate 
TMATS setup records, especially setup records that are different from previous setup records in
the data file. The preferred method to locate these setup records is by indexing Computer 
Generated Data Format 1 packets using the indexing method described in paragraph 6.7. 
 
 The data that follows the CSDW in the data packet is the TMATS setup information in 
Chapter 9 format. 
 
=== Type 0x02, Computer Generated Data, Format 2 (Recording Events) ===

Computer Generated Data, Format 2 packets are used to record the occurrence of events during a recording 
session. Event criteria are defined in the TMATS setup record. Note that a recorded event is 
different and distinct from a Chapter 6 .EVENT command. A .EVENT command may result in a 
Recording Event packet if it has been defined in the TMATS setup record. 
 
The layout of the CSDW is shown in Figure 6-10. The uEventCount field is a count 
of the total number of events in this packet. The bIntraPckHdr field indicates the presence 
of the optional intra-packet data header in the intra-packet header. 
 
<code> 
struct SuEvents_ChanSpec 
    { 
    uint32_t    uEventCount  : 12;          // Total number of events 
    uint32_t    uReserved    : 19; 
    uint32_t    bIntraPckHdr :  1;          // Intra-packet header present 
    }; 
</code> 
 
<html><center><b>
Type 0x02 Computer Generated Data Format 2 (Events) CSDW
</b></center></html>

There are a number of permutations of the recorded event. In fact, there are enough 
permutations that it makes sense to represent the data message layout in non-specific terms. 
Later, during packet processing, generic data fields can be cast to their specific formats. Event 
data without optional data (bIntraPckHdr = 0) is shown in Figure 6-11. Event data with 
optional data (bIntraPckHdr = 1) is shown in Figure 6-12. The format for the event 
message itself is shown in Figure 6-13. 
 
<code> 
struct SuEvents 
    { 
    uint64_t              suIntraPckTime;   // Intra-packet time stamp 
    struct SuEvents_Data  suData;           // Data about the event 
    }; 
</code> 
 
<html><center><b>
Type 0x02 Computer Generated Data Format 2 (Events) message without optional data
</b></center></html>

<code> 
struct SuEvents_with_Optional 
    { 
    uint64_t              suIntraPckTime;   // Intra-packet time stamp 
    uint64_t              suIntrPckData;    // Intra-packet data 
    struct SuEvents_Data  suData;           // Data about the event 
    }; 
</code> 

<html><center><b>
Type 0x02 Computer Generated Data Format 2 (Events) message with optional data
</b></center></html>

<code> 
struct SuEvents_Data 
    { 
    uint32_t    uNumber         : 12;       // Event identification number 
    uint32_t    uCount          : 16;       // Event count index 
    uint32_t    bEventOccurence :  1;       // 
    uint32_t    uReserved       :  3;       // 
    }; 
</code> 
 
<html><center><b>
Type 0x02 Computer Generated Data Format 2 (Events) message data
</b></center></html>

The suIntraPckTime field in the data structures of Figure 6-11 and Figure 6-12 
(shown above) represents event time in either 48-bit relative time format derived from the RTC 
(format shown in Figure 6-5), or as absolute time. If this time is absolute time, it is in either 
Chapter 4 weighted 48-bit time (format shown in Figure 6-6) or IEEE 1588 time format (format 
shown in Figure 6-7). 
 
 If the event message includes the optional suIntrPckData Intra-packet Data Header 
field, shown in the data structure of Figure 6-12, this field holds the absolute time of the event. 
The format of this data is the same as the Time Data Packet Format 1, depicted in Figure 6-18 
and Figure 6-19. Unfortunately, Time Data Packet Format 1 represents time in more than one 
format and this data format does not include a method to determine which time format is used in 
the Intra-packet Data Header. For this reason, this field should be used with caution, if used at 
all. Data about the recorded event is found in the SuEvents_Data structure shown in 
Figure 6-13. The particular event is identified by the uNumber field, which corresponds to 
Recording Event index number (i.e. the "n" value in "R-x\EV\ID-n") in the TMATS Setup 
Record for this recording. The uCount field is incremented each time this event occurs. The 
bEventOccurence field indicates whether the event occurred during or between record 
enable commands.

==== Type 0x03, Computer Generated Data, Format 3 (Recording Index) ====

Computer Generated Data, Format 3 packets record file offset values that point to various important data 
packets in the recording data file. Chapter 10 data files can be very large, and it's generally 
impractical to search for specific data without an index of some sort. Currently recording index 
packets are used to index the position of time packets and event packets to make it easy to move 
to a specific time or event in the data file. However, nothing precludes the use of index packets 
to index other data packet types.

Index entries are organized into a two tier tree structure of Root Index packets and Node 
Index packets. A Node Index Entry contains information (e.g. packet type, channel, offset) 
about the specific data packet to which it points. Multiple Index Entries are contained in a Node 
Index type of index packet. A Root Index type of index packet is used to point to Node Index 
packets in the data file. Root Index packets are organized as a linked list of packets. Each Root 
Index packet contains a value for the file offset of the preceding Root Index packet in the linked 
list. Index packets (Root and Node) can be stored anywhere in a data file with the exception that 
the final Root Index packet must be the last data packet in a data file. The presence of indexing 
is also indicated by the TMATS field "R-x\IDX\E" having a value of "T" (i.e. "true"). Note 
that it is currently not unusual to find a TMATS IDX value of false, but find a valid Root Node 
packet at the end of the data file. 
 
 The layout of the CSDW is shown in Figure 6-14, and is a common format between Root 
and Node index packets. The uIdxEntCount field is a count of the total number of indexes in 
this packet. The bIntraPckHdr field indicates the presence of the optional intra-packet data 
header. The bFileSize field indicates the presence of the optional file size field. The 
uIndexType field indicates the whether the indexes that follow are Root or Node indexes. If 
file size is present, it follows the CSDW as an unsigned 64-bit value. 


<code> 
struct SuIndex_ChanSpec 
    { 
    uint32_t    uIdxEntCount : 16;      // Total number of indexes 
    uint32_t    uReserved    : 13; 
    uint32_t    bIntraPckHdr : 1;       // Intra-packet header present 
    uint32_t    bFileSize    : 1;       // File size present 
    uint32_t    uIndexType   : 1;       // Index type 
    }; 
</code> 
 
<html><center><b>
Type 0x03 Computer Generated Data Format 3 (Index) CSDW
</b></center></html>


Node Index packets are composed of a CSDW, an optional file size field, and multiple 
Node Index structures.

Each Node Index structure is composed of an intra-packet time stamp, an optional intra-packet
data header, and a Node Index Entry data structure. The intra-packet time stamp 
represents indexed packet data time in either 48-bit relative time format derived from the RTC 
(format shown in Figure 6-5) , or as absolute time. If this time is absolute time, it is in either 
Chapter 4 weighted 48-bit time (format shown in Figure 6-6) or IEEE 1588 time format (format 
shown in Figure 6-7). 
 
 If the index message includes the optional Intra-packet Data Header field, this field holds 
the absolute time of the Index. The format of this data is the same as the Time Data Packet 
Format 1, depicted in Figure 6-18 and Figure 6-19. Unfortunately, Time Data Packet Format 1 
represents time in more than one format and this data format does not include a method to 
determine which time format is used in the Intra-packet Data Header. For this reason, this field 
should be used with caution, if used at all. 


The structure of the Node Index Entry is shown in Figure 6-15. The uChannelID field 
is the Channel ID of the indexed data packet. The uDataType field is the data type of the 
indexed data packet. The uOffset field is an unsigned eight byte value representing the offset 
from the beginning of the data file to the indexed data packet. The uOffset field should 
always point to the Sync Pattern (0xEB25) of the indexed data packet. 
 
<code> 
struct SuIndex_Data 
    { 
    uint32_t    uChannelID  : 16; 
    uint32_t    uDataType   :  8; 
    uint32_t    uReserved   :  8; 
    uint64_t    uOffset; 
    }; 
</code> 
 
<html><center><b>
Type 0x03 Computer Generated Data Format 3 (Index) Node Index Entry
</b></center></html>


Root Index packets are composed of a CSDW, an optional file size field, and multiple 
Root Index Entry structures. Root Index structures provide information about and point to Node 
Index packets described above. 
 
Each Root Index is composed of an intra-packet time stamp, an optional intra-packet data 
header, and a Node Index data packet offset value. The intra-packet time stamp represents 
indexed packet data time in either 48-bit relative time format derived from the RTC (format 
shown in Figure 6-5), or as absolute time. If this time is absolute time, it is in either Chapter 4 
weighted 48-bit time (format shown in Figure 6-6 or IEEE 1588 time format (format shown in 
Figure 6-7). 
 
 If the Root Index message includes the optional Intra-packet Data Header field, this field 
holds the absolute time of the Node Index packet. The format of this data is the same as the 
Time Data Packet Format 1, depicted in Figure 6-18 and Figure 6-19. Unfortunately, Time Data 
Packet Format 1 represents time in more than one format and this data format does not include a 
method to determine which time format is used in the Intra-packet Data Header. For this reason, 
this field should be used with caution, if used at all. 
 
 The Node Index offset field of the Root Index packet is an eight byte unsigned value 
representing the offset from the beginning of the data file to the Node Index packet. 
 
==== Type 0x04 - 0x07, Computer Generated Data, Format 4 - Format 7. ====

Reserved for future use.