IR Remote Controls - How They Work

[Jon Wilder]

Hi all. I'm going to be working with a IR projector screen controller soon. The controller uses a PICmicro and I plan to write new firmware with a different IR code set to allow for a universal remote control to control it.

When the remote sends a signal, does it send it as 1 = IR emitter on / 0 = IR emitter off? Or does the emitter flash a carrier signal and 1 = carrier on / 0 = carrier off?

 

[Nigel Goodwin]

Hi all. I'm going to be working with a IR projector screen controller soon. The controller uses a PICmicro and I plan to write new firmware with a different IR code set to allow for a universal remote control to control it.

When the remote sends a signal, does it send it as 1 = IR emitter on / 0 = IR emitter off? Or does the emitter flash a carrier signal and 1 = carrier on / 0 = carrier off?

Neither - there are numerous schemes used, my PIC tutorials cover the Sony SIRC's one, which is nice and easy to receive (all are easy to transmit).

The problem is the received pulse widths are almost always nothing like the transmitted ones, they can be either narrower or wider, and can change with signal strength etc. so the scheme used needs to take account of that.

 

[Jon Wilder]

In reading your tutorial, this is what I'm gathering -

The transmitter sends bits by varying the "on" time of its IR emitter. An on time of 2.4mS is a start bit, an on time of 1.2mS is a 1 while an on time of 0.6mS is a 0, with a 0.6mS separation time between bits.

Do I have this correct?

In regards to the 0.6mS separation between bits...is this 0.6mS measured from the fall time of the previous bit to the rise time of the next bit?

Also...is there a stop bit? Is the "mark" state high or low?

 

[Nigel Goodwin]

In reading your tutorial, this is what I'm gathering -

The transmitter sends bits by varying the "on" time of its IR emitter. An on time of 2.4mS is a start bit, an on time of 1.2mS is a 1 while an on time of 0.6mS is a 0, with a 0.6mS separation time between bits.

Do I have this correct?

In regards to the 0.6mS separation between bits...is this 0.6mS measured from the fall time of the previous bit to the rise time of the next bit?

Also...is there a stop bit? Is the "mark" state high or low?

No stop bit, one isn't required - and yes the 0.6mS is the time between 'blocks of pulses' on transmit, and (roughly) between the decoded output pulses from the receiver IC (which is active LOW).

 

[Jon Wilder]

OK so I was partially right. The emitter pulses a square wave carrier in the frequency range of around 38kHz, and this carrier is transmitted for 2.4mS for a start bit, 1.2mS for a logic 1 and 0.6mS for a logic 0 with a 0.6mS break between each bit. If I were to build a transmitter, this would be simple enough to do where I could generate the data signal, then use this signal to modulate the carrier via NAND hardware gating.

From what I'm reading, IR detectors such as the TSOP1738 are supposed to decode this and output the bit stream on their "data" leg but inverted?

 

[Jon Wilder]

For an IR transmitter with a 38kHz carrier using a 16MHz crystal, I was able to generate the 38kHz carrier using a CCP module using the following values -

PR2 = 104 (0x68)
T2CON = 0b00000100 (0x04)
CCP1CON = 0b00011100 (0x1C)
CCPR1L = 53 (0x35)

This gave me a carrier frequency of 38.1kHz with a perfect 50% duty cycle.

Are IR detectors all that picky about the accuracy of the carrier frequency? Example, a TSOP1738 looks for a carrier frequency of 38kHz. If I transmit 38.1kHz during my bursts, is it not going to detect it? Or is there a tolerance factor of a few hundred hz or so?

 

[Jon Wilder]

Figure this should work for an IR transmitter carrier modulator -

 

[Nigel Goodwin]

Why are you making such hard work of this?

Hardware and software are covered in my tutorial - there's no reason whatsoever to want to use CCP hardware, or an external Nand gate - do as I did, simple software loops and the pulse width timing done by the number of pulses sent (this gives nice exact output pulses). There's also no need to have 50% duty cycle, it's normal to have a low duty cycle to save power.

The TSOP's aren't at all fussy, tolerance isn't a 'few hundred Hz' - it's a LOT more than that, 36KHz, 38KHz, 40KHz - all seem to work just as well, there's going to be a drop in range if you're off centre frequency, but it doesn't seem to be of any consequence.

I couldn't even tell you what frequencies the many TSOP's I've used even are.

 

[Jon Wilder]

Like this Nigel? I just coded up some test code to send a start bit, followed by 01001 sent LSB first (just an arbitrary byte value of no significance to test my code). Yes I used a PWM module to generate the carrier, and timer 1 to time the pulse width.

Why? Just to do it that way. There's more than one way to skin a cat after all and I wanted to do it in a way that I thought up rather than copy/paste someone else's code (which seems to be the thing to do nowadays). I didn't use hardware gating though. I simply switched off the PWM module, then immediately wrote a 0 to the output pin. Another way it could be done would be to tie a 10K resistor from the pin to Vss, then tristate the pin. But no real benefit or code savings to that approach.

I scrolled the cursor on the scope to check the pulse width timing and everything came out to be right...2.4mS start bit, 0.6mS bit separation, 0.6mS for logic 0 and 1.2mS for logic 1.

Another question I have...the emitter is fed bursts of a 38kHz carrier wave, but I've never known an LED to respond that fast due to them having hysteresis. How exactly can it flash at the carrier frequency? Or are IR LED's just a whole different animal as compared to visual LED's? Or can all LED's flash at that rate but the flash just isn't visible to the human eye?

 

[granddad]

You may be interested in my ir remote solution.... https://www.electro-tech-online.com/articles/ir-remote-as-mcu-input.736/

 

[killivolt]

I think their not visible to the naked eye. However, you should be able to see the flashing with a video camera. Maybe even your phones camera - I test IR diodes that way on our systems.

kv

Edit: But, I have never tried using my camera on my phone.

 

[be80be]

The phone works great use mine to test remotes with all the time.

 

[Colin]

My PIC program learns the code from any IR Tx

 

[Jon Wilder]

I think their not visible to the naked eye. However, you should be able to see the flashing with a video camera. Maybe even your phones camera - I test IR diodes that way on our systems.

kv

Edit: But, I have never tried using my camera on my phone.

On some LED IR emitters you can see the flashing. But those flash at the frequency that the carrier is being switched on & off (the data stream frequency), not at the carrier frequency itself.