Even if you were off frequency several kHz, it would still work with reduced range is all. So you are saying that the RAW values (strings of CSV numbers that are negative and positive integers) are consistently received? If so, I believe you can have the library send the data from that format, but it still doesn't help you receive them. It sounded like a simple change to raise the number of bits to 64 from the post I read. Of course, after glancing thru the code, I didn't see it that way. They had left an important piece out of their post; namely which specific format to modify.
I've seen "universal" remotes that broadcast several different codes for each button press (hoping one of them will work, presumably). Maybe that's the problem.
It would be easy to see if you connect an oscilloscope to the leg of the IR receiver.
Keep in mind that those short numbers are just the library's attempt at figuring out an unknown protocol and condensing it into a more manageable form. If it's not working, you'll need to take a look at the unencoded version of the signal. If you look at it in raw on/off pulse times, patterns should emerge. The code could be too long, it could be sending in two short bursts, or you could have even found a bug. You won't know until you look at the actual signal and figure out why it isn't being handled properly.
I just discovered something--if I am too close to the sensor (3 feet), I get inconsistent results. 5 or so feet and I get consistent results. Odd.
Following up:
http://matthewrupert.net/2013/03/13/arduinoir/
I am using the IR remote sensor library. Everything works fine. Now I want that when I press my KEY numbered ' 1 ' on IR remote and successively press the other e.g. volume + , what should be done to to read this complete procedure.
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 think it might be a performance issue at the arduino. I use an arduino mini pro 5v 16MHz
Library is "IRremote.h" and I'm controlling DC motors with the IR
Here's my output with thin Main Loop, "Other Button" is the #fail condition
Opening port
Port open
IR Receiver Raw Data + Button Decode Test
255
other button
16736925
VUp
16736925
VUp
16736925
VUp
16736925
VUp
16712445
VDown
4294967295
other button
16712445
VDown
4294967295
other button
16712445
VDown
4294967295
other button
4294967295
other button
4294967295
other button
16720605
VSlower
16720605
VSlower
4294967295
other button
16761405
VFaster
10
4294967295
other button
4294967295
other button
4294967295
other button
16761405
VFaster
10
16761405
VFaster
10
16761405
VFaster
10
16748655
HFaster
16748655
HFaster
16754775
HSlower
Here the same sequence with "THick " main Loop:
Port open
IR Receiver Raw Data + Button Decode Test
1253111733
other button
3219426777
other button
3622325019
other button
5316027
other button
4001918335
other button
4001918335
other button
713775392
other button
3810010651
other button
3810010651
other button
4202145195
other button
3499001667
other button
5316027
other button
5316024
other button
176854242
other button
2098956842
other button
4001918335
other button
4001918335
other button
5316027
other button
2603687621
other button
3887428328
other button
851901943
other button
1223062238
other button
268228494
other button
3789458290
Hi I am ajay.
I am beginner in arduino software. I just want to know the code for ir receiver, i am having arduino uno board along with TSOPSM0038 IR Receiver i just want to know the coding for this program can any one help me please.
Well an old post, and it seems to be a common problem..
For future reference 
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.
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
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.