Mitigating USB DAQ design challenges with onboard intelligence
Data Acquisition and Control (DAQ) systems come in many varieties, each with unique challenges. Some of these challenges are not obvious to designers that are new to DAQ systems. The incorporation of USB in DAQ systems can ease system design, but it can also introduce new, USB-specific wrinkles. Using onboard intelligence can greatly broaden the range of DAQ applications suited to USB.
More and more companies are incorporating USB devices into their embedded applications and systems. With more than 10 billion units worldwide, this widely accepted standard is driving faster and faster into the world of embedded system design.
In modern data acquisition, USB is taking over from previous generations of bus-driven cards like PCI, at least in applications where the USB latency/bandwidth performance envelope is supported. USB devices introduce features such as hot plugability and externally powered operation. Hot-plug removes the need to power down a system to repair, add, or swap data acquisition boards. Externally powered USB devices are capable of continuing to operate even if the host computer locks up or resets. These features make USB very attractive when considering a high-reliability DAQ system design.
Some aspects of the USB specification, on the other hand, can be considered a liability when implementing a DAQ system. Support for low-power modes, for example, can surprise system designers: The Operating System (OS) of the host computer might request the USB device effectively shut itself off simply because the system considers itself idle, even though the USB data acquisition product is quite busy accumulating data.
When working with embedded USB DAQ systems, designers need to deal with a wide range of challenges, including those related to transaction rates, watchdog features, and sleep/suspend states, as demonstrated by the following application examples.
Optimizing transaction rates in pulse-width modulated outputs
A primary limitation of USB DAQ systems is transaction rate. This significantly differs from bandwidth but is closely related to latency. Bandwidth is a measure of data per second, and latency is a measure of how long after the request for input or output before it occurs. The USB transaction rate is the time between sequential requests of an input or output before it re-occurs – specifically, 250 µsec. The difference between transaction rate and latency is the sequential term: The USB latency can be near zero in any given asynchronous transfer request if the request is issued right before the next scheduled transaction event. Conversely, the latency can be as high as 250 µsec if the request is issued just after a transaction event. On average, latency will be 125 µsec based on asynchronous requests, but the sequential transaction rate is 250 µsec, the time between USB transactions.
A straightforward result of this transaction rate relates to bit-banging, the technique of “manually” controlling digital output bits to emulate desired waveforms. On a PCI device, designers can bit-bang digital outputs at more than 100,000 transactions per second from user applications, but with USB there’s a strict limit of 4,000 Hz. This restricts the utility of USB DAQ systems. On the other hand, the onboard intelligence of USB devices allows many typical bit-banging operations to be offloaded to the microcontroller on the device itself.
For example, an application requiring pulse-width-modulated digital outputs could, on a PCI card, use bit-banging techniques to control generic digital outputs. Reaching 1 percent precision at a 10 KHz or lower base clock frequency on PCI is straightforward using modern software timing techniques, but the same techniques used to reach 1 percent precision on USB devices would cap out at a 20 Hz base frequency. By increasing the onboard intelligence, the host can offload the bit-banging onto the device, eliminating the 250 µsec USB transaction latency. This allows the performance to achieve even better than 1 percent precision using the same 10 KHz base frequency.
Adding watchdog functionality to USB DAQ systems
In an environmental test chamber application, a control application quirk arose due to the external power option of the USB DAQ cards. High-reliability DAQ systems use watchdog timer cards to cause computer power to reset if the application software locks up, preventing real-world equipment from running amok while the control software is unavailable. In this example involving Form-C relays driving heating coils and power supplies, if the software froze the heaters could have been left active too long, potentially destroying the Unit Under Test (UUT). The original design used a PCI relay product and a PCI watchdog board, and worked quite well. However, the system was migrated to a USB solution to gain all the advantages of the modern bus.
Using external power, and without a watchdog card to monitor the application state, the computer wouldn’t be reset and the relays would remain energized if the application froze – or even if the computer turned off. A watchdog feature can be added as a custom firmware tweak on the USB card itself. This mitigates the risk of overheating the coils by turning off the relays if no valid commands arrived at the device over the course of a few seconds.
Adding a watchdog feature can also be necessary in analog output (DAC) applications when USB is involved in the design. Relays have a well-defined “off” state (de-energized), as do analog outputs (zero volts). In DAC devices, digital counts are converted to analog output voltages based on the underlying resolution of the converter chip and the analog output range. A unipolar DAC may vary the output voltage from 0 V to 5 V, for example, by accepting an input count from zero to the max resolution of the DAC chip. A very common DAC is 16-bit resolution, which has a max count of 65,535. In unipolar ranges, zero counts equals zero volts, and max counts equals max volts. In bipolar ranges, however, zero counts is output as negative full scale (-5 V for example). In order to achieve zero volt output, mid-scale counts (32,768) must be written to the DAC. In the following example, the specific USB analog output board configured each channel as unipolar or bipolar via onboard jumpers. The firmware couldn’t detect the position these option jumpers had been configured to, and therefore didn’t know if a given channel was unipolar or bipolar.
Any trivial implementation of a watchdog feature similar to the implementation used in the previously mentioned relay board would have run into dangerous territory. To safely add a watchdog to this application, designers created a watchdog firmware API allowing the application software to specify the “safe” state – the state to which each output on any card would revert if the watchdog algorithm “barked.” This allows applications to specify watchdog timeout durations, and the “safe” state for all output types: relays, FETs, digital outputs, DACs, and even frequency generating counter outputs.
Preventing unwanted sleep/suspend commands
In a research lab application, a quadrature encoder interface was used to count revolutions of rodents’ exercise wheels. With hundreds of exercise wheels spinning furiously at any time of the day or night, an always-on acquisition system was a strong requirement. In this instance, the lab computers allocated to the DAQ system were prone to rebooting spontaneously. In an attempt to prevent the PC from rebooting, designers tried using an externally powered digital input product to decouple the host PC’s brain from the acquisition process.
However, during the power cycle process of the PC the USB bus was still sending “sleep” commands to the attached USB devices. Further investigation revealed no way of preventing this “command” from being issued: Any 3 µsec idle period of the USB bus is enough to be interpreted as a sleep command by all attached devices. This is a trivially obvious occurrence during power cycles and various types of computer reset, and is, in hindsight, a very intelligent method of informing attached peripherals that sleep mode is desired; after all, when the computer is off, the typical USB keyboard-and-mouse devices originally envisioned by the USB spec should power down as well. Therefore, when the computer reset or was powered off the DAQ card was powering off, and ceased its counting of the exercise wheel rotations and velocity.
Simply disabling the ability of the device to enter sleep mode can resolve this issue. However, permanently disabling sleep modes is both inelegant and inefficient. A more efficient fix involves the watchdog capability. When watchdog capability is included in the device’s firmware, it’s clear when devices are being used in a high-reliability environment. Therefore, the firmware takes note when the watchdog feature is enabled and disables sleep modes only if the watchdog is running.
Improving USB DAQ functionality
With ACCES I/O Products’ Firmware Evolution 2.0 release for the company’s dozens of USB DAQ modules, the custom features implemented in the previous application examples come standard to address a wide variety of similar issues. PWM outputs, debounced inputs, high-and-low-side latching inputs, and other features are now provided as part of this update. Adding these features as standard integrated firmware on all USB DAQ modules allows USB to be a more beneficial technology for data acquisition applications.
Navigating the challenges of USB DAQ design
These application examples demonstrate the wide array of “gotchas” that could surprise designers during high-reliability USB DAQ system development. Though USB use in embedded systems is quickly growing and does have its benefits, careful attention must be paid to avoid pitfalls during system design. Understanding the performance envelope available to USB – both the bandwidth and latency factors, as well as the improvements to these limits that can be realized by moving implementation details onto onboard intelligence – is critical to successful USB DAQ projects.
ACCES I/O Products email@example.com www.accesio.com