IRIG106wiki

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.

 
struct SuCompGen0_ChanSpec 
    { 
    uint32_t uReserved; 
    }; 

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.

 
struct SuTmats_ChanSpec 
    { 
    uint32_t    iCh10Ver      :  8;         // Recorder Ch 10 Version 
    uint32_t    bConfigChange :  1;         // Recorder config changed 
    uint32_t    iReserved     : 23;         // Reserved 
    }; 

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.

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.

 
struct SuEvents_ChanSpec 
    { 
    uint32_t    uEventCount  : 12;          // Total number of events 
    uint32_t    uReserved    : 19; 
    uint32_t    bIntraPckHdr :  1;          // Intra-packet header present 
    }; 

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.

 
struct SuEvents 
    { 
    uint64_t              suIntraPckTime;   // Intra-packet time stamp 
    struct SuEvents_Data  suData;           // Data about the event 
    }; 

 
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 
    }; 

 
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;       // 
    }; 

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.

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.

 
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 
    }; 

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.

 
struct SuIndex_Data 
    { 
    uint32_t    uChannelID  : 16; 
    uint32_t    uDataType   :  8; 
    uint32_t    uReserved   :  8; 
    uint64_t    uOffset; 
    }; 

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.

Reserved for future use.