Menu
▾
▴
1 Attachments
#173 IR receiver refuses to work on a new hardware
My IR receiver refuses to work on my new box (hostname puma). While mode2 produces some pulse-signal sequences that look normal at first glance, irw is silent when I use my old lircd config. irrecord is unable to build a config (says Cannot decode data). On my old box (hostname luna) everything works perfect for 2 years. Signals are clearly recognized by LIRC. I've attached output of different commands that I run on puma and luna. I guess something's wrong with the kernel driver as mode2 sometimes outputs weird spaces like 6350. Please help to debug.
Attaching lircd.conf
Hm.... when I look at the mode2 output I don't really follow - you have compacted somehow, right?
Anyway, I think I see sequences like
space 16777215
space 792025
in that data. This is basically [#172] and might be the reason for the decoding failure
Are you able to apply a patch?
Related
Tickets:
#172Hi Alec,
Thanks for a quick response!
I used "-m" parameter of mode2 that nicely compacts pulse-space sequences. I'll attach an output without the option later on.
Sure, I'm able to apply the patch. Will get back to you to report my findings in a couple of days.
Hm... did you find the proper one to try? Attaching (from release branch) just in case...
Oh, I thought you want me to apply kernel patch. Never mind. Lirc patch is easier.
Unfortunately, it haven't resolved my issue. Double spacing is gone though. In case you're wondering, I was applying the patch to master branch (41baa27863961a59528902feae53ea477f3a9e77).
I attached plain mode2 output.
I guess the root of the decoding problem is in strange spaces or pulses like this:
space 6350
pulse 7400
space 6200
space 6150
pulse 6300
space 7300
They look random and suspicious to me. I couldn't find them in the luna's output.
You see, header
pulse 9100
space 4450
is always reading clearly and then there should be the data section with zero encoded as
pulse 600
space 500
and one as
pulse 600
space 1650
At least this is my understanding.
However, we get
...
pulse 650
space 500 <-- zero
pulse 600
space 1650 <-- one
pulse 600
space 1650 <-- one
pulse 650
space 1600 <-- one
pulse 650
space 1650 <-- one
pulse 600
space 6350 <-- what's this?!
pulse 1550 <-- something is wrong here too
space 550 <-- zero
pulse 600
space 500 <-- zero
pulse 600
space 1650 <-- one
pulse 650
...
No wonder decoder cannot understand anything.
Any ideas why I have this glitches?
Just to confirm my finding, I just decoded luna's mode2 output and it is
0010.0000.1101.1111.0010.0010.1101.1101 (dots are just for reading convenience)
which means 20DF.22DD in hex - this is exactly "ok" button code in my config.
puma's mode2 output is
0010.0000.1101.1111.0?10.1101.1101
where ? means a broken sequence.
The broken sequences appear in random places when I press "ok" button again and again.
(corrected mistypes)
Last edit: Nikita Melnichenko 2016-02-02
Another thing to mention, puma's running xhci as opposed to ehci on luna. I cannot switch xhci off in UEFI/BIOS to check if there any difference. I wonder if we can develop this thought further.
Looked through logs again, this message looks suspicious:
usb 1-13: device descriptor read/64, error -71
Did you encounter this kind of message for any other IR devices?
Hm... is this the dreaded kernel bug discussed in http://www.gossamer-threads.com/lists/mythtv/users/589923 ?
I read the thread twice and I'm not sure - is there a way to check? The end of the thread leaves the issue unsolved.
Did you mean the idea of patching kernel /usr/src/linux/drivers/usb/core/config.c by replacing n =32 with n = 10 as Jerry suggested?
This seems to up for discussion at the kernel forum: http://www.spinics.net/lists/linux-media/msg99820.html
Moving away from the 0.9.4 release. Also, this is more like a tracker bug for something which probably is a kernel driver problem.
Ping? Any news on this issue?
Do you mean there are some action items on my side?
Well, just interested if there was some clue after discussing with the kernel folks.
From a lirc perspective, we need to know if this indeed is the kernel or a lirc problem. One way would be to perform the same testing as in [1] and see if the output is broken in the same way. If so, this certainly is a kernel issue.
BTW: what kernel version are you on?
[1] http://lists.mythtv.org/pipermail/mythtv-users/2015-June/379724.html
I'm on the latest 4.1. I see that the patch discussed here is not yet merged to mainline kernel (4.7). As for the testing you're referring, I guess mode2 is as much raw output as you can ever get since it shows timings as read by kernel from a device. Anything else is just a wrapper around those timings trying to recognize well-known patterns. I proved that timings are read wrong - there are random errors. It's no doubt for me it's a kernel bug for this type of device.
Well then, all agree this is a kerrnel bug.
Have you tried the patch?
While you are right about the low-level nature of mode2, my point with usiing ir-keytable is that this is a tool supported by the kernel. The kernel folks really don't know about mode2.
No, I haven't. The patch affects usb core and I don't want to hurt realiability of other usb devices. I just bought another device that happens to work fine. I still own the original device and intend to test it on a prominent release if needed.
BTW, I checked an output of ir-keytable during my initial investigation. I remember it did not work as expected. Only useful output was a summary of the device driver features (included in the first attachment).
OK, let's sit back and wait until something happens with the kernel (for reference: the llnux-usb list).
Fixed in the kernel years ago