IR transmission reliability

I've been playing around with an IR transmission system - basic pulsed LED to Panasonic detector module, with variable-length modulation pulses [250-900 usec on a 56.9khz carrier] - and I notice as you move the beams around/etc, that the received puslewidths tend to be somewhat susceptible to signal strength and beam angle.

So, I was wondering about how they get super reliable operation with TV remotes. Mine seems to not work at all [too far away, bounce off reflected surface, etc] or it gives the correct code every time. I know that some remotes use same-width pulse bursts with phase-modulation, while others use simple constant-period RZ codes with presence or absence of a pulse signalling 0 or 1, eg ...1.1.1...1.1...1.., etc.

This, plus my measures cited above, indicate that relative timing between pulses may be a more reliable measure than the width of the received pulses, given variations in intensity/distance/angle/etc.

Anyone know how to get the best reliability out of these things?

thanks for any help,

- dan michaels

formatting link
============================

Reply to
dan michaels
Loading thread data ...

Ok, that's a pretty high carrier frequency as IR carriers generally go, but as long as it matches the receiver your using it should be fine. When I was tinkering with IR (about a year ago, so bear with me ;-) I noticed the same thing. When viewed with a scope, the pulse widths would vary as you waved the remote around.

I think they obtain good performance by using pulse width variation so wide that it's impossible to not "see" the difference between a wide pulse and a narrow one, even with the variations caused by reflections, movement etc. Using a Sony remote for example, signals start off with a

4T duration 50% duty cycle pulse train that sets the agc circuitry in the receiver. Then there is usually a pause that is 1T uS duration. Then the pulse train is based of pulses that are high (actually low when coming from inverting receiver) for either 1T (for logical 0) or 2T (for logical 1) followed by a 1T low. T is approximately 550 uS.

I don't really "know", but I have some ideas. ;-) I think the AGC is important, so keep your transmissions short. I hear that many receivers have problems with long transmissions. They just kinda run out of steam without some recovery time.

In my tinkerings, I used the capture module to measure the pulse width with Timer1. When a capture occured, the ISR would look at the width measurement (CCPR1H) and fuzzily assign it the identity of 1 or 0 bit. A Timer1 overflow was used to catch timeouts and reset the state machine in hopes of resyncing. It works for me. ;-)

michael

Reply to
Anthony Fremont

The other poster mentioned it, but I'll reinforce it: many folks who have trouble with this make the mistake of using a constant carrier. There must be a "quiet" time between bursts, or else the AGC in the module will go so low that even a normal signal will be ignored. The datasheets usually cite 600 us (or less) on, 600 us off.

The age-old IRPD circuit floating around the Web incorporates this flaw, but in a subtle way. The circuit toggles the carrier between two LEDs. The ideal situation would be for the object to be on the right or left only, so the receiver only sees the properly "chopped" signal. But if the object is right in front, the receiver effectively gets a continuous carrier, because it's reflecting light from both LEDs. The sensitivity of the detector then goes down, and people wonder why.

If you are indeed chopping the carrier into

Reply to
Gordon McComb

Hi Gordon and Tony, and thanks for the responses. First off, 56900 khz is one of the standard IR module frequencies, so I picked it becuase it's far away from 40 khz, which is what most people seem to use.

Reading the datasheets on the IR modules does indicate min+max values on the pulsewidths - which I assume is realted to the AGC circuit action - as you both indicated. I think my pulsewidths + trains are all more or less within the correct range.

My current signal is a 2 msec header pulse, followed by up to 5 shorter on-off followon pulses, with the train repeated every 32-50 msec or so. I gave up on the PWM idea after noting how much variation you get in received pulsewidths.

Currently I am using patterns as follows [imagine each 1 or . = 500 usec long] - the remote for my JVC TV uses something like this, although it never seems to have long spaces in the pulsetrain.

1111...1.1.1.1.1 (repeat after 32-50 msec) 1111...1........ 1111.....1...... 1111.......1.... 1111.........1.. 1111...........1 (6)

or various combinations of same, eg

1111...1...1.1.. 1111.....1.....1 etc

Do you think there will be any AGC problems with something like pattern (6), with a long space between header [1111..] and the data [.........1]?

thanks,

- dan =================

Reply to
dan michaels

That's understandable. ;-)

That may be, but I also think that this has to do with the detector portion of the module and what it wants to see.

If I understand, you are not sending any IR signal during the 0 portions of your data. Is that correct? If so: I think you may wish to send your data in some kind of code whereby there is a balanced stream of 1's and 0's. You could use a Manchester code for all the data you send that way you don't send long trains of the same thing. Anything to keep your data close to a 50% duty cycle will help.

michael brown (remember me?)

Reply to
Anthony Fremont

Yeah, for what I wanted to do, I needed the long spaces in there, but I'm looking over the various other coding schemes, like Sony uses:

formatting link

[yeah right, michael - big guy from texas with a beard and a harley - still got the harley after the mishap?]
Reply to
dan michaels

I've got a little doo-dad I threw together that reads a Sony remote and displays the temperature from the selected Dallas 1-wire temp sensor onto a Hitachi based LCD display. The Sony code was easy to decode using TMR0 and CCP module interrupts to measure the pulse width in a

16F628. As long as you build in a little fudge factor for the pulse widths it works quite reliably. You should be able to shorten up the pulses to match your carrier frequency. YMMV

Here's a couple of links:

formatting link
I can't seem to find one of the sites that I used back then that contained alot of nice info. :-(

RC-5 is a common protocol, but damned if I can figure out a good, easy way to decode it. Of course sending it is a breeze.

You don't think I'd let a little thing like that slow me down, now do you? ;-) The bike wasn't hurt that bad, it's fine now and fast as ever. When are you coming back to the piclist?

michael brown

Reply to
Anthony Fremont

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.