hello people
I'm new to embedded, so please be patient with me. I want to capture a typical remote controllers IR signal. I'm aware of the different protocols and their decoding process. My question is this, can I NOT decode the signal and just record it using the timer and just playback the stream using the same sampling frequency? Theoretically with regards to Nyquist sampling theory if my timer frequency for sampling is double the max frequency of the desired signal, I can rebuild it. IS THIS correct or am I missing something in the big picture? I am using an AVR ATM32 and sampling with a 25 0khz timer in CTC mode.
Any practical or theoretical help will be appreciated.

 

Why do you want to capture and replay the IR signal?

If you wish to decode the signal you need to know how the data is encoded.

If all you want to do is relay the data stream then you should sample the data at least 16 times the bit rate.

 

Hey MrChips
Thanks for the speedy reply.
As for why am I trying to record the signal, I want to control my TV with a simple Micro.
Currently I'm sampling a 38kHz signal, with a sampling frequency of 250 kHz. That's more than 6 times the carrier frequency, shouldn't that be enough for rebuilding the signal?
Anyhow, I will do as you suggested and increase the sampling freq. As for transmission, will sending the recorded stream with the same sampling timer do the job?

 

I'm guessing you want to build something like one of those "universal remotes " when you put your remote to the device and record the transmission and assign it to a certain button.

 

Well you're going about it the wrong way.
There is no need to record the IR data stream. What you need is a two stage approach.
Firstly, you need to decode the signals from the remote controller for all the required functions.

Once you have the codes written down you can program the microcontroller to emit the IR commands.

I have a blog that shows you how to accomplish the first part.
The second stage is even simpler than the first.

 

Sure you can sample a 38KHz signal at 250KHz and then regenerate it... as long as you later do some more processing. Plus much of that data is just the carrier frequency: the IR comes in discrete packages (bunches) of 38KHz waves and if you have a 38KHz IR receiver (and you absolutely should) then you don't have a 38KHz signal to sample, it is much much lower in frequency.

This signal also repeats so you need to pull the essential part of the signal from the repeat.

Here's a decent tutorial on sampling IR signals for an Arduino. It explains the signal pretty well and has some code to pull the signal from the noise.

I did wish it would have one more picture. Here's the raw IR signal (from their tutorial). It is the 38KHz signal you are asking if you can sample:

The signal is ON/OFF keying, a very simple modulation method. Think Morse code simple. It transmits a wave for a one, and transmits nothing (or no wave) for a zero. The 38KHz is so fast relative to the data rate it looks like solid max to min to max transitions.

When you add in the IR detector the 38KHz gets removed, and all your processor should see in the "envelope" or the actual one's and zero's:

The tutorial should have included a picture like this... THIS is the signal you need to sample.

 

Hey people
Thanks for the quick replies.
MrChips, I understand that the 2 stage approach seems to be the correct road to go for expanding the project, but isn't recording and replaying the stream the easier way to get the job done?
Is there a fundamental flaw in this approach in terms of performance and stability? In the 2 stage approach, we have to take into consideration all the different protocols that exist for remote controllers, like NEC and Philips, while recording seems much easier to accomplish.

 

Do you have the internet? I think you must as you are here. There are scores of pages describing the encoding method and even the actual data patterns associated with lots and lots of controls out there. You should spend some time reading these just to acquaint yourself with the form of the data to capture.

Using a look up table (such as most remotes have) means you have a solid control over how a device maps to your controller, but obviously it is useless when presented with a device not in its data base. I've had (bought, not built) universal remotes that have just such a learn function: you pick a button, start learn mode, show it a code, and it blinks when it has it.

These things can be fun to play with. When getting into LCD displays I made a board that read a controller and displayed (with words) what button you pressed. I got the codes with a digital scope so I could capture the patterns, but a good program in your AVR could do the same.

DO look into those IR sensor such as adafruit uses. They are commonly available, last time I looked even Radio Shack had one for sale.

 

typicalStranger, i understand what youre trying to do, and at first glance, a raw recording of the signal would seem easier, but it really isnt. you need significantly more storage and speed, compared to the decoding/encoding method. there are ir modules that handle the carrier for you completely, so when you watch the input pin, only the relevant data is passed along. theyre very easy to use, and from what i remember, they are not expensive (maybe 3 to 5 times more than a single ir led)

-t

 

I designed an analyser that records the period (length) of each "feature" of the wave, ie; logic high features and logic low features. That takes one byte for each "feature" which with most remotes takes 2 feature bytes per signal bit.

Those 2 bytes per feature are just sent to the PC as serial and displayed on the PC screen. I chose the speed of the micro such that the periods recorded were in actual mS or multiple thereof (I think I chose 100 = 10.0mS) and removed cumulative error on each period so the display on the PC screen can very accurately reflect the actual encoded signal.