IRremote library missing

Created Tue, 04 Aug 2015 08:59:14 +0000 by GastonLagaffe

GastonLagaffe

Tue, 04 Aug 2015 08:59:14 +0000

Salut,

am I right that the IRremote library that comes with the chipKit core is not written for chipKit? Looking through the forum and the web resources, I cannot find a IRremote library that runs on chipKit. The forum example I found (http://chipkit.net/forum/viewtopic.php?t=389) is not working (returns nothing but 1). I do not have a complex IR project, I just want to read a simple IR remote control that comes with the beginner kit for Arduino using the IR sensor (i.e. Elecfreaks beginner kit). Before diving into reinventing this old wheel I just want to check if there is really no IRremote lib available

Ciao, Mathias

Jacob Christ

Sun, 12 Jun 2016 01:42:09 +0000

What version of the dev tools are you using? Do you know if the library uses interrupts? I'm having trouble with interrupts with chipKIT-core 1.1.0

Jacob

majenko

Sun, 12 Jun 2016 09:16:13 +0000

There is no IRremote library in chipKIT core. Can you point to where you found the library?

Writing an IR receiver library is not actually that hard - as long as you have a demodulating receiver. The typical demodulated signal consists of a series of pulses of varying length. Different remotes use different combinations of lengths. The trick is how to identify the different remotes and decode them properly. Most send a unique header code using their own pulse lengths, and those pulse lengths may well be different to the payload pulse lengths. The spaces between the pulses as well often form part of the actual data stream. That's known as "Mark / Space" combinations. The relationship between the length of the mark (1) and the space (0) defines the value of the symbol. It's basically a form of PWM - it's possible to encode a number of different values into a single symbol then. Some remotes use just binary symbols (short/long and long/short), but some use maybe 4 values encoded in one symbol (0 = #, 1 = ##, 2 = ###__, 3 = #### for example).

The best possible library to write which would give the most accurate results whilst at the same time being non-blocking would use the Input Capture peripheral to grab the length of each mark / space segment and add them to a queue to be decoded - with a "space too long" timeout to indicate an end of transmission. That really limits the pins you can use though. Most libraries use interrupts set to CHANGE mode (which the PIC32 doesn't have) and capture the millis() or micros() value at each change from LOW to HIGH or HIGH to LOW.

Since that interrupt method can't be done on the PIC32 (well, it can if you change the edge trigger in the interrupt setting register from within the interrupt routine so it looks for the next edge - but that's nasty) it may be better to use the Change Notification interrupts. This not only gives you more pins to choose from, but can also work in CHANGE mode rather than just RISING or FALLING modes.