04 Oct 2012

Software Designed Instruments: What Are They?

David A. Hall, of National Instruments talks about software designed instruments and shows how they provide additional functionality over traditional approaches

For the last several decades, programming an instrument was like barking commands at a puppy.

You “asked” to do things through a series of SCPI (pronounced “skippy”) commands, and hoped it did what you told it to. This was appropriate when all you want from your instrument is a simple spectrum plot – but many engineers want more.

Today, with software-designed instrumentation, engineers can completely redefine and reprogram the behaviour of the instrument itself, taking advantage of all the processing power and system design software tools at their disposal.

With these advancements, shouldn’t we demand more of our instrumentation then just passively responding to commands? Who wouldn’t want to reprogram a puppy (or an instrument in this case) to respond to more advanced commands?

Evolution of RF Instruments

The introduction of software-designed instruments is fundamentally changing the way we think about how to use instrumentation. Two decades ago, RF instruments such as signal generators and analysers were generally fixed-function boxes. They gave you a good spectrum display or constellation plot, but it was difficult to use them for much else. Starting in the late 1990’s, PC-based modular RF instruments (such as PXI) began to slowly change the way engineers used instruments. These PC-based instruments featured digital, IQ sampling architectures and were easily connected to software running on a PC. During this time, the industry observed engineers solving challenges such as passive RADAR detection, signal record and playback, software-defined radio prototyping, and RFID tag emulation by simply adding software to the instrument.

Looking forward, the next evolution of instrumentation technology will make it possible for engineers to easily redesign the software running on the instrument itself (commonly known as firmware). For advanced automated instrumentation users and RF system designers, the motive for this trend should be completely obvious. If you’ve ever struggled with an instrument’s “list mode” API, tried to get faster test times in a stimulus-response measurement, or tried synchronising a digital bus with the RF signal, then you’ve probably wished for the day you could tweak the instrument’s firmware instead of programming around it on the PC. Of course, tweaking an instruments firmware carries another requirement: the firmware must be easy enough to understand and modify.

Software Designed Instrument

That day has arrived. National Instruments recently announced the world’s first software-designed instrument. The NI PXIe-5644R vector signal transceiver (VST) (Figure 1) – features an RF signal generator, RF signal analyser, and a digital pattern generator/analyser all within the same module. However, unlike the previous generation of modular instruments, the new VST also contains a user-programmable FPGA built on the NI LabVIEW reconfigurable I/O (RIO) architecture. By making the FPGA (which runs the instrument’s firmware) accessible and easy to program in LabVIEW, engineers can now modify the firmware of the instrument itself, improving it for their specific application needs.

 Figure 1. PXIe-5644R vector signal transceiver incorporates multiple instruments in addition to an FPGA onto the same module.

Under The Hood of Instrumentation Software Architecture

At a high level, automated instruments fundamentally use multiple-processor architectures. Here, the supervisory processor (usually a PC) automates the secondary processor (the instrument) through a series of commands. The instrument is therefore responsible for interpreting commands and responding with appropriate hardware actions. For example, suppose the PC sends a command to set RF centre frequency. Upon receiving this command, the secondary processor (usually a PC or FPGA or both) executes appropriate hardware changes such as: 1) disabling RF output, 2) retuning the local oscillator (either VCO or YIG), 3) setting appropriate gain and attenuator levels, and 4) waiting for amplitude and frequency settling.

The primary difference between the traditional instrument paradigm and the software-designed paradigm is that the latter enables the user to modify the behaviour of the secondary processor. This enables the user to solve more advanced applications such as synchronising digital IO control with RF front-end changes or embedding signal processing code into the instrument itself.

In Figure 2, we observe the block diagram of the default RF signal analyser firmware (delivered to the user in a LabVIEW sample project) for the PXIe-5644R VST. Similar to other RF signal analysers, the firmware contains blocks – known as the instrument design libraries – execute traditional functions such as IQ data correction (calibration), signal processing (decimation, frequency shift, etc.), timing/triggering, and writing to DRAM.

 Figure 2. Instrument design libraries are an “open-source” firmware implementation that user can modify.

