What is LXI?

The LXI Consortium was formed in 2005 with the goal of using LAN-based communication to control instrumentation. LXI stands for (LAN eXtensions for Instrumentation) and the hope is that high-performance, low cost systems can be built based on standard Ethernet technology, as an alternative to the popular, but more industry-specific GPIB communication interface.

The LXI standards mostly prescribe hardware and firmware requirements for building LXI-compliant instruments. These requirements are grouped into three classes of LXI compliance -- Class A, Class B, and Class C. (Note that the use of the term "class" here has no relation to the notion of "class" in IVI instrument classes.) The features of each class are summarized in the following table:

Features of LXI Devices

As the table in the previous section shows, LXI devices possess a variety of useful features, base on their LXI functional class (A, B, or C). The most fundamental features of LXI are required for all functional classes. First and foremost, an IVI driver (either IVI-COM or IVI-C) must be provided with any instrument claiming LXI compliance. Next, the instrument must provide a configuration web page so that users can simply open a browser, navigate to the LAN address of the instrument, and interact with the device. In addition, all LXI devices must support a standard discovery mechanism so that tools and client applications can determine what devices are connected to the network.

With LXI Class B comes important new requirements. First, Class B devices must support the IEEE 1588 Precision Time Protocol standard. This standard provides a way for multiple devices to synchronize their clocks over standard Ethernet networks. Since LAN-based communication is inherently non-deterministic, some mechanism for reliably synchronizing devices in a system is required. The IEEE 1588 standard (simply referred to as "1588") provides this for LXI devices.

Class B devices also support LAN-based triggering and events. The LXI specification defines how devices format, send and receive special LAN packets used to communicate between devices. All Class B devices support a standard set of eight LAN packets. This forms a sort of virtual LAN-based trigger bus, with each of the standard eight LAN packets (known as "LAN0...LAN7") serving as individual trigger lines. LXI devices can be programmed to trigger a measurement or sweep based on receipt of a LAN packet or they can be told to send a specific LAN packet (an event) when a particular operation has completed or the device enters some other interesting operational state.

Class A devices are the most complex LXI devices. They support all of the functionality defined for Class B but add a hardware trigger bus. This trigger bus can be useful in applications that demand extremely precise timing and ultra-low latency triggering between components.

The IviLxiSync Specification

In 2006, the IVI Foundation and the LXI Consortium joined forces to define a standard API for controlling the triggering and eventing capabilities of LXI devices. The result of this cooperation was the IviLxiSync specification, formally known as IVI-3.15: IviLxiSync Specification. The IviLxiSync specification is not an instrument class specification, because it does not define functionality for a particular type of instrument. Rather, it defines operations common to any LXI-compliant device, whether that device is a DMM, oscilloscope, or spectrum analyzer.

Since the IviLxiSync specification spans devices of all instrument classes, it is common that an IVI driver will support IviLxiSync as well as one or more IVI instrument classes. Some of the operations that a client application can perform through the IviLxiSync interfaces include:

•Configuring a device to trigger on a specific LAN packet.

•Configuring a device to send an event upon receipt of a particular event from another LXI device.

•Using filtering to control from which devices an instrument "sees" incoming LAN triggers.

•Retrieving event log entries from the device.

Just as with IVI instrument classes, the standard functions and attributes defined in the IviLxiSync specification are compiled into an IVI-COM type library. This type library is shipped as part of the IVI Shared Components. Also, as with IVI instrument classes, users can program interchangeably with LXI devices by referencing the IviLxiSync type library and using only IviLxiSync-defined interfaces in their application.

IviLxiSync Subsystems

The IviLxiSync API is divided into five subsystems. Each subsystem controls different aspects of LXI device operation in a system. Depending upon a device's functional class, it may support only some of these subsystems. Class C devices, for example, need not support any of the functionality defined in the IviLxiSync specification. Also, only Class A devices will typically support arming, triggering, and events using the hardware trigger bus. The following table gives the different IviLxiSync subsystems along with their functionality:

IviLxiSync Programming Example

This section presents an example LXI test system with common programming tasks using the IviLxiSync interfaces. The example code is based upon the stimulus/response test system shown in the figure below:

In the system above, an arbitrary waveform generator (arb) is used to stimulate a device under test with waveforms at various frequencies, in order to measure the distortion characteristics of the device across its operating range. The stimulus waveform is up-converted to microwave frequencies using an upconverter module and the receiver uses a downconverter to translate the DUT output signal into a range suitable for processing by the digitizer.

The up and down converters are capable of frequency stepped sweep operations (start Frequency, stop Frequency, step Frequency) and can initiate each step based on a trigger signal. The LXI-defined LAN events will be used for this triggering. At each frequncy in the sweep, the digitizer acquires the DUT's output waveform using an internal signal level to trigger the acquisition. At each step in the frequency step sweep, the digitizer will wait for a LAN signal from the upconverter and downconverter modules indicating that their signals have settled.

The first task is to configure the digitizer to output a synchronization signal to trigger the arb. The LXI-defined LAN packet named "LAN1" will be used for this purpose. We want the digitizer to send the LAN1 event to the arb when the digitizer is in the waiting-for-trigger state (also known as "armed"). IviLxiSync defines the "WaitingForTrigger" event name as a standard string to identify precisely this device state. This is referred to as the "source" of the outgoing event, because when it occurs (e.g. when the digitizer enters the waiting-for-trigger state), the digitizer will send an outbound LAN packet ("LAN1" in our example).

We next configure the arb to accept a trigger on the rising edge of the LAN1 packet that the digitizer will be sending.

Next, we configure the digitizer to send an event on LAN2 on the falling edge of the IviLxiSync-defined "WaitingForArm". As with "WaitingForTrigger", the "WaitingForArm" event name provides a standard way to refer to common events that occur within an LXI device. We use the falling edge of the LAN2 packet to trigger the upconverter and downconverter, which must be configured to accept LAN2 as their trigger source.

The digitizer needs to begin processing when the output signals from both the upconverter and downconverter have settled to a point suitable for processing. This can be accomplished by configuring the upconverter to send a LAN3 packet when the "Settling" event occurs. Similarly, the downconverter will send a LAN4 packet when its "Settling" event occurs.

With the LAN signals "wired" appropriately, the remaining tasks involve configuring and initiating the actual measurements. This might involve configuring other aspects of the digitizer (acquisition length, etc.) and loading a signal file into the arb. The frequency sweep parameters of the upconverter and downconverter also need to be configured.

Copyright 2013-16 Boonton. All rights reserved.