Inconsistent IR receive codes

Ziplock9000 · February 6, 2017, 4:47pm

I'm using the standard IRremote.h library to decode incoming remotes. I've tried 3 from different manufacturers remotes (from high quality products). All of them have the issue where the same button pressed multiple times is inconsistent. Not just the code, but the protocol keeps changing from JVC, Sanyo, NEC to unknown. This happens on all remotes and buttons

This image shows the same button pressed twice.

I'm using an Arduino Uno, Pin 11 and Keyes KY-022 TSOP1838 37.9kHz
External PSU @12v hasn't helped.
IRremote library is the latest
I've not pasted any code as it's just the same as the example code from the library.

I've had a good Google and look on this forum and nothing has worked short of trying a different receiver.

Any help appreciated. Thanks.

Ziplock9000 · February 6, 2017, 5:58pm

Here's more data from pressing "1" on a Hitatachi CLE-960 remote

Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:AF5B04F
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:5D4CF2E5
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:AF5B04F

Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:FFFFFFFF
Protocol: (NEC) Value:AF5B04F
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:AF5B04F
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:AF5B04F
Protocol: (JVC) Value:AF5
Protocol: (NEC) Value:FFFFFFFF
Protocol: (NEC) Value:AF5B04F
Protocol: (UNKNOWN) Value:83AC8803
Protocol: (NEC) Value:FFFFFFFF

83AC8803 seems quite common, lesser so AF5B04F. Then there's AF5 and FFFFFFFF

DrDiettrich · February 7, 2017, 9:08am

To exclude electrical problems: Is your receiver a 3.3V or 5V type? Did you add a capacitor to stabilize the operating voltage of your receiver? Did you add a pullup resistor?

The raw data look good to me, the dumped pulse widths are consistent and indicate the NEC protocol.

Eventually you want to try my improved IRremote library, where you can call the NEC decoder directly. This way you can exclude false decoding by other decoders in the library.

Ziplock9000 · February 9, 2017, 10:36pm

DrDiettrich:
To exclude electrical problems: Is your receiver a 3.3V or 5V type? Did you add a capacitor to stabilize the operating voltage of your receiver? Did you add a pullup resistor?

The raw data look good to me, the dumped pulse widths are consistent and indicate the NEC protocol.

Eventually you want to try my improved IRremote library, where you can call the NEC decoder directly. This way you can exclude false decoding by other decoders in the library.

Sorry I never had alerts turned on.
I've supplied the KY-022 receiver with 5v from the Arduino's 5v rail which from the datasheet is what the TSOP1838 works with.
It looks like the KY-022 has a resistor and LED. The resistor looks like it's there just as a current limiter for the LED.

No matter what Remote I use, the same button from them will produce one of several results. Very little consistency.

It seems other people using the KY-022 and similar modules are getting good results without a cap and/or resistor, but I will explore that further.

EDIT 1: Yeah the datasheet has a cap and resistor to suppress power supply disturbances. I'll try it, but I'm guessing that's not the issue.

Thanks.

Due_unto · February 9, 2017, 10:56pm

