Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inconsistent decoding for unknown. #264

Closed
PaulKierstead opened this issue Jul 6, 2017 · 13 comments
Closed

Inconsistent decoding for unknown. #264

PaulKierstead opened this issue Jul 6, 2017 · 13 comments
Assignees
@crankyoldgit
Labels
enhancement

Comments

@PaulKierstead
Copy link

Version/revison of the library used

Version 2.1.0

Expected behavior

Using IRrecvDumpV2
Point Apple iMac remote at it and press a key. Do the same when the signal is weak to get some variance.

Actual behavior

Sometimes you get different Code values, but the raw content is very very close.

Example, here is two decodes:

Encoding  : UNKNOWN
Code      : 50B12173 (34 bits)
Timing[67]: 
     +9150, -4650     + 550, - 650     + 550, -1800     + 600, -1750
     + 650, -1800     + 550, - 700     + 550, -1800     + 550, -1750
     + 650, -1750     + 600, -1750     + 600, -1750     + 650, -1700
     + 650, - 600     + 650, - 650     + 550, - 600     + 600, - 600
     + 600, -1750     + 650, -1750     + 650, - 600     + 550, -1800
     + 600, - 650     + 600, - 600     + 650, - 650     + 500, - 700
     + 600, - 600     + 650, - 650     + 600, -1750     + 650, - 600
     + 650, - 550     + 650, - 600     + 650, - 600     + 600, - 650
     + 650, - 550     + 700
uint16_t  rawData[67] = {9150,4650, 550,650, 550,1800, 600,1750, 650,1800, 550,700, 550,1800, 550,1750, 650,1750, 600,1750, 600,1750, 650,1700, 650,600, 650,650, 550,600, 600,600, 600,1750, 650,1750, 650,600, 550,1800, 600,650, 600,600, 650,650, 500,700, 600,600, 650,650, 600,1750, 650,600, 650,550, 650,600, 650,600, 600,650, 650,550, 700};  // UNKNOWN 50B12173

.. some other stuff here

Encoding  : UNKNOWN
Code      : 6CB58446 (34 bits)
Timing[67]: 
     +9150, -4600     + 650, - 600     + 650, -1650     + 650, -1700
     + 650, -1750     + 650, - 600     + 650, -1700     + 650, -1750
     + 650, -1750     + 650, -1700     + 650, -1700     + 650, -1700
     + 650, - 600     + 650, - 600     + 650, - 600     + 600, - 600
     + 650, -1750     + 650, -1750     + 650, - 600     + 650, -1700
     + 600, - 600     + 700, - 550     + 650, - 550     + 650, - 600
     + 650, - 600     + 650, - 600     + 650, -1750     + 600, - 600
     + 650, - 600     + 650, - 550     + 650, - 600     + 650, - 600
     + 650, - 600     + 600
uint16_t  rawData[67] = {9150,4600, 650,600, 650,1650, 650,1700, 650,1750, 650,600, 650,1700, 650,1750, 650,1750, 650,1700, 650,1700, 650,1700, 650,600, 650,600, 650,600, 600,600, 650,1750, 650,1750, 650,600, 650,1700, 600,600, 700,550, 650,550, 650,600, 650,600, 650,600, 650,1750, 600,600, 650,600, 650,550, 650,600, 650,600, 650,600, 600};  // UNKNOWN 6CB58446

The RAW data for those two are extremely close (just a little variance on timing) yet the codes are different. I've seen some other codes too (for the same button and raw data). It seems to happen mostly when you get some garbage (really weak signal) between a couple of decodes.

Am I blind here (it is late...), or should I not trust the code value for unknown, or is this a bug?
@crankyoldgit
Copy link
Owner

crankyoldgit commented Jul 6, 2017 via email

@crankyoldgit
Copy link
Owner

crankyoldgit commented Jul 6, 2017 via email

@crankyoldgit
Copy link
Owner

I've simulated the data you provided. There are a number of issues with your capture etc.

I'm right in my memory that Apple use a NEC-like protocol, but don't strictly follow the NEC standard. Thus technically it isn't a NEC code. I'll look at adding something to report that sort of thing in the dump program.

However, the main issue is the "SPACE"s in the rawData you captured are a fair way outside of the normal values. I had to turn up the TOLERANCE value in IRrecv.h file to +/-50% (default is +/- 25%) for it to recognise it (mostly) as an NEC-like protocol. That is, the values of '700' are too large for the expected value of approx 560.

An alternative is change MARK_EXCESS (again in IRrecv.h) to 0U.

TL;DR: Your rig for capturing, or the remote itself is to far out of spec for the default code/values. You'll need to customise/tune those parameters or the timings for NEC directly to suit your specific case.

Perhaps try a new battery in the apple remote.

crankyoldgit added a commit that referenced this issue Jul 6, 2017
@crankyoldgit
Support reporting of 'NEC'-like 32-bit protocols. e.g. Apple TV remote
ce004a6 
- Apple TV remotes use the NEC protocol, but don't follow the integrity checks.
  Decode these last and report them separately in the example code.
- Addresses Issue #264
@crankyoldgit
Copy link
Owner

FYI, from the Troubleshooting guide.

  1. When it detects it as Unknown, the NN-bit code value reported is useless for sending purposes.

