When purchasing an item of 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 A doesn’t make. All too often, the different pieces of equipment, while working well in isolation, aren’t designed to fit easily into a production test flow that places a high priority on communication and synchronization between modules.
This article will review common software interfaces for test equipment, potential interface barriers and how to remove them, issues to watch for and questions to ask before buying. It will conclude by discussing JFW Industries’ approach to integrating test equipment.
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 to driving a piece of test equipment: it can use a proprietary driver that must be downloaded to each host; or it can accept commands using a generic interface such as HID or CDC.
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 and Linux, 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, for example, 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, is often a common resource shared between several different computers. In this case, each computer must contain a copy of each driver and 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 or mice. The CDC class is intended for modems and other communication devices. Using this class, the test equipment simulates a modem (i.e., 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.
There’s no doubt that on the surface a graphical user interface (GUI) running on Windows or Linux 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 the packages that connect Python scripts to GPIB, RS232, USB and Ethernet instruments are easy to download.
The GUI must provide a scripting interface that allows control of the hardware directly, instead of only through the GUI screen. Further, the interface must support a script that can access multiple pieces of equipment in an automated sequence.
Some additional requirements for a GUI are:
- It should be able to control multiple devices. Otherwise, there will be multiple copies of the GUI running in parallel, resulting in potential timing issues between devices.
- It must be multi-threaded so that each user connection is handled in its own process and timing scripts do not tie up the system.
- It must also be able to handle different interfaces — Ethernet, RS232, USB, GPIB, for example — simultaneously.
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 or 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 a designer to incorporate an attenuator or test system into a larger test suite running under LabView or other framework.
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 potential interface barriers and how to remove them is an important first step before evaluating any piece of test equipment.