an 8192 sensors matrix scanning in under 4ms?

Hi everyone,

So i'm a musician, and i have this electronic drum project where i'd like to scan a matrix of 8192 simple sensors (FSRs), each sensor is a 5mm square of interdigitating fingers with some piezo-resistive stuff on it to create a variable resistance across the electrodes, varying with finger pressure. All of them are disposed in a 128x64 array... and i need to scan them really, really fast, more precisely, i need to make a full scan in under 4ms... (I know, i know... i know...) to have a large proper multitouch XYZ pad.

let's say... let's feel optimistic and consider the best case scenario, with a full matrix scan in 1ms, that's more than 8 millions of ADC conversions per sec, plus all the demux and mux switching, and that's only for the data acquisition. For what's next, i decided that whatever the microchip(s) i use, i would only scan the matrix with it, and then, only if it's relevant (meaning at least a determined threshold has been crossed), send data out (I2C, TX, whatever i'll figure...) to a computer for post treatment (force evaluation, and sound triggering), so i'm not overcrowding the serial or whatever other connexion with Mbs of useless data... So the data coming out of the chip would be a bunch of coordinates and a voltage value as integers, at the very worse 5 fingers x 4 sensors per finger at the same time x 2 coordinates per sensor + voltage value = 60 bytes (or more depending on which resolution i choose for the voltage) per ms.

I put a lot of thinking into this, and considered dozens of different ways i could implement this, but for each one there's a catch, a problem, or simply some knowledge i would have to painfully and time consumingly acquire in order to just theoreticaly evaluate the relevance of it...

I've been thinking for ages (ok, only monthes...) and i still have nothing, well i know what won't work, which leaves me with only what i don't know if it could work...

if i'm using a single proc, even with a180Mhz, that leaves me with less than 30 instructions to accomplish one MUX/DEMUX + ADC conversion + evaluate if the threshold has been crossed + send the data if it has

Of course i'm taking into account not using the slow common arduino fonctions and instead using direct port adressing etc (i successfully used that in other projects)... I'm quite familiar with C, much less with the AVR architecture and how registers work in these chips, not to mention assembly language and stuff, each time i wanna evaluate a solution i find myself in front of a new montain to climb...

So i considered other options, using a raspberry Pi with additional ADCs, but i would still need fast enough multiplexing... i'm absolutely not familiar with the Pi, nor with ADCs, i feel that's another 6 months of work just to find out how to implement this and then find another catch and go back to square one... (right now i still have to wake up from the dream in which i'm doing everything with Atmega chips...)

and i'm not even taking into account the proper inductance of a 64x32 cm matrix... So maybe splitting it in smaller arrays could solve problems i yet don't know about

I feel this is going bad, i just don't know how much, and i guess that's why i'm here...

I even considered going Chuck Norris on this thing and put a whole bunch of Atmegas linked to a master by an I2C bus, each doing the MUX/DEMUX/ADC/threshold evaluation task each for a small dedicated array like 8x8. Problem is an I2C bus would not exceed 1 Meter, my matrix is 64cm long, and only a few dozens of devices can be chained (i read 112?) so i would be stuck at something like 64 Atmegas... the only advantage i see here is that ADC conversions, and threshold evaluations would be done in parallel, which is exactly what's required to achieve such a massive scan in less than 4ms.

Of course i thought about power consumption... I'm not planning to run on batteries and even if i have to burn 10 amps to get this thing going, so be it.

the ideal case scenario would be to have ADC conversions trigger only if the voltage is at a specified level, and have everything rest the rest of the time, that would require an external mux to send V+ to the electrodes continuously, and a threshold circuit or i know some ADC's have the embedded ability to do that (at least i sort of imagine they can) like this one maybe

some chips could be put in sleep mode, but i don't know if it's really a solution as there will be a wake up time...

There it is, things have to happen in parallel or really, really fast...

I even read this ENTIRE patent which adresses this exact problem by scanning only a fraction of the electrodes and interpolating the results: US9001082B1 - Touch sensor detector system and method - Google Patents

Well it certainly is clever, and it works, but that could only divide my problem by a factor of 16 at most... they say 150hz is ok, but not in my case.... (as for patent infringement, i'm not planning on selling anything)

I don't know which way to go... Or even if there is one, i still believe there is!

I could indeed ask someone which does this kind of weird stuff for a living, as a matter of fact i did, he's the one who told me to try with the RPi... but oh boy how lonely i felt when i had to go through the entire litany of how ADCs have to be managed, fed and loved... I'm a musician, i like this stuff but it's driving me insane

I any of you happen to have any suggestion or an old analog oscilloscope to throw at me, or if you know of someone who could REALLY help me, understands the real darkmatterness of this, please do put me in contact with this holy angel of light... please...

Thanks for reading my plea :confused:

Yes, that's quite a task. 128 x 64 array.

Here's a possible approach. For the scan you have about 30µs to handle each row of 64.

suppose each of the 64 column lines has a pull up resistor, and you activate the row line
by pulling it down to 0V. During this 30µs period you use eight 8-to-1 analog switches to
route the 64 voltages to eight comparators. [ The comparators share a preset reference threshold
voltage set by a trimmer pot.]

That's 4µs to let the comparators settle, and all their open-collector outputs are shared -
if any of them pulls low the shared output goes low and you detect this to stop the scan.

So you need to be able to change 3 address lines to the analog switches once every 4µs, and
read a single input before the next time round the loop. With direct port manipulation that
seems reasonable.

To control the 128 row lines you can chain shift registers like '595's, and after scanning each
row you'd clock the shift registers once to move the active line along. However we want
the output of the shift registers to be open-collector, so plain 74HC595's aren't suitable without
buffering with octal open-collector buffers (assuming such exists).

Once you've detected a hit you read the 8 comparator inputs with an ADC (perhaps another 8-to-1
analog switch to do that).

The whole design should be proven with a smaller, perhaps 16 by 8 array, first to iron out teething problems.


i'd like to scan a matrix of 8192 simple sensors (FSRs)...

You do mention 'multitouch' (but don't specifically mention 'resolution' or 'accuracy') but bear with me for a moment...

Like the old resistive touchscreens, it may be possible to rig two arrays of fixed resistors, a TopGrid and BottomGrid then attach the FSR's between top and bottom at each intersection. i.e. replicate the top and bottom resistive layers and use the FSR's to connect them.

Then you'd only need to drive each layer and do two ADC conversions to get a location.

I googled for something to illustrate this: 4-Wire Analog-Resistive Touch Screens - might be interesting if you are not familiar with resistive touchscreens.

And this illustrates the resistor grid: ( R >> FSR )

(I know, i know... i know...) As I was drawing this I was thinking: "this'll be a nightmare!"

Anyway... food for thought :slight_smile:



For the ultimate in A/D converters get one known as a "flash converter", these take just one clock cycle to settle and are used for converting video streams. However, I do think their are better ways to detect a press position.
See my project:- spoonDunio

Ok, your instrument makes the 200 touch pad linnstrument look like a toy. The Arduino Due source code is in github if you are interested.

However, I do think their are better ways to detect a press position.
See my project:- spoonDunio

Nice... for some reason reminded me of the old Stylophone :slight_smile:

And another better way to detect a press detection:

You could triangulate the press position on a surface by reading only 4 force sensors on the corners.

for multi-touch you could array this in grids of 100mm or something.


for some reason reminded me of the old Stylophone

Not altogether a coincidence :wink:

A low cost easy way to do this sensing is to use a Raspberry Pi and it's own 7" touch screen display.

For such a number of sensors it looks that as you said you'll need to use a divide & conquer strategy, where you'll have a bunch of small components to process a row or a column or maybe a small x by y matrix (8x8 maybe).
In order to choose what to use to do that, maybe this article is useful: The Amazing $1 Microcontroller - Jay Carlson

I have only played with atmel mcus and just a bit with the esp8266, but I know they are not the best solution for every problem, take a look at that article, it makes easier to compare small mcus, maybe you find there one that is better suited to this very particular job.

Probably the RPi is not a good solution to this kind of stuff, as I've red that it's not easy to make it work as a real time system.

Woaa, thank you so much guys for taking the time to answer with all of these clever thoughts! It's a completely different atmosphere at the StackExchange forum :slight_smile:

I love the SpoonDuino i found it to be very poetic!

There's definitely a lot to think about in what you all said, i will certainly need more time to consider all this, and maybe afterall i'm a bit too much out of my leage with this project, at least in it's current design... but i still can reduce it to a 32x64 matrix and see if the "divide and rule" strategy could work...