0
\$\begingroup\$

I'm trying to build a device that is able to learn the code sent from an IR Remote when a button is pushed and that is able to subsequently recognize it when received. I need my device to be compatible with all TV Remotes, so that is able to save and recognize a code independently from the protocol used by the remote.

In my opinion, since I need to recognize only one sequence, the better choice is to analyse the raw signal without decoding it the protocol. In this way I don't need to program the uC to recognize different types of protocols and it will works with every remotes, and those that use uncommon protocols.

My idea is this:

When the device need to be "programmed" it starts to sample to IR Receiver output signal every X time until the signal return to idle. These samples are saved in the uC memory.

When the device is normally working, if an event occurs (the receiver output goes low or high), the uC starts to sample the received signal and compare it to the reference signal, previously saved.

It this method good or is there a better way to do this?

If this is the better choice, what could be a good sample frequency (considering the difference between the protocols and that they works at different frequencies like 36 kHz and 38 kHz)?

\$\endgroup\$
1

1 Answer 1

1
\$\begingroup\$

Your idea is potentially feasible but there are some issues to overcome.

1) The typical IR receiver module will strip out the 36/38/40 KHz carrier frequency from the detected IR transmission and present the decoded envelope waveform at its output. IR receivers are typically optimized for detections at a particular carrier frequency and so it may be necessary to make your device with multiple IR receivers for the carrier frequencies that you would like to support.

2) One reason to understand the actual protocol used by a particular IR remote device is to allow the detecting device to apply bigger margins to the detection pulse width windows. Without the protocol known the margins on pulse width detection have to be tight enough to match the worst case narrowest pulses (and highest pulse rates) of the set if remotes and protocols that you would plan to support.

3) There can be significant differences between the detected timing of pulse widths between "learn mode" and actual "use mode". This occurs because in the learn mode the transmitter remote is typically much closer to your device than in the usage mode. Pulse widths of the detected waveforms can be distorted at the receiver during normal usage scenarios due to multi-path conditions, reflections and ambient lighting conditions. These factors can make repeated reliable detection a challenge.

4) The variation of the carrier frequencies used by different remotes could lead you to using a design where you did not use a typical demodulating IR receiver but instead use a photo diode to detect the IR. In this mode you would get the actual signal transmitted by the remote and could be insulated from the carrier frequencies of assorted remotes.

5) Detecting at the raw carrier level can lead to some difficulty of determining a reliable starting point of a transmission. Most "protocols", after demodulation, have pulses that can be detected to identify as a start or sync pulse.

Hope this information is helpful for you in considering your path ahead.

\$\endgroup\$
3
  • \$\begingroup\$ Thank you, your answer has been very useful. I'll try to use protocols since use the raw signal isn't so easy as initially seem. Unfortunately reach the full compatibility with all remotes will be very difficult. I will focus on the most common protocols. \$\endgroup\$
    – Oceanic815
    Commented Oct 6, 2013 at 18:42
  • \$\begingroup\$ Addtionaly, RC5 has a 'toggle bit' that is toggled each time the button is pressed. Hence 'store and compare' would work only half the times :( \$\endgroup\$ Commented Oct 6, 2013 at 19:19
  • \$\begingroup\$ So my idea is definitely not very good, thank you. \$\endgroup\$
    – Oceanic815
    Commented Oct 7, 2013 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.