An Alias By Any Other Name

Generally speaking, an alias can be a problematic thing. In the world of Data Acquisition, Aliasing is equally problematic. As with an alias, aliasing is a bit of a fake, a phony, a confusing situation where the data that you capture is not indicative of the true signal that is being measured.

Data acquisition relies on sampling, or taking a single measurement of a signal, at regular intervals. If the signal is changing more slowly than the sampling rate, an accurate representation of the signal can be represented by the individual measured samples. To be precise, the sampling rate should be at least twice the frequency of the signal that is being measured.

Aliasing occurs when the sampling rate is less than two times the frequency of the signal being measured. The actual signal frequency is mistakenly measured as a lower frequency when the sampling rate is too low. There is no way to identify that the signal being measured is actually an alias frequency.

To prevent aliasing, a traditional DAQ system will employ anti-aliasing filters which will limit the frequency of the signal being measured to less than one-half of the acquisition rate. This method can be effective, but does suffer from some drawbacks, such as:

  • Additional circuitry for the filtering function
  • Fixed filter frequency
  • Multiple filters required for different acquisition rates
  • In multi-channel, scanned systems, each channel requires individual filters

One of the key principals of OpenDAQ is to employ hardware that is as simple as possible. To that end, OpenDAQ utilizes one analog to digital converter per channel. And, to address the aliasing problem, the analog to digital converters utilize over-sampling to perform digital filtering. This ensures that aliasing can’t occur. More importantly, the additional circuitry required to performing anti-aliasing is not required.

What is not apparent in this discussion thus far, is that acquiring samples at varying sample rates requires anti-aliasing filters with different filter frequencies. If one were to need to acquire data at different rates, some sort of programmable filter would be required for each channel in a data acquisition system.

The OpenDAQ approach ensures that there is no need for complex filtering systems. This keeps the circuitry simple and clean. The over-sampling nature of the analog to digital converters means that the filter automatically adjusts to the sampling rate. Any sampling rate is supported and is guaranteed to filter out signals that could alias.

In addition to the benefits of simple circuitry and automatic filtering based on sample rate, this approach also ensures that each channel in the DAQ system is sampled at the same time. In a scanned DAQ system, where there is only a single analog to digital converter, sample and hold amplifiers must be used to capture the signal on all of the channels, then hold it temporarily while each channel is scanned separately by the single analog to digital filter. Using an analog to digital converter for each channel eliminates the need to use the sample and hold circuitry to allow for simultaneous capture and acquisition of all channels in the DAQ system.

The OpenDAQ approach to analog to digital capture and conversion keeps the circuitry simple, and also ensures that all channels in the DAQ system are sampled simultaneously. The added costs involved in using a single analog to digital converter per channel are mostly offset by eliminating programmable anti-aliasing filters on each channel. And when considering the costs to implement simultaneous sample and hold circuitry, individual analog to digital converters per channel are actually a cost-effective solution to many problems that need to be considered in data acquisition systems.

And the Meek Shall Dictate the Bus Speed

If you have ever worked with standard bus interfaces before, you will know that in almost all cases, the transfer speed of the bus is, in some way, fixed between devices on the bus. This is the typical case for both point-to-point and multi-point busses.

Having a fixed bus speed can simplify the design and implementation of the bus. But it does require that the devices that participate on the bus must be able to provide and consume the data at the prescribed rate, without data loss.

One of the oldest interface busses, serial, implemented various serial transmission rates. This would allow different devices of different aggregate data transfer rates to utilize the serial interface to facilitate device to device transfers. But there is no mechanism to dynamically determine supported serial transfer rates between devices. The rates must be known ahead of time.

The SPI standard implemented a much higher serial data transmission rate than classic serial. Yet the data rates between devices must be known in advance. In the case of SPI, there isn’t a fixed rate between devices, rather a maximum data transfer rate that can be supported. Regardless, that maximum rate must be known ahead of time, and can’t be determined dynamically.

The I2C interface is another variation of a serial interface bus. But unlike classic serial and SPI, I2C does specify a minimum serial transfer rate that must be supported by all devices. There are also upper serial transfer rates that depend on the rates supported by different I2C devices. But it can at least agree on a minimum data transfer rate.

