Unable to capture SONY TV codes correctly
xwin opened this issue · comments
I have built IRBlaster following schematic exactly and used parts mentioned on the github site. However the device can't capture SONY TV codes correctly. I get following URL which does not work:
http://blaster1.local:80/json?plain=[{'data':[2396,596,1194,604,618,580,1196,602,594,606,1194,604,594,606,594,604,1194,604,594,606,594,604,594,604,594],'type':'raw','khz':38}]
The device shows up as UNKNOWN. I have tried at least two remotes which produce the same code and both produce similar issue. I have built simple circuit with Arduino PRO Micro and using Arduino version of IRremote library. Using the same IR receiver, the library correctly captures the codes as A90:SONY:12 from both remotes.
I also built IRrecvDumpV2 example from IRremoteESP8266 library version 2.7.7 and that appears to ID the key correctly:
Code : 0xA90 (12 Bits)
uint16_t rawData[103] = {2422, 576, 1218, 580, 594, 604, 1220, 580, 594, 606, 1220, 580, 618, 580, 594, 604, 1218, 582, 618, 580, 620, 578, 618, 580, 594, 25830, 2424, 570, 1220, 580, 620, 578, 1220, 578, 620, 578, 1218, 580, 620, 580, 618, 580, 1194, 604, 620, 580, 620, 578, 620, 578, 598, 25828, 2424, 572, 1220, 578, 620, 580, 1220, 580, 618, 580, 1218, 580, 594, 604, 620, 578, 1220, 578, 620, 580, 618, 580, 620, 580, 620, 25804, 2422, 572, 1194, 604, 596, 604, 1218, 580, 618, 580, 1196, 604, 620, 580, 618, 580, 1220, 578, 594, 606, 618, 580, 594, 604, 594}; // SONY A90
uint32_t address = 0x1;
uint32_t command = 0x15;
uint64_t data = 0xA90;
I used the same library version and the same input pin in both cases. It appears to be interface issue between the library and the rest of the blaster code.
Hm I have SONY remotes and can capture those with no issues. Are you using the same pin for receiving in the IR Controller as well as your test builds? Does the serial output also show unknown?
I use the same exact build on the breadboard. It looks very similar to your picture. Someone reported this issue with the build on a soldered breadboard and I could reproduce it on my setup. I was quite surprised as the TV is quite old CRT, made around 2003. The report was with the newer TV, not sure what age but LCD.
I was mocking with the code trying to isolate the problem and found that if I disable everything but the IR code, the problem still remains. I just placed ifdef around most of the code. Could be some global class does something as well.
Serial output shows the same code as displayed by the web interface:
Signal received:
One line: F124B0B6:UNKNOWN:13
uint16_t rawData[25] = {2390,612, 1190,612, 592,604, 1190,614, 590,606, 1190,612, 590,606, 590,606, 1188,614, 592,604, 590,606, 592,604, 590}; // UNKNOWN F124B0B6
Signal received:
One line: F124B0B6:UNKNOWN:13
uint16_t rawData[25] = {2416,588, 1188,614, 616,580, 1214,588, 618,578, 1214,588, 616,580, 618,578, 1214,588, 618,578, 614,582, 616,580, 616}; // UNKNOWN F124B0B6
I am quite intrigued why this is, since the example from the library works perfectly well on the same setup. I just flash it and run it.
Actually SONY used different protocols over the years and one of my remotes worked OK with the design.
I stripped the code to this IRControllerStripped.zip. I still can reproduce the problem. This is only IR related part, nothing else. So there is no interference from other code which is good news. Since the library example by itself works I just need to find the differences with example.
I tracked it down. The clue was rawData[25] in the non working case vs rawData[127] in the working case. I don't know why but timeout must be increased to 35-40ms for SONY remotes to be identified correctly:
IRrecv irrecv(pinr1, captureBufSize, 35); /* working */
IRrecv irrecv(pinr1, captureBufSize); /* not working */
Could you please change the default timeout or should I submit a pull request?
I have tested it with the full application and it is working correctly at least with the remotes that I have. Strangely unit test application is working with the default timeout, unless I am missing something.
Hm wonder why the default of 15 doesn't work on your end. I will say I have no issue scanning my sony remote.
I will say I know sony codes are different than lots of others because they work by pulsing the same code 3 times to send their signal, so they are in theory longer than say an NEC code. Probably no danger in expanding the default timeout to 35 though, I'll add this change
Done