Unexpected and incorrect HEX codes coming from IR Remote, but only occasionally?

Hello! :slight_smile: I’m working on a lil project with some NeoPixels being controlled by an IR remote, and with there being multiple strips, I felt it would be best to first select the desired strip, and then the colour. The code is getting there, albiet with a few bugs. I’ve set the serial monitor up for debugging.
When a strip is selected (I call them ‘shift buttons’, like on a keyboard), the program and serial monitor detect it flawlessly, every time. However, when I press ONLY a colour button to test the input, a seemingly random, HEX code pops up on the serial monitor which changes with each press. This seems to cause the whole code not to function past selecting a strip.
Would anyone be able to give me a hand as to why this incorrect code might be popping up please? I’ve tested the function of the buttons on a IR remote testing script and the buttons correlate to the HEX displayed everytime so I know the physical route to the Arduino isn’t flawed
Below is the code:

#include <IRremote.h> //include IR library
#include <Arduino.h>
#include <FastLED.h> //include LED library
#define NUM_LEDS1 18 //say how many leds is in row 1
#define NUM_LEDS2 17 //say how many leds is in row 2
#define NUM_LEDS3 20 //say how many leds is in row 3
const int RECV_PIN = 8; //say what pin IR sensor is plugged into
const int LEDPIN = 13;//say what pin blue STATUS led is plugged into

IRrecv irrecv(RECV_PIN);
decode_results results;
unsigned long key_value = 0;
int shiftbutton = 0;

CRGB leds1[NUM_LEDS1]; //link leds1 with how many leds are in it
CRGB leds2[NUM_LEDS2]; //link leds2 with how many leds are in it
CRGB leds3[NUM_LEDS3]; //link leds3 with how many leds are in it
size_t NumLeds[3] = { NUM_LEDS1, NUM_LEDS2, NUM_LEDS3 };
CRGB* strips[3] = { leds1, leds2, leds3 };

void setup()
{
  Serial.begin(57600);

  irrecv.enableIRIn(); //Enables IR
  irrecv.blink13(true); //Flashes onboard LED when IR input detected
  pinMode(LEDPIN, OUTPUT); //set signal led as an ourput
  FastLED.addLeds<NEOPIXEL, 5>(leds1, NUM_LEDS1); //setup for row 1
  FastLED.addLeds<NEOPIXEL, 3>(leds2, NUM_LEDS2); //setup for row 2
  FastLED.addLeds<NEOPIXEL, 6>(leds3, NUM_LEDS3); //setup for row 3
}

void loop()
{
  readIR();
  ShiftButtons();
  LEDStrip();
}

void readIR()
{
  if (irrecv.decode(&results))
  {
    // debug
    Serial.println("processing received IR");
    // if not repeat key
    if (results.value != 0XFFFFFFFF)
    {
      key_value = results.value;

      // debug
      Serial.print("using new value ");
      Serial.println(key_value, HEX);
    }
    else
    {
      // nothing to do
      // key_value still contains the result of the previous read

      // debug
      Serial.print("using old value ");
      Serial.println(key_value, HEX);
    }
    irrecv.resume();
  }
}

void ShiftButtons()
{
  switch (key_value)
  {
    case 0xFF30CF:
      shiftbutton = 1;
      break;
    case 0xFFB04F:
      shiftbutton = 2;
      break;
    case 0xFF708F:
      shiftbutton = 3;
      break;
  }

  // debug
  Serial.print("shiftbutton set to ");
  Serial.println(shiftbutton);
}

void setStrip (size_t index, CRGB color)
{
  fill_solid(strips[index], NumLeds[index], color);
  FastLED.show();
}

void LEDStrip()
{
  if (shiftbutton == 0) return; // no strip selected

  // debug
  Serial.print("LEDStrip: using key value ");
  Serial.println(key_value, HEX);

  CRGB color = CRGB::Black;
  switch (key_value)
  {
    case 0xFF1AE5:
      color = CRGB::Red;
      // debug
      Serial.println("color set to red");
      break;
    case 0xFF9A65:
      color = CRGB::Green;
      // debug
      Serial.println("color set to green");
      break;
    case 0xFFA25D:
      color = CRGB::Blue;
      // debug
      Serial.println("color set to blue");
      break;
  }

  setStrip(shiftbutton - 1, color);
  shiftbutton = 0;  // reset the flag
}

Thanks!
Tom

The variable 'color' is local to LEDStrip(), and can't be accessed outside the function.

Also, any strip update operation will wreak havoc on IR, because it turns off interrupts.

Okay I’ll swap it around tomorrow, thanks! As for the second point, are you referring to my code, something that can be avoided or is it just a general fact to bare in mind?

Thanks

It's an inescapable general fact. Some interrupt driven code can work seamlessly, such as serial, but that is because the UART hardware can tolerate short delays between receiving characters and handling them. With IR, 433MHz OOK wireless, and maybe some others I haven't become aware of, it will fail because they depend on microsecond timing. This is true, at least, for AVR architecture.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.