ch10_handbook:data_file_interpretation
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
ch10_handbook:data_file_interpretation [2014/04/13 17:10] – bob | ch10_handbook:data_file_interpretation [2014/07/16 15:18] (current) – Added links to TSPI and CAN Bus pages bob | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ~~ODT~~ | ||
===== DATA FILE INTERPRETATION ===== | ===== DATA FILE INTERPRETATION ===== | ||
Line 71: | Line 72: | ||
==== Overall Data Packet Organization ==== | ==== Overall Data Packet Organization ==== | ||
- | Overall data packet organization is shown in Figure 6-1. Data packets contain a standard | + | Overall data packet organization is shown below. Data packets contain a standard |
header, a data payload containing one or multiple data messages, and a standard trailer. The | header, a data payload containing one or multiple data messages, and a standard trailer. The | ||
standard header is composed of a required header, optionally followed by a secondary header. | standard header is composed of a required header, optionally followed by a secondary header. | ||
Line 100: | Line 101: | ||
| DATA CHECKSUM | **Packet Trailer** | | | DATA CHECKSUM | **Packet Trailer** | | ||
- | **Data Packet Organization** | + | < |
Data packets must contain data. They are not allowed to only contain filler. Filler can be | Data packets must contain data. They are not allowed to only contain filler. Filler can be | ||
Line 136: | Line 137: | ||
The packet header contains information about the data payload such as time, packet | The packet header contains information about the data payload such as time, packet | ||
length, data type, data version, and other information. The layout of a Chapter 10 packet header | length, data type, data version, and other information. The layout of a Chapter 10 packet header | ||
- | is shown in Figure 6-2. FIXME | + | is shown below. |
< | < | ||
struct SuI106Ch10Header | struct SuI106Ch10Header | ||
{ | { | ||
- | uint16_t uSync; | + | uint16_t |
- | uint16_t uChID; | + | uint16_t |
- | uint32_t ulPacketLen; | + | uint32_t |
- | uint32_t ulDataLen; | + | uint32_t |
- | uint8_t ubyDataVer; | + | uint8_t |
- | uint8_t ubySeqNum; | + | uint8_t |
- | uint8_t ubyPacketFlags; | + | uint8_t |
- | uint8_t ubyDataType; | + | uint8_t |
- | uint8_t aubyRelTime[6]; | + | uint8_t |
- | uint16_t uChecksum; | + | uint16_t |
}; | }; | ||
</ | </ | ||
- | **Packet header structure.** | + | |
+ | < | ||
The Channel ID field uniquely identifies the source of the data. The value of the | The Channel ID field uniquely identifies the source of the data. The value of the | ||
Line 197: | Line 199: | ||
The optional secondary header is used to provide an absolute time (i.e. clock time) stamp | The optional secondary header is used to provide an absolute time (i.e. clock time) stamp | ||
for data packets. The secondary header time format can be interpreted several ways. The | for data packets. The secondary header time format can be interpreted several ways. The | ||
- | specific interpretation is determined by the value of header Flag Bits 2 and 3. The structure | + | specific interpretation is determined by the value of header Flag Bits 2 and 3. The structure |
- | Figure 6-3 is used when secondary header time is to be interpreted as a Chapter 4 format value | + | is used when secondary header time is to be interpreted as a Chapter 4 format value |
- | (Flag Bits 3-2 = 0). The structure | + | (Flag Bits 3-2 = 0). The following |
interpreted as an IEEE 1588 format value (Flag Bits 3-2 = 1). | interpreted as an IEEE 1588 format value (Flag Bits 3-2 = 1). | ||
Line 213: | Line 215: | ||
}; | }; | ||
</ | </ | ||
- | **Optional secondary header structure with IRIG 106 Ch 4 time representation.** | + | < |
- | < | + | < |
struct SuI106Ch10SecHeader_1588Time | struct SuI106Ch10SecHeader_1588Time | ||
{ | { | ||
Line 224: | Line 226: | ||
}; | }; | ||
</ | </ | ||
- | **Optional secondary header structure with IEEE 1588 time representation.** | + | < |
==== Data Payload ==== | ==== Data Payload ==== | ||
Line 240: | Line 242: | ||
when there are no more data messages to read. | when there are no more data messages to read. | ||
- | Intra-packet headers, when they are present, typically contain one, or sometimes more | + | Intra-packet headers, when they are present, typically contain one, or sometimes more |
than one, time stamp as well as other information about the data message that follows. | than one, time stamp as well as other information about the data message that follows. | ||
- | Commonly used structures for intra-packet time data are shown in Figure 6-5, Figure 6-6, and | + | Commonly used structures for intra-packet time data are shown in the three figures below. |
- | Figure 6-7. These three time structures will be referenced in most of the data format descriptions | + | These three time structures will be referenced in most of the data format descriptions |
that follow. | that follow. | ||
Line 253: | Line 255: | ||
}; | }; | ||
</ | </ | ||
- | **Intra-packet Time Stamp, 48-bit RTC.** | + | < |
< | < | ||
Line 264: | Line 266: | ||
}; | }; | ||
</ | </ | ||
- | **Intra-packet Time Stamp, IRIG 106 Ch 4 binary** | + | < |
< | < | ||
Line 273: | Line 275: | ||
}; | }; | ||
</ | </ | ||
- | **Intra-packet Time Stamp, IEEE 1588** | + | < |
==== Data Formats ==== | ==== Data Formats ==== | ||
Line 304: | Line 306: | ||
[[Ethernet Data]] | [[Ethernet Data]] | ||
+ | |||
+ | [[TSPI Data]] | ||
+ | |||
+ | [[CAN Bus Data]] | ||
==== Time Interpretation ==== | ==== Time Interpretation ==== | ||
Line 349: | Line 355: | ||
algorithm for reading all root and node index packets is as follows: | algorithm for reading all root and node index packets is as follows: | ||
- | 1. If " | + | 1. If " |
2. Move read pointer to last packet of data file. Store file offset of this packet. | 2. Move read pointer to last packet of data file. Store file offset of this packet. | ||
+ | |||
3. If last packet data type does not equal 0x03 (Computer Generated Data, Format 3) | 3. If last packet data type does not equal 0x03 (Computer Generated Data, Format 3) | ||
- | then index does not exist. | + | then index does not exist. |
4. Get the index count from the CSDW. | 4. Get the index count from the CSDW. | ||
+ | |||
5. For each root index contained in the packet, | 5. For each root index contained in the packet, | ||
* Read the Node Index offset value | * Read the Node Index offset value | ||
Line 360: | Line 370: | ||
* Get the node index count from the CSDW | * Get the node index count from the CSDW | ||
* For each node index contained in the packet read and store the time stamp, channel ID, data type, and data packet offset values. | * For each node index contained in the packet read and store the time stamp, channel ID, data type, and data packet offset values. | ||
+ | |||
6. Read last root node index. If offset value is equal to current root node packet offset | 6. Read last root node index. If offset value is equal to current root node packet offset | ||
(stored in Step 2) then done. | (stored in Step 2) then done. | ||
+ | |||
7. Else the move read pointer to the next Root Index packet offset value | 7. Else the move read pointer to the next Root Index packet offset value | ||
+ | |||
8. Read the next Root Index packet. | 8. Read the next Root Index packet. | ||
+ | |||
9. Go to Step 4. | 9. Go to Step 4. | ||
Line 392: | Line 406: | ||
multicast addresses. | multicast addresses. | ||
- | Multicast data is filtered by the Ethernet controller hardware, only passing subscribed | + | Multicast data is filtered by the Ethernet controller hardware, only passing subscribed |
packets to the software driver for decoding. This improves performance under high network | packets to the software driver for decoding. This improves performance under high network | ||
traffic loads. Ethernet controllers only have a limited number of multicast addresses they can | traffic loads. Ethernet controllers only have a limited number of multicast addresses they can | ||
Line 411: | Line 425: | ||
Ethernet technologies support larger jumbo frames. | Ethernet technologies support larger jumbo frames. | ||
- | Chapter 10 data packets are sent in a UDP/IP packet by prepending a UDP transfer | + | Chapter 10 data packets are sent in a UDP/IP packet by prepending a UDP transfer header to the UDP data payload. Chapter 10 data packet(s) smaller than the 32k maximum size will prepend the non-segmented UDP transfer header shown below. |
- | header to the UDP data payload. Chapter 10 data packet(s) smaller than the 32k maximum size | + | |
- | will prepend the non-segmented UDP transfer header shown in Figure 6-54. A Chapter 10 data | + | |
- | packet larger than the 32k maximum size will need to be segmented before transmission, | + | |
- | will prepend the segmented UDP transfer header shown in Figure 6-55. IPv6 supports large data | + | |
- | packets, negating the need for segmented data packets. | + | |
< | < | ||
Line 426: | Line 435: | ||
}; | }; | ||
</ | </ | ||
- | **UDP Transfer Header, non-segmented data.** | + | < |
+ | |||
+ | A Chapter 10 data packet larger than the 32k maximum size will need to be segmented before transmission, | ||
+ | will prepend the segmented UDP transfer header shown below. IPv6 supports large data packets, negating the need for segmented data packets. | ||
< | < | ||
Line 440: | Line 452: | ||
}; | }; | ||
</ | </ | ||
- | **UDP Transfer Header, segmented data.** | + | < |
Computer Generated Data, Format 3 (Recording Index) packets are meaningless in a | Computer Generated Data, Format 3 (Recording Index) packets are meaningless in a | ||
Line 446: | Line 458: | ||
will have contiguous sequence numbers for error detection. They should be ignored, though, | will have contiguous sequence numbers for error detection. They should be ignored, though, | ||
when received. | when received. | ||
- |
ch10_handbook/data_file_interpretation.1397427006.txt.gz · Last modified: 2014/04/13 17:10 by bob