Receiving Different IR Codes From Same Remote/Button

I am working on a project that detects what button was pressed and displays it on a LCD screen.

I am using this library for handling receiving the IR codes: GitHub - Arduino-IRremote/Arduino-IRremote: Infrared remote library for Arduino: send and receive infrared signals with multiple protocols

Everytime I press the same button on my Time Warner Cable remote I get different results.

What is the cause of this and how can I account for it?

#include <IRremote.h>

int RECV_PIN = 11;

IRrecv irrecv(RECV_PIN);

decode_results results;

void setup()
{
  Serial.begin(9600);
  irrecv.enableIRIn();
}

void loop() {
  if (irrecv.decode(&results)) {
    Serial.println(results.value, HEX);
    irrecv.resume();
  }
}

Are you sure it's always different?

I found that I got two different codes with some buttons, and it alternated between the two.

For example the "down" button produces either a 1041 or 3089 and I just used the || (the "or") in my code like this:

   if (results.value == 1041 || results.value == 3089) 
      {
         // do stuff
      }

I just pressed the same button 25x and these are the values I received,

3653895 - 14 Times
421066283 - 1 Time
615415119 - 2 Times
604317718 - 2 Times
1358155102 - 1 Time
35434315 - 1 Time
609534435 - 2 Times
325791992 - 2 Times

Ok, you got me stumped there. No idea why that could be, but I have limited experience of using the IR I must say.

It has stumped me too. I have tried multiple different remotes and they all work like expected with only one code per button but this Time Warner Cable remote keeps sending different values...

Perhaps it's some kind of proprietary security thing, where the receiver can unravel the "arbitrary" string and act on it, without having to know in advance what strings might arrive. But then, why does the one string score 14/25....

So there really isn't a way to get a 100% recognition rate for the codes?

Well you could do your 25 click test a few more times until you think you have seen them all, and then "or" them like I had above.

But it could just simply be that the remote you have doesn't work on the "one button- one (or two) code" principal? Have you any documentation on what that remote is supposed to produce?

I am not sure where I would find that information. The booklet that it came with is available here: http://www.universalremote.com/resources/pdfs/UR5U-8520L.pdf but there's no information on such and I'm not sure where else to look.

Try this sketch to spit out a nicely formatted list of on/off pulses in microseconds:

It's just the ir decode sketch from adafruit.com with a function added (printpulses3) which spits out the pulses in array format that can be copied and fed into the IRremote lib's sendRaw function. You can take a look at the rest of the project if you want to see how I used it. The issue you're experiencing may be more obvious when you look at the received signals in a less condensed format, though.

Around here the cable company (comcast) has started to use the XMP protocol which makes decoding a bit trickier. I had no luck reading it with adafruit's ir sensor and had to order a new one from digi-key that supports XMP. So if changing the formatting of the output doesn't help solve/spot the problem, you may want to google your remote and find out if it's using XMP or some other protocol. FWIW, you don't really need to be able to properly decode their protocol. You just need to understand it well enough to get a good signal recording that you can duplicate.

Oh, one last thing... The ir decoders from vishay are pretty sensitive. If that's what you're using, you may want to wire it up according to the datasheet's example with the cap and resistor to clean up the output a little if you haven't done that already.

JimboZA:
Are you sure it's always different?

I found that I got two different codes with some buttons, and it alternated between the two.

For example the "down" button produces either a 1041 or 3089 and I just used the || (the "or") in my code like this:

Yep. This is so you can tell when the user lifts his finger and presses the same button again (as opposed to holding the button down and sending the same code multiple times).

you don't really need to be able to properly decode their protocol....

True.... but he does need to know that he's covered all the possibilities with enough testing to ensure that in a few weeks a button doesn't generate a code he didn't see in testing and thus didn't cater for.

I guess that's what you meant by:

understand it well enough to get a good signal recording that you can duplicate

AJKnoch:
I just pressed the same button 25x and these are the values I received,

3653895 - 14 Times
421066283 - 1 Time
615415119 - 2 Times
604317718 - 2 Times
1358155102 - 1 Time
35434315 - 1 Time
609534435 - 2 Times
325791992 - 2 Times

Maybe it's because the receiver frequency doesn't match the transmitter frequency very well so you get glitches (IR remotes don't all use the same modulation frequency).

Maybe it's because the receiver frequency doesn't match the transmitter frequency very well

Good point: when I bought my 38 receiver, they shop had 37.5 as well.

JimboZA:

Maybe it's because the receiver frequency doesn't match the transmitter frequency very well

Good point: when I bought my 38 receiver, they shop had 37.5 as well.

My VISHAY IR receiver datasheet lists variants at 30, 33, 36, 36.7, 38, 40 and 56 kHz. They use a bandpass filter so there's a bit of tolerance but maybe that remote is transmitting at 33 or 40kHz.

PS: You could hook an oscilloscope to the transmitter LED to find out...

AJKnoch:
I just pressed the same button 25x and these are the values I received,

3653895 - 14 Times
421066283 - 1 Time
615415119 - 2 Times
604317718 - 2 Times
1358155102 - 1 Time
35434315 - 1 Time
609534435 - 2 Times
325791992 - 2 Times

Well that can't be right in my opinion. Since the new library was just released on the 16th, I suspect you are looking at a bug.

It's been a little while, but I've looked at well over a dozen different remote controls on a scope and with linux. I have never seen anything that should result in differences like that. It's common for the protocol to flip a bit between transmissions or even send a final code after you let up from holding the key. I never saw anything that would be that difficult to cope with. Something seems amiss, but try a different remote control if you can.

Did you ever get a solution here? I'm trying the exact same thing--And seeing, as you did, different values each time.

runningdude22:
Did you ever get a solution here? I'm trying the exact same thing--And seeing, as you did, different values each time.

What kind of remote are you using? I have the same problem myself now with the U-verse remote. I did some digging, and I think the problem is that the remote is sending more than 32 bits which seems to freak out the library. I saw where somebody said they made a change in the library somewhere and worked for them, but I don't know any more than that. I'd like to fix mine too, so keep this thread alive if you find a solution.

Supposedly Samsung remotes use 38kHz. When I use the IR library I have to output raw codes to see them with my Samsung remote. It works--I see codes--but they are different every time. Any suggestions?

@afremont --Its a samsung remote for my Time Warner DVR box. When I output raw codes I can see them just fine. After some digging it does appear that the samsung remote is using 38kHz carrier frequency, which would be compatible with the IR receiver I am using-- IR Receiver Diode - TSOP38238 - SEN-10266 - SparkFun Electronics