Receiving Different IR Codes From Same Remote/Button

For me the solution was using 9v battery instead of using power from the computer to the usb of the arduino

I have some cheap remotes from china - they give inconsistent results as well (what a surprise) I think that the main problem with these is one of the clocking in the cheap remotes.

After a bit of debugging and looking at the data stream it appears that the remote is giving a reasonable result, but the tolerance that the library tries when decoding an unknown data stream is too high. By opening the tolerance I am now getting a consistent result.

Here is the extract from irRecv.cpp

//+=============================================================================
// hashdecode - decode an arbitrary IR code.
// Instead of decoding using a standard encoding scheme
// (e.g. Sony, NEC, RC5), the code is hashed to a 32-bit value.
//
// The algorithm: look at the sequence of MARK signals, and see if each one
// is shorter (0), the same length (1), or longer (2) than the previous.
// Do the same with the SPACE signals. Hash the resulting sequence of 0's,
// 1's, and 2's to a 32-bit value. This will give a unique value for each
// different code (probably), for most code systems.
//
// Using arbitrary remotes with the Arduino IRremote library
//
// Compare two tick values, returning 0 if newval is shorter,
// 1 if newval is equal, and 2 if newval is longer
// Use a tolerance of 20% - changed to 40%
//

int IRrecv::compare (unsigned int oldval, unsigned int newval)
{
if (newval < oldval * .6) return 0 ;
else if (oldval < newval * .6) return 2 ;
else return 1 ;
}

1 Like

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!