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