Problem of using an array of TSSP4038 IR sensors

Hello everyone,

I'm a newbie of using Arduino. I’m finding an Arduino beam break sensor and found TSSP4038. However, my use case is quite tricky and don’t know if it is possible.

Here are the requirements:

  • An array of six TSSP4038 placed closed to each other (distance about 1 cm) and pointed to the same direction (the opposite side is an array of six IR beam emitter). The distance between emitter and sensor is about 1m.
  • Reading signals from the array of TSSP4038 sensors with refresh rate 30 times per second (delay 33 milliseconds each time of signal reading) and the signal log on a PC.
  • Both of emitters and sensors are working at the same time but not working one by one. Since in this case each sensor’s signal reading has to be having high refresh rate, I cannot use the method of triggering them one by one.

Here are my questions:

  • Single Arduino can support this situation? (e.g. Arduino Uno) (If not, would it be too difficult to design the circuit using multiple Arduino and transferring the signals to PC?)
  • TSSP4038 support this refresh rate?
  • Interference would be occurred if the emitters don’t emit straight beam (e.g. LED lights), right? (I see the effective sensor angle of TSSP4038 is about 45 degrees) What if I use some material (e.g. plastic) and fold them as tube to cover the sensors?

It may be too many questions but I really can’t find the solutions. Thank you so much for your patience.

You do realize the TSSP4038 is a IR receiver for 38Khz remote control applications?

.

Seems the TSOP40xx is for remote (intermittend), and the TSSP40xx for beam break (continuous).

You can connect several sensors parallel, because they heve open collector outputs with weak pull up.
Never tried six though.

Refresh rate?
The TSSP has AFAIK a reaction time of about 500us (1/2000 of a second).
Up to you how fast you react to that.

Emitters need to be driven with a continuous 38kHz signal (for a TSSP4038).
Leo..

larryd:
You do realize the TSSP4038 is a IR receiver for 38Khz remote control applications?

.

I think so..., and is it possible to use it as a break beam sensor? I saw this post and I think the use case is similar to mine.

My use case is sensing and transferring the signal to PC if there is a obstacle between emitter and sensor (the straight line between them). Or is there any simpler solution that I can try, instead of using emitter and TSSP4038?

Wawa:
Seems the TSOP40xx is for remote (intermittend), and the TSSP40xx for beam break (continuous).

You can connect several sensors parallel, because they heve open collector outputs with weak pull up.
Never tried six though.

Here comes up with another question... How do I recognise the specific sensor's signal? Since there is no that many signal input ports on Arduino (I guess), I need to build a circuit on a bread board and connect all of the sensors to the Arduino via one signal port.

Wawa:
Refresh rate?
The TSSP has AFAIK a reaction time of about 500us (1/2000 of a second).
Up to you how fast you react to that.

Emitters need to be driven with a continuous 38kHz signal (for a TSSP4038).

So...I think I can deal with the interference problem with triggering emitters one by one, since the reaction time is short enough. But would it be too difficult to control the time of triggering of emitters one by one, saying I'm using IR LED?

Wawa:

const byte IR_LED = 11; // IR transmitter LED with 100ohm (minimum) CL resistor

const byte IR_Receiver = 8; // from receiver output
const byte onboard_LED = 13; // onboard indicator LED
boolean receiverState;

void setup() {
  pinMode (onboard_LED, OUTPUT);
  pinMode (IR_LED, OUTPUT);
  pinMode (IR_Receiver, INPUT);
  // from Nick Gammon
  TCCR2A = _BV (COM2A0) | _BV(WGM21);
  TCCR2B = _BV (CS20);
  OCR2A =  209; // ~209 = ~38kHz | ~219 = ~36kHz
}

void loop() {
  receiverState = digitalRead (IR_Receiver);
  if (receiverState == HIGH) { // beam interrupted
    digitalWrite(onboard_LED, LOW); // green onboard LED off
    delay(1000);
  }
  else { // beam detected
    digitalWrite(onboard_LED, HIGH); // green LED on
  }
}

Back to the post you replied, I see the emission control of IR LED is taking when setup() but not loop(), if I didn't misunderstand the code. Is it possible to handle the emission when looping?

Again, thanks for you guys' patience.

The TSSP40xx expects a continuous 38kHz signal from the IR diodes.
Code is put in void setup(), because it has to be constructed only once (keeps on going).

Not sure why you want to use six IR diodes and six sensors.
One poster here did 120meters with one set.
Leo..

Wawa:
The TSSP40xx expects a continuous 38kHz signal from the IR diodes.
Code is put in void setup(), because it has to be constructed only once (keeps on going).

Not sure why you want to use six IR diodes and six sensors.
One poster here did 120meters with one set.
Leo..

Do you mean someone did the similar thing? Can you post the link?

The reason I want to use six beam break sensors is I need to get the fast and small motion of human precisely. I'm building a computer game that controls with fast and subtle hands movement. I've already coded it using Unity and now I'm starting to look for the sensors and work on it.

I doubt that a beam break sensor is the right sensor for subtle hand movements.
Post a drawing.
Leo..

Wawa:
I doubt that a beam break sensor is the right sensor for subtle hand movements.
Post a drawing.
Leo..

I'm now thinking that my word "subtle" is kind of misleading LOL. Whatever, here is the drawing about the sensors setup.

Assume the black cylinders are the sensors and red beams are the IR from the emitters placed on opposite side, human hand moves up and down and I can get the signal by hand breaking the beams.

And assume that the sensors placed closed enough so the gap between sensors is not a problem.

The pictures I attached below are the same as above, just in case that IMGUR is not working.

Over 25 years ago, Xerox had a machine with a "touch" screen which worked exactly like that. There was a grid of horizontal and vertical beams, and when you "touched" the screen you actually broke one of each horizontal/vertical beams so it knew where your finger was. It was as if you had "touched" an icon on the screen, although your finger didn't really need to touch the screen.

kenwood120s:
Over 25 years ago, Xerox had a machine with a "touch" screen which worked exactly like that. There was a grid of horizontal and vertical beams, and when you "touched" the screen you actually broke one of each horizontal/vertical beams so it knew where your finger was. It was as if you had "touched" an icon on the screen, although your finger didn't really need to touch the screen.

I was also thinking that in earlier times touch screen implemented with beams since this is a straight-forward method to get xy-coordinates of finger.

However, I cannot use the touch screen in this case since it ruins the gaming experience. Or is there anyone who did the array of beam sensors before that I can reference?


Edit:
Let me clarify why I use this old school way. There are many devices like Kinect or Leap Motion that have full API support to do this, speaking of sensing hand's y-coordinate in the middle air, but in this case what I need is a low and stable latency of sensing and transferring signal, on the scale of millisecond, because it is a fast-paced game. I experienced a game based on Leap Motion (not published yet, created by an indie game creator) and the latency and unstable of sensing motion affects the gaming experience. Of course, it might be because of the programmer's skill but what it means that I will have to take very much effort on optimisation on sensing motion. And what I believe is this approach (an array of sensors) would be stable enough due to low computation.
One more approach I gave up is connecting a camera and scanning the pixels colour difference between background(preset) and captured. However, this might be high computation demand and I prefer to reserve the computation on the game.

Problem is that IR LEDs are not producing a "laser beam" like in the picture, but light in a cone shape.
This could only work if you matrix them (turn one set on at the time).
Leo..

On the subject of the IR leds, I may have missed it, but how is OP producing the 38kHz carrier?

Wawa:
Problem is that IR LEDs are not producing a "laser beam" like in the picture, but light in a cone shape.
This could only work if you matrix them (turn one set on at the time).
Leo..

Do you mean turn on one LED and only read the signal from sensor placed at the same level of the LED at the time?

This may be a solution but you said the continuous 38kHz signal from the IR diodes can be constructed only once at setup(), right? (Or I just misunderstood what you mean?) (Therefore, I can't turn on them one by one..., right?)

Wawa:
The TSSP40xx expects a continuous 38kHz signal from the IR diodes.
Code is put in void setup(), because it has to be constructed only once (keeps on going).

squaresun:
Do you mean turn on one LED and only read the signal from sensor placed at the same level of the LED at the time?

This may be a solution but you said the continuous 38kHz signal from the IR diodes can be constructed only once at setup(), right? (Or I just misunderstood what you mean?) (Therefore, I can't turn on them one by one..., right?)

Yes.

"Code is put in void setup()..."
Didn't say it has to be.

Never done this, but it seems you have to generate an 38kHz signal on one output pin (for one IR LED).
And read the matching sensor after the sensor has stabilised (4ms?).
Then turn the LED off, and move to the next pair.

For this setup (intermittend signals) you can use the more common TSOP40xx sensor.
See datasheet for timings.
Leo..

Wawa:
Yes.

"Code is put in void setup()..."
Didn't say it has to be.

Never done this, but it seems you have to generate an 38kHz signal on one output pin (for one IR LED).
And read the matching sensor after the sensor has stabilised (4ms?).
Then turn the LED off, and move to the next pair.

For this setup (intermittend signals) you can use the more common TSOP40xx sensor.
See datasheet for timings.
Leo..

So I should look for an Arduino which has at least six output pin since each LED should connect to one output pin?
How about the sensors, each of them should connect to one pin of Arduino and also six pin is needed, right?

kenwood120s:
On the subject of the IR leds, I may have missed it, but how is OP producing the 38kHz carrier?

Oh ok nvm I saw it's some Nick Gammon voodoo in setup.

I'm wondering why you're using a carrier at all: what's wrong with an ir led which is just solid on when it's unbroken, sensed by a simple photodiode?

That said, and given you're thinking carrier already, would it be worth exploring modulating the 6 outputs uniquely so that each sensor is only reacting to its own transmitter. Then they can all be on all the time. (That's an off the top of my head thought. It won't be difficult to modulate the signal, but I'm not sure how big a deal it will be to demodulate it at the receiver.)

kenwood120s:
I'm wondering why you're using a carrier at all: what's wrong with an ir led which is just solid on when it's unbroken, sensed by a simple photodiode?

Actually I've never thought about that. So what you mean is when I triggering them one by one then sensed by a simple photodiode would work. Did I get it right?

kenwood120s:
That said, and given you're thinking carrier already, would it be worth exploring modulating the 6 outputs uniquely so that each sensor is only reacting to its own transmitter. Then they can all be on all the time. (That's an off the top of my head thought. It won't be difficult to modulate the signal, but I'm not sure how big a deal it will be to demodulate it at the receiver.)

It seems quite tricky but I will try to look into it. Also, is it work with photodiode? Anyway, thanks for the reply.

Well I've used a simple on/off ir led read by a simple ir photo diode, with no carrier required, as a break beam a couple of times with no problem.

More than that I can't say, I'm afraid.

squaresun:
So I should look for an Arduino which has at least six output pin since each LED should connect to one output pin?
How about the sensors, each of them should connect to one pin of Arduino and also six pin is needed, right?

Yes, but most Arduinos have more tha 12 pins available.

Try to get one set working first.
The tone command could be ok for testing.
Leo..

kenwood120s:
I'm wondering why you're using a carrier at all: what's wrong with an ir led which is just solid on when it's unbroken, sensed by a simple photodiode?

Ambient light could be a big problem with a 1meter gate.
Modulated IR receivers ignore static natural light and mains frequency modulated light.

kenwood120s:
It won't be difficult to modulate the signal, but I'm not sure how big a deal it will be to demodulate it at the receiver.)

3-pin IR receivers are so much more than a photo diode.
diode>amplifier>agc>demodulator>driver>voltage regulator, all in one.
Leo..