Issue decoding #243
Comments
|
@jorgecis Thanks for the report. I'll look into it. First thing to note, it's reporting 34bits, where NEC is 32 bits, plus I know a rawData[] length of 67 is correct for 32 bits, thus something is broken. |
- Fixes Issue #243 - [bugfix] Incorrect assumption on minimum entry length when decoding. Off by one. - [bugfix] Make matching the trailing gap/space on commands optional if we run out of buffer. - Fix a wayward Serial.println() debug statement that got missed. - Add unit tests to add coverage for the bug found.
- Fixes Issue #243 - [bugfix] Incorrect assumption on minimum entry length when decoding. Off by one. - [bugfix] Make matching the trailing gap/space on commands optional if we run out of buffer. - Fix a wayward Serial.println() debug statement that got missed. - Add unit tests to add coverage for the bug found.
- Fixes Issue #243 - [bugfix] Incorrect assumption on minimum entry length when decoding. Off by one. - [bugfix] Make matching the trailing gap/space on commands optional if we run out of buffer. - Fix a wayward Serial.println() debug statement that got missed. - Add unit tests to add coverage for the bug found. - Bump version to v2.0.1
|
Hey @jorgecis I think it should address the issue you're seeing. |
- Fixes Issue #243 - [bugfix] Incorrect assumption on minimum entry length when decoding. Off by one. - [bugfix] Make matching the trailing gap/space on commands optional if we run out of buffer. - Fix a wayward Serial.println() debug statement that got missed. - Add unit tests to add coverage for the bug found. - Bump version to v2.0.1
|
@jorgecis The fix has been submitted, and a new release created. Can you please confirm it addresses your issue? https://github.com/markszabo/IRremoteESP8266/releases/tag/v2.0.1 |
|
I flash my esp8266 using the last lib 2.01 and I got the same result. |
|
Thanks for the feedback. I'll try to set up something similar to your config to test it here. |
|
To made it simple I'm using the code in the example IRrecvDumpV2.ino as it without any change, my hardware is a adafruit esp8266, the only thing connected is a Infrared receiver in the PIN 14. I using a real remote control (ONKYO) but also I try others remotes and also another esp8222 to send codes, I found that the RC6 was detected. Part of the debug log is Attempting NEC decode The old library works fine. |
|
Thanks for that. I'll try to have a patch for you to test in a few mins. It will give me some more debug information. |
|
Yes, If I comment those lines the code was detected Encoding : NEC |
|
Can you try downloading this branch (https://github.com/markszabo/IRremoteESP8266/tree/issue-243) and try it out for me please? I'm looking for the debug lines like:
|
|
Please include relevant debug lines around it etc. |
|
I think that maybe the problem is the rawlen is base 0 if (offset <= results->rawlen - 1 && I'll try the code in your branch |
|
I think it is correct. re: Waiting on your results. And mega thanks for the prompt testing for me. |
|
No problem, but I change the code, the original was offset <= results->rawlen, I think that the -1 is missing. |
|
Ah. yes. You are correct, and I was mis-quoting the wrong code. But I'm never 100% certain. :-) I think the issue lies in NEC_MIN_GAP is probably the wrong value in real-world situations. Hence the extra debug code to work this out. |
|
the function matchAtLeast is never called Attempting Aiwa RC T501 decode |
|
Yes, it is being called.
And .. that's way unexpected. hmmm. |
|
OK just in case if you need it, the value of offset is 68 the same that results->rawlen |
|
Thanks. I'm just uploaded a new commit to that branch. I think I understand what is happening. Can you let me know if that works? Obviously you'll need to re-download etc etc. Again, thanks for the quick turnaround. This really helps. |
|
Sorry wrong code, let try again |
|
Phew. I saw the email, and thought "ohes noes, wtfbbq" ;-) |
|
sorry for that, this is the real result Matching ATLEAST 0 vs 21940. Matching: 0 >= 225 [min(329, 225)] |
|
Huzzah. |
|
I have other issues with other protocols and I think is the same function, for example Attempting JVC decode |
|
JVC at least I have a remote for. |
|
Ok, just to inform you, If I comment the gap check in the ir_JVC the code is detected Matching MARK 500 vs 525. Matching: 9 <= 10 <= 16 |
|
ta. |
|
re: your JVC dump.
1700 is an unexpectedly short gap. I think there may be more code in the buffer. I've half a mind to pull out the gap checking code, but some protocols need it to distinguish from each other. |
- Issue #243 uncovered an odd case where a zero length end gap is encountered. - Add unit test to cover zero length space at the end. - Add more debugging code for matchAtLeast()
|
I think I may have found the root cause. |
|
Ok, I you need another test let me know |
|
Sure. Can you please change line 135 in ir_JVC.cpp to: And let me know if it works. I think you were right with how I'm calculating the end of the buffer. |
|
Ok I did the change, I have 2 controls, with the first one the gap is there Attempting JVC decode With the second one nogap but works Attempting JVC decode |
|
Interesting. The first one (the one with [69] in the timing/rawData) has two codes in it. i.e. It has a repeat code as well. |
|
Thus the gap thing/code is doing it's job. It's detecting a valid break in the message and working out the code is really a JVC code. Great. |
|
Can you please re-download and try that branch again. Just made some more fixes (to all protocols) |
|
With the last change, look like everything is working now, like for example JVC with repeat ########## |
|
Cool. Not sure about the last one. Looking at it, it doesn't match the JVC spec at all. |
- [bug] Issue #243 uncovered an odd case where a zero length end gap is encountered. - Add unit test to cover zero length space at the end. - Add more debugging code for matchAtLeast() - [bug] fix incorrect end of buffer calculation in decodes
- [bug] Issue #243 uncovered an odd case where a zero length end gap is encountered. - Add unit test to cover zero length space at the end. - Add more debugging code for matchAtLeast() - [bug] fix incorrect end of buffer calculation in decodes
- [bug] Issue #243 uncovered an odd case where a zero length end gap is encountered. - Add unit test to cover zero length space at the end. - Add more debugging code for matchAtLeast() - [bug] fix incorrect end of buffer calculation in decodes
|
FYI, the code/fix for this has made it into next published release https://github.com/markszabo/IRremoteESP8266/releases/tag/v2.0.2 Marking this issue close, please reopen if you don't believe it is fixed. |
|
@jorgecis FYI, I did some research. I couldn't find any solid reference to a 32bit JVC code. All the official JVC documents I could find all indicated that it was all 16-bit. So that odd button you found. No idea. :-/ |
Version 2.00
Using the example code IRrecvDumpV2.ino
I got this
Encoding : UNKNOWN
Code : B47AF5B7 (34 bits)
Timing[67]:
+9000, -4500 + 650, - 550 + 650, -1650 + 600, - 550
+ 650, - 550 + 600, -1650 + 650, - 550 + 600, -1650
+ 650, -1650 + 650, -1650 + 600, - 550 + 650, -1650
+ 650, -1650 + 650, - 550 + 600, -1650 + 650, -1650
+ 650, - 550 + 650, - 550 + 650, -1650 + 650, - 550
+ 650, - 550 + 650, - 550 + 600, - 550 + 650, - 550
+ 650, - 550 + 650, -1650 + 600, - 550 + 650, -1650
+ 650, -1650 + 650, -1650 + 650, -1650 + 650, -1650
+ 650, -1650 + 600
uint16_t rawData[67] = {9000,4500, 650,550, 650,1650, 600,550, 650,550, 600,1650, 650,550, 600,1650, 650,1650, 65
0,1650, 600,550, 650,1650, 650,1650, 650,550, 600,1650, 650,1650, 650,550, 650,550, 650,1650, 650,550, 650,550, 65
0,550, 600,550, 650,550, 650,550, 650,1650, 600,550, 650,1650, 650,1650, 650,1650, 650,1650, 650,1650, 650,1650, 6
00}; // UNKNOWN B47AF5B7
Using the old code was detected as NEC
The text was updated successfully, but these errors were encountered: