Weighing Up Oscilloscope Software Benefits

The primary capability of oscilloscopes is to display waveforms. A real-time visual presentation of signal activity distinguishes DSOs from digitizers and other types of data acquisition systems. Nevertheless, a DSO acquires and stores a waveform as a series of data points, so it’s not surprising that application-specific software has been developed to process that data.

Very broadly, two types of software are available: programs that interact with a scope’s hardware and those that don’t. Third-party analysis software typically is independent from the scope hardware whether the software runs under the scope’s Windows operating system or on a separate PC. Software and firmware provided by the scope manufacturer may be more closely linked to hardware operation.

For example, serial bus compliance testing software provided by the scope manufacturer may control scope settings and signal capture and then operate on the data acquired under those conditions. General-purpose programs simply analyze previously acquired data.

A wide range of application-specific software is available and can be grouped into categories by industry or application type. In Table 1, each column corresponds to a class of applications, and the entries identify specific capabilities. For HDMI, Infiniband, XAUI, and several other bus types, physical-layer compliance testing does not necessarily include decoding. This capability is supported by logic analyzers and protocol analyzers.

Table 1. Scope Software Categories and Capabilities

Although the table represents the range of available software, it is not a comprehensive guide. For example, if a company offers software that addresses a particular function, it probably is not compatible with all of that company’s scopes. Some table entries might need to be combined or further subdivided to directly match a software product. And, no doubt other capabilities exist that are not listed.

Inside Your Scope

Compared to analog oscilloscopes, DSOs are much more complex. When a trigger occurs in an analog scope, the sweep is started, and the signal on the CRT’s vertical deflection plates is displayed as a function of time. In a DSO, acquisition and display are separate functions so processes that are inherently simultaneous in an analog scope require coordination.

Trigger Abstraction
Also, DSOs abstract triggering to several levels. Initially, the concept of arming was added to support pretrigger acquisition. When the data acquisition system was armed, it continuously overwrote its memory until a trigger event occurred to create a time reference for the data being captured. Acquisition completed, and the memory contents were displayed relative to the trigger.

Mask testing is an example of exception triggering often executed in software although some newer scopes apply hardware acceleration. The only interesting waveforms are those that do not pass the test. But before a decision can be made, the waveform must be captured by conventional arming and triggering in the background. Because a DSO has separate acquisition and display processes, the data retained and displayed can depend on the test result.

Several scope models offer hardware-based serial bus triggering. According to Agilent Technologies’ USB Protocol Triggering and Decode for Infiniium 9000 Series Oscilloscopes datasheet, “When serial triggering is selected, the application-specific software enables special real-time triggering hardware inside the scope. This hardware reconstructs protocol frames using signals acquired from either scope or digital channels. It then inspects these protocol frames against specified protocol-level trigger conditions and triggers when the condition is met. Hardware-based triggering ensures that the scope never misses a trigger event when armed.”

Obviously, other manufacturers may approach serial bus triggering differently. Nevertheless, serial bus triggering represents a high level of abstraction well beyond simply triggering on a voltage level or rising edge.

The last sentence in the quote is important because it refers indirectly to the underlying data acquisition process going on in the background. DSOs acquire signals based on an arm, trigger, store; arm, trigger, store… sequence. Regardless of the scope architecture, there is some time lost between the previous store and next arm events during which no data is captured, and it’s possible to miss frames. Some scopes are better than others in this respect.

Addressing the broader subject of scope software, Chris Loberg, Sr., technical marketing manager at Tektronix, said, “Our bench oscilloscopes offer modules for automated power analysis that include power quality, line harmonics, switching loss, safe operating area, and other key measurements as well as modules for automated serial analysis with triggering, decode, and search for common serial buses such as I²C, SPI, CAN, LIN, FlexRay, I²S, and RS-232. Our bench mixed-signal oscilloscopes have parallel bus analysis as standard.”

The automated serial analysis modules referred to are small plug-in firmware modules that configure built-in triggering hardware to recognize certain types of bus events. Front-panel bus buttons allow different bus types to be selected, input channels defined, thresholds set, and data formats specified. Tektronix supports serial bus triggering on start, stop, missing acknowledge, address, data, and combined address and data fields. A decoded LIN bus frame is shown in Figure 1.

Figure 1. LIN Bus Decoded FrameCourtesy of Tektronix

“For the extensive analysis commonly required during characterization and compliance test,” Mr. Loberg continued, “we offer more than 30 oscilloscope software analysis packages on our performance and ultra-performance oscilloscopes including technology-specific measurement and compliance software, application solutions for jitter and timing analysis, and channel emulation and equalization tools. With these packages, you can analyze a variety of challenging system designs.

“The most complex analysis functionality is available on our Windows-based performance and ultra-performance scopes. This approach is aligned with our customers’ needs, which implies that as designs increase in speed and complexity, the software package options grow in analysis capability,” he concluded.

