The backup plan was to use IR sensors with an ON or OFF digital output only like these.
It says:-
IR sensor tuned to 38KHz, perfect for receiving commands from a TV remote control.
True, but useless for what you want. This is because the LEDs need modulation and the sensors only pick up pulses if you send less than 30 or so pulses without a gap.
Is multiplexing the best idea then,
It is one idea. Each sensor needs it's own input so imagine using an 8 input multiplexer then you need 300 / 8 = 38 chips. Each one of these has one output that feeds into the next level of multiplexers so that means you need 38 / 8 = 5 chips on the second level. Each one of those 5 can feed into the on chip A/D multiplexer so you will need 38 + 5 = 43 chips. Doable but not very economic.
As has been pointed out you need to scan those at quite a rate. The thing is that most of the time the sensors will be detecting nothing.
If you used a port expander like the MPC23S17 this has a capability of 16 bits. Each of these bits can cause an output ( called an interrupt output but don't uses it as an interrupt ) to change when any of these bits change. Therefore you only have to look at one bit to in effect scan all 16 bits for a change. This greatly speeds up the process of scanning all the sensors. Only when the interrupt bit has changed do you need to go into the port expander and find out what particular sensors have changed.
You can use 8 of these MPC23S17 on the SPI bus simply giving you 128 sensors. However, it is not too difficult to cascade three banks of these to give you the 300 you want. So that is only 19 chips you are using.
What are your feelings on this solution with the new sensors?
Too slow. Check pg4 (trepeat = 500 ms).
So pulseIn() would need 1/2 sec to take a measurement for each sensor (x 288).
If that were true then it would certainly be far too slow, however, I took 500 ms to be an example value for an input signal to the sensor. I thought it's PWM output would be much faster. I might well be wrong, it's not clear to me. It does say under applications (pg. 1) "Sensor for large format touch panels" - that's what I'm doing, right? Why would they design it to be so slow?
That "ms" unit must be microseconds. 38KHz, 1/38000 = .000263, half that is .000131. They show it as "120 ms".
kadamr:
If that were true then it would certainly be far too slow, however, I took 500 ms to be an example value for an input signal to the sensor. I thought it's PWM output would be much faster. I might well be wrong, it's not clear to me. It does say under applications (pg. 1) "Sensor for large format touch panels" - that's what I'm doing, right? Why would they design it to be so slow?
That "ms" unit must be microseconds. 38KHz, 1/38000 = .000263, half that is .000131. They show it as "120 ms".
I thought the 38 kHz value is about only detecting modulated IR light (at that frequency) incident on the sensor and that the PWM cycle could be at a different speed and they set it to a few 100 ms for whatever reason. Do you think that the 38 kHz is the PWM speed as well (or instead)? I do like the PWM idea over analogue so if it could work that'd be nice.
If that's the case (about the ms = microsecs) I'll email them to verify. In addition to the Vishay TSSP4P38 (which may potentially be designed for this application, see pg. 1) there are a couple of other options besides using IR phototransistors that is. The Adafruit site recommends/sells Vishay TSOP3802 that seem to have a digital 1 or 0 output only. But this one may also be the 'useless for my purpose' variety, see quote:
Grumpy_Mike:
It says:-
IR sensor tuned to 38KHz, perfect for receiving commands from a TV remote control.
True, but useless for what you want. This is because the LEDs need modulation and the sensors only pick up pulses if you send less than 30 or so pulses without a gap.
Is the Adafruit one also just for remotes? Thanks for the info by the way and the port expander idea - I'll definitely look into it.
There is one other option I found. Here is a video showing a Sharp IS471F in an interactive single cell setup, pretty much exactly what I'm aiming for (x288). It can be calibrated for the acrylic surface as well which is ideal. It is really expensive and binary output only however. Does anyone see any issue with this one?
Due to the their really high cost, if I were to buy any I might only make the corner of the screen interactive or something. But if I did have lot's of these - how would the best way to collect their outputs? They are binary output only, right? So no ADCs (not analogue) then - just multiplexing or shift registers (or interrupt port expander if I use lots)?
That "ms" unit must be microseconds. 38KHz, 1/38000 = .000263, half that is .000131. They show it as "120 ms".
They're showing the output signal which was created from the IR led pulse bursts at 38 KHz.
If that were true then it would certainly be far too slow, however, I took 500 ms to be an example value for an input signal to the sensor. I thought it's PWM output would be much faster. I might well be wrong, it's not clear to me. It does say under applications (pg. 1) "Sensor for large format touch panels" - that's what I'm doing, right? Why would they design it to be so slow?
From Fig 10, it looks like the repeat rate would vary from 50 ms to 680 ms (depending on the signal strength due to distance of object from sensor?) Anyways, this varying response is for each sensor and would not be additive if the pulseIn() function is avoided. Once the information is in the Arduino, there would be 288 bits, with each bit changing according to the signal pattern on Page 4. All that's needed is to measure the time duration each bit is low. By using arrays to store the fall times and rise times of each bit, each difference would be the signal strength of each sensor.
My opinion is that this could work if pulseIn() is avoided and a method like "blink without delay" is implemented with arrays of size 288 to store the time information.
My opinion is that this could work if pulseIn() is avoided and a method like "blink without delay" is implemented with arrays of size 288 to store the time information.
My opinion is that this wouldn't work as you are taking far too long to do the conversion just to see if there is something present which most of the time there would not be. Remember the processor also has to control the visible LEDs and the pattern they go in.
My opinion is that this wouldn't work as you are taking far too long to do the conversion just to see if there is something present which most of the time there would not be. Remember the processor also has to control the visible LEDs and the pattern they go in.
I thought the 38 KHz would be the same for all sensors, just one 38 KHz source (constant frequency) and 50% duty cycle. This isn't the same type of sensor that's used for IR communication like TV remotes and garage door openers. The only information it returns is a pulse with varying width, repeating at 50-680 ms.
EDIT: Oops ... you said "visible leds" not IR leds.
MORE: The processor would only have to track the bit timing of 36 bytes. A method something like this could be used to store the sensor status and time/duration information.
Example: This function is manipulating 80 bits (10 bytes). I've timed this function on the Due - 1,000 iterations took 790 us. So the execution time is 0.79 us.
void buttonFilter(void)
{
if (millis() - millisStart >= 2)
{
for (int i = 0; i < qty; i++)
{
buttonState[i] = (buttonState[i] << 1) | digitalRead(buttons[i]); // shift and read
if ((buttonState[i] & B11111) == B01111) // if rising and high for 3 stable reads
{
buttonRead[i] = 1;
}
if ((buttonState[i] & B11111) == B10000) // if falling and low for 3 stable reads
{
buttonRead[i] = 0;
}
}
I guess whatever is decided for a sensor, it would be good to pre-test just a few of them. Even a small 2x2 or 3x3 matrix could be directly connected to the Arduino and evaluated.
My opinion is that this wouldn't work as you are taking far too long to do the conversion just to see if there is something present which most of the time there would not be. Remember the processor also has to control the visible LEDs and the pattern they go in.
I thought the 38 KHz would be the same for all sensors, just one 38 KHz source (constant frequency) and 50% duty cycle. This isn't the same type of sensor that's used for IR communication like TV remotes and garage door openers. The only information it returns is a pulse with varying width, repeating at 50-680 ms.
EDIT: Oops ... you said "visible leds" not IR leds.
MORE:
The processor would only have to track the bit timing of 36 bytes. A method something like this could be used to store the sensor status and time/duration information.
Thanks both for your input. I'll check that method out. I'm being drawn to the Sharp IS471F's after all. That's because, as shown in the video I linked a couple of posts back, it's proven to function for my kind of application, albeit with binary touch only. Given the expense of the components I might opt for only making a corner of the screen interactive such that it could be used as a small controller. This video also uses those components and works really well. As you can see you only need a bit of interaction to play tetris/snake etc.. I would really prefer a fully interactive touch screen but it would cost up to $500 for my display size, which is just crazy (with those components anyway). So I'm now considering using a corner of 3 x 3 pixels for controlling the table. Maybe 9 pixels in each corner for (4 players/persons) but not the entire surface (yet).
In the diagram at the very end of the datasheet (linked above) they use a suitable wavelength IR LED linked to the Sharp IR sensor. The modulation is driven by the sensor and it's also a modulated input so ignores background light. The output is a single bit, I believe. So if I had 9 per corner I need 9 regular IR LEDs, maybe a capacitor, and then a way of collecting the 9 inputs. Firstly, is there any issue with any of that so far? Reaction speed or anything like that...? And secondly, what would be the best way to collect 9 binary outputs, MUXing, shift registers or...?