Connecting 192 (or 128) Analog Inputs at High Sampling Rate

Hello everybody,

After much deliberation and reading many forum posts related to my problem, I have decided to start a new topic on the issue of connecting 3x64 analogue inputs (as in potentiometers) to an Arduino MEGA 2560 R3 with (nigh on) concurrent signal readings, or a high polling frequency.

For my third semester project in Industrial Design, I am currently working on a new MIDI device controlled by 64 identical ‘keys’ that can be accessed from either side. Each key’s movement is bidirectional and sends out a potentiometric signal (volume) depending on its travel distance. Furthermore, every single key is layered with ‘soft potentiometers’ (modulation) on both sides that vary in resistance depending on where the key is pressed along its length. While, for reasons of experimentation, I would love for there to be two separate soft potentiometers on each key, I am not averse to the simplification of just connecting both sides to one analogue output; hence the alternative 128 inputs if 192 are too many. Lastly, two long soft potentiometers span the entire length of the keyboard, enabling a user to modulate a note’s frequency seamlessly, but I think we can leave this out of the conversation.

I am willing to spend somewhere around €150 on the electronics required (excluding the Arduino) to quickly and reliantly condense all those signals into something workable in digital space. This is not exactly a cheap project (the soft potentiometer’s graphite foil is surprisingly expensive), so if there are more elegant and efficient solutions that cost a bit more, do please divulge them.

The soft potentiometers are homemade and resemble this commercial product:
Spectrasymbol SoftPot:
http://www.spectrasymbol.com/potentiometer/softpot/how-it-works-softpot

I have read somewhere that the Arduino’s 16-pin ADC does not work particularly well with multiple inputs if you’re looking for something with barely any delays between reading each pin, so I would like to outsource the job of converting analogue to digital signals to external ADCs. Although, I have read about a way to boost the internal ADC’s sampling rate by raising its clock (would this change anything?):

‘Overclocking’ the Arduino’s ADC:

For 192 inputs, I had played around with the thought of connecting everything to four mux shields (as in Mux Shield II), Lab3’s input channel extenders, or connecting the modulation side to 16 8-channel multiplexers connected to the MEGA’s on-board ADC pins, leaving the volume side to be connected to 8 8-channel ADCs going to the board’s digital pins. I have explored a couple of multiplexer options, including more expensive 16-channel ICs.

Mux Shield II:

Lately I have been thinking of connecting 24 8-channel multiplexers to 3 8-channel ADCs going to the Arduino’s digital connections. Or 24 8-channel ADCs connected directly to the digital pins (If there are enough), or using three shift registers to bundle 8 ADCs each to save pins on the Arduino. I think digital is the way to go when connecting to the Arduino, considering that a 10-bit resolution is more than enough for my endeavours and the board has an easier time dealing with multiple digital signals at once.

Here are some ICs I have been eyeing:
74HC4067D analogue multiplexer:

This thread has been helpful in choosing these ICs:

This has become quite an encyclopedic post, but I hope you can bear with me and that we may find a solution to this conundrum :slight_smile:

I don’t think you can make it work, as described. It would be too slow.

Do you think there's no way of making it happen at all? Would changing the amount of inputs alleviate this problem of being too slow?

I know some latency would be involved, but as long as it is not overly jarring I would like to give it a try.

On the other hand, I was also thinking of replacing the soft potentiometers with a capacitive matrix measuring the same kind of displacement along the length of the keys. I don't see a way around the potentiometers controlling the volume side of things, though.

It's the number of A/D conversions that will kill you.

Ok, so you're saying that this amount of information/inputs would have to be digital from the very beginning if I were to have any hopes of connecting this to the Arduino? If I were to break down all my potentiometers into a multitude of incremental binary switches/buttons (which would be quite a few), this would work better?

Or do you think I should go the completely analogue route and create a synthesizer? I originally intended this to work with DAWs on a computer, but really the most important part for me is the control scheme/interactivity side of it and how one modulates sounds.

If I were to break down all my potentiometers into a multitude of incremental binary switches/buttons (which would be quite a few), this would work better?

Yes it would but it would be quite impracticable.

You need to do simple maths to see how impracticable.
192 signals with 128 switches per signal is 192 * 128 = 24576 switches, given your budget of €150 then that is €0.00610351563 per switch, let's call it €0.006. And that is before you get to wire up 24576 inputs to an Arduino.

the Arduino's 16-pin ADC does not work particularly well

The Arduino does not have a 16-pin ADC, don't know where you got that idea from. There is one ADC inside the Arduino's processor chip with a 6 input multiplexer on its input. And it works better than you need.

You need to harden up on you soft hand waving figures:-

high polling frequency. ..... latency would be involved, but as long as it is not overly jarring

So align yourself with a reality check.

You can get external ADC chips that work very fast.

I was also thinking of replacing the soft potentiometers with a capacitive matrix measuring the same kind of displacement along the length of the keys.

A capacitave matrix is very very slow when compared to the internal ADC.

Ok thank you for that answer, yes sometimes I tend to spiral off until I'm faced with a reality check :slight_smile:

The Arduino MEGA does indeed have 16 analogue pins. When you say it works better than you need, do you mean my idea of using many ADCs similar to that of the board itself could work?

My approach of using potentiometers came after going through many possible solutions, including capacitive sensing, and I still think that it is the most compact and efficient -- so I'd like to stick with that.

I think the ADC I mentioned before is quite fast (200ksps sampling rate), what are your thoughts?

The Arduino MEGA does indeed have 16 analogue pins.

