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 18:41] – 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 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. |
< | < | ||
Line 198: | 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 241: | 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 305: | Line 306: | ||
[[Ethernet Data]] | [[Ethernet Data]] | ||
+ | |||
+ | [[TSPI Data]] | ||
+ | |||
+ | [[CAN Bus Data]] | ||
==== Time Interpretation ==== | ==== Time Interpretation ==== | ||
Line 401: | 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 420: | 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 436: | Line 436: | ||
</ | </ | ||
< | < | ||
+ | |||
+ | 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. | ||
< | < |
ch10_handbook/data_file_interpretation.txt · Last modified: 2014/07/16 15:18 by bob