Classic serial provided handshaking via optional handshaking lines. As with serial baud rate, support for handshaking is not guaranteed and must be agreed upon ahead of time. Unlike classic serial, SPI and I2C provide no such standard handshaking mechanisms.

OpenDAQ relies on micro-controller modules to run the show. These devices typically will implement classic serial and SPI interfaces. Some will also implement I2C. There is no other standard interface available on any micro-controller that can be leveraged to work on OpenDAQ. Classic serial, SPI and I2C can be used as long as their limitations are understood and worked with.

SPI is the best-supported interface for connecting function-specific integrated circuits and sub-systems. These include, but are not limited to, analog to digital converters, digital to analog converters, digital IO expander devices, and micro-SD bulk storage devices. SPI sub-systems include USB, Bluetooth, WIFI and Ethernet interfaces. Working with these devices requires that the host SPI system must understand and not exceed the maximum serial transfer rate of each of these devices.

For basic DAQ systems, serial interfaces will do the job. But as the complexity and performance of DAQ systems increases, the limitations of serial interfaces becomes a challenge.

OpenDAQ allows for greater performance and complexity by taking a modular approach that allows more than one brain, or micro-controller module, to be utilized in a single OpenDAQ system. Such increased complexity may require communications between processors that can’t be met by serial interfaces. To provide the needed flexibility, OpenDAQ borrows a page from the dark ages of device interfacing, and implements a version of an interface that, although decades old, is still supported in some DAQ instruments to this day, IEEE488.

The IEEE488 interface is unique in that it implements a handshaking mechanism that tailors the data transmission rate to the slowest participating device on the bus. Although this may sound limiting, the slowest bus device only dictates transfer rates while commands are sent, and while data is transferred with the slowest device. When data is being transferred between faster devices, the slowest device does not limit the transfer rate.

There is no set data transfer rate one the IEEE488 bus. It can run as fast as the fastest devices can manage, yet run as slow as the slowest device needs, without any up-front configuration or negotiation.

It may not be readily apparent, but when implementing communication between devices with varying workloads, this bus fits the bill perfectly. It adapts to both devices in real-time. And, unlike serial interfaces, IEEE488 supports multiple devices shared on the same bus without the need for extra hardware.

Although the IEEE488 bus was designed and implemented as an external bus, using cables to connect different physical devices, OpenDAQ implements a version of this bus internally, to connect intelligent sub-systems together in a manner that utilizes the real-time adaptability of the bus to ensure that data transfers never over-run. As an internal interface, the maximum bus transfer rate can achieve transfer speeds significantly faster than the 1 MByte/Sec maximum transfer rate of the external IEEE488 bus.

Given the horsepower that is now available with off the shelf micro-controller modules, it is now possible to implement an internal version of this interface using simple I/O lines, rather than relying on IEEE488 controller and peripheral devices that are obsolete and no longer available. Despite the obsolescence of the hardware, the functionality and flexibility of the IEEE488 interface bus has yet to be matched by any other interface bus currently available.

If I Only Had a Brain

All OpenDAQ products need to have a brain. We call this brain a processor, but what we really mean is that the brain is a micro-controller that has some digital I/O and a couple of common peripheral interfaces. But in the OpenDAQ architecture, the processor also contains memory for programs and memory to store acquired data, among other things.

Unlike a micro-controller chip, that needs other supporting hardware to actually work, the brain in an OpenDAQ product is a fully-functional module that can connect to things using basic connectors. These modules are available off-the-shelf and come with software for writing your own programs. These programs are programmed into the module and will run independently from the computer that was used to compile and download them into the module.

The most common of these modules include the Arduino family and the Raspberry PI family. The Arduino family includes modules that have widely differing speed performance, available generic I/O pins, and available standard interfaces, such as serial, SPI, I2C, etc. Raspberry PI modules generally offer greater performance, available memory, and advanced peripherals such as USB and video capabilities.

OpenDAQ does not specify any particular brain for any particular job. DAQ tasks vary widely in the complexity and horsepower needed to accomplish the given job. Selecting a single brain would be overkill in some cases, and underkill in others. OpenDAQ recommends that it is better to fit the brain with the overall job.

OpenDAQ can take this somewhat agnostic approach because the interfaces with the hardware that perform the various DAQ functions is abstracted into defined interfaces such as serial, SPI and I2C. Interfaces that require more complexity or performance than these standards is implemented using standard digital I/O pins.

