IR Remote Control Issues

[Kamikaze47]

Ok, I just tried it with a 10 ohm resistor, so 340mA through the LED. It only seems to have made a very small difference to the range, and I still have to point the LED *directly* at the TV for it to work - Even a few degrees make a difference.

I will try playing with the frequency again.

Also, do you think 50% duty cycle is the best bet? I wasn't sure what to use, and 50% seemed logical, but now i'm considering a lower duty cycle as that means the LED should theoretically be able to handler a higher peak current.

*edit* My TV is a Samsung LA40R71BDX

*edit2* Fixed mistake in schematic (thanks keithdoxey)

[Jumper]

http://www.sbprojects.com/knowledge/ir/nec.htm

Someone said Samsung uses NEC code 38 kHz with a dutycycle around 0.25 to 0.33

HOW IS YOUR TIMING?

Increasing IR current that much would have made a difference if that was the true problem.

Do you have a scope so you can meassure the output of the TV remote control LED? (and if you have a nice digital one you might even post the pic)


/me

[Kamikaze47]

I dont have scope unfortunately. So what I did was hook up an IR receiver to a PIC, and had it sample it every 10uS and output it to my PC which I then put into excel and made a graph. The pic attached has the signal from my TV's remote at the top, and the signal from my home made remote below. The scale on the bottom is in 10's of uS.

As you can see, the timing is pretty close. I would have thought if it was a timing issue, it simply wouldn't work at all instead of bad range?

I'm going to try 38khz at 25% and see how that goes.

[dhouston]

Samsung uses 38kHz and sends a 32-bit code similar to the NEC protocol but with a shorter lead-in pulse and with the bits interpreted differently. Samsung uses a 4.5mS start pulse followed by a 4.5mS space. Your example appears to be for the "1" key.

[Kamikaze47]

Samsung uses 38kHz and sends a 32-bit code similar to the NEC protocol but with a shorter lead-in pulse and with the bits interpreted differently. Samsung uses a 4.5mS start pulse followed by a 4.5mS space.

Sounds exactly like what i've observed. Do you know of a page on the net somewhere that has more detailed info on the protocol they used? I havn't been able to find any info on it.

[Jumper]

When you PIC-scoped the remote what receiver did you use? What is the range and sensitivity using the standard tv remote control and this receiver?

Then we can get an idea of the FQ used. If you have good distance with the remote then it must be your LED that has a major output power problem. It might be burnt due to over current along the evolution chain.

Have you tried to move one thansistor to the base of the other, so you do all the mixing on the base.

Maybe just loose both transistors and sink current with the PIC and make a software mixer by turning on and off HPWM (and connect the led there with a resistor)

what partnumber is the led?
what part number is the receiver you have used?

/me

[dhouston]

Sounds exactly like what i've observed. Do you know of a page on the net somewhere that has more detailed info on the protocol they used? I havn't been able to find any info on it.

I don't recall seeing any detailed description. There is a simple description at http://www.techdesign.be/projects/011/011_waves.htm and there are CCF codes on RemoteCentral.com and at http://ir.premisesystems.com/. There are a few detailed descriptions of the NEC protocol. It was the first and was copied with minor changes by many others. Here's a datasheet for an early NEC encoder chip - http://davehouston.net/Nec6121.pdf

EDIT: BTW, I find it easier to record the codes as .wav files using a soundcard. This way you can use a wave editor to view them. See http://davehouston.net/learn.htm

OTOH, if you sample with a PIC using a phototransistor, you can get the carrier frequency and eliminate any guesswork.

[ardhuru]

Hi,

This technique should help you get a substantial improvement; instead of gating the LED using HPWM and a data pin, use the data pattern to control the HPWM pin itself (keep the HPWM running all the time, and just turn the HPWM pin to an input wherever you dont want a transmission); Darrel had suggested this during an earlier post pertaining to X10 transmission and it worked like a charm.

If nothing else, it would at least eliminate the drop across one transistor, and you would save a pin as well. You would also find the waveform far more consistent with the original remote.

Regards,

Anand

[Kamikaze47]

Ok, here's what i've done since the description in my original post:

- Changed the LED's resistor to 10 ohm
- Removed one transistor, turning on and off PWM to control the LED
- Changed the frequency to 38kHz
- Changed the duty cycle to 25%
- Improved the timing using TMR0 for timing instead of PAUSEUS

The end result is an improvement, but not spectacular. The range is improved, however I still need to point the LED pretty much directly at the TV for it to work - Whereas i can point my normal TV remote anywhere in the room and it will work (even pointing directly away from the TV).

Perhaps I need some kind of diffusing material in front of the LED? I'm not sure what to use tho. Or maybe I need to get an LED with a better viweing angle, but i'm not sure that this is the case, unless my tv's remote has a 360 degree viewing angle - lol. I assume that my tvs remote is simply powerful enough to bounce off the walls and eventually find its way to the tv no matter what direction i point it.

[ardhuru]

Ok, I just tried it with a 10 ohm resistor, so 340mA through the LED.

Just realised; if my math is right, you are *not* getting 340 mA thru' the LED with a 4.7K bias resistor; I would reduce that to 1 K; at the most 2.2 K.

Regards,

Anand