Receiving Different IR Codes From Same Remote/Button

Same problem here. Different readings every time. By the way; almost ALL remotes are made in China.

1 Like

A timely post, as I was consternated at the reluctance of my remote (cheap Chinese universal remote). I'm actually getting very similar timings but they are decoded differently, for example:

Encoding  : NEC
Code      : 33B8609F (32 bits)
Timing[67]: 
     +8950, -4500     + 500, - 600     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, - 600     + 500, - 600     + 500, -1700
     + 550, -1700     + 550, -1700     + 500, - 600     + 550, -1700
     + 500, -1700     + 550, -1700     + 500, - 600     + 550, - 600
     + 500, - 600     + 500, - 600     + 550, -1700     + 500, -1700
     + 550, - 600     + 500, - 600     + 500, - 600     + 500, - 600
     + 550, - 600     + 500, -1700     + 550, - 600     + 500, - 600
     + 500, -1750     + 500, -1700     + 500, -1750     + 500, -1700
     + 550, -1700     + 500

Encoding  : UNKNOWN
Code      : 9866EE37 (32 bits)
Timing[67]: 
     +8950, -4500     + 500, - 600     + 500, - 650     + 500, -1700
     + 500, -1700     + 550, - 600     + 500, - 600     + 500, -1700
     + 550, -1750     + 500, -1700     + 500, - 600     + 550, -1700
     + 500, -1700     + 550, -1700     + 500, - 600     + 550, - 600
     + 500, - 650     + 450, - 650     + 500, -1700     + 500, -1750
     + 500, - 600     + 500, - 600     + 500, - 600     + 500, - 650
     + 500, - 600     + 500, -1750     + 500, - 600     + 500, - 600
     + 500, -1750     + 500, -1700     + 500, -1750     + 500, -1700
     + 550, -1700     + 500

Encoding  : JVC
Code      : 33B8 (16 bits)
Timing[67]: 
     +8950, -4450     + 550, - 550     + 550, - 600     + 500, -1700
     + 550, -1700     + 500, - 600     + 500, - 600     + 550, -1700
     + 500, -1750     + 500, -1700     + 550, - 600     + 500, -1700
     + 550, -1700     + 500, -1700     + 550, - 600     + 500, - 600
     + 500, - 600     + 550, -1700     + 500, - 600     + 550, -1700
     + 500, - 600     + 500, - 600     + 550, - 600     + 500, - 600
     + 500, - 650     + 500, - 600     + 500, -1700     + 500, - 600
     + 550, -1700     + 500, -1750     + 500, -1700     + 550, -1700
     + 500, -1750     + 500

These were received a few seconds apart, pointing the remote at the ceiling. I changed the tolerance in compare(), as suggested in reply #30, to 50% but it doesn't seem much better:

Encoding  : NEC
Code      : 33B8A05F (32 bits)
Timing[67]: 
     +8950, -4500     + 500, - 600     + 500, - 600     + 550, -1700
     + 500, -1700     + 550, - 600     + 500, - 600     + 500, -1700
     + 550, -1700     + 550, -1700     + 500, - 600     + 550, -1700
     + 500, -1750     + 500, -1700     + 500, - 600     + 550, - 600
     + 500, - 600     + 500, -1750     + 500, - 600     + 500, -1750
     + 500, - 600     + 500, - 600     + 500, - 600     + 550, - 550
     + 550, - 600     + 500, - 600     + 550, -1700     + 500, - 600
     + 500, -1750     + 500, -1700     + 550, -1700     + 500, -1750
     + 500, -1700     + 550

Encoding  : JVC
Code      : 33B8 (16 bits)
Timing[67]: 
     +8950, -4500     + 500, - 600     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, - 600     + 500, - 600     + 500, -1700
     + 550, -1700     + 550, -1700     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, -1700     + 500, - 600     + 500, - 600
     + 550, - 600     + 500, -1700     + 550, - 600     + 500, -1700
     + 550, - 550     + 550, - 600     + 500, - 600     + 500, - 600
     + 500, - 650     + 500, - 600     + 500, -1700     + 550, - 600
     + 500, -1700     + 550, -1700     + 500, -1700     + 550, -1700
     + 500, -1750     + 500

Encoding  : UNKNOWN
Code      : A0F5DAD5 (32 bits)
Timing[67]: 
     +8950, -4500     + 500, - 600     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, - 650     + 450, - 600     + 500, -1700
     + 550, -1700     + 550, -1700     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, -1700     + 500, - 600     + 500, - 600
     + 550, - 600     + 500, -1750     + 500, - 600     + 500, -1700
     + 550, - 550     + 550, - 600     + 500, - 600     + 500, - 600
     + 500, - 650     + 500, - 600     + 500, -1700     + 550, - 600
     + 500, -1700     + 550, -1700     + 500, -1700     + 550, -1700
     + 500, -1750     + 500

Hmmmmm..... is it really a 64 bit code? Based on persistent use, the "NEC" code is the correct decode.

Update - from the link given above Using arbitrary remotes with the Arduino IRremote library, I get

If your remote uses a protocol with multiple duration values, you probably won't get unique values from this algorithm.

I see three values in the timings so maybe that's it. But looking at the algorithm, I can't see why there should be such a difference. Am I missing something obvious?

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