Receiving Different IR Codes From Same Remote/Button

Update - I disabled all known protocols in the header file and it decodes perfectly as an UNKNOWN type. So the next question would be - why does it get tricked into falsely accepting the codes as NEC, JVC? I did try tightening the spec to 0.95 while I was experimenting but that didn't work. At least, I have it working for what I need.

In my case, the remote wasn't the problem, but the receiver was. I had different readings all the time. With every remote. Includig the expensive ones. So I tryed a different IR reciever. That wordked. No different readings anymore. So I suggest you change the IR reciever.

ffpbar:
In my case, the remote wasn't the problem, but the receiver was. I had different readings all the time. With every remote. Includig the expensive ones. So I tryed a different IR reciever. That wordked. No different readings anymore. So I suggest you change the IR reciever.

Not necessary. I have been getting extremely similar raw readings every time. You can see that if you look at the raw IR dumps I posted above. It is only the 32 bit hash value that was screwed up. Since I disabled the manufacturers protocols as I described above, the same receiver works flawlessly every time.

The present question is, why do the decode functions for the manufacturers protocols fail so badly, generating false positives with this transmitter? By the way, for reference, it's the Senlian RM-408C.

aarg:
Update - I disabled all known protocols in the header file and it decodes perfectly as an UNKNOWN type. So the next question would be - why does it get tricked into falsely accepting the codes as NEC, JVC? I did try tightening the spec to 0.95 while I was experimenting but that didn't work. At least, I have it working for what I need.

could you please explain to me how to do this? Thanks.

Vaupell:
Well an old post, and it seems to be a common problem..

For future reference :wink:

Often the problem is cheap shit from a company called "keyes" they
produce a ton of crabby sensors and other stuff to sell to new players..

I once had a similar problem, i solved it by using a old TV-Remote.
Using a high quality remote like the ones that comes with your TV, ensures a steady, constant ir signal.

Where the cheap ones can change value, depending on the angle between the receiver and sender.
...

Use a program to read your TV remote keys and then reprogram your software to use it.

So the problem was with crappy sensors from Keyes, but you solved the problem by not replacing the sensor, but a different transmitter.. That doesn't make sense.

Hi, guys,
Have the same problem

Ziplock9000:
So the problem was with crappy sensors from Keyes,

If the problem was with "crappy sensors", could anybody recommend some good sensors, please?

Hello guys! I have a question about the IR receiver whitch I have salvaged from and old VCR,

I have connected it to my Arduino and its signal pin is normally HIGH, and when I press any button than it

goes LOW, is it suppoesed to be like that? and if yes than what signals does matter the LOW's or the HIGH's?

I would really apreciate it if anyone could give me a little advice about this subject. thank you.

i'm also facing this problem , when i'm doing my first IR project.....but it happens only with my cheap chinese remote , when i tried with panasonic viara remote it works very well..and gives same signal (code) every time ........

TV remotes always send the same codes per button. Inconsistent readings can be caused by distance or using the wrong protocol to interpret.

I'm using a Panasonic DVD remote and it's doing the same thing.

I also just tried with an IR remote app, and it's doing the same thing.
Is this a problem with my receiver? Or maybe some sort of interference with my wiring?

I had the same issues.
I could "fix" it by changing the voltage to 3.3 V and decreasing the distance for the cheap remote.
Other remotes (e. g. Onkyo Receiver) work just fine with 3.3 V but not always with 5. The LED on the Arduino board blinks regularly, instead of the irregular blinking while using the cheap remote.

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 :smiley:

2 Likes

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.

1 Like

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
1111
111 1 Your hand/reflector
11
\
()
\ \ 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.

SUCCESS!

akeom:
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:

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

#define LED_PIN     6
#define NUM_LEDS    150
#define LED_TYPE    WS2812B
#define COLOR_ORDER RGB
CRGB leds[NUM_LEDS];

#define UPDATES_PER_SECOND 100

CRGBPalette16 currentPalette;
TBlendType    currentBlending;

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

#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 
 switch(results.value)
 {
   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;
     }
     Serial.println(brightness);
     break;
   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;
     }
     Serial.println(brightness);
     break;
   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;  
   default: 
     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.begin(9600);
 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?
   translateIR(); 
   irrecv.resume(); // receive the next value
 }
 delay(200);
  
 static uint8_t startIndex = 0;
 startIndex = startIndex + 1; /* motion speed */
 FillLEDsFromPaletteColors( startIndex);
 FastLED.show();
 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

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:

#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... :slight_smile:

Tomasz

Hi guys! My answer may help you.

xxx Quick summary:

It's a timing problem. You NEED to give the code/arduino time to read the ir sensor. If you do, it will/should read the correct value every time.

I'm new to actually posting onto the forums so I hope the code copies correctly...

I was using the WS2812b led strip like user Josh780. I was having a similar issue of the IR sensor reading a different value EVERY single time I pushed the button. But then when I would use a default example code it would work perfectly and always read the correct value (e.g. serial print exactly what values the IR sensor reads). I thought it would store read values in some sort of buffer but it doesn't look that way.

I am working on a project with addressable LEDs (WS2812) that will pulse or move to the music (I know, super unoriginal) and I wanted a way to "switch" led modes and I didn't like just having a single pushbutton. Ironically that had similar timing issues that cause problems with the leds.

xxx My solution:

Unless you can live with a 500 ms delay in your loop (most of us CAN'T) then the next logical step is to take a HUGE pause, but only when you need to. So whenever the IR sensor reads something, we pause and wait for a REAL reading. The first reading doesn't matter, it's garbage anyway, or you wouldn't be reading this post.

Then we have a while loop that will wait for either:
a) a new reading or b) 1 second has passed
then we will do whatever using a switch case based on what the IR sensor reads.

I know this solution won't work for everyone, but it feels DARN NICE to be able to press a special button and ACTUALLY have it do what I meant. The drawback is I have to press the button twice. On the bright side, it feels more like a real consumer product because the leds pause and wait 1 second for input. It just feels like it was meant to be this way.

Let me know if this helps!

my code:

if (irrecv.decode(&results)) {

   quick_flash();
   irrecv.resume(); // Receive the next value
   
   t_wait = millis();
   
   while (!irrecv.decode(&results) && millis()-t_wait<1000)
   {
     //wait for new input up to 1 second
   }
   
   Serial.println(results.value, HEX); //debug

   switch (results.value)
   {
     case 0xFF6897: //0
       led_mode = 0; // all off
       break;

     case 0xFFA25D: //POWER BUTTON
       led_mode = 0; // all off
       break;

     case 0xFF30CF: //1
       led_mode = 1;
       break;

     case 0xFF18E7: //2
       led_mode = 2;
       break;

     case 0xFF7A85: //3
       led_mode = 3;
       break;

     case 0xFF10EF: //4
       led_mode = 4;
       break;


     case 0xFFFFFFFF: //REPEAT
       break;

   }
   delay(200); // so we don't read the same button press again
   irrecv.resume(); // Receive the next value
 }