Go Down

Topic: Receiving Different IR Codes From Same Remote/Button (Read 28708 times) previous topic - next topic


I know this is an old thread but I think I have something to add for anyone that is struggling with errant remote codes.

I am using the 'Keyes' cheapo remotes currently and was getting some random numbers.

I found that my standard desk work lamp (halogen incandescent bulb) was pointing directly at the IR receiver and after repeat tests was effecting the receiver.

After I pointed the main 'beam' away from my project, remote and receiver worked almost flawlessly.

TL;DR  Consider your ambient lighting!

Rnubi :D


I come years too late to help the original user, but it may help a novice having the same issue:
ground related issues will cause erratic and random like readings. Make sure your Arduino and your peripherals share the same ground.


I have to admit when I read post #46 I said "No way" but unbelievably that worked for me. I have tried 3 original Yamaha, Samsung and LG remotes, a Harmony universal and I Xiaomi IR blaster and all gave me random output all the time. I moved the power for my IR receiver from the breadboard to the Arduino Uno and everything started working. I have tried everything from getting new IR receivers to new remotes and it turned out to be such a simple thing like using the same ground. Armorican you a true hero in my book.


Hello to Everyone!
I had the same problem. Now is fixed!
Do not direct lighting the sensor! Just use a reflector like a mirror. Or just use your hand at 45 degree.
             =>   The sensor is here
111 1                        Your hand/reflector
           \   \                           The remote
            \   \
             \   \
I receive the same codes!

You can try another way also:
Put a sheet /try with two sheets also/ of white paper between the remote and the sensor. This will works like a filter.



Hi, same problem here. Following experiment:

- I commented out nearly all of my main loop
- after that, I could receive the right button-pressed codes
- uncommented main loop ->> same problem again.
I am observing the same behavior. After a few hours of debugging, I've found that I'm able to retain the majority of my original main loop() commands, provided I insert a delay() call of at least ~200ms. With this, I don't see perfect interpretation of the IR signals, but at least half of them are received correctly. I'm wondering if it's a timing issue, where if the IR signal is received while the loop() function is processing other data, it somehow jumbles the result. This makes me curious if it is a performance issue or whether the IRremote library could be modified to halt other processing as soon as it starts receiving a signal. I'm not an expert with Arduino, but I would have thought an interrupt-driven event would do this anyway.

Does anyone have any suggestions?

As background, what I'm trying to accomplish is control of an LED strip using the FastLED library, then altering the LED sequence with an IR remote. So far all I've implemented is brightness control, but if I can get this working, there's a whole slew of features I'd like to add.

For reference, here's my code:
Code: [Select]

#include "IRremote.h"
#include <FastLED.h>

#define LED_PIN     6
#define NUM_LEDS    150
#define LED_TYPE    WS2812B


CRGBPalette16 currentPalette;
TBlendType    currentBlending;

// set up global variable for tracking LED brightness, initially set to half-power
uint8_t brightness = 128;

#define IR_PIN 11  // Signal Pin of IR receiver to Arduino Digital Pin 11

/*-----( Declare objects )-----*/
IRrecv irrecv(IR_PIN);     // create instance of 'irrecv'
decode_results results;      // create instance of 'decode_results'

/*-----( Function )-----*/
void translateIR() // takes action based on IR code received
 // describing Remote IR codes
   case 0xFFA25D: Serial.println("POWER"); break;
   case 0xFFE21D: Serial.println("FUNC/STOP"); break;
   case 0xFF629D: Serial.println("VOL+");
     if (255 - brightness < BRIGHTNESS_INCR) {
       brightness = 255;
     } else {
       brightness += BRIGHTNESS_INCR;
   case 0xFF22DD: Serial.println("FAST BACK");    break;
   case 0xFF02FD: Serial.println("PAUSE");    break;
   case 0xFFC23D: Serial.println("FAST FORWARD");   break;
   case 0xFFE01F: Serial.println("DOWN");    break;
   case 0xFFA857: Serial.println("VOL-");
     if (brightness < BRIGHTNESS_INCR) {
       brightness = 0;
     } else {
       brightness -= BRIGHTNESS_INCR;
   case 0xFF906F: Serial.println("UP");    break;
   case 0xFF9867: Serial.println("EQ");    break;
   case 0xFFB04F: Serial.println("ST/REPT");    break;
   case 0xFF6897: Serial.println("0");    break;
   case 0xFF30CF: Serial.println("1");    break;
   case 0xFF18E7: Serial.println("2");    break;
   case 0xFF7A85: Serial.println("3");    break;
   case 0xFF10EF: Serial.println("4");    break;
   case 0xFF38C7: Serial.println("5");    break;
   case 0xFF5AA5: Serial.println("6");    break;
   case 0xFF42BD: Serial.println("7");    break;
   case 0xFF4AB5: Serial.println("8");    break;
   case 0xFF52AD: Serial.println("9");    break;
   case 0xFFFFFFFF: Serial.println(" REPEAT");break;  
     Serial.println(" other button  ");
   }// End Case
   Serial.println(results.value, HEX);

 delay(200); // Do not get immediate repeat
} //END translateIR