Yes it does but it is not

16-pin ADC

It might be a 16 input ADC but using the phrase you did means it is a chip with 16 pins and is an ADC.

I think the ADC I mentioned before is quite fast (200ksps sampling rate), what are your thoughts?

You need to get the data out of it and that takes the time. I use those chips a lot for Raspberry Pi projects that have no built in ADC. It suffers from noise on a simple setup and has more resolution than you need. Being MIDI all you need is an 8 bit ADC and there are faster ones.

My advice would be to build just one input and see how it goes. Then you can scale up but not to the ridiculous extent you propose. However, like everything in life electronics does not scale up easily. There are new problems you haven’t even thought of once you start getting big systems. Like layout problems, propagation delays, decoupling issues, power supply distribution not to mention the shear large number of wires that need soldering.

OK I concede I might have misspoken about the analogue pins on the MEGA board.

Being MIDI all you need is an 8 bit ADC and there are faster ones.

I agree, 8-bit is definitely sufficient, after all, this instrument will be played with fingers, not surgical robots. Also, where would the limit be for when you would term the amount of inputs to be ridiculous? I can consider reducing the amount of working keys to 24 for 3 octaves for demonstrational purposes.

A fellow on a different forum said the multiplexer and ADC approach would work, although it would probably suffer from noise and wiring issues, as you pointed out, too. I was playing with the thought of separating every 64 channel row completely, wiring them up to three individual UNO boards and then handling them as three individual but codependent MIDI interfaces in a DAW. Would that mitigate the scaling problems you speak of?

The same person also suggested the use of 32 Atmega8 chips using I2C to talk to a Raspberry Pi (for 128 channels, that is). I’ll have to look into this quite a bit more, but it does seem like this system could boast a lot of processing power and maybe even circumvent the noise etc. issues of using MUXes and ADCs. Here’s a link to the discussion if you’re interested:

https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=151606

In any case thank you very much for the help, it’s greatly appreciated!

I think each key should have its own processor and handle all the data for that key, then send the data to a master controller that collates it and sends it down the midi stream.

Yes, that seems to be the best possible solution. I'll keep this thread updated in any case. First, I need to sit down and try to integrate the solution posted on the aforementioned forum for Raspberry Pi into the overall package.

using I2C to talk to a Raspberry P

Using I2C for this is a bad idea. It is quite a slow interface and with a lot of pots you need all the speed you can get.

I would say between 64 and 100 pots is about the limit that you could expect.

I agree, 8-bit is definitely sufficient, after all, this instrument will be played with fingers, not surgical robots.

Yes but even if you had a surgical robot the MIDI standard only uses 7 bits to encode it's parameters.

Using I2C for this is a bad idea. It is quite a slow interface and with a lot of pots you need all the speed you can get.

When you say slow, do you mean overall latency or short signals that could be missed/swallowed due to too slow sampling rates?

In any case, the I2C connection looks to be very advantageous in terms of wiring, and I can't think of a better solution at the moment :confused:

I would say between 64 and 100 pots is about the limit that you could expect.

So that would be 64 pots per Arduino if I were to follow through with using 3 boards?

By slow I mean the data transfer rate is only 10K bytes / second. To say you were worried about the A/D sampling time, this is going to be your limiting factor.
Also the I2C protocol involves a salve only sending data when asked so there is a lot of polling going on, so the useful data transfer rate is in effect a lot slower.

So that would be 64 pots per Arduino if I were to follow through with using 3 boards?

You would then have the problem of combining the data.

the data transfer rate is only 10K bytes / second

I’m assuming you’re referencing the standard mode of I2C at 100kbps, but it’s possible to increase that rate to 400kbps fast mode on the Pi, and the proposed connection runs at 400KHz.

The SPI protocol on the other hand is supposed to be significantly faster, but I’d need 48 slave selects which is more than the Pi could offer. Would shift registers work here or also impede the system’s speed too much?

but I’d need 48 slave selects

Yes which you can get from 6 GPIO pins and a few logic chips.

Hi again,

good to know that one of my suggestions makes sense :).

To revisit the maths on I2C though, I don't see why it would be too slow for my purpose. Assuming I read 4 analogue pins at an 8-bit resolution each from a chip, adding an address length and read state of another 8 bits, plus some overhead (including the time required for switching the analogue multiplexers); I2C might need about 50 bits to read an entire chip, or four sensors.

As the Raspberry Pi and the ATMega8s (or PCF8591s) are capable of running I2C at at least 400KHz, 400 000/50=8000 read cycles in a second. Every cycle, it reads 4 bytes worth of analogue data, so 32 000 bytes per second.

For 192 inputs, each input can be read (32 KB/192 inputs) approx. 167 times a second, which is faster than a perfectly adequate mouse or keyboard (125 Hz polling rate).

Please correct me if I'm wrong, but I don't see an issue with regards to speed?

but I don't see an issue with regards to speed?

Well try it, but seeing how concerned you were about speed at the start of this post you seem to have accepted a slowdown by a factor of 10 to 20 times.

I will indeed try it. I don’t see where I specified the system’s speed anywhere other than saying high polling frequency, so that factor is a bit out of place here. Anyways, 167 Hz is far beyond anything anyone could ever even hope to play (10000 BPM), so there shouldn’t be any ghosting or speed related issues.

You said:-

to an Arduino MEGA 2560 R3 with (nigh on) concurrent signal readings,

If that is not fast then I don't know what is.

Anyways, 167 Hz is far beyond anything anyone could ever even hope to play

That is 6mS latency, if you get it that fast.