When Choosing Test Equipment, Don’t Forget the Interface

By: Paul Pickering

When purchasing RF test equipment, such as an RF switch or a programmable attenuator, it’s tempting to concentrate on specifications such as insertion loss, frequency range or VSWR.

But implementing a complex testing scheme usually involves integrating multiple pieces of equipment from multiple manufacturers.

A customer will often purchase the first piece of equipment from their preferred vendor, complete with software, and begin to develop their test flow. Later, they need another component, perhaps one that vendor doesn’t make. All too often the different pieces of equipment, while working well in isolation,  are not designed to easily fit into a production test flow that places a high priority on communication and synchronization between modules.

Proprietary vs. Generic Interfaces

A typical RF test scenario can include equipment from many different suppliers, each with their own control software, command set, interfacing mechanics and so on.

In general, there are two approaches  in driving a piece of test equipment:  deploying proprietary drivers  to each host, or using  generic command sets on standard interfaces with common protocols  such as USBs HIDand CDC device class.

One potential problem with proprietary drivers is that the manufacturer may not support your operating system, making it difficult to use the equipment in an automated test scenario. For example, a manufacturer may provide drivers for Windows, but not for Mac OS or older Windows versions such as Windows XP. A small manufacturer may not have the time or the expertise to develop drivers for multiple platforms. Or the market for a platform may not be big enough to justify the expense: they may not be major players, but platforms such as Raspberry Pi are expanding beyond the hobbyist market and dipping their toes into industrial applications.

In a laboratory environment, users may have a wide variety of tests to run and simply pull equipment off the shelf when needed. A USB device, for example, often a common resource shared between several different computers. In this case, each computer must contain a copy of each driver and be kept up to date as new releases arrive, adding to the workload of the lab manager.

Using a generic driver, the test equipment is designed to look like a standard device class; so long as a device adheres to the class specification, the standard installed driver will work. Let’s use USB as an example, since it’s becoming the standard for newer installations.

USB has several generic classes. The HID (human interface device), as its name suggests, primarily covers items such as keyboards and mice. The CDC class is intended for modems and other communication devices. Using this class, the test equipment simulates a modem (e.g., a virtual COM port serial interface).

A generic USB interface solves interoperability and driver management issues, but might violate the USB standard or consume greater CPU resources than a proprietary interface. A generic interface incurs no licensing fee, is universal in application and can be readily modified.

GUI Issues

A graphical user interface (GUI) running on Windows offers many advantages: it’s intuitive, simplifies common tasks and makes it easy to get started. But in an automated test flow, other features are more important.

Test engineers often use a scripting language to link together multiple pieces of equipment that must operate in a defined sequence. Python is a popular choice for laboratory automation because it’s simple, easy to learn, cross-platform and has support for many common interfaces such as  GPIB, RS232, USB and Ethernet. .

A GUI  may provide a scripting interface that allows direct control of the  equipment , but when combining equipment from multiple manufactures it is unlikely the scripting features of one GUI will interface with equipment from other manufactures. Having the ability to control the various equipment outside of a manufactures GUI, such as using Python, is critical when integrating equipment from multiple manufactures. .

Questions to Ask

Here are a couple of questions to ask a vendor when considering a new piece of equipment:

• Does the equipment use a generic interface? If so, how is it implemented? If not, what operating systems are supported? What is the update procedure?
• If the equipment uses a GUI, does it provide a scripting interface? Can the GUI control multiple pieces of equipment with different interfaces?
• How will the equipment work in an automated test scenario with multiple devices operating in a defined sequence?

The JFW Control Philosophy

JFW Industries works with its customers to help them solve complex interface needs and remove barriers to communication between devices. The product catalog includes a variety of interfaces such as RS232, Ethernet, USB and GPIB. These use ASCII commands and generic interface protocols, and the company can also provide custom remote commands if requested.

JFW Industries offers Windows-based GUI test programs for its devices. As shown in Figure 2, these GUI are designed to operate well in a multi-device test flow. There are also Python libraries that allow designers to incorporate  attenuators or test systems into a larger test suite. .

Conclusion

The software interface is an often overlooked, yet critical item in putting together a test system. It’s not enough for a piece of equipment to work well in isolation. In a production environment it must interact with and take commands from other modules, and in a laboratory setting it must work seamlessly with multiple hosts.

Understanding some of the potential interface barriers and how to remove them is an important first step before evaluating any piece of test equipment.