I have 300 infrared analogue sensors that give an ouput of between 0 and around 5 V on a third pin representing completely dark to 100% infrared detection. I want to collect all this information thirty times per second on my microcontroller. Of course I don't have 300 pins available so I was looking for guidance regarding the best way to do this. I had a few ideas:
I could use a regular form of multiplexing, however, the microcontroller would then have to evaluate 300 analogue signals. This probably isn't the best solution.
Locally (for each IR sensor) convert the analogue signal to 8-bit digital (i.e. a byte representing 0 to 255 for 0 to 100% IR detection) using an ADC (analogue to digital converter chip). Then I'm not sure the best way to collect the data. I could use a parallel 8-bit output ADC and use shift registers to convert the parallel digital info into serial. However, I would then need to daisy chain 300 8-bit shift registers - sounds problematic. Or I could use serial ADCs and daisy chain them but I can't figure out how that would work - any ideas? Finally I can't use SPI or I2C ADCs because SPI requires an additional pin per address (300 pins required again) and the I2C ADCs have only 9 available addresses.
I welcome any ideas or guidance. There may be a very simple way of doing this that I'm missing! Thanks!
johnwasser:
I would use one ATTiny84 for each five IR inputs.
So I was wrong about daisy chaining SPI - it's only during basic multiple usage that you require an additional pin per address. That is to say I wouldn't need 60 pins (= 300 / 5) on my microprocessor to use SPI with the 60 ATtiny84s, right? I thought I read somewhere it's 6 A/D pins not 5, perhaps I'm mistaken?
I'm not familiar with ATtiny84s. So it has 5 pins that I could take the analogue IR sensor input from and convert that to an 8-bit value and then using SPI send it to the main microprocessor. The sensors are in a matrix of 12 x 24 (288 sensors, not quite 300) but are separated in each direction by 2 inches. I would need quite long wire to connect 5 sensors to each ATtiny84 - would this cause any issues? Would I need to program the ATtiny84s at all or just use them through the SPI line? How difficult would doing all the SPI communication be? I'm a bit inexperienced in this regard - should it be relatively easy or quite difficult? I guess I would use Wire library or something...?
Thanks for your response, it's potentially the solution!
I would suggest breaking it down halfway. Look for 16 input ADCs with an I2C or SPI interface. In this case, it would seem advisable to use as much hardware "grunt" as possible, rather than a multiplicity of MCUs requiring a communication protocol.
But I could be wrong. When you start to mention long wires, I see problems. Long wires on analog inputs introduce noise; long wires on digital communications introduce timing problems, SPI may not work so well at all, depending on just how long these wires are, you might have to consider RS422.
So, what do you propose to do with the data you collect anyway?
Paul__B:
So, what do you propose to do with the data you collect anyway?
I'm making an interactive LED table. This link shows something that isn't too dissimilar to what I'm aiming to achieve. I didn't write a full description in my first post as too much text distracts people from the question I'm really looking for an answer to. I've already done all the colour RGB LED parts and have a 12 x 24 grid of pixels that play pretty patterns, however, I have no interactivity except via a PC currently. I want to add into each cell an IR LED and sensor but I don't just want 'touched' or 'not touched', i.e. binary detection, I want it to detect how covered each cell is (approximately) - hence the anologue conversions!
In terms of long wires. Well if I had one chip with 12 free A/D pins per row then the longest wires would be about 12 inches. Each cell I've made is 2 by 2 by 2 inches. Hence if the chip is in the middle of a 12 cell row it is 6 cells from the top or bottom and 6 x 2 = 12 inches. That would be for the analogue signals. The converted signals that are daisy chained and sent by SPI would have to travel through all the chips to the master microprocessor. That would be across 24 columns that are 2 inches wide, so the entire length would be 4 foot, but the individual wires between chips would only be 2 inches long. How does that sound? Plausible or problematic? To clarify: the longest individual wires are 12 or 2 inches long for analogue and digital signals respectively.
I might convert each analogue signal to just 4-bit digital representations (0 to 15 touch detection levels) to minimise data quantities. This data is then used to interact with the display! How does that all sound? It must be doable as the link shows above. Although I realise he is using a binary touch system not analogue which is my preference! As I mentioned, I've done the RGB LED part already which took quite a while.
CrossRoads:
Or use 38 8-channel ADCs, MCP3008, with three 74HC154 to demux the SPI signal to select one chip at a time.
Thanks for your response! Those chips look great, I didn't realise they exist. Do they come in versions with more than 12 channels, maybe 16 of which I could use 12...? That way I could have one per column (each column has 12 sensors) meaning I would need 24 in total for all the columns. Unless there are 24 channel version!
I'm confused about SPI now. I initially thought you need one additional line per extra component. Hence why I think you say I need the MUX chips, right? But this site seems to suggest you don't when you use daisy chaining...? And that's the impression I got from reading other users comments - but I might well be wrong! I want to use already existing SPI libraries - I'm not smart enough to write my own yet. What's your opinion on the SPI situation?
kadamr:
I've already done all the colour RGB LED parts and have a 12 x 24 grid of pixels that play pretty patterns
...
Each cell I've made is 2 by 2 by 2 inches. Hence if the chip is in the middle of a 12 cell row it is 6 cells from the top or bottom and 6 x 2 = 12 inches. That would be for the analogue signals.
That sounds no problem. I would reiterate my suggestion of using 16 input ADCs. Plenty of bypass capacitors.
Now the series chain of SPI could certainly be a problem. The data chaining from device to device is not so much of a problem as it is buffered at each, but the clock and latch lines common to all 18 over such a length could be. A "star" arrangement with some buffers however (noting that the data lines would come in with the radial connections and then loop out again) should be OK - say six buffers (74HC14) driving three lines each.
Any 16 & 32 channel ADCs are surface mount parts, some more difficult to use than others.
Not all SPI parts are daisychainable - the MCP3008 is one that is not. These multichannel parts need input commands to select the channel, mode, etc.
You can browse others to see if any will pass along data received on the data in pin.
I use SPI all the time. Shift registers are generally daisychainable; more complex parts are not. Hence the need to create more chip select signals.
CrossRoads:
You can browse others to see if any will pass along data received on the data in pin.
All right, great, thanks for the help! I will check through the links and do some research. In the meanwhile I should ask: do you think that this approach will work?
I want to update the sensor information to the master microprocessor as fast as possible so any hand gestures on the table aren't missed etc.. Realistically that means around 30 refreshes per second I would guess. Would this be possible using MUX chips and the ADCs you mentioned? It won't be too much data and take up all the processing power of the master would it? I would probably use an Arduino of sorts or a Teensy 3.1 I have spare.
Also what is your opinion on wire lengths and SPI - the table is 2 by 4 foot but I gave the wire lengths in a post above. Maximum wire lengths for analogue signal is 12 inches and there will need to be around the same length if not more between each ADC and the master if MUXing is necessary. Is this going to cause big issues?
300 * 30 = 9000 samples per second.
So you've got 1/9000 Sec = 111uS to take a sample and make a decision before making the next sample.
30 samples/second might be pushing it. You're not going for flicker free LED animations with the sensors here, so slower would likely be quite acceptable.
CrossRoads:
300 * 30 = 9000 samples per second.
So you've got 1/9000 Sec = 111uS to take a sample and make a decision before making the next sample.
30 samples/second might be pushing it. You're not going for flicker free LED animations with the sensors here, so slower would likely be quite acceptable.
Okay I guess I can slow it down a bit, I suppose I'll have to make a prototype to really see how effective it is. So this seems like the best solution; using MCP3008s - 3 per 24 sensor row, meaning I need 36 in total (12 rows). Then using MUX chips for the SPI control.
Another thing I've been thinking about is how can I deal with background IR and the maximum IR incident on the sensor being less than 100%. That is to say if the analogue range is 0 to 5 V from the IR sensor then given how the table works I will probably only ever get as low as (say) 1 V minimum due to background IR (extraneous rays) and probably never reach the full 5 V because my hand wouldn't reflect all the IR rays from the IR LEDs.
I can use the master microprocessor to just adjust for this but I feel it would be better to do this locally for every one of the 300 sensors using one (or two) screw-adjustable potentiometer or something for the whole system. I don't know how to even approach this problem though! Essentially I want to transpose my 1 to 4 V analogue scale (which should be 0 to 5 V if it wasn't for the problems mentioned) to be 0 to 255. Otherwise 5 V would be 255 but I will never reach 255 or go as low as 0. If that makes sense? How could I do that?
You can wire one or two and sample at the planned rate, see if it's responsive enough.
I don't know how you adjust for each sensor locally without processing at each sensor locally.
Apologies for butting in, but, for my education, why has multiplexing been discounted here? Seems an obvious way to keep the component count down vs the proposed solutions, which seem to use adc chips or ATtinys at a fraction of their potential speed. For 30 frames/s, less than 9,000 samples per second are needed, half the capacity of an ATmega from what I've read.
Well, we don't know how the OP has gone about wiring up the LED matrix. If that involved multiplexing, maybe something could be piggy-backed onto that. As each set of LEDs are powered during the matrix scan, power could also be provided to the corresponding IR sensors. Their outputs could then be read by a far smaller number of ADC inputs.
For example, lets suppose a chain of 5 x TLC5940s were being used to sink the LED current from each column, and a couple of '595s or '138's with MOSFETs attached used to energise each row in turn, the IR detectors on the rows could also be energised. Then by commoning the outputs from the detectors into columns (diodes may be needed), only 5 x MCP3008 would be needed. Alternatively, 3 x 4051 analog multiplexers could feed 3 ADC pins on the ATmega and used to scan rapidly over 8 the channels.
I'm sure my ideas above are full of holes and assumptions! That's why I asked to be "educated".
PaulRB:
why has multiplexing been discounted here? Seems an obvious way to keep the component count down vs the proposed solutions, which seem to use adc chips or ATtinys at a fraction of their potential speed.
It's a valid point from my perspective too. I had initially thought I would multiplex the 288 analogue signals. But then calculated if I was to use 8-channel MUX chips then I would require (288 / 8 =) 36 of them, which isn't a problem. However, that means I would need 36 pins on my master board in addition to the 4 lines for controlling the MUXs, isn't that right? I could use a 16-channel MUX which reduces this number a bit but it's still to many pins! And I couldn't find any larger than 16 that were through-hole type for amateur soldering etc.. So then I thought what if the analogue signals were converted into a single digital data stream that would require only 3 or 4 pins for something like SPI. That is how I got around to this post and the discussion and conclusions in all the previous posts. Also I thought that one master converting all the analogue signals might be too hard for it to do quick enough?
So the current option is using multi-channel ADCs and connecting them to the master via SPI with a MUX chip for slave selection. Alternatively, perhaps analogue MUXing is better - could someone tell me how I can MUX 288 signals and only use very few pins. The same master has to control the 288 RGB LEDs as well.
PaulRB:
Well, we don't know how the OP has gone about wiring up the LED matrix
The RGB LEDs are rows of WS2812b LED strips that I've separated to 1 LED per 2 inches. Similar to these NeoPixels for example. They are controlled in one data line using timing-specific shift registers. I was trying to produce the reverse solution for the IR light detectors. I've used a premade library and they were very easy to run at 100's of frames per second with many LEDs and minimal CPU usage.
Happy for any advice as always! Thanks for the responses - really helpful. Could MUXing be done with few enough pins and with a faster enough A/D conversion rate?
If my idea could work, it would mean a couple of 74hc595's (connected to the Arduino SPI outputs) to select one of the 12 rows. Depending how much current 24 x IR detectors need, you may or may not need 12 x transistors to boost the current from the '595's outputs to power a row of detectors. If the outputs of a column of IR detectors can be commoned-up, you may need a diode on each detector to prevent their output shorting away into the other rows. Then 3 x 4051 analog multiplexers (using 3 unused '595 outputs to select channel) connect the 24 columns to 3 Arduino analog inputs.
This all rather depends on how those IR detectors work, for example how quickly they settle once power is supplied, how quickly their output levels become stable at the ADC inputs having gone through the multiplexers, and so on...
If the 595's make the process too slow, and 7 Arduino outputs are available, the 4051's could be driven directly with 3 lines and 2 x 74hc138/238 driven with 4 more lines to select the row.
PaulRB:
This all rather depends on how those IR detectors work, for example how quickly they settle once power is supplied, how quickly their output levels become stable at the ADC inputs having gone through the multiplexers, and so on...
So your idea is that if you could selectively power each of the 12 rows of 24 sensors then a whole column could be wired into just one input of a MUX chip because only the powered row would be read (i.e. one single sensor). Therefore you only need enough MUX inputs for the 24 columns and not all the 288 sensors.
So if I used a 16-channel SPI shift out register (or two 8-channel ones) then I could power each of the 12 rows in turn (perhaps with the help of transistors and diodes). Then I only have 24 MUX channels which three 8-channel MUX chips would read. This would reduce the number of components significantly and therefore price. However, it all depends on the sensors behaviour when being turned off and on so rapidly. If I understand correctly!
Thanks for the proposal, it seems to have potential to me. Is there a way of selectively switching the data lines on and off instead of the entire sensor row? I will look at the available sensors and if there is any info on how long they take to settle...