IEEE Microwave Magazine - September/October 2018 - 28

When Choosing Test Equipment,
Don't Forget the Interface
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 HID and
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 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, 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.

Figure 1: Multiple devices must work seamlessly together in an automated test flow. Source: RfMW UK

Table of Contents for the Digital Edition of IEEE Microwave Magazine - September/October 2018