Many communications systems digitize incoming analog signal information with a high-speed A/D converter and then route the digitized information between system elements for processing and analysis. Typically, the digitized information is intermediate frequency (IF) data sent from a radio frequency (RF) downconverter to digital signal processing equipment or sent from digital signal processing equipment to an RF upconverter.
Until now, the interface for transmitting the digitized IF data stream between system elements over the communications link has been application- and/or equipment-specific. Often, it has also been proprietary: the system’s digitizing source packages the IF data into a unique, proprietary format, which the signal processing destination must know how to unpack (Figure 1).
As a result, every time a source or destination component changes, the interface for passing digitized data between them also changes, and new software must be written to achieve or restore interoperability.
Standardizing the Digital IF Interface
Standardizing the digital IF interface across receiver/transmitter equipment, signal digitization and conversion equipment and signal processing equipment would clearly benefit both OEMs and vendors. System manufacturers would no longer have to rework their systems each time they upgraded a component.
In addition, instead of being locked in to a particular vendor, OEMs could pick and choose the best component for the application at hand from a marketplace of interoperable products and essentially “plug and play” those components. Vendors would no longer be required to rewrite their digital IF interconnect logic to yet another data format, saving resources and increasing time-to-market. Standardizing digital IF could make system deployment faster and technology refresh easier for both system manufacturers and their vendors.
In 2004, Mercury Computer Systems and DRS Signal Solutions (DRS-SS) formed an informal industry group that solicited participation and input from the signal acquisition and processing community and its OEM customers for the development of such a standard. The informal industry group voted to associate with the VITA Standards Organization (VSO), and the VITA 49 Working Group was created to design a digital IF interface standard for adoption by VITA.
The Digital IF Data Representation
The Digital IF Data Representation (VITA 49) defines a data structure for the transmission of digital IF data between one or more sources and one or more destinations for both the receive and transmit paths. The Digital IF Data Representation is link-agnostic: it defines a methodology for representing digital IF data that can be layered on top of any transport protocol and any physical communication link (Figure 2).
The goal of the Digital IF Data Representation is to define a data structure that can be used by a sensor source to transmit digitized data to a signal processing destination, or by a signal processing source to transmit digital data to an emitter destination. Initially, it is focused on radio IF to convey digitized analog radio signals between RF communication receivers/transmitters and digital processing devices (Figure 3).
Although the Digital IF Data Representation is intended for use in both military and commercial applications, it is particularly targeted toward beam-forming and direction-finding signal-processing systems, as well as communications and signal intelligence (SIGINT) systems. Any communications system that needs to change an analog signal to digital information and then send it on for processing—such as police and fire department communications systems—is a candidate for the Digital IF Data Representation. Designers of electronic intelligence (ELINT) systems and software defined radio (SDR) systems may also find this standard useful.
Digital IF Data Representation Packet Types
The Digital IF Data Representation uses a packet-oriented approach to specifying a data representation standard. The working group has discussed the need for three packet types. A streaming data packet defines the base structure for representing digital IF data, a source characteristics packet enables components in a distributed system to communicate their capabilities to each other, and a status change packet conveys changes in the system’s state.
The Digital IF Data Representation basic standard (VITA 49.0) defines the streaming data packet. Extensions to this standard (VITA 49.x) will define the other two types.
Streaming Data Packet Format
The streaming data packet is designed to minimize transmission overhead and maximize its applicability to a broad range of applications. It consists of a header, a few optional header words, a variable-size data payload and a trailer (Figure 4).
Because the Digital IF Data Representation has been designed with multi-channel beam-forming and direction-finding applications in mind, the streaming data packet provides features that address the requirements of these applications. These include timestamp support, meta-data support and system event support.
Timestamp support is critical for synchronizing multiple channels of information in beam-forming and SIGINT applications.
Meta-data support enables a multi-channel source to add meta-data with a channel number to a data sample and then interleave the samples in one data payload. The meta-data associated with the data sample, which contains the channel number, allows the destination to determine to which channel a sample belongs when the destination unpacks the data.
System event support enables a source to communicate information about system events, such as an A/D converter overload or a radar antenna crossing north, to a destination. Events that affect the entire payload can be indicated, as can events that affect only a portion of the payload.
The packet definition also specifies a configuration key for linking a streaming data packet to other Digital IF Data Representation packet types that will be defined in the future.
A streaming data packet can contain up to one million words of data payload. It allows an equipment manufacturer to encode digitized IF data samples of real (unsigned or signed) or complex format in a comprehensive range of widths, packed or unpacked, and tag the data samples (or not) for interleaving or other purposes. The manufacturer must specify how the data is formatted within the data payload, including data sample width, type, data packing method and whether or not the data samples have meta-data.
The data payload can also be zero to enable the transmission of a header immediately followed by a trailer to communicate an event. The trailer specifies the type of event and the header can contain a timestamp that indicates when the event occurred.
Implementing the Standard
To implement the Digital IF Data Representation, the source equipment manufacturer creates the logic that encodes the digitized data into streaming data packet format, while the destination equipment manufacturer creates the logic that reads and parses the incoming packet and hands off the data to the next processing stage for data payload decoding.
Both source and destination equipment manufacturers generally embed the digital IF interface logic in FPGAs. The source equipment manufacturer must also publish its compliance with the Digital IF Data Representation’s data payload encoding parameters, typically in the product’s data sheet. In addition, if the source equipment manufacturer uses meta-data and events, it must publish its meta-data and event definitions.
Source and destination components using the Digital IF Data Representation are immediately interoperable for digital IF transmission over communications links. Vendors never have to rewrite those products’ packing or unpacking logic. For example, while the logic in a destination component that decodes the data payload will change depending on the application, the logic that unpacks it will not.
Demonstrating the Standard
In January 2005, Mercury and DRS-SS began preparing a demonstration of the prototype VITA 49.0 Digital IF Data Representation, using a version of the streaming data packet format under design in the demo source equipment (DRS-SS) and destination equipment (Mercury). The companies then separately developed their respective source and destination digital IF logic based on these demonstration versions.
In the demonstration configuration (Figure 5), two RF signal generators generate an RF signal that continuously sweeps over a frequency band to two tuners. Each of these tuners converts the incoming RF to IF, digitizes it at 80 Msamples/s and encodes the digitized IF data and timestamp into the prototype Digital IF Data Representation streaming data packet format. The tuners then transmit the streaming data packet output over 2.5 Gbit/s Serial Front Panel Data Port (SFPDP) fiber to the destination equipment chassis, which reads and parses the incoming streaming data packets.
Meanwhile, a display computer connected to the source and destination equipment chassis via an Ethernet hub requests a snapshot of the outgoing data from the source equipment chassis approximately once per second.
A bit in the streaming data packet had been previously identified to mark a packet as a snapshot for display. When the tuners receive a request from the display computer, they set this bit in the next packet they process to mark it as a snapshot for the destination equipment. The tuners then send this packet to the display computer over the Ethernet connection and output it over the fiber.
On the other end, the destination equipment chassis examines the snapshot bit in the incoming packets and sends the snapshot packets it receives over the Ethernet connection to the display computer.
The display computer shows the snapshot data from the source equipment chassis and the destination equipment chassis in side-by-side windows. The source window shows what was transmitted over the fiber, while the destination window shows what the destination equipment received.
The demonstration showed that the sent and received data was exactly the same: time-tagged digital IF data was moving across the fiber link from source to destination without becoming corrupted. The demonstration also illustrated the fact that Digital IF enables two chassis to interoperate despite potentially different software run-times and/or environments.
The Standard Today
The VITA 49 working group has nearly completed the Digital IF basic standard (VITA 49.0), which contains the streaming data packet definition. The group was expected to submit the base standard for balloting in the fourth quarter of 2005. Extensions to the standard, for example, the source characteristics and source status change packet definitions, are in the planning stages and will likely be released as future VITA 49.x versions.
The Digital IF Data Representation serves as a strategic technology that will enable OEMs to select processor-based DSP boards and digital receivers without being required to commit to a vendor-specific interface strategy.
Mercury Computer Systems