A secondary observation from Figure 2 is that a sufficient level of documentation of the instrument’s firmware is required (and provided) to enable user modification. In this case, instrument functionality is defined by LabVIEW FPGA code, which is a graphical high-level abstraction programming tool that lends itself to easy-to-read documentation. Without it, making changes to the firmware would at least require VHDL expertise and, more likely, intimate knowledge of the instrument architecture.

Solve Unique Applications with Software-Designed Instrumentation

For many engineers, the idea of re-programming firmware might seem a little scary. To ease the transition into this new approach, software-designed instruments (like the PXIe-5644R VST) have default personalities and programming interfaces that enable them to be used like traditional instruments. However, the true value of user-programmable firmware is that it enables engineers to solve applications that were previously impossible with off-the-shelf hardware.

For example, consider the application of RF power amplifier (PA) testing. Because typical modulated signal measurements such as WCDMA’s error vector magnitude (EVM) and adjacent channel leakage ratio (ACLR) can change significantly with small changes in output power, it’s important to measure a PA’s performance at a precise output power. As a result, PA testing usually involves “servoing” the PA, a closed-loop control process that requires adjusting the input power from an RF signal generator to achieve the desired output power.

Traditionally, due to the large overhead of instrument control, PA servoing was a time-intensive process that could take up to 5 seconds with traditional instruments. With a software-designed instrument such as a vector signal transceiver, however, the instrument’s firmware can be modified to handle the closed-loop control as shown in Figure 3. By calculating the PA output power and adjusting the signal generators input power in firmware (on the FPGA), servoing time is dramatically from seconds to miliseconds.

 Figure 3. Instrument firmware can be modified to perform closed loop control.

A second application where software-designed instruments, enable engineers to solve unique challenges is in the field of Multiple Input Multiple Output (MIMO) channel emulation. A MIMO Channel Emulator is an instrument that can emulate these multi-antenna, real-world electromagnetic propagation characteristics in real-time in a repeatable lab environment.

Historically, channel emulators were expensive instruments implemented with costly analogue hardware. Today, however, improved performance from RF instruments combined with high-performance signal processing targets such as FPGA’s enables channel emulation to be implemented with digital designs. Software-designed instruments such as the NI vector signal transceiver are able to uniquely solve this application through the user-programmable FPGA, as shown in Figure 4. Here, an FPGA is connected to both the RF signal generator and analyser. By modifying the firmware code on the FPGA, an engineer can easily deploy the mathematical modes needed to emulate the wireless channel – hence building a channel emulator.

 Figure 4. Deploying channel emulator mathematical models onto software-designed instrument’s FPGA enables engineers to use the instrument like a channel emulator.

A final application improved by software-designed RF instruments is general-purpose automated test. When working with complex products such as integrated radios and transceivers, engineers must often test multiple mixed-signal ports with specific timing intervals. Here, testing a device might require an engineer to generate an RF signal in parallel with generating a digital pattern to device under test (DUT).

In the past, these applications were solved using multiple instruments and were often handled sequentially. However, the ability to control digital ports and RF ports in parallel through user-programmable firmware enables engineers to ultimately reduce test time and test cost. A real-world example of this is the WLAN characterisation lab at Qualcomm Atheros. By synchronising all DUT control with RF generation and measurements, engineers were able to use the NI vector signal transceiver to reduce test time by 200X compared to previous rack-and-stack instruments.

The Future of Software-Designed Instruments

In many ways, the evolution of instrumentation to a “software-designed” approach paradigm is a natural transition in the way engineers use and create software. Over time, system design software tools such as NI LabVIEW have evolved to offer increasing sophistication in the way engineers can abstract low-level details. For many, the idea of modifying instrumentation firmware written in a low-level assembly language would be unthinkable – and for good reason.

As one might imagine, the inner workings of an RF instrument – especially one that integrates several instruments onto the same module – require sophisticated abstraction software. As a result, software-designed instrumentation will evolve only so far as the abstraction software and high-level synthesis software tools required for engineers to modify firmware.

It’s worth asking the question of whether or not we expect other instrument vendors to ever offer software-designed instruments in the way that NI is doing. Because software-designed instrumentation requires a highly capable, yet understandable and modifiable firmware design, it’s arguable that a graphical programming environment is a necessity. Now if we could only figure out how to program our puppy with LabVIEW.

Page 1 of 1

About the author

Most popular articles in Test & measurement