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.
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.
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
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.
Figure 2 The time-series stereo audio is sampled at 44.1kHz, 32-bit floating point. Source: Audacity
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:
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.