It is the job of the brain to interface with the DAQ-specific hardware using these generic interfaces, perform basic tasks such as buffering data, and ultimately interface with a device to control the system, such as a PC, tablet, or smart-phone. Numerous off-the-shelf processor modules and hardware is available to implement the link between the OpenDAQ brain, and the higher-level control device using common interfaces such as Ethernet, WIFI, Bluetooth, and USB.

In high-performance applications, multiple brains can be used to implement DAQ tasks that have higher complexity, such as many channels, greater acquisition speed, internal data processing, concurrent channel readings, and so forth. But modularity and hardware abstraction is used to cleanly define the boundaries between these various brains, and OpenDAQ hardware.

By leaving the brain as a selection based on user preference and needed performance, OpenDAQ remains truly open and will allow future advances in ‘brain power’ to easily interface with OpenDAQ hardware for many years to come.

The Desktop PC Model

The Desktop PC was a revolution in micro-computer design for many reasons. OpenDAQ looks at the modular concepts of the desktop PC for inspiration in implementing modular hardware that is designed to accomplish specific DAQ tasks.

The Desktop PC implemented fundamental computer hardware that would be used in all computer applications on a mother-board. This hardware was fixed, was not intended to be upgraded, and would serve the needs of the PC for the lifetime of the unit.

To implement tasks that were not covered by the basic mother-board hardware, the PC took a novel approach. A common bus was implemented that would accept multiple plug-in cards. Hardware functionality could be added to the PC simply by purchasing plug-in cards for each added function that was needed. When combined with the software necessary to control the hardware, a flexible PC was born.

Some PCs were configured and sold as off-the-shelf solutions. Other PCs were customized by selecting specific plug-in cards to suit the jobs to be performed. All PCs could be upgraded in the field by replacing or adding plug-in cards. Such flexibility was a first in the micro-computer world and set the stage for all subsequent PCs, even those offered today.

The actual OpenDAQ implementation may not be cards that plug into slots with edge connectors. But the concept of using a common bus to provide the connection between a common core and DAQ-specific hardware elements is one of the defining features of OpenDAQ.

Welcome to OpenDAQ

Welcome to the OpenDAQ discussion site. OpenDAQ is the start of a community of users that have an interest in helping to create a hardware/software platform that focuses on data acquisition tasks and problems.

Although measuring analog signals and converting them into digital format has been around for decades, it has largely been ignored by the open source community. Yet Data Acquisition (DAQ) surrounds us every day. Your cell phone, your car, your tablet all perform DAQ tasks.

DAQ can be implemented in many different ways. Most often some sort of DAQ instrument and software combination is purchased and configured by the user to perform specific DAQ tasks. These systems often are geared toward making a single sort of DAQ measurement, such as measuring a voltage. But making other kinds of DAQ measurements, such as temperature, require an entirely different instrument, or at the very least, an add-on option to a base DAQ system.

DAQ instruments and hardware run the gamut from simple $100 boxes with limited performance, to $muti-thousand systems that offer superior performance and durability. Flexibility, however, is either difficult to find, difficult to implement, costly, or some combination of the three.

OpenDAQ attempts to address limitations with current DAQ offerings by approaching DAQ from a novel direction. Some of the OpenDAQ concepts include:

  • Open hardware
  • Open software (and firmware)
  • Hardware modularity
  • Hardware abstraction
  • Flexible cost/performance balance
  • Off-the-shelf hardware modules
  • Off-the-shelf DAQ systems

Off-the-shelf hardware and systems are future offerings that will be based on ultimate architecture choices that will, in part, be co-designed by the OpenDAQ community.

Currently we are working to spread the word, and add users to the community. In addition, new articles will be written to better define OpenDAQ concepts, as well as to convey design decisions that have already been made. We will discuss the logic behind each of the concepts and decisions, and elicit feedback.

We hope to arrive at OpenDAQ specifications that will drive the design of hardware, software and firmware modules which will become the basis for the official OpenDAQ content.

Data Acquisition is used more and more every day for consumer, commercial, and research applications. We at OpenDAQ.org wish to pull back the curtain, share how DAQ can be done well, and give the user the final option of going totally on their own, implementing a solution with OpenDAQ hardware/software/firmware modules, or purchasing a flexible OpenDAQ system.