Yokogawa bucks the trend by not being Windows-based, but this really has little to do with actual scope functionality. The company’s DL9000 and DL6000 Series support hardware-assisted serial bus analysis. This includes user-defined serial bus triggering on up to 128 clocked or unclocked bits and arbitrary on-screen decode of any serial pattern in hex or binary. The Xviewer PC software application facilitates file transfer, waveform viewing, and remote DL-series scope control.

In LeCroy’s Vehicle Bus Analyzer products, the company groups a WaveRunner scope together with CANbus hardware triggering, software decoding, measurement and graphing capabilities, and application-layer triggering and decoding. Essentially, this is a scope-based protocol analyzer.

Physical-layer triggering establishes a time reference within a series of logic transitions, but data link-layer triggering relates those transitions to data and address values. Application-layer triggering and decoding are abstracted yet further and assign meaning within the application context, such as the engine speed is 1,000 rpm.

Decoding vs. Triggering
When triggering on a specific bus condition, other data combinations are ignored. In contrast, decoding defines each frame type as well as the associated address and data. Decoding and triggering are separate processes with very different characteristics.

Where triggering implies sufficient speed to keep up with the bus states changing at the scope channel inputs, after the trigger is recognized, acquisition completes, and decoding takes place on static, stored data. Most scopes perform decoding in software whether through proprietary analysis programs or via third-party applications. Figure 2 displays a listing of USB protocol events together with a corresponding physical-layer waveform.

Figure 2. USB Physical-Layer and Protocol Event Correlated ViewsCourtesy of Agilent Technologies

According to Johnnie Hancock, a product manager at Agilent, there are three key advantages of hardware-based decoding vs. software-based decoding:
1. With hardware-based decoding, decoding and triggering of a serial bus use the same technology. If the scope can trigger on a particular serial communications event, it also can decode it. With software-based decoding, there often is inconsistency between hardware-based triggering results and software-based decoding results caused by slightly different threshold-level settings or errors and bandwidth limiting through the hardware path but not the software path.
2. Many of today’s serial bus applications required deep memory acquisitions to capture several packets of serial communications with high sampling resolution. With slow waveform and decode update rates, the scope can become nonresponsive and difficult to use.
3. Also related to waveform and decode update rates is the probability of catching errors. With Agilent’s hardware-based decoding, waveforms can update up to 100,000 waveforms/s with protocol decode updating at the display’s 60-Hz refresh rate. With these fast decode update rates, the statistical probability of decoding errors and seeing red error messages flash on the screen is significantly improved.

Kenneth Johnson, senior product marketing manager at LeCroy, explained the benefits associated with software decoding: “The special X-Stream software architecture and fast CPUs used in our scopes support software-enabled protocol decoding that is faster than on any competing oscilloscope. We constantly benchmark the calculation speeds of various operations and have yet to see hardware-accelerated decoding perform faster than the software algorithms we use.

“A new option for the WavePro 7 Zi and WaveMaster 8 Zi Scopes provides a combined PCIe physical-layer capture, decode annotation, and export to LeCroy PCIe Protocol Analyzer and Bit Tracer software. This will allow correlation of protocol packet information and physical-layer views as well as simple access to both.”

Outside Your Scope

To be fair, not many scopes involve proprietary hardware in data analysis. Certainly, this is the trend in some new scopes, but they represent a small percentage of the installed DSO base. Nevertheless, although hardware-based serial bus decoding may be an exception, it does highlight the different level of proprietary hardware access that scope manufacturers’ software and optional firmware may enjoy compared to that of third-party products.

It’s instructive to review comments made by Amherst Systems Associates (ASA) relative to the company’s M1 Oscilloscope Tools™ (M1OT) software to scope interfacing. There are four approaches:
•?Connecting Internally: Fastest data transfer and no additional PC required. Shared CPU and RAM, which slows down analysis; scope screen may be too small; only possible on Windows-based scopes.
•?Connecting Externally via Ethernet: Allows fast data transfer and remotely located PC. Requires separate crossover connection or approval to use company LAN.
•?Connecting Externally via USB-TMC: Fast data transfer. Only certain scope models have USB-TMC; this is the Type B square connector, not the more commonly found Type A flat one.
•?Connecting Externally via GPIB: May be the only choice on older scopes. Provides the slowest data transfer and requires GPIB hardware in both scope and PC.

In contrast, LeCroy’s Mr. Johnson stressed the tight integration of application software into the scope’s user interface. “Processed results are returned to the scope display as internally generated values and presented in a time-correlated way along with the other scope information,” he continued. “These results can be further processed by other scope tools. Also, should it be advantageous to export data to a separate PC, the LeCroy Serial Interface Bus (LSIB) supports data export at up to 325 MB/s via the scope’s PCIe bus.”

Searching vs. Triggering
In newer scopes, the capability exists to specify a very narrow trigger condition, but what is your justification for doing so? Initially, you may only know that a problem exists. Instead of manually trying to pinpoint the error, what if your scope software provided equivalent information by examining successive acquisitions, identifying protocol frames, and highlighting inconsistencies?

