Go Down

Topic: Receiving Different IR Codes From Same Remote/Button (Read 27983 times) previous topic - next topic

iancon

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.
//
// http://arcfn.com/2010/01/using-arbitrary-remotes-with-arduino.html
//
// 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 ;
}

ffpbar

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

aarg

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:
Code: [Select]
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:
Code: [Select]
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 http://www.righto.com/2010/01/using-arbitrary-remotes-with-arduino.html, I get
Quote
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?
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

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.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

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.

aarg

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.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

bmossade

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.

Ziplock9000

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.

Glumgad

Hi, guys,
Have the same problem

So the problem was with crappy sensors from Keyes,
If the problem was with "crappy sensors", could anybody recommend some good sensors, please?  

Arman Meradi

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.

pravindesai100

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 ........

INTP

TV remotes always send the same codes per button. Inconsistent readings can be caused by distance or using the wrong protocol to interpret.

JustJustin

I'm using a Panasonic DVD remote and it's doing the same thing.

JustJustin

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?

kabinx

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.

Go Up