Thursday, March 28, 2024
Login

When Choosing Test Equipment, Don’t Forget the Interface

Parent Category: 2018 HFE

By Paul Pickering

Introduction

When purchasing programmable, controlled RF test equipment elements, such as RF switches and attenuators, 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.

An RF/microwave entity wishing to establish test capability will often purchase the first piece of equipment from their preferred vendor, complete with software, and begin to develop a test flow menu. Later, they need another component, perhaps one that vendor doesn’t make. All too often the different pieces of equipment, while working well stand-alone, are not designed to easily fit into a production test flow that places a high priority on communication and synchronization between various modules with diverse functionality.

Proprietary vs. Generic Interfaces

A typical RF test scenario can include equipment from many different suppliers (Figure 1), each with their own control software, command set, and interfacing mechanics. In general, there are two approaches in developing a piece of test equipment: 1) deploying proprietary drivers to each host, or 2) using generic command sets on standard interfaces with common protocols such as USBs, Human Interface Devices (HID), and Communication Device Class (CDC).

1805 HFE test01

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

One potential problem with proprietary drivers is that the manufacturer may not support the 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. Conversely the market for a platform may not be big enough to justify the expense, although not major players, platforms such as Raspberry Pi are expanding beyond the hobbyist market and lightly engaging 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, can often be 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 fit a standard device class. If the device adheres to the class specification, the standard installed driver will work. Since it’s becoming the standard for newer installations, we will use USB as an example.

USB has several generic classes. The HID as its name suggests, primarily covers items such as keyboards and mouse devices. 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 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 high-level programming language 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 manufacturers.

Questions to Ask

Here are some questions to ask a vendor when configuring a new piece of test 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.

1805 HFE test02

Figure 2 • JFW’s USB test software GUI can control multiple devices. Source: JFW Industries.

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

Configuring a good test system requires careful attention to software interfaces. It’s not sufficient 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 in evaluating any piece of test equipment.

Search

CLICKABLES