Need to imitate an A/C IR remote

Hi everyone,

I'm currently trying to read and then imitate the signal from an A/C IR remote, and I'm having a hard time at it...

I first bought an off-the-shelf module, based on a PIC 16F628. This module just hangs when I try to run the memorize function (I suspect an overflow error).

So I've decided to write a program myself, using a loop that detects states (0s or 1s) and times them using one of the internal timers.

I detect states, but they don't last the same time :

several 1s during 1387 µs.
several 0s during 1470 µs.
several 1s during 1820 µs.
several 0s during 1865 µs.
several 1s during 4648 µs.
several 0s during 4615 µs.

The total message length seems to be larger than 45 bits (my µC RAM could not hold more data).

I've tried sampling bits at fixed frequencies (my first try was one sample every 474 µs) but when I send the sampled signal back to the AC it does not detect it.

I've opened the A/C remote to see if I could get more clues, and what I found is the following:
The circuit is composed of one IC, one IR LED, one crystal (looks like a 32.768 kHz, but nothing's written), a couple of resistances, a capacitor and a transistor (for driving the LED).

The IC (a 52-pin LQFD) is marked:
SBL3103F
RE
609P7002

Any ideas to explore?

Thanks a lot!

You could do with a storage scope to freeze the display, once you've found the required bit pattern, it's easy to recreate it with a PIC.

Many remotes use the Philips RC5 system, which uses Manchester coding - in which one's and zero's are represented by the transistion between states - check my PIC RF tutorial for some details of it. But there are a LOT of different remote control schemes.

@Nigel:
Thanks!
I've already tried with the scope, but the onlmy one I can get my hands onto is an USB pc-scope (picoscope), which is no good as data logger for frequencies above 1 kHz...

Another question: I find that the number of bits transmited is quite enormous, since 45+ bits to transmit only an ON order plus current state of the control -temperature set point between 18 and 25 °C in one °C steps, and mode (three bits more for cold, heat, vent, drying and auto). What is the usual bit length of a command word of an IR remote (in your experience)?

The Sony SIRC's system uses either 12, 25 or 20 bits - but bear in mind if it's Manchester coded that gives the appearance of twice as many bits. Also bear in mind that may be a pre-amble before the actual data bits are sent!.

It can be quite a job decoding remote controls - I know, I've been there!.

At those data rates, you can use your PC as a storage oscilloscope. There are many shareware products. The old Media Player was good enough to give you a general idea; I don't know how the new versions are.

Thanks for your insights!

I will try with one of those programs that let you view the audio in as an oscilloscope.

Of course, what bothers me most regarding this signal, is the fact that there doesn't seem to be a constant time base! The greatest common denominator of the times I've detected seems a bit to small (in the order of 100 µs) to be realistic (it would also mean that that all 1s and 0s are packed together, and no single 1 or 0 is "alone").

Async serial streams don't have a constant time base, unless they're Manchester encoded, IR signals already contain a carrier frequency for noise reduction so Manchester encoding isn't usually used. If you're not removing the carrier frequency you're going to get skewed data like that.
Transmitting specific bit patterns like sending out a "U" character on a PC serial port set to 8n1 will always result in a transition every bit, that would give you a nice signal to monitor but you'd have to find an appropriate button to push based on it's encoding scheme, and since you don't know the encoding scheme..
Post an audio recording (at the highest sampling rate you can manage on your sound card) of the signal line with a decent ground and if not me then someone else should be able to decode it for you.

Sceadwian said:

Async serial streams don't have a constant time base, unless they're Manchester encoded, IR signals already contain a carrier frequency for noise reduction so Manchester encoding isn't usually used. If you're not removing the carrier frequency you're going to get skewed data like that.

Click to expand...

The worlds most common remote system, the Philips RC5, uses Manchester coding - so it's VERY commonly used in IR remote controls. I've no idea what you mean by "IR signals already contain a carrier frequency for noise reduction", it doesn't make much sense?, unless you mean the 38KHz carrier used? - which has nothing to do with any coding.

The reason Manchester is used is basically two fold, first it's an NRZ (Non Return to Zero) system, but most importantly (for IR) there's no constant timebase required (unlike what you said), it's essentially self clocking (if you want) but all you need to do is detect the level changes, the timing doesn't really matter - unlike other methods. This is VERY important for IR, as the timing of the received pulses isn't the same as the transmitted timing - which completely messes up normal asyncronous RS232.

He's using a micro controller to sample the baseband frequency at fixed periods? There's no telling what intermediate frequencies he could be picking up if the signal isn't going through a proper low pass to remove the carrier.

Nigel: Do manchester encoded IR streams often contain a carrier as well? If the OP is using perhaps an IR module to receive and not a simple IR detector the signal received is not going to contain relevent data as the data signal is going to be shunted to ground unless the encoded bit rate is in the modules pass band.

@Sceadwian:

I was using a µcontroller to time the transitions, so I was not sampling at a fixed frequency (which I didn't know, and with a PIC I don't have the memory to sample the signal at a high enough frequency to be sure to cover all the spectrum of possible frequencies for the remote).

Sceadwian said:

He's using a micro controller to sample the baseband frequency at fixed periods? There's no telling what intermediate frequencies he could be picking up if the signal isn't going through a proper low pass to remove the carrier.

Click to expand...

Again, what do you mean by 'carrier', if you mean the 38KHz then it's removed in the IR receiver IC, all you get out is a datastream - no carrier at all.

Nigel: Do manchester encoded IR streams often contain a carrier as well? If the OP is using perhaps an IR module to receive and not a simple IR detector the signal received is not going to contain relevent data as the data signal is going to be shunted to ground unless the encoded bit rate is in the modules pass band.

Click to expand...

My PIC RF tutorial explains Manchester coding - but I don't understand the rest of your sentence?. And you're using 'carrier' in a confusing way again?.

I have just been able to see that the signal is really modulated at 38 kHz, but I still have a hard time decoding the bit stream...

I will post some captures done with an storage oscilloscope I've managed to get a hold on, and using a phototransistor.
(The first three are an off signal at different scales, the last one is an on signal (which is longer).
Is there any simple way to decode this?

To start with, use an IR receiver IC, this outputs just the data, without the unwanted 38KHz carrier - makes it easier to see what's happening.

To try and decode it, try different buttons - in your case it obviously doesn't apply - but how I've always done it is to compare the numeric buttons, One and Two should be very similar. In order to help I've usually drawn the different waveforms on graph paper - it allows you to easily compare them and see the changes.

After analysing the signal without the carrier, what is the easiest way to recreate it? Is there any other way better than bit banging a port on a PIC?

Looking at the captures, it does look like it could be philips RC6.
This web site that gives information on RC6 and some other IR protocols. (To get full details would mean looking through the data sheets of the R/C chip manufacturers).

An experienced person can sometimes tell the type of protocol by listening to the signals from a R/C handset held next to an AM radio (LW if you have it)

Good luck with your project

CheapSlider said:

Looking at the captures, it does look like it could be philips RC6.

Click to expand...

I've done a lot with RC6 (Sky Digital remote), this looks nothing like it - RC6 is just an extended version of RC5.

The encoding method doesn't really matter, all he needs to do is reproduce it, those scope images show the exact bit timeing, it's easy enough to implement on a micro controller. Just use a PWM ouput to generate the 38khz carrier directly on an LED and turn the PWM output on and off using a table to match the recorded signal.

And Nigel the reason I kept mentioning the carrier is because if he was using the photo diode directly on a PIC to sample the signal without removing the carrier the signal he read would be effectivly mixed with the difference in his PIC's sampling frequency and the IR's carrier frequency, at no point did he say he was using an IR module to decode the pulses, so he was probably picking up mixing byproducts from the 38khz carrier the sampling frequency of his pic (he said it was 474usecs which is about 2khz) and the actual data pulses. Basically garbage.

Sceadwian said:

The encoding method doesn't really matter, all he needs to do is reproduce it, those scope images show the exact bit timeing, it's easy enough to implement on a micro controller. Just use a PWM ouput to generate the 38khz carrier directly on an LED and turn the PWM output on and off using a table to match the recorded signal.

Click to expand...

No need to use PWM, it's dead easy (and more accurate) to just do it in software, and means you can send the exact number of cycles you want.

Uses more processor time though, timers are relativly easy to multiplex for more than one task, you can't take back the cycles wasted in delay loops doing it directly in code.

Sceadwian said:

Uses more processor time though, timers are relativly easy to multiplex for more than one task, you can't take back the cycles wasted in delay loops doing it directly in code.

Click to expand...

No, but you've still got to time the output pulses some how!.