Universal IR receiver

[Frank B]

EDIT:

This is now available as library at GitHub
[Link]

The following Teensy 3 Pins are usable:

 IR_PIN  3 // FTM1_CH0
 IR_PIN  4 // FTM1_CH1
 IR_PIN  5 // FTM0_CH7
 IR_PIN  6 // FTM0_CH4
 IR_PIN  9 // FTM0_CH2
 IR_PIN 10 // FTM0_CH3
 IR_PIN 16 // FTM1_CH0
 IR_PIN 17 // FTM1_CH1
 IR_PIN 20 // FTM0_CH5
 IR_PIN 21 // FTM0_CH6
 IR_PIN 22 // FTM0_CH0
 IR_PIN 23 // FTM0_CH1
 IR_PIN 24 // FTM0_CH2
 IR_PIN 25 // FTM2_CH1
 IR_PIN 32 // FTM2_CH0
 IR_PIN 33 // FTM0_CH1

It chooses the correct timer & channel automatically.
Clock Source is FLL, so the lib is independend of F_CPU.

--------------------------------------------------
Hi,

more than 4 years ago, i published in a german forum (mikrocontroller.net) bit of source for an universal IR-receiver. The original code was for STM32.
This version is for Tennsy 3.

Theoretically it can handle almost any protocol.
The idea is to ignore the protocol, and instead to measure only the cycles. These are stored in a table, normalized, and processed with a 32-bit hash.

The "output" is this 32-Bit hash-value, so every key on your remote(s) has its own 32-Bit value.

Advantages over "normal" algorithms:
- Only at the end of the last bit a bit is calculated, so the CPU-usage is minimal. The interrupt (pin-change) uses the lowest priority.
- It works without change for almost every remote control, the manufacturer of the remote does not matter. Every family member can use his onw remote control
- very short code.

Mostly I've used a "Sony" remote control (for a DIY-webradio) with an TSOP1136 as receiver-ic.

 

[onehorse]

Hi Frank,

This looks very interesting. My son and I used a Sparkfun IR remote to control his RedBot. The code we got with it seemed to be specific to a certain IR encoding standard. I like the idea of an IR interpreter independent of any manufacturers standard. Also, the way we were using the remote was by polling for a new key press, which is inefficient, especially on our RedBot where there are a lot of other sensors and other (motor) control signals. Nice use of the interrupt, which is a cleaner solution. The code we have uses only one byte codes; the IR remote we were using only has 8 buttons. With 32 bits one can get mighty fancy control over a device!

 

[MichaelMeissner]

I agree with onehorse, it looks interesting. Every so often, I think about adding IR to my projects (probably with the IRemote library, possibly with the SIS-2/SIS-8 chips). Something that works via interrupts instead of polling would be useful.

 

[Frank B]

A downside is, that this technique is in theory a bit more sensitive to jitter.
I guess, that with cheap china remotes the results of standard-algorithms are a bit better.
This implementation tries to reduce the impact of jitter with a slow timer-clock, and additionally integer-divides all bitlengths with the shortest. finally, the least significant bit is ignored (maybe this last step is not needed).
My results are good, my project was at receiving ir as good as the old cd-player (from which i used the remote).

If somebody wants to "play": I guess, the dedicated timer is not needed. Maybe, a normal pin-change-int and using micros() to measure the times is sufficiant. I did'nt try this.

 

[robsoles]

I went looking, a while back, for a touch screen universal remote control imagining that somebody should have made something roughly the shape of a ""smartphone"" with a receiver as well as transmitter so it could be programmed to replace any remote the end user could still access - I was pretty disappointed by the time I gave up looking for any simile of that.

When I can I want to get a touch screen and other required parts to see if I can make one that is at least acceptable to me. Chances are somebody might beat me to it if it occurs to them because I am one busy and distracted dude with (currently) minimal (read: no actual) fiscal resources; I won't mind one bit if someone does beat me to it, especially if they sell me one for < $200 AU (when I can afford it (facepalm)(lol))


Your work may be a fine foundation for such a device, I think it would be cool if you make a library of it - especially if your library covers sending as well

 

[Frank B]

I uploaded the lib at Github - pls. see the first post

It would be great to know, which remote (brand, typenumber, and the protocol, if you know it) works for you, so that i can make a list of "known to work" remotes.
if it works NOT let me know too: there are a a few things that can be tuned (timeout, # of bits..), and maybe we can get it to work.

 

[Frank B]

especially if your library covers sending as well

I'll wait for pullrequests ;-)