Corrupt IR Codes - coding error?


I’m trying to combine Ken Schirrffs IR library with the Adafruit Neopixel library but I’m having issues.
The Ir code works fine on its own but when I integrate it with the led code (also working fine) the ir codes seem to get corrupted.
I’m not sure if this is something to do with the received code getting overwritten where it is stored in memory?

I’ve tried commenting out different parts of code and it works fine until I actually send data to the light string using the ColorBlip function.

Anyone shed any light on this?

#include <IRremote.h>
#include <Adafruit_NeoPixel.h>
int numpixels=51;
Adafruit_NeoPixel strip = Adafruit_NeoPixel(numpixels, 6, NEO_GRB + NEO_KHZ800);
int RECV_PIN = 2;
int code;
IRrecv irrecv(RECV_PIN);
decode_results results;

void setup() {
  strip.begin();; // Initialize all pixels to 'off'
  irrecv.enableIRIn(); // Start the receiver

void loop() {
  colorBlip(strip.Color(255, 0, 0), 25);

void testfunc() {
  for (int i=0;i<1000;i++) {

void colorBlip(uint32_t c, uint8_t wait) {
  for (int j=0; j<10;j++) {
    for(uint16_t i=0; i<strip.numPixels(); i++) {
//      switch(checkir()) { 
//      case -1:
//       return;
//      case 1:
//        c=strip.Color(255,0,255);
//        break;
//      case 2:
//        c=strip.Color(0,255,0);
//        break;
//      case 3:
//        c=strip.Color(255,255,0);
//        break;
//      case 4:
//        c=strip.Color(0,0,255);
//        break;
//      }
      strip.setPixelColor(i, c);
      strip.setPixelColor(numpixels-i, c);
      strip.setPixelColor(i, 0);
      strip.setPixelColor(numpixels-i, 0);

uint8_t checkir() {
   if (irrecv.decode(&results)) {   
    long int decCode = results.value;
    switch (decCode) {
      case 49796:
      case 49836:
        code= -1;
      case 49872:
      case 49859:
      case 49688:

    irrecv.resume(); // Receive the next value
  return code;

Hmm. Or maybe it's something to do with the neopixel library turning off interrupts.

Why would that corrupt the values though?

I'm confused.

When working with loops that are time-critical, as IR, I recommend just eliminating the issue and move IR to a dedicated uC, such as the tiny85:

The t85 is a very economical ... $1.29 ea/qty 1 from Newark.


Some things to try: (in order) - Enable the pull-up resistor on the RECV_PIN pin (2) (may stop some interference). - try other pins as RECV_PIN, instead of RECV_PIN(2) - The LEDs may be interfering with the IR receiver (by emitting IR) - so try shielding the IR receiver from the LEDs and/or introduce a command that actually doesn't change the LEDs (more likely to get interference when things are changing) - You didn't mention, which IR receiver you are using. Sometimes, the data sheet will suggests optional components for removing noise. Some are more resistant to interference than others. - decoupling capacitors - I am not familiar with can't comment on potential conflicts with various pins/interrupts etc.

Thanks for the tips.

mrburnette, using something like the tiny85 may well be the best approach - I'd like to see what the problem is first though if possible. AnalysIR, thanks for your suggestions. I've tried all of them except for the decoupling capacitors which I don't have here. No joy though, even when I am sending 'all off' data to the lights, the ir signal is corrupted.

Model # of IR receiver or link to datasheet?

Oh yes sorry, its a TSOP4838 - data sheet here:

I think my problem is to do with interrupts. The neopixel library temporarily disables interrupts. As I reduce the frequency of the light updates, the ir becomes more reliable.

I could probably live with this but I probably need to think about mrburnette's approach.

Interrupts: IRremote uses a timer constant of 50uSecs granularity to detect the signals (defined in the library code) - so if you tried to adjust that in the range from, say, 25->100uSecs you might just miss/avoid the impact of any potentially conflicting interrupts.

Also, try out IRLib as an alternative. Its a rewrite of IRremote and may not suffer the same way.

Ambient Light: As you say less likely, but reducing the update frequency could also reduce interference from the LED ambient light also. The TSOP4838 uses AGC2 & you might get better results with TSOP4438 (AGC4), [u]if[/u] the interference is via ambient light from the LEDs.

You could also try just using varying the blue light only (furthest from Red/IR), which would help confirm if indeed the interference is Interrupt or ambient. (Turn Red & Green always off)