void setup()   /*----( SETUP: RUNS ONCE )----*/
 // LED Setup
 delay( 3000 ); // power-up safety delay
 FastLED.addLeds<LED_TYPE, LED_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip );
 FastLED.setBrightness( brightness );
 currentPalette = RainbowColors_p;
 currentBlending = LINEARBLEND;

 // IR Setup
 Serial.println("IR Receiver Button Decode");
 irrecv.enableIRIn(); // Start the receiver
}/*--(end setup )---*/

void loop()   /*----( LOOP: RUNS CONSTANTLY )----*/
 if (irrecv.decode(&results)) { // have we received an IR signal?
   irrecv.resume(); // receive the next value
 static uint8_t startIndex = 0;
 startIndex = startIndex + 1; /* motion speed */
 FillLEDsFromPaletteColors( startIndex);
 FastLED.delay(1000 / UPDATES_PER_SECOND);
}/* --(end main loop )-- */

// Function to actually set LED colors
void FillLEDsFromPaletteColors( uint8_t colorIndex)
   // uint8_t brightness = 255;
   for( int i = 0; i < NUM_LEDS; i++) {
       leds[i] = ColorFromPalette( currentPalette, colorIndex, brightness, currentBlending);
       colorIndex += 3;


Hi All, same problem here too.

I took few minutes to test the turboto technic, and it's works, the buttons begin to send the same number on the monitor.(certainly enough to find the correct number, not yet sending test at time, AC remote)

Thanks turboto
Don't think about what the code do, be the code


I think I solved that problem.

I used to have the same problem with IRremote library - codes were inconsistent for most of the times (I was be able to receive the same code 3 times out of 5).

I've read all posts under this topic. I tried 3 different "cheap" remotes (one from Arduino starter kit, two controlling some disco lights) as well as TV Samsung remote; I bought different receiver - nothing helps.

So I've started looking at library implementation. Someone here suggested to remove all Remote Control definitions other than default - it didn't help. I tried to change tolerance under IRrecv::compare - also didn't help...

But what I noticed library is using kind of weird hash of output values to calculate final result.

So I printed raw data from signals.rawbuf and I imported them into Excel.
After painting them on graph I've noticed they're pretty consistent for every key press.

So long story short instead of using signals.value I'm calculating my own 64bit integer in following way:

Code: [Select]

#define IR_TOLERANCE 17

if (irrecv.decode(&signals))

    uint64_t irVal = 0;
    for(int i=3; i<(signals.rawlen-1); i++)
        int Delta = signals.rawbuf[i] - signals.rawbuf[i+1];
        if (Delta < 0) Delta = -Delta;
        uint8_t b = (Delta < IR_TOLERANCE) ? 0 : 1;

        if ((i-3) < 63)
            irVal = irVal | ((int64_t)b << (int64_t)(i-3));

    uint64_t x1 = irVal;
    uint32_t x = x1 >> 32;
    Serial.print(x, HEX);
    x = x1 & 0xFFFFFFFF;
    Serial.println(x, HEX);
    irrecv.resume(); // get the next signal

End of it is pretty complicated because Arduino compiler doesn't want to print x64 integer.

I defined IR_TOLERANCE for 17, you can try to lower it if it's still not consistent.

Sometimes (very rare in my case) I'm receiving wrong code. But it doesn't really matter - 99% is good.

PS. Someone should update that library... :)


Go Up