Overview

This paper describes a method, refered to here as Net106, to encode and transport individual IRIG 106 Ch 10 data channels over a connectionless datagram network transport. A method involving UDP/IP is described but any network datagram protocol can be accommodated. The purpose of this method is to allow multiple seperate data channels to transmit their data to 1) a single receiver in the case of unicast, or 2) multiple receivers in the case of multicast, and have the reciever reconstruct the multiple data sources into a valid IRIG 106 Ch 10 data stream for storing or display.

Traditional instrumentation consists of a recorder box with various types of hardware interfaces integral with the recorder and recording medium. The traditional instrumentation approach has several drawbacks.

• The traditional architecture doesn't scale well in several ways.
  • The number of recorded data channels are limited to the specific capability of the recorder model.
  • The size of the system under test is limited by the distance you are able to transmit the baseband signals to be recorded.
• The traditional architecture doesn't accommodate new and different data interfaces well. Data interfaces are limited to the capabilities of the recorder box and the data interfaces that vendor provides. There is no ability to "mix and match" interfaces from multiple vendors.
• There is limited or no ability for secondary backup data recorders or data displays to get real time data.
• Data signals must travel to the recorder interface rather than being able to bring the recorder interface to the data signal.

This paper describes a distributed instrumentation architecture where each data channel is implemented as a node on a suitable network (like Ethernet) and uses connectionless datagrams (like UDP) to transport data. Typically data interfaces are implemented using a small dedicated network aware processor such as those offered by Rabbit Semiconductor and Netburner. In a lab environment data interfaces can be inexpensive personal computers with the appropriate hardware interface. These data channel network nodes transmit data to one or more receivers which can then record, decode and display, and/or resend the data.

Benefits of this architecture include:

• It is easy to "mix and match" various data interfaces, even from different vendors, to meet instrumentation requirements simply by plugging them into the network hub.
• The type and number of data interface channels is only limited by the number of network ports and available bandwidth.
• Small dedicated data channel interfaces can be placed near the data source and sampled data is then transmitted over the network to the receiver.
• Multiple data recorders and/or data displays can receive all data channels.
• Data can be transported over existing TCP/IP networks

Key goals of this propose architecture are:

• Permit scalability only limited by network throughput and topology constraints
• Provide a design that easily accomodates new data types and hardware interface types
• Takes advantage of existing protocols and hardware
• Non-proprietary

Proposed Method

In this proposed method, the basic unit of information is a standard IRIG 106 Ch 10 data packet consisting of a Ch 10 header and data payload sections. All network datagram packets begin with an identifying header. Ch 10 data structures within the datagram are guaranteed to "line up" with the beginning of a packet boundary. In other words, the Net106 method described is not a streaming method with no notion of internal Ch 10 data structure. Instead the integrity of Ch 10 data structures is preserved within a single data packet. This allows easy decoding and display in real time.

For Ch 10 data packets that are small enough to fit into a single datagram (usually 32k for UDP, but sometimes as small as 8k) the entire Ch 10 packet can be transmitted in the datagram as-is with no additional header or other data overhead. See Figure 1 below for the datagram packet layout. A Net106 datagram that is the beginning of a Ch 10 packet is recognised by the standard Ch 10 packet sync pattern value of 0xEB25, refered to here as HEADER SYNC PATTERN. As a minimum, this first Net106 packet should contain a complete Ch 10 header and optional secondary header, as well as the channel specific data portion for data type. If the data portion of the packet is small enough it can follow the channel specific data field in the datagram packet.

In many cases, though, a complete Ch 10 data packets is too big to fit into one datagram packet. In this case a method to fragment large Ch 10 packets across multiple datagrams is proposed. This is accomplished by splitting the data portion of the Ch 10 packet into smaller units. The first datagram contains a standard Ch 10 header and channel specific data. Subsequent datagrams are prefixed with a uniquely identifying header. See Figure 2 below for datagram packet layout. A Net106 datagram that is a subsequent data packet is recognised by a packet sync pattern value of 0xEB26, refered to here as the DATA SYNC PATTERN.

In general a Ch 10 data packet body consists of multiple data messages. The Ch 10 data packet body must be split at the boundary between data messages. In other words, a subsequent Net106 data message would always have a Net106 header followed by the standard Ch 10 Intra-Packet Header, followed by the complete data message. This allows data decode and display applications to process a received Net106 datagram without having to "string together" two datagrams to get a complete data message.

Net106 data datagram messages contain the same Channel ID and Sequence number values as in the associated header. Data messages also have a Sub-sequence number starting at zero and incremented by one to permit in-order reassembly and dropped packet detection.

Net106 Header Datagrams

All Net106 Header datagram fields are identical to the corresponding IRIG 106 Ch 10 data fields.

Net106 Data Datagrams

Net106 Data Datagrams have the following header fields:

• DATA SYNC PATTERN - Value of 0xEB27
• CHANNEL ID - Same as corresponding Net106 Header Datagram value
• DATA TYPE - Same as corresponding Net106 Header Datagram value
• SEQUENCE NUMBER - Same as corresponding Net106 Header Datagram value
• SUB-SEQUENCE NUMBER - Value starting a 0 and incrementing for each datagram in the series.

Unaddressed issues

• Distribution of time
• Remote configuration of data channel interfaces
• Error detection and retransmission
• Are there any cases where Channel Specific Data is needed in subsequent data only packets?
• Splitting large, single data packets (maybe Program Stream video?) needs to be addressed

add a comment User Contributed Notes and Comments

Deprecated: Function strftime() is deprecated in /web/irig106/comments/show.inc on line 89

11/23/2015 09:24 - Charan (charanjg at mail dot com)

I need information regarding secondary header. they say it is optional. how can we enable or disable secondary header?. when is it usefull?? please do reply.

add a comment