A quick intro to processing A/D converter data streams
Article By : Don Dingee
Here are a few basic design considerations for analog and mixed-signal engineers to know about processing A/D converter data streams.
Congratulations, you’ve set up an A/D converter or a smart sensor and the host processor is getting data from readings. That’s the first step. For some applications, getting one reading on demand might be useful. Many applications call for some computation on a stream of readings.
Signal processing is a deep topic, but we’ll keep this simple for makers. Here’re a few basics to know about processing A/D data streams.
- Time is an important dimension
Analyzing two-dimensional (2D) data, such as pixel data from an image sensor, is much more complex. For this, we’ll assume that we’re processing a continuous, real-time one-dimensional (1D) time series from each sensor. A time series is just what it sounds like: samples taken at sequential points in time, oldest to most recent.
What makes analysis much easier is consistently spaced A/D samples. Ideally, samples are at a constant output data rate (ODR), firing readings at a set frequency. Regardless of when the host reads the data, sample spacing is known and consistent. For instance, an ODR of 20 Hz means samples are 50 milliseconds apart. While it’s possible to timestamp irregular samples and figure out spacing, that requires more storage and more processing.
- Local decision-making can help
Another simplification comes from understanding the application and interpreting data and its significance. This is one of the key tenets of edge computing—don’t send raw data to the cloud for processing it it’s not interesting. Local decision-making helps reduce network congestion and cloud storage requirements.
A couple of examples may help illustrate this point. Say a sensor is monitoring temperature of a pump motor. Do you need to see perfectly normal readings? No. You want to know a sensor is functioning, and it would alert you when temperatures rise and approach overheating.
Another example is a model rocket altimeter. While it’s sitting on the launch pad, stationary, readings aren’t very interesting except for setting a reference zero altitude. “Launch”, from an altimeter’s view, comes when there is an above-threshold (like 5-m) altitude change plus an acceleration. Data collection begins from that point forward.
Figure 1 Simulation of model rocket flight data showing altitude, acceleration, and velocity. Source: OpenRocket
- Three basic motivations for processing
Makers may be familiar with statistical computations for a batch of sample data. Processing A/D data streams, with samples coming in real-time, is a bit different. There are three basic motivations for stream processing.
- Noise reduction: Knocking down evenly distributed “white” noise is easy with averaging techniques. A moving average tries to smooth out a signal, taking the most recent N samples and averaging them. When the next sample comes in, it’s tossed in with the most recent N-1 samples and averaged again. Moving averaging introduces a lag, which gets larger as the period gets larger. Often, two moving averages, one with a shorter period of M samples and one with a longer period of N samples, are computed and compared.
- Prediction: For control systems, it’s very useful to be able to predict, or at least make an educated guess about what the next sample will be from a set of prior samples. For instance, predicting drone motion with external forces like varying wind at work is a challenge. There are “filtering” step predictors, factoring uncertainty into a best new estimate. The most common is the Kalman filter, often available in canned library algorithms.
- Frequency-domain analysis: A time series may reveal some information, but often the real information lies in frequency domain. Assuming Nyquist sampling, a Fast Fourier Transform (FFT) converts time series data into energy in frequency bins. For analyzing audio data, or vibration patterns, using the frequency domain is essential.
Figure 2 The time-series stereo audio is sampled at 44.1kHz, 32-bit floating point. Source: Audacity
- Sensor fusion may provide insight
Finally, there’s the idea of sensor fusion. Readings from different types of sensors combined to yield more information than a single sensor alone could provide. Sensor fusion can also get complicated quickly. Fusing data with different sample rates and time delays between sensors becomes impractical.
Simplification helps. Let’s return to our model rocket altimeter example. Good altimeters have both a pressure sensor and an accelerometer, and they run at the same low sample rate, so there’s no significant phase delay. We talked about detecting “launch”. Approximating maximum altitude, or apogee, is possible from pressure readings alone. A more accurate reading comes from correlating the sample where acceleration ceases—1 g, straight down.
Sensor fusion is also common in the inertial measurement units (IMUs) widely used in drones and robots. Combining accelerometer, gyroscope, and magnetometer readings gives a more complete picture of pose. A packaged IMU with integrated processing may do much of the computation.
Recapping steps in processing A/D data streams
Given libraries for key algorithms, time-series data analysis is doable. Here is the summary of the steps:
- Select and set up an ODR for a sensor, and pick the same rate for any other sensors.
- Apply local decision-making to reduce data transmission, processing, and storage requirements.
- Decide what the application needs: noise reduction, prediction, or frequency-domain analysis.
- Borrow proven code for more sophisticated algorithms from an application library where possible.
- Leverage sensor fusion where problems are well-explored, and solutions known.
Gaining confidence with processing A/D data streams can lead to more insights from data. It might even inspire you to innovate with your own sensor packages and algorithms.
This article was originally published on Planet Analog.
After spending a decade in missile guidance systems at General Dynamics, Don Dingee became an evangelist for VMEbus and single-board computer technology at Motorola. He writes about sensors, ADCs/DACs, and signal processing for Planet Analog.
