External ADC vs Multiplexing vs Multiple Arduinos - lowest latency?

Hi All

I need to continuously monitor/sample 32 analog inputs with minimal latency (all at 10bit).

As far as I can tell there are three ways for me to achieve this ...

  1. Acquire and incorporate (through SPI?) a few External ADC chips with appropriate specs.
  2. Increase number of inputs with Multiplexing.
  3. Use multiple Arduinos to get desired number of inputs and feed into a master Arduino of some kind.

Which is likely to be the best architecture for achieving minimum latency at the end?

My problem is that trialling all three options is quite daunting/expensive/time-consuming and I expect I'll find multiple complications with each anyway.

So I would really appreciate someone with a lot more experience than me saving me the trouble and pointing me in the right direction from the start (or other options I haven't thought of?)

I have read previous relevant posts re 'multiple analog inputs' on this forum plus google in general, so apologies if the answer to this is already on here but I couldn't find it!

Some background information if it helps …

  • Why need 32? They will correspond to sensors in a unique musical instrument. Reducing this number kind of ruins the whole thing! (It was a struggle to be satisfied with just 32.)
  • Minimal Latency? Ideally <20ms for the complete system, but this will include plenty of latency incurred at later stages (eg wireless transmission, signal processing, midi communication). I really need to minimise it ruthlessly at every stage.
  • The readings will usually be converted to midi (though current plan is to do that outside the arduino, in a PC), but still need 10bit resolution out of the Arduino, despite eventual midi being 7bit.
  • Sample Rate needed? not sure yet. Probably less important than latency. Will need to be suitable for Midi messages at the end of it all, but I imagine the wireless transmission stage will be limiting factor for this (planning on using NRF24L01).
  • There will be a variety of sensor types - including FSRs, Infrared distance sensor, ultrasound distance sensor, flex sensors, basic pots, custom pots, softpots, resistive XY touch pad etc. I am aware these will lead to a variety of input impedances and signal ranges (and latencies in the actual code needed to read some of the more complicated sensors)- I was planning to give each an op amp circuit to try to present similar signal ranges and impedences to ADC(s). Not sure yet how to deal with the different latencies that the actual unique code needed for some of those will incur, but I think that's a coding challenge, not a hardware one, so not worrying about that yet!
  • There will rarely be more than a handful of sensors giving active signals at any one time, but they all still need to be scanned swiftly just in case, even if the majority are then deemed dormant.
  • Power may be a challenge - it will need to be battery powered. I am expecting to need to incorporate a heavy weight of battery power!
  • Size is also potentially an issue - eg I may struggle to make room for 5 x Arduino Megas, if that's what's recommended.
  • I have been working from Mike Cooks book 'Arduino Music and Audio Projects', which has provided excellent advice and inspiration on many obstacles, just not the answer to this specific question!
  • I am planning on using 'Mega 2560 R3'(s), but not the end of the world if I need to go with something else. Smaller would certainly be welcome.

I hope that all makes sense.

Many thanks for reading.

My first response would be to get some Maple mini they have 9 analog inputs I do not believe the analog input is faster than an Arduino but they can be used with the Arduino IDE
They're small like a nano they are very low power they have 12 bit ADC lines

Reading 32 signals in 20 ms is no problem as such - but you have to know more about the individual sensors.
Ultrasound distance readers often output digital signals that need to be timed (that's a problem for your 20 ms requirement).
IR distance sensors maybe digital, maybe analog.
Most other sensors you list appear to be analog indeed.
Most Arduinos have 6-8 analog inputs, reading all of them will take about 1.2-1.6 ms (100 us per reading, but due to the switching of channels you need to read them twice). You're going to need external ADCs for the rest, those should be able to give you a set of readings faster, especially if you use the SPI version. I2C is much slower, maybe too slow. Depends on the chip, bus speed and the amount of data.
If you plan on using multiple Arduinos, you won't run short of pins soon. Megas is overkill. Go for the Pro Mini, very small footprint and they have all 8 analog pins exposed (the Uno/Nano only have 6 analog pins available, D6 and D7 are not broken out).

Analog multiplexing is all you need or want. Multiple processors is not viable.

Latency is not the issue. It only takes about 100 microseconds to do an analog conversion on a 16MHz AVR but when the processor is chewing up all its time doing analog conversions at the fastest rate possible, you will have have no computing power remaining to do anything with the data.

There are far better solutions for audio than the AVR architecture. Just for comparison, have a look at the Teensy 3.4 & 3.5.

25 or 27 analog inputs and two independent adc channels, 13 bits resolution possible
2 12 bit dac’s
180Mhz clock rate, 240MHz overclocked
1024kb flash, 256kb ram
Extensive library support
Compact form factor
<$30 each

https://www.pjrc.com/teensy/techspecs.html

avr_fred:
There are far better solutions for audio than the AVR architecture. Just for comparison, have a look at the Teensy 3.4 & 3.5.

As I understand it, OP is not looking to process audio signals as such, but reading sensor signals which happen to come from an audio environment (I think it's something like "when did I press which key of the instrument") as input for a midi system.

wvmarle:
As I understand it, OP is not looking to process audio signals as such, but reading sensor signals which happen to come from an audio environment (I think it's something like "when did I press which key of the instrument") as input for a midi system.

There. Fixed it for ya. Sheesh. What a bunch of pedantic nit pickers around here lately.

wvmarle:
...Nano only have 6 analog pins available, D6 and D7 are not broken out).

:o

You mean A6 and A7 ?

I'd go with 8-channel SPI ADCs, such as one of these. Easy to cycle thru all 8 channels quickly. Faster than the 10-bit conversion time of a Nano's ADC.

https://www.digikey.com/products/en/integrated-circuits-ics/data-acquisition-analog-to-digital-converters-adc/700?k=mcp3&k=&pkeyword=mcp3&pv667=60&FV=ffe002bc%2C3cc004e&quantity=0&ColumnSort=0&page=1&stock=1&pageSize=25

If you have 32 sounds - can you not just read those sounds that are “active” at any time ( identified by say a digital signal) and measure those.
You have to think what you are going to do with all that data pouring into the Arduino and that will shape what you do .

Hi,
Welcome to the forum.

Please read the first post in any forum entitled how to use this forum.
http://forum.arduino.cc/index.php/topic,148850.0.html.

What data are you aiming to collect, amplitude or are you trying to measure or record frequency?

Thanks.. Tom... :slight_smile:

there are 3 points that have been made that bear directly on the problem at hand.

wvmarle pointed out that regardless how fast or how much power your circuity/ board/chips have or the micro-controller has, if your sensor takes 750 mS to report a value, that is the limiting factor. so sensors are a big part if the speed.

avr_fred pointed out that moving from the 16mHZ AVR processor of the Arduino board will greatly speed up your ability to read the points.

crossroads pointed out that with good part selection, you can get the inputs faster by using multiple parts than you would be able to do with an Arduino.

In my view, getting away from the Arduino an into a much faster chip would be one step.
listing all the sensors with their inherent times is another step.

my thoughts were to scan the slow sensors with a separate micro, but once you move up in abilities ( Teensy?) that becomes less of an issue.

Ok thanks all. Lots of useful advice.

I will investigate Teensy 3.5 as 27 analog inputs just might do for the simple FSR style sensors and the smaller size and superior speed would definitely be welcome. I could employ a second Microprocessor to deal with the slower more complicated sensors and a third to compile the results and send output stream down NRF24L01. Just not experienced with Teensy. Is is feasible to mix and match different microprocessor types for these three functions? Any advice on that welcome.

Also I'm not sure I'm entrely clear on one of the key questions - if I do end up using Arduinos and extending native input count using Multiplexing or external ADCs - which is likely faster (ignoring issue of a few slower sensors)? Ie as wvmarle says if one reading takes 100us, but need to read twice (=200us) then am I right in saying using Multiplexing for the simple sensors (say 27 of them) could take roughly 27 x 200us = 5.4ms? Would I likely beat this time by using external ADC instead through SPI with otherwise the same microprocessor?

In answer to a few outstanding questions ...

TomGeorge:
What data are you aiming to collect, amplitude or are you trying to measure or record frequency?

Just a stream of readings from all the 'active' sensors - ie 10bit values. 'Active' being any that experience change at any given read over a given small threshold (ie - still need to read them all each time to check).

hammy:
If you have 32 sounds - can you not just read those sounds that are “active” at any time ( identified by say a digital signal) and measure those.

ok sounds good, but how can I do that? Assuming I want to start reading any sensor whose value has 'moved' say +/- 3 (on a 10bit 1023 scale), how can a Digital input be engaged to trigger that?

wvmarle:
Reading 32 signals in 20 ms is no problem as such

Yes 20ms may seem like an achievable aim, but 20ms is my aim for the overall system end to end. I will likely lose something in the region of 5ms in the wireless transmission and receiver, another 5ms processing, and another 5ms with the midi conversion and triggering of the actual Midi device at the end of the whole chain. So this initial reading stage really needs to be in the region of 5ms or less.

TomGeorge:
Please read the first post in any forum entitled how to use this forum.
http://forum.arduino.cc/index.php/topic,148850.0.html.

Yes I did read the 'how to use this forum' post first and tried to adhere to correct etiquette. Have I not managed it?

Thanks all!

That 100 us per ADC conversion is for the ATmega chips; I don't know how the Teensy deals with this. Likely a lot faster.

For the rest of your timing:

  • why using wireless transmission for something that's time sensitive?
  • why would processing take that long? What are you even processing?

Also: start with making this work for 1 sensor first. See how fast everything reacts. Then start wiring up more sensors, adding code to deal with them (if written properly that's very easy - can be as simple as increasing the value of the variable that tells the code how many sensor there are).

Ok thanks wvmarle.

I'll start testing.

In response to your questions ...

wvmarle:

  • why using wireless transmission for something that's time sensitive?

It's time sensitive because its designed for live musical performance, and too much latency makes that impossible. It needs wireless transmission for the same reason - jumping around a stage whilst attached to cables is no longer necessary for any instrument, so hoping to provide the same luxury for mine.

wvmarle:

  • why would processing take that long? What are you even processing?

As a minimum it may be just sending the readings from a sensor through some mathematical response shaping function and sending out as midi expression controller values. However some sensors will also be combined through trig functions and mapped to create angular values, others may be combined to create multiple formant filter parameters (lots more maths!), others will be processed and combined to produce actual midi notes depending on the values, and others may become parameters for oscillator(s) which in turn provide Midi expression outputs. Or any combination of the above. Also, the whole thing may also need to monitor a separate midi input to perform algorithm that works out rhythm and timing information from it to apply it to the created midi output. And probably more! It could all take next to no time, which would be great, but as I keep saying, I need to minimize latency at every stage. I won't be happy getting to 19ms if the ADC reading is taking the first 18ms! All stages should be as fast as I can feasibly get them.

Thanks all. Will be back if I hit more obstacles!

My thinking behind my earlier response was that maybe a digital signal would be available when a sound is generated - eg by a key press or something linked to that sound source ; then just digitise that one .

I measured many years ago that the smallest latency a human can detect is around 10mS.

You may care to reconsider your requirements.

Allan

MacDall:
Just a stream of readings from all the 'active' sensors - ie 10bit values. 'Active' being any that experience change at any given read over a given small threshold (ie - still need to read them all each time to check).

So you are not looking for an input that exceeds a threshold, but a change in signal, ie the measured delta, that exceeds a threshold?
You are detecting rate of change?
Tom... :slight_smile: