1
\$\begingroup\$

If I can just call on you again to help me advance in a project.

My infrared beam breaker circuit is lacking in range. I would need it to be able to bridge a doorway, so about a meter.

On the receiver side, I am using TSOP1236, which can be triggered by my TV's remote control from across the room. The problem thus lies with the transmitter.

This is the exact schematic that I followed (one modification: using a 9V battery with a LM7805 voltage regulator):

enter image description here

I'm using this exact IR LED.

The 555 timer works in astable mode. The output frequency of this circuit is about 35.2KHz. Currently the range is a couple of centimetres.

Could anyone point me in the right direction to increase the range? Will bringing the output frequency closer to 36KHz do the trick, and provide for a range of about one meter? If so, could you tell me what capacitor and two resistors I would need for that?

Reading this forum and others, something tells me I should connect the output of NE555 to the base of a BC 547 transistor which would act as an amplifier. Maybe this schematic is the way to go? Maybe it is overkill.

Very curious about your replies.

\$\endgroup\$
  • \$\begingroup\$ Your LED is designed to be operated at 20mA with a maximum current of 50mA. A common LM555 can source or sink much more than that so adding a transistor won't help. In fact, your circuit could drive much more than 50mA through the LED so you may have damaged it. \$\endgroup\$ – Elliot Alderson Mar 12 at 15:12
  • \$\begingroup\$ Please add a link to the manufacturer's datasheet for the receiver. \$\endgroup\$ – Elliot Alderson Mar 12 at 15:13
  • \$\begingroup\$ Thank you, @ElliotAlderson. I figured a ((5-1,5)/20) ≈ 180 ohm resistor might do the trick. Would you agree? \$\endgroup\$ – Nils Deschrijver Mar 16 at 19:31
  • 1
    \$\begingroup\$ 180 ohms sounds reasonable for operation at 5V. \$\endgroup\$ – Elliot Alderson Mar 17 at 0:49
1
\$\begingroup\$

There are a number of things which are problematic here, starting with the fact that your circuit is missing a critical function.

Your receiver is, like most, designed to detect bursts of the carrier frequency, and not its constant presence. It is designed to receive data and a steady signal doesn't carry much information - instead, the data is encoded in the coming and going of the signal, so it includes an Automatic Gain Control which will cause it to largely ignore something that is always there.

To make this work, you need a second pulser which enables and disables the first to produce bursts

You could do that with a 556 or another 555, but a 555 type solution is already an atypical choice for this. If you are going to keep that, you'll need to tune the carrier timing loop to the center of the receiver's sensitivity. And running it off a 9v battery with a linear regulator is a good way to rapidly drain that battery.

Typical implementations would instead use either a special function ship, or more commonly a small inexpensive microcontroller - the ATTiny85 is an example of one commonly used in hobby IR remote transmitters (you might start with an Arduino and work down, also see the tv-b-gone project). It's also possible there are off the shelf remotes that would transmit (their burst pattern) endlessly if you solder bridge one of their button contacts - though make sure they'll do this if batteries are put in with the button already pressed before you modify one, and you might consider adding resistance to the LED circuit to lower the drive level.

As noted you also appear to be overdriving the LED by using too small a resistor. While long range remotes do often use a transistor to amplify, for the kind of range you are talking about the output of all but the weakest MCU GPIO pins would be sufficient.

Another piece of the system you will need is something in the receive that can stretch the pulsed output the receiver will produces from a burst signal into a continuous one. This can be done with things like a time continuously reset by received pulses, which will timer out and declare an alarm if they miss. But again, it's more common to do this with an MCU where you can write rules.

And MCU->MCU implementation also lets you send and look for a unique digital code, if that would be helpful to avoiding mutual interference from systems installed on other doorways that might reflect into the wrong receiver.

\$\endgroup\$
  • \$\begingroup\$ Out of curiosity; can't this be solved by using a TSOP that supports continuous 36 kHz signals, like the TSOP4038 can receive continuous signals or bursts for 38 kHz? \$\endgroup\$ – Nils Deschrijver Mar 16 at 19:22
  • \$\begingroup\$ @NilsDeschrijver if have such a part and are correctly assessing its behavior, sure, but they are relatively uncommon, especially when someone buys a part (perhaps from a hobby source) by vague description rather than from a large supplier with a diverse catalog after extensive study of a data sheet. \$\endgroup\$ – Chris Stratton Mar 16 at 19:23
  • \$\begingroup\$ First of all, Chris, I wanted to thank you for your extensive reply. I believe I found the solution. I used Arduino ISP to program an ATTiny13 to drive two IR LEDs using this source code: tinyurl.com/y5fseqbe. I have 2 questions, if I may. 1) PB0 works, but PB1 doesn't. Possibly because 'setting the COM0A0 bits to one allows the OC0A pin to toggle on Compare Matches if the WGM02 bit is set. This option is not available for the OC0B pin' (datasheet ATTiny13). Would this be solved by using ATTiny85 or is the code wrong (also)? \$\endgroup\$ – Nils Deschrijver Mar 16 at 19:45
  • \$\begingroup\$ That is an entirely different question which would need to be separately posted with enough comprehensive information to be answerable without relying on external links. Also be sure to explain why you need two distinct outputs. \$\endgroup\$ – Chris Stratton Mar 16 at 19:47
  • \$\begingroup\$ And, finally, 2) about modifying the receiver. The working IR LED now makes the receiver's output, a regular LED, blink (testing set-up). I described my project and code on forum.arduino.cc/index.php?topic=602313.0. Referring to 'stretching the pulse'; I understand I now need to rewrite that code to not define a beam break as a lack of a continuous signal but as a lack of a burst when expected? If so, and because my IR LEDs/receivers are 3 centimetres apart, shouldn't my bursts be quicker by using a shorter delay() for instance? A person walks through those beams very quickly. \$\endgroup\$ – Nils Deschrijver Mar 16 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.