Working with IR and lenses

I am making a laser tag system with my arduino and I've moved on to the step of sending my IR LED through a lens to focus the light to get more distance and prevent a huge tag radius that would form otherwise.

Some background about my protocol: Every time the gun is shot, I send a unique ID of who is shooting (so that the player who is shot will know who shot him) using SoftwareSerial through a 555 timer chip. The chip is hooked up to create a frequency of 56khz so the IR light will be the right frequency to be sensed by my 56khz IR sensor. To make sure no bit errors are observed, I simply send the UID, currently simply a number between 1-14, twice in the same byte. Eg: for UID 3, the bits sent would be 0011 0011. Then on the receiving end, if the two nibbles are not the same, the byte is ignored and it waits for the next byte.

Anyway, the system works 100% close up and without a lens. The UID being sent by the laser gun is always correctly decoded and there are never any problems. When I introduce using a lens, though, the data transfer only works up to a foot away from the lens with an error rate of around 1 wrong identification in 10, but any farther and the whole transfer goes to hell. At one point about 4 feet from the lens, the data being sent through the beam was 0% correct; it was literally never decoded correctly (for the example UID 3, it detected values 5, 10, 11, and 13 but rarely ever detected the same incorrect value more than a few times in a row).

And yes, these error rates are including my automatic ignoring of bytes whose nibbles are not the same, meaning that at 4 feet away the transfer of data somehow changed from 0011 0011 to 0101 0101 for 5, 1010 1010 for 10, etc.

My main question is this: If my system worked 100% without a lens, why does adding a lens cause such terrible failure rates? Is there something else I should be doing to use a lens?

Errr...what kind of lens? Lenses can either focus light or disperse it. Additionally, some lenses are good at passing infrared light and some lenses heavily attenuate it. It's not just a piece of glass!

-- The Ruggeduino: compatible with Arduino UNO, 24V operation, all I/O's fused and protected

There's also the focal length of the lens to consider - if the focal length is really short, or you don't have it focused properly (how are figuring this out? A good way to make sure of the focus would be to use a visible LED in place of the IR LED)...

What specific IR sensor are you using?

RuggedCircuits: Errr...what kind of lens? Lenses can either focus light or disperse it. Additionally, some lenses are good at passing infrared light and some lenses heavily attenuate it. It's not just a piece of glass!

It's a double convex lens. I don't have any information on whether it works with IR well, but it works with a red LED perfectly.

There's also the focal length of the lens to consider

I have the LED exactly the focal length away from the lens (in this case it is 15 cm), and I did make sure that it was focusing well using a red LED first. I could see the red LED on a white piece of paper in the day time (my windows were closed and lights were off but light from outside still gets in anyway) from 10 feet away.

What specific IR sensor are you using?

The sensor I'm using is the TSOP4856 (Datasheet:

This is odd but it might have something to do with the charastics of the receiver. In place of sending a single byte I would try sending a package, that is send a start byte say 02 then send your data byte, then invert your data byte and send it again. You then have four versions of your tag data, if any three are the same then treat it as valid. Also look up the theory of error correcting codes, you probably need that here.

What baud rate are you using? It might be that you have to slow this down or even speed it up because these receivers are not designed for receiving asynchronous data, it is the DC level that kills them. They are designed for recieving stuff by something like Manchester encoding so you could try that.

I agree with Mike. Don't forget that the serial data you're sending is 8n1 meaning that the signal will be solid high, the start bit will be low, then your data bits (1 high 0 low), and a stop bit which will pull it high. The fact that your signal will be solid high when you're not transmitting is going to anger your IR sensor. The data sheet states that it must see low for at least 12 cycles after every 10 cycles. Also your start bit must be high. Recheck the datasheet for this information. In retrospect you wanted to buy a fixed-gain sensor (TSOP77038, TSOP5038, TSOP4038, or TSOP58038) so that you wouldn't have to work around these requirements in your design.

I think these problems will be most easily solved with a suitable IR/remote control library.

light is attenuated as inverse-square law, so even with a lens the signal strength will very rapidly fall off with distance. If your lens system gives you 100 times the brightness compared to no lens, that’s only a ten-fold increase in range, and then only if the focus and aim are set up just right…

I’d use a red LED for now, so you can see where the light is focussed, and set things up. Then go back to IR diode and you will have to readjust the focus a little due to chromatic aberation.

More sensitivity can be got by adding a lens to the revceiver too.