Is there a possibility of another IR source in the room (like kids watching TV and flipping through channels causing your erratic behavior? IR bounces around like crazy and it could even be from another room.

scottbnoob · February 9, 2017, 11:24pm

I had an issue with IR values jumping around and found that using pin11 for a different component was the problem (even just the mention of pinMode(11,...) would set the values to jump all over the place).

Never had the receiver in pin 11 itself but you could try a different pin.

Ziplock9000 · February 9, 2017, 11:28pm

Due_unto:
Is there a possibility of another IR source in the room (like kids watching TV and flipping through channels causing your erratic behavior? IR bounces around like crazy and it could even be from another room.

Nope. The incorrect results only happen at the exact moment I press a remote button. All other times there's no input.

Ziplock9000 · February 9, 2017, 11:34pm

scottbnoob:
I had an issue with IR values jumping around and found that using pin11 for a different component was the problem (even just the mention of pinMode(11,...) would set the values to jump all over the place).

Never had the receiver in pin 11 itself but you could try a different pin.

Interesting, thanks I'll give that a try with the resistor and caps mentioned in the data sheet.

Grrr.. this post limit is a pain in the arse.

Ziplock9000 · February 10, 2017, 12:13am

Well I've tried a 4.7uF electrolytic cap across the GND and +5v, with a 100ohm resistor on the +5v exactly as it has in the data sheet.

Same results

I then moved it to pin 3 and 5

Same results.

This is the output from the same button on the same remote:

Protocol: (NEC) Value:AF5CE31
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (LG) Value:AF5CE3
Protocol: (NEC) Value:AF5CE31
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (NEC) Value:AF5CE31

Protocol: (NEC) Value:AF5CE31
Protocol: (NEC) Value:AF5CE31
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7ED27B68
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:3E5ABCF9
Protocol: (NEC) Value:AF5CE31
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (NEC) Value:AF5CE31
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (NEC) Value:AF5CE31
Protocol: (NEC) Value:AF5CE31
Protocol: (JVC) Value:AF5
Protocol: (UNKNOWN) Value:B35C630C
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B
Protocol: (UNKNOWN) Value:7709F61B

Here's another run with raw data and timings.

Protocol: (UNKNOWN) Value:7709F61B
Encoding  : UNKNOWN
Code      : 7709F61B (32 bits)
Timing[67]:
     +8850, -4550     + 450, - 650     + 450, - 650     + 500, - 650
     + 450, - 650     + 500, -1700     + 500, - 650     + 450, -1750
     + 500, - 650     + 450, -1750     + 500, -1750     + 450, -1750
     + 500, -1750     + 450, - 650     + 500, -1750     + 450, - 650
     + 450, -1750     + 500, -1750     + 450, -1750     + 500, - 650

     + 450, - 650     + 500, -1750     + 450, -1750     + 500, -1750
     + 450, - 650     + 500, - 600     + 500, - 650     + 450, -1750
     + 500, -1750     + 450, - 650     + 550, - 550     + 550, - 600
     + 500, -1700     + 550
unsigned int  rawData[67] = {8850,4550, 450,650, 450,650, 500,650, 450,650, 500,1700, 500,650, 450,1750, 500,650, 450,1750, 500,1750, 450,1750, 500,1750, 450,650, 500,1750, 450,650, 450,1750, 500,1750, 450,1750, 5
00,650, 450,650, 500,1750, 450,1750, 500,1750, 450,650, 500,600, 500,650, 450,1750, 500,1750, 450,650, 550,550, 550,600, 500,1700, 550};  // UNKNOWN 7709F61B
================================
Protocol: (UNKNOWN) Value:7709F61B
Encoding  : UNKNOWN
Code      : 7709F61B (32 bits)
Timing[67]:
     +8900, -4450     + 550, - 600     + 500, - 600     + 550, - 550
     + 550, - 600     + 500, -1700     + 500, - 650     + 500, -1700
     + 500, - 600     + 500, -1750     + 500, -1700     + 550, -1700
     + 550, -1650     + 550, - 600     + 500, -1700     + 550, - 600
     + 500, -1700     + 550, -1700     + 550, -1650     + 550, - 600
     + 550, - 550     + 550, -1650     + 600, -1650     + 550, -1650
     + 600, - 550     + 550, - 550     + 550, - 550     + 600, -1650
     + 550, -1600     + 650, - 550     + 550, - 550     + 550, - 600
     + 500, -1700     + 550
unsigned int  rawData[67] = {8900,4450, 550,600, 500,600, 550,550, 550,600, 500,1700, 500,650, 500,1700, 500,600, 500,1750, 500,1700, 550,1700, 550,1650, 550,600, 500,1700, 550,600, 500,1700, 550,1700, 550,1650, 5
50,600, 550,550, 550,1650, 600,1650, 550,1650, 600,550, 550,550, 550,550, 600,1650, 550,1600, 650,550, 550,550, 550,600, 500,1700, 550};  // UNKNOWN 7709F61B
================================
Protocol: (JVC) Value:AF5
Encoding  : JVC
Code      : AF5 (16 bits)
Timing[67]:
     +8900, -4450     + 550, - 550     + 550, - 600     + 550, - 550
     + 550, - 550     + 550, -1700     + 550, - 550     + 550, -1700
     + 550, - 550     + 550, -1700     + 550, -1650     + 550, -1700

     + 550, -1650     + 550, - 550     + 600, -1650     + 550, - 550
     + 550, -1700     + 500, -1700     + 550, -1700     + 500, - 600
     + 500, - 650     + 500, -1700     + 500, -1750     + 500, -1700
     + 500, - 600     + 500, - 650     + 500, - 600     + 500, -1750
     + 500, -1700     + 550, - 550     + 550, - 600     + 500, - 600
     + 550, -1700     + 550
unsigned int  rawData[67] = {8900,4450, 550,550, 550,600, 550,550, 550,550, 550,1700, 550,550, 550,1700, 550,550, 550,1700, 550,1650, 550,1700, 550,1650, 550,550, 600,1650, 550,550, 550,1700, 500,1700, 550,1700, 5
00,600, 500,650, 500,1700, 500,1750, 500,1700, 500,600, 500,650, 500,600, 500,1750, 500,1700, 550,550, 550,600, 500,600, 550,1700, 550};  // JVC AF5
unsigned int  data = 0xAF5;
================================
Protocol: (NEC) Value:AF5CE31
Encoding  : NEC
Code      : AF5CE31 (32 bits)
Timing[67]:
     +8900, -4450     + 550, - 550     + 550, - 600     + 500, - 600
     + 500, - 600     + 550, -1700     + 500, - 600     + 500, -1750
     + 500, - 600     + 500, -1750     + 500, -1700     + 500, -1700
     + 550, -1700     + 550, - 550     + 500, -1750     + 500, - 600
     + 550, -1700     + 500, -1700     + 550, -1700     + 500, - 600
     + 550, - 600     + 550, -1650     + 550, -1700     + 550, -1650
     + 550, - 550     + 550, - 600     + 550, - 550     + 550, -1700
     + 550, -1650     + 550, - 550     + 550, - 600     + 500, - 600
     + 550, -1700     + 500
unsigned int  rawData[67] = {8900,4450, 550,550, 550,600, 500,600, 500,600, 550,1700, 500,600, 500,1750, 500,600, 500,1750, 500,1700, 500,1700, 550,1700, 550,550, 500,1750, 500,600, 550,1700, 500,1700, 550,1700, 5
00,600, 550,600, 550,1650, 550,1700, 550,1650, 550,550, 550,600, 550,550, 550,1700, 550,1650, 550,550, 550,600, 500,600, 550,1700, 500};  // NEC AF5CE31
unsigned int  data = 0xAF5CE31;
================================
Protocol: (UNKNOWN) Value:7709F61B
Encoding  : UNKNOWN
Code      : 7709F61B (32 bits)
Timing[67]:
     +8850, -4500     + 500, - 650     + 500, - 600     + 550, - 550
     + 550, - 600     + 500, -1700     + 550, - 600     + 500, -1700
     + 550, - 550     + 600, -1650     + 550, -1650     + 600, -1650

     + 550, -1700     + 550, - 550     + 550, -1650     + 550, - 600
     + 550, -1650     + 550, -1700     + 550, -1650     + 550, - 600
     + 550, - 550     + 550, -1650     + 600, -1650     + 550, -1700
     + 550, - 550     + 550, - 550     + 550, - 600     + 500, -1700
     + 550, -1700     + 500, - 600     + 500, - 600     + 500, - 650
     + 500, -1700     + 500
unsigned int  rawData[67] = {8850,4500, 500,650, 500,600, 550,550, 550,600, 500,1700, 550,600, 500,1700, 550,550, 600,1650, 550,1650, 600,1650, 550,1700, 550,550, 550,1650, 550,600, 550,1650, 550,1700, 550,1650, 5
50,600, 550,550, 550,1650, 600,1650, 550,1700, 550,550, 550,550, 550,600, 500,1700, 550,1700, 500,600, 500,600, 500,650, 500,1700, 500};  // UNKNOWN 7709F61B
================================
Protocol: (JVC) Value:AF5
Encoding  : JVC
Code      : AF5 (16 bits)
Timing[67]:
     +8900, -4450     + 550, - 600     + 550, - 550     + 550, - 550
     + 550, - 600     + 550, -1650     + 550, - 550     + 550, -1700
     + 550, - 550     + 550, -1700     + 550, -1650     + 550, -1700
     + 550, -1650     + 550, - 600     + 550, -1650     + 550, - 600
     + 550, -1650     + 550, -1700     + 550, -1650     + 550, - 600
     + 550, - 550     + 550, -1650     + 550, -1700     + 550, -1650
     + 550, - 600     + 550, - 550     + 500, - 600     + 550, -1700
     + 450, -1750     + 500, - 650     + 450, - 650     + 500, - 600
     + 500, -1750     + 450
unsigned int  rawData[67] = {8900,4450, 550,600, 550,550, 550,550, 550,600, 550,1650, 550,550, 550,1700, 550,550, 550,1700, 550,1650, 550,1700, 550,1650, 550,600, 550,1650, 550,600, 550,1650, 550,1700, 550,1650, 5
50,600, 550,550, 550,1650, 550,1700, 550,1650, 550,600, 550,550, 500,600, 550,1700, 450,1750, 500,650, 450,650, 500,600, 500,1750, 450};  // JVC AF5
unsigned int  data = 0xAF5;
================================

I'm starting to wonder if it's just a bad receiver ?

DrDiettrich · February 10, 2017, 1:39am

As already mentioned, selecting a single protocol (NEC) should yield consistent results.

Ziplock9000 · February 13, 2017, 11:36pm

DrDiettrich:
As already mentioned, selecting a single protocol (NEC) should yield consistent results.

As I said in my OP, I have multiple remotes, from multiple manufacturers and none of them are consistent. I doubt very much that all of them are using NEC.

DrDiettrich · February 14, 2017, 10:22am

You can disable all decoders except NEC, or use my extended library and call decodeNEC directly.

Ziplock9000 · February 15, 2017, 12:49am

DrDiettrich:
You can disable all decoders except NEC, or use my extended library and call decodeNEC directly.

Ok I'm not understanding something here.

As I've mentioned, I have multiple remote controls all broadcasting IR signals from different protocols that I need to be able to read.

How would I be able to read a signal that is say Samsung, Sanyo, Lego or any other none NEC protocol if I've disabled those protocol decoders??

Are you suggesting that I should "force" them to NEC and that would give a unique HEX number that I could use instead?

A little bit more explanation as to why you're suggesting this (on the surface) seemingly illogical action would be helpful.

Thanks.

DrDiettrich · February 15, 2017, 2:15am

If multiple decoders claim to be able to decode a given signal, which one would you trust? The library uses the first decoder that reports success, even if this is not the right one. If you really use controls of multiple protocols, you have to try to decode each signal with every decoder, and select the right result yourself.

Ziplock9000 · February 15, 2017, 10:54am

DrDiettrich:
If multiple decoders claim to be able to decode a given signal, which one would you trust? The library uses the first decoder that reports success, even if this is not the right one. If you really use controls of multiple protocols, you have to try to decode each signal with every decoder, and select the right result yourself.

I'm sorry but you're really not understanding this at all. Everyone else seems to have understood what's going on here and offered good suggestions.

The problem is that it's not selecting the same decoder each time the exact same signal comes in from the exact same button on the exact same remote. The debug output above shows the data from the same key on the same remote clicked repeatedly after a pause between each click. As you can see, the protocol detection and data are not consistent.

As I've mentioned several times the incoming signal can be from any one of several protocols that come from any remote I happen to have at hand. No matter the broadcast protocol, the detection is always inconsistent.

So your suggestion to force it to use NEC decoding when we know the incoming signal is not always NEC is clearly the wrong solution.

Why force a peg into a round hole when you know it's quite often square or triangular?

Problem 1 - The protocol is not being detected consistently

This could be an algorithmic problem with the library? Very doubtful as the one I'm using is widely used with a lot of success.
Could it be signal noise? I added the cap and resistor and it didn't seem to help much.
Could it be the pin I used? I tried several pins to no avail.
Could it be the remote? No, I used several different high-end ones ones from different manufacturers that work.
Could it be because your not forcing it to NEC decoding? Absolutely not as the signal is often not NEC anyway.
Could it be the frequency of the receiver? Unlikely, as it's the 38Khz one that is most common
Could it be a bad receiver? This is possible and people have reported it before.. Further testing needed.

Like I said, the next step is to try a different receiver.

DrDiettrich · February 15, 2017, 11:24am

The reason for the randomish selection are minor timing differences in the received signals. If you decode the exactly same raw data, the result will always be the same. If not, then the signals are different, for any of several possible reasons.

Topic		Replies	Views
Different values when pressing the same button of IR remote controller Programming	9	2827	May 5, 2021
IR receive problem - unknown random codes Sensors	12	28191	May 6, 2021
With Arduino The same key from the remote control sends different values Sensors	3	586	May 6, 2021
Receiving Different IR Codes From Same Remote/Button General Electronics	57	56706	May 6, 2021
Inconsistent HexCodes on IR receiver Programming	3	246	September 24, 2023

Inconsistent IR receive codes

Problem 1 - The protocol is not being detected consistently

Related topics