I've now just updated it further to clarify it's not a reliable value even for receiving too.

It's partly based on timing values so it isn't a 100% correlation with the button pressed again.

@crankyoldgit crankyoldgit self-assigned this Jul 6, 2017
@crankyoldgit crankyoldgit mentioned this issue Jul 6, 2017
Merged
@PaulKierstead
Copy link
Author

PaulKierstead commented Jul 6, 2017 •
edited
Loading

Thank very much for the detailed and helpful response! I'll try some of those things tonight and report back. Do the values for space have any 'real-world' correspondence? Using a scope, my spaces generally come in at 640 us or so, sometimes a little lower. Using a different remote (one from Adafruit, NEC protocol) I still see similar values, so I'd guess it is the receiver or the ESP timing on my rig that is different. I'll look seeing if I can tweak it to be reliable (though #265 would be very nice)

Edit: I take back the part about spaces. On the scope, for the Adafruit NEC one, the "low" portion was typically around 640 us, and the "high" portion around 560 us. I'm not sure which is considered the space, so I crossed that bit out in favour of this more detailed explanation. I'm pretty sure the Apple one was very similar, but will check again. Note if the remote is close there is no problem, generally.

@PaulKierstead
Copy link
Author

Ok, update on timing. The "low" portion of the signal on the scope, which seems to be the constant part after the initial pulse, is about 580us on the Adafruit remote, but 640 us on the apple remote. This is with a strong signal. I swear I buy CR2032's and they magically disappear, I can't find replacement one in the house

@PaulKierstead
Copy link
Author

So, I patched in your change on 2.1, and it definitely seems more consistent; now I could just check for 32 bits and NEC-Like, and pretty sure of a decode. Sample output (may not be the same button as before...), with a repeat:

Encoding  : NEC (non-strict)
Code      : 77E1A040 (32 bits)
Timing[67]: 
     +9200, -4550     + 650, - 600     + 650, -1700     + 650, -1700
     + 650, -1750     + 650, - 600     + 650, -1700     + 650, -1700
     + 650, -1700     + 650, -1700     + 650, -1700     + 700, -1650
     + 650, - 550     + 650, - 550     + 650, - 550     + 650, - 550
     + 650, -1750     + 650, -1700     + 650, - 600     + 700, -1650
     + 650, - 600     + 650, - 550     + 650, - 550     + 650, - 550
     + 650, - 550     + 650, - 550     + 700, -1700     + 650, - 550
     + 700, - 550     + 650, - 600     + 650, - 550     + 700, - 550
     + 650, - 550     + 650
uint16_t  rawData[67] = {9200,4550, 650,600, 650,1700, 650,1700, 650,1750, 650,600, 650,1700, 650,1700, 650,1700, 650,1700, 650,1700, 700,1650, 650,550, 650,550, 650,550, 650,550, 650,1750, 650,1700, 650,600, 700,1650, 650,600, 650,550, 650,550, 650,550, 650,550, 650,550, 700,1700, 650,550, 700,550, 650,600, 650,550, 700,550, 650,550, 650};  // NEC (non-strict) 77E1A040
uint32_t  address = 0x87EE;
uint32_t  command = 0x0;
uint64_t  data = 0x77E1A040;

Encoding  : NEC (Repeat)
Code      : FFFFFFFFFFFFFFFF (0 bits)
Timing[3]: 
     +9200, -2250     + 650
uint16_t  rawData[3] = {9200,2250, 650};  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t  data = 0xFFFFFFFFFFFFFFFF;

@crankyoldgit
Copy link
Owner

crankyoldgit commented Jul 7, 2017 via email

@crankyoldgit
Copy link
Owner

I've just thought of and implemented a way to auto-calibrate an incoming signal if it is a bit out of spec based on this issue. I've done it for NEC messages, and it seems to work for existing in-spec messages and your slightly askew Apple Remote.

See this branch for progress.
It needs to be merged with the other branch for it to work for you at present (ie. NEC-like etc)

crankyoldgit added a commit that referenced this issue Jul 8, 2017
@crankyoldgit
Support reporting of 'NEC'-like 32-bit protocols. e.g. Apple TV remote (
5f2c202 
#265)

- Apple TV remotes use the NEC protocol, but don't follow the integrity checks.
  Decode these last and report them separately in the example code.
- Addresses Issue #264
@crankyoldgit crankyoldgit mentioned this issue Jul 8, 2017
Merged
@crankyoldgit
Copy link
Owner

The auto-timing-adjust for incoming signals has been added to master
I'm going to consider this issue closed now.

@PaulKierstead
Copy link
Author

Thank you very very much! I'm popping out of country for a bit, but will give it a try when I get back.

@PaulKierstead
Copy link
Author

Follow up: Works really really well. I get very consistent decodes even when the signal is quite weak, considerably more stable results then before.

As a note to anyone who reads this: Long interrupt routines will pooch your results :) (no fault of this library, it ruins the timing) I fixed it by making my offending code into a poll instead of interrupt driven.

@crankyoldgit
Copy link
Owner

Good to hear. Yes, You need to do the absolute minimum you can get away with in the interrupt code/routines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@crankyoldgit crankyoldgit

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@crankyoldgit @PaulKierstead