LeCroy’s WaveScan™ feature allows searching in a single acquisition using more than 20 modes. Or, you can scan for an event that meets your conditions over hours or days and perform some action when it is found.

Similarly, the Tektronix Wave Inspector^® feature provides a means of zooming and panning through very long data records. You can search through an acquisition and automatically mark all occurrences of a user-specified event.

Galen Wampler, president, Prime Data, was quoted in a 2006 Tektronix press release: “Wave Inspector is essentially the first instance of a new paradigm for searching through long record length acquisitions; it is to waveform management what search engines are to the Internet.”

Searching vs. triggering considerations shaped logic analyzer development years ago and resulted in the progressive introduction of more and more complex triggering capabilities. The search facilities being implemented on today’s scopes and in features like M1OT’s Hidden Anomaly Location routine are providing a better balance between triggering and searching.

Specialized vs. Generic
A few applications cry out for extreme amounts of memory, speed, and trigger specificity, but most do not. For those that do, the only way to gain all the advantages of a high-end scope is to retain access to its specialized hardware features. Generally, this means you must buy application-specific software provided by the scope manufacturer because it can use those capabilities.

Software that works only with captured data files is operating separately from your scope whether it runs on the scope’s microprocessor or on a PC. On the one hand, as emphasized by ASA, interacting on this level allows the same functionality to work with any scope. On the other hand, proprietary scope hardware won’t be accessed by generic third-party software. Of course, you can always set up your own acquisition conditions and then use a software application to further analyze the data you capture.

These kinds of trade-offs are important because they can incur additional cost; slow down acquisitions, data transfer, and analysis; and constrain your choice of scope vendor.

ASA founder Mike Williams observed that in his experience scope users are much more likely to use his company’s M1 software to search for anomalous conditions than set up extensive triggering conditions on a DSO. Besides, a very large number of older scopes are still giving great service but do not have the latest—and in many cases extra cost—triggering and decoding capabilities.

M1OT presents the same user interface and set of capabilities regardless of which model scope it’s used with. It follows that test results across a lab’s mixed brands and models of scopes will correlate well because the same algorithms have been used for all measurements, even jitter analysis as shown in Figure 3. Jitter testing is a particularly egregious example of getting different measurement results depending on which scope-based algorithm is used.

Alternative Solutions
PC-based scopes are an obvious alternative to consider, and so too are the various analysis and modeling software applications such as MATLAB, Mathcad, and LabVIEW. National Instruments (NI) Senior Product Manager Rebecca Suemnicht made several comments relevant to alternative solutions:

“One frustration many engineers face is that there often is little overlap in software application solutions across a range of oscilloscopes, even from the same vendor. Unfortunately, most application solutions reside on the more expensive Windows-based oscilloscopes. With software-defined instruments, engineers can leverage common hardware components from a variety of vendors and combine both standard and user-defined measurements with custom data-processing routines.

“Engineers using traditional instruments often rely on their instrumentation vendors to offer the software routines to test standard buses and interfaces,” she continued. “With software-defined instruments and programming languages such as LabVIEW, engineers can test multiple standards using common modular hardware components and implement emerging and custom wireless protocols and algorithms in their test systems regardless of the maturity of a new protocol or standard.”

Tektronix has addressed some of these concerns by including a copy of the NI Signal Express Tektronix Edition with each of the company’s basic or bench scopes. This software facilitates instrument control, datalogging, analysis, and report generation. Tek’s OpenChoice Developer’s Kit supports scope control via a variety of programs such as NI LabVIEW, MATLAB, and Python.

NI offers the following hardware-independent analysis packages: the Spectral Measurements Toolkit, the Sound and Vibration Measurement Suite, the LabVIEW Advanced Signal Processing Toolkit, the LabVIEW Digital Filter Design Toolkit, and the Modulation Toolkit.

Summary

Oscilloscope software is a multifaceted topic. You can choose to look only at the optional software applications offered by your scope vendor. For most people, this is a straightforward approach even if it may appear expensive. It has the advantage of retaining scope-specific hardware capabilities that more generic software may not access.

The next level of enhancement to consider is running third-party analysis applications under your scope’s operating system. This option supports tight integration of your custom signal-processing algorithms so that they appear to be part of the scope firmware. For example, LeCroy’s XDEV Development Package completely integrates third-party programs into the scope’s processing stream. Similarly, Agilent offers the User-Definable Measurement option that is based on an embedded MATLAB function.

Familiarity and scope ownership are two very good reasons to buy application-specific software from your scope vendor, install it, and get on with your job. But what about the next job? Most software of this type solves a narrow set of problems.

Less specific software provides better future-proofing although it also has an offsetting disadvantage. It won’t be as well integrated with your particular scope so analysis routines may not run as fast. It might need to reside on a separate PC, and this will involve a connecting cable and perhaps additional interfacing hardware. But you gain much better control of future expenses and often the benefit of lower initial cost.

January 2010