Recording IR remote signals — Is this method feasible?

[Alex_Sanders]

Alright, here is what I'm coming up with:

we all know that most IR remote, if not all IR remotes works by the "lights on/lights-off" "principle", be the actual implementation “measuring” interval or space between 2 "ons" (or two offs), or demodulating one consistent on (or off) for a specific period of time as on (or off).

So if I were to record practically any remote in the world, all I got do is have a receiver-diode hooked to a MCU, read the port as frequent as possible, then record exactly when the target remote was switched on and off, so I imagine I can store a "time table" in the MCU and it will be something like:

22H STRT
24H 0015 (ms)
26H 0030 (ms)
...36H END
To be more specific, if there's a rise edge or a fall edge detected, the MCU will record it and store it in the RAM (and finally write back to ROM), if there is none, then no action will be taken, and since I'm measuring as fast as possible, there is just no way an edge will be ignored or missed.

So when I play it back, I just light up and choke off a IR LED with the same on-off sequence.Is this possible?

Also, shall I USE STM32 or MSP430? I want the power consumption to be as low as possible, I'm looking at something like a button cell last at least 6 months.

 

[vk6kro]

Yes, you can do this and it would be an interesting project.

I have a "learning" remote control that will learn the outputs of another remote control and allocate the sequences to various buttons as you choose them.
It is used to replace a dead remote by getting the codes from a borrowed one.

The data on a remote is sent quite slowly, so you could capture it easily.

They use a non-return-to-zero approach where two "highs" in a row are just transmitted as one long "high".

Can't advise you about different micros, though. There is a computer section in this Forum and someone there may have first hand information, if you don't get it here.

 

[Alex_Sanders]

Yes, you can do this and it would be an interesting project.

I have a "learning" remote control that will learn the outputs of another remote control and allocate the sequences to various buttons as you choose them.
It is used to replace a dead remote by getting the codes from a borrowed one.

The data on a remote is sent quite slowly, so you could capture it easily.

They use a non-return-to-zero approach where two "highs" in a row are just transmitted as one long "high".

Can't advise you about different micros, though. There is a computer section in this Forum and someone there may have first hand information, if you don't get it here.

Glad to get that assurance. Thanks.

 

[I_am_learning]

I once tried to do this, but dropped out and did Protocol decoding, because my micro-controller didn't have enough room to store the timings.
So, you better first find out how many buttons you want to store, and what storage space you would need.
You can always use external storage (like external eeprom) but that rips you off from the advantage of using a micro-controller and not micro-processor.

 

[vk6kro]

The output of a remote control is a burst of pulses at 40 KHz for a high and nothing for a low.

The data rate is about 1 KHz or 0.001 seconds of pulses for a "high" or about 40 pulses.

These should be received with a IR receiver module which is a 3 wire device which contains amplifiers, filters and an infra red detector.

This module takes care of a lot of the difficult stuff for you. The output of this device is data which you would take to your processor.

You would start observing for pulses and each time you look at the input, you compare it with the previous reading.
If it is the same, you ignore it, but if it is different, you note whether this was a rising edge or a falling one.
So, you would end up with a series of perhaps 20 pulse edges and when they occurred and you would need to store them in a list.

You could then read these edge lists and reproduce the original data then apply it and a new 40 KHs carrier to an infra red LED.

 

[Alex_Sanders]

You would start observing for pulses and each time you look at the input, you compare it with the previous reading.
If it is the same, you ignore it, but if it is different, you note whether this was a rising edge or a falling one.
So, you would end up with a series of perhaps 20 pulse edges and when they occurred and you would need to store them in a list.

Um, do you have any module in mind that you would recommend? Yes, letting a module do the reading work is most preferable.

I totally missed the quoting part, could you please give some further elaboration? Why do I have to compare anything at all since all I got do is record everything?

Under the same light, why would the rising edge or the falling edge be of any importance here? If the module, assuming I'm using one, detect something and previously detected nothing, then it must be an rising edge, and vice versa for the falling edge? Isn't it that simple?

I think a list of 20 moments really shouldn't be a problem, although I could be very well over simplifying things.


Thanks once again for your help, and boy am I hungry for more of your professional advice.

 

[vk6kro]

To record this type of signal, you have two choices and one will use a lot more memory to store the results than the other.

You could sample the signal 400 000 times a second. This is 10 times the 40 KHz carrier frequency and you need to sample this fast because you have to establish the exact edge of the input pulses.
This would require huge storage and some very fast hardware to store the result while this was happening.

However if you took this signal and fed it to a suitable LED, it would work.

The other way is to use a IR receiver and get rid of the 40 KHz part. You could sample a lot slower, but you still have to find the edges and store only the timing of the edge and whether it was a rising edge or a falling edge. This way, you store only a few bytes instead of a whole lot of bytes that are all the same.
IR receivers are readily available. Just ask at any big electronics store.

This has the disadvantage that you need to reconstruct the original signal with its 40 KHz carrier and do it with just the timing and pulse information. Quite a big job.

Incidentally, I came across this website:
http://www.remotecentral.com/cgi-bin/codes/
which looks like an amazing database of remote control codes.

 

[Alex_Sanders]

To record this type of signal, you have two choices and one will use a lot more memory to store the results than the other.

You could sample the signal 400 000 times a second. This is 10 times the 40 KHz carrier frequency and you need to sample this fast because you have to establish the exact edge of the input pulses.
This would require huge storage and some very fast hardware to store the result while this was happening.

However if you took this signal and fed it to a suitable LED, it would work.

The other way is to use a IR receiver and get rid of the 40 KHz part. You could sample a lot slower, but you still have to find the edges and store only the timing of the edge and whether it was a rising edge or a falling edge. This way, you store only a few bytes instead of a whole lot of bytes that are all the same.
IR receivers are readily available. Just ask at any big electronics store.

This has the disadvantage that you need to reconstruct the original signal with its 40 KHz carrier and do it with just the timing and pulse information. Quite a big job.

Incidentally, I came across this website:
http://www.remotecentral.com/cgi-bin/codes/
which looks like an amazing database of remote control codes.

Yea, my point is, using an readily made module to hook up to a MCU sampling as fast as possible, but record data ONLY WHEN an EDGE is DETECTED, and write down timer intervals between edges.


You are right, it's going to be a real big job.