Hey guys,
I'm working on a project to make a piece of test equipment for a research project (in case you're curious, it's a sort of robotic fish to test state space models, control algorithms, and whatnot).
The problem is that I have many analog signals (around 20 or so) that I have to sample at 100Hz (after front-end filtering of course) and need as many bits of resolution as possible. Therefore, I decided to use a set of ADS1115 external ADCs. Each ADS1115 has 16 bits of precision, but is kind of slow - about 4 to 8 ms per sample per signal in single-shot mode. For 20 signals, that amounts to about 80ms at best, which is blowing my 100Hz requirement by a ton.
My proposal is to use the continuous-conversion mode on a single ADS1115 chip and mux all of the signals into the ADC channel that is being continuously quantized. This is because, although continuous-conversion mode is MUCH faster than the normal single-shot mode, it will only allow you to sample a single ADC input pin. I figure the mux could allow me to sample many signals via a single ADC input very quickly.
Question: Do you think the mux/continuous-conversion solution is viable? What are the pros and cons of the solution? Do y'all have a better possible solution?
Thanks!
Mux 20 analog signals into 1 16-bit value and be able to split them back out of the data later?
It will take careful work and shielding to collect 16 bits of data without the low 4 to 6 bits being noise. Just because the chip is capable of precision it doesn't mean that signal fed to it is accurate. Even 10-bit res takes some care.
Your external ADC can read very fast but the what speed is the data link between that ADC and the controller?
A 16MHz controller can pass 1 megabyte per second but won't be able to do much between-reads processing.
All AVR's have a single 10-bit ADC that can read a single channel and do simple processing at 8 or 9 reads per millisec. You can oversample a single signal at 1K rate with cycles to spare. Switching to another analog pin takes wasting the first read but you could still oversample one pin before oversampling the next and cover 5 pins at 200Hz on an Uno chip (has 6 analog inputs) while the Arduino Micro has 12 analog input pins able to oversample 10 pins at your desired 100Hz rate for each.
Shop around, a Micro or equivalent really does not cost much. Two Micros could cover your 20 inputs.
Next level are the ARM-chip Arduinos. 12-bit ADC on boards running 48MHz and up clock rates.
I like the PJRC compatibles for price and power.
https://www.pjrc.com/teensy/
Note that the Teensy 3.5 and 3.6 boards have on-chip FPU's and on-board SD sockets. The cheaper 3.1 lets you OC to 96MHz and has 21 analog input pins to a 12 or 13 bit ADC that yes can be oversampled higher.
The AVR chip Arduinos have pins that are more robust and simpler to operate but the ARM-duinos perform like rockets by compare.
AVR chips can be run faster than 16MHz. The guarantee goes up to 20MHz and I have an overclocked 1284P board that runs at 24MHz without getting warm or being unstable but AFAIK that's close to the limit and maybe over on a chip by chip basis.
That failing, I'm quite sure there are much faster ADCs than the ADS1115 around. Indeed, if anything it's not fast. The sampling rate of the ADS1115 is just 860 samples per second, so no matter how well you mux, you can sample no more than 8 sensors at 100 Hz with one such chips.
100 Hz * 20 * 256 = 512 KHz !
Well, provided you really need 16-bit ADC conversions at 100 sps, you can achieve this with your builtin ADC channels on the DUE and a MUX (because it is limited to 12 analog inputs).
You will have to oversample and average accordingly to obtain 16-bit conversions from 12-bit conversions.
From the Silicon Labs Application Note AN118(IMPROVING ADC RESOLUTION BY OVERSAMPLING AND AVERAGING):
Assume a system is using a 12-bit ADC to output a
temperature value once every second (1 Hz). To
increase the resolution of the measurement to 16-
bits, we calculate the oversampling frequency as
follows:
fos = 4pow4 * 1Hz = 256Hz
Thus, if we oversample the temperature sensor at
fs=256 Hz, we will collect enough samples within
the required sampling period to average them and
can now use 16-bits of the output data for a 16-bit
measurement. To do so, we accumulate (add 256
consecutive samples together), then divide the total
by 256. Such a process
is commonly referred to as decimation.
This results in 16-bits of useful data. Such an operation
is referred to as accumulate and dump.
512 KHz is well below the maximum conversion frequency of your builtin ADCs ( 1Msps ).
GoForSmoke:
Mux 20 analog signals into 1 16-bit value and be able to split them back out of the data later?
No, mux 20 signals into one ADC input pin and read the output based on which signal is currently being connected via the mux.
GoForSmoke:
Your external ADC can read very fast but the what speed is the data link between that ADC and the controller?
A 16MHz controller can pass 1 megabyte per second but won't be able to do much between-reads processing.
Do you mean it can pass 1MBps of I2C data specifically? I would only need about 4KBps data rate (2 bytes * 20 signals * 100 Hz = 4KBps).
GoForSmoke:
Shop around, a Micro or equivalent really does not cost much. Two Micros could cover your 20 inputs.
Next level are the ARM-chip Arduinos. 12-bit ADC on boards running 48MHz and up clock rates.
I like the PJRC compatibles for price and power.
Teensy USB Development Board
Note that the Teensy 3.5 and 3.6 boards have on-chip FPU's and on-board SD sockets. The cheaper 3.1 lets you OC to 96MHz and has 21 analog input pins to a 12 or 13 bit ADC that yes can be oversampled higher.
Ok, this sounds like a much better solution. I'll probably just go with a Teensy. Thanks! (+1 karma)
Power_Broker:
No, mux 20 signals into one ADC input pin and read the output based on which signal is currently being connected via the mux.
Every time you switch the signal source it will be disturbed and need settle time same as if you switched pins. You can still read at the higher rate but you're going to have to ignore 1 or more reads for every good read.
Do you mean it can pass 1MBps of I2C data specifically? I would only need about 4KBps data rate (2 bytes * 20 signals * 100 Hz = 4KBps).
That is SPI at twice the default speed on a 16MHz controller. I2C is slower.
2 bytes at 8 bits each * 20 signals * 100 Hz is 32KB/s.
Doesn't I2C have a protocol with device addresses, requests and returns? SPI does not.
Ok, this sounds like a much better solution. I'll probably just go with a Teensy. Thanks! (+1 karma)
Those high-end Teensy's look great. The pins are not as 'robust' as AVR pins, they source or sink less current and I've been informed by WestFN that they take an extra step or so for some manipulations. Paul Stoffgren of PJRC has likely left answers to all the ordinary stuff (and more) on their forum.
It was PJRC's Teensy 2.0 that 'inspired' the Arduino Micro. The PJRC software gave it instant support.
Will you be feeding the data direct to PC via USB? Yes, you can.
GoForSmoke:
Those high-end Teensy's look great. The pins are not as 'robust' as AVR pins, they source or sink less current and I've been informed by WestFN that they take an extra step or so for some manipulations. Paul Stoffgren of PJRC has likely left answers to all the ordinary stuff (and more) on their forum.
What do you mean by "extra step for some manipulations"? Do you mean like port manipulations? If so, can't I just use digitalWrite() or digitalRead if I'm using the Arduino IDE with the Teensy build option (already installed on my PC)?
GoForSmoke:
Will you be feeding the data direct to PC via USB? Yes, you can.
Yes, I'm not doing anything with the data except to send it to a PC via usb.
Yes, the Arduino functions are likely safed, WestFN was describing direct port manipulation.
The Teensy 2.0 and Teensy++ 2.0 have AVR chips with built-in USB. Their data rate is USB 1.1.
The core probably can't match that but the print buffer also probably never fills up.