In the same room is fine. I was meaning are there any Wifi devices within a few inches.
We do actually have a Wink Hub that’s used for home automation within a couple feet of the media center. I can try killing that and see if it makes a difference. It’s hardwired itself, but obviously uses wireless to communicate with the smart devices.
EDIT: Turns out I lied about the proximity of the WAP; as part of the remodelling work, we do actually have the access point right by the media center at this point too. I’ll try moving both that and the smart hub when I can to see if that has an impact.
can you try the following from ssh:
systemctl stop lircd_helper@lirc0
mode2 -d /dev/lirc0
This will stop lircd and run the mode2 diagnostic program to look at the raw output of the IR receiver before it (would otherwise) go into lircd.
When no remote buttons are pressed, there should be no output. When a button is pressed you should see lots of lines with mark and space scroll by.
Do you see any random mark and space lines scroll by when no remote buttons are pressed ?
If so do they stop if you cover the front of the Vero ? If not, do they stop if you hold it further away from any other devices ?
1 Like
Well… looks like I’m an idiot. The wireless access point that had been moved nearby during the renovations was indeed generating a significant amount of activity on the IR receiver even when nothing was being pressed on remotes. I had no idea that 802.11n/ac protocols would interfere with IR activity, so it didn’t even occur to me to worry about placing an access point nearby. I just needed a port to plug the WAP into temporarily while it was away from its normal space in the house, and the switch by my media center was the most convenient.
I ran an extra-long cable from the switch to move the WAP to another part of the room, and now I only see very occasional pulse and space lines when nothing is being pressed, not a constant scroll of activity. Testing the remote with standard lirc shows it working just fine again.
I’ll probably still rotate over to using the ir-keytable mapping, since it appears more functional/robust overall, but the basic issue was clearly just the wi-fi proximity. It was total dumb luck that I pushed the May update on the same day I moved the WAP, since I often run pending updates on my devices on days where I’m working on other things around the house and don’t expect to be using them.
I’m editing the thread title now and linking the top post to this one so no one else gets confused.
The problems I was having were related to WiFi too. In my case when I was streaming across the 5ghz band with high bandwidth videos. Here’s the thread between Sam and i. We worked off-line on this for well over a week.
I’m curious as to how a ir remote that is operating at 38khz is getting interference from a 5ghz signal. Would it be safe to assume this is a hardware problem specific to the Vero?
No, it wasn’t bad hardware. the interference was at the interupt level on the processor trying to handle interupts (IRQ) for the WiFi usage and LIRC IR commands. Sam mentions this in one of his comments in the thread. I have multiple Vero 4K+ units. all experiienced this behavior prior to enabling ir-keytable. Sam mentions that OSMC is moving to ir-keytable in version 2.0.
Intermittent IR performance under certain specific circumstances is something I’ve been chasing for a while now. But I hadn’t been able to really nail down the cause as there seemed to be multiple factors at play and a lot of inconsistent results during testing confusing the issue. Based on the extra findings in this thread here is my theory of what is happening. (warning, will get technical 
)
It looks like there may be a small amount of pickup of 5Ghz WiFi by the IR receiver preamp in the Vero4k. Most likely the frequencies resonate well with the lengths of the signal tracks on the PCB and the RF ends up being rectified and detected by the preamp.
This causes a pulse of 5Ghz WiFi to appear to the IR preamp as if it was a very weak pulse of infrared light, thus when there are no real IR signals being received this is amplified and results in the spurious mode2 mark/space signals seen from WiFi. 2.4Ghz signals don’t seem to cause any problem, at least in my testing.
My WiFi router (a Virgin Media Superhub 2ac) is only 50cm from my Vero4k and doesn’t cause any issue, however the internal WiFi operating on 5Ghz or my phone placed within about an inch of the top do cause a noticeable effect on the Mode2 command output.
As placing the phone using 5Ghz on top causes the same effect as enabling internal WiFi I think we can now rule out IRQ handling conflicts between WiFi and IR receiver as a factor - we did think that was the issue at one point but now I think it’s unlikely and that it’s an RF pickup issue.
So if it’s RF pickup, why do kernel decoders configured with ir-keytable seem to be unaffected ? I’m going to speculate a little here but I believe the reason is that lircd has always been extremely fussy about the exact length of the marks and spaces in the received IR signal, and any small deviations cause decoding errors.
This is particularly apparent when one person uses irrecord to record a profile for a specific remote on say a Raspberry Pi, and someone else records the same remote on a different device like a Vero with a different IR receiver - the lircd.conf file you end up with it can have very different mark/space lengths encoded in it. And the lircd.conf file that works well on the same device that it was recorded on often doesn’t work nearly as reliably on a different device.
This is in contrast to the ir-keytable learning process which will give exactly the same codes, every time, for a given remote no matter what IR receiver is used during the learning process.
Irrecord records different mark/space timings because the characteristics of the IR receiver - both the IR diode/IR window and the IR amplifier can affect the mark/space ratio of the pulses slightly as you’re taking a sinusoidal signal and clipping it into a digital signal using different thresholds.
This can also happen if your remote is very close to the receiver or very far, or if there is a lot of ambient light in the room - it can cause the mark/space ratio to change slightly, and lircd doesn’t seem to cope well with these changes.
I noticed during testing that even when working normally with lircd my remote works reliably at a considerably greater distance using ir-keytable than it does with lircd. As the signal gets weaker and the mark/space ratio stretches lircd fails to decode the signal but the kernel decoder is still able to decode the signal correctly.
The effect of the RF signal on the IR receiver would be as a DC bias when a pulse of RF is present, so the overall effect is that the RF signal would change the mark/space ratio slightly similar to going a long way from the receiver, and therefore pulsing RF would introduce timing jitter into the digital signal recovered from the IR receiver.
The fact that the kernel IR decoders can still seemingly work perfectly in these circumstances suggests that whilst not ideal, the jitter is minor and that it’s just lircd which can’t cope with this additional jitter in the signal.
So assuming this is all correct, what is the outcome ? In a future version of the Vero hardware it might be possible to improve the filtering on the IR receiver to reduce any effects from WiFi signals.
But for existing units the solution is to move from lircd to ir-keytable configured kernel decoders for their superior performance and reliability, and practically speaking this solves the problem for existing devices.
Moving away from lircd is something that has been on our roadmap for quite a while, however recent changes to the Raspberry Pi kernels that are removing support for lircd (or at least making it very difficult to get it to work) will be forcing us to hurry up and implement official support for ir-keytable sooner rather than later.
That support would include a GUI in My OSMC to select and enable ir-keytable profiles, inclusion of a few default profiles like we do now for lircd, and a system service to activate the chosen profile automatically on boot.
In the meantime it is possible for anyone affected to manually create and use an ir-keytable profile and activate it using a boot time script.
This could explain the IR issues I experienced (IR keys repeated when Kodi is running and LG TV connected - #46 by sam_nazarko)
The Vero is close to my (5Ghz only) WiFi, but connected using ethernet. ir-keytable resolved most of my issues. The only problem that remained, was missed keypresses during (Live TV) playback: responsiveness in OSD menu was poor. I think interrupts also affected ir-keytable decodes to some extend.
I finally resolved all issue by using a Flirc. Now the IR performance is not affected by interrupts. It would be nice to include a “standalone IR processor” in a future Vero device.
Just out of curiosity (as I don’t own one of these units) would it be possible to just disable the built in wifi and add something like foil tape to act as a rf shield?
Just turn off WiFi under My OSMC -> Network.
I have a Pi 3B and have the same problem as this. The " mode2 -d /dev/lirc0" discussed above shows lots of output. I have 2 Pi 3Bs and both show the same problem. I do have a Pi 2 lying around and am currently looking at trying it there.
Edit: not much point testing on the 2 as it only uses a dongle for the wifi. I will be back where I have a 3 in a couple of weeks so I will continue testing there. If there is anything I can check in the mean time let me know. The 3B+ is connected via wifi and there are no routers etc within 15 feet. My ir receiver is connected to the gpio pins.
Very strange. I connected the Pi 3B to the wifi router with the other radio (2.4Ghz) and now I have no repeats. So maybe in my situation the wifi interference comes from the 5GHz radio on the Pi itself?
Is the Pi nearby?
Here’s the setup. OSMC (latest non-buster) is running on a Raspberry Pi 3B, connected via wifi to a router about 15-20 feet away on a different floor. The IR receiver on the Pi is connected to the gpio pins. The remote is an Inteset 422, and OSMC is using the lircd-full config.
When the wifi connection is 5GHz, I get many key repeats, almost to the point where the system is unusable. As stated above, when monitoring what the IR receiver is receiving, there is much noise in a darkened room with no buttons being pushed on the remote. When the wifi connection is 2.4GHz, there are little to no key repeats. There is still noise when monitoring the IR receiver though. My assumption is that even though the connection to the router is 2.4GHz, the 5GHz radio is still active, so the noise is being picked up from there.
Any chance of moving up your migration to the kernel lirc stuff in 19, or at least a test load?
Likely. We need to move to Python3 for v19. Almost certainly guarantees a new My OSMC.
Great. If you would like to try something in 18 I’d be happy to be a guinea pig… It does seem to be quite a common problem.
This isn’t something that we’d expect to ship in Kodi v18.
But we can help you with ir keytable.
I posted the instructions above in this thread on how to enable ir-keytable with 18. I have it working on all of my Vero 4K+ devices.
Just a couple of notes on the rc.local lines, for anyone else who wants to try it. The first kill command can be more safely replaced by sudo systemctl stop eventlircd, or alternatively, if you’re not swapping back and forth much for testing, you can just run sudo systemctl disable eventlircd once, which will stop it from running on boot, at which point you don’t need a stop line at all.
The second command may also need to be adjusted for protocol, depending on which device you have your universal remote emulating. For example, mine is currently sudo /usr/bin/ir-keytable -p rc5,lirc --delay=500 --period=125 -c -w /etc/rc_keymaps/osmc to handle my remote utilizing the former OSMC IR remote mappings.
You may also need to experiment a little bit with the keymaps to get the buttons doing what you want, since, for whatever reason, the operational button mappings from lirc for a remote don’t seem to correspond exactly to the ir-keytable mappings (e.g., I had to change a button from KEY_OK in lirc to KEY_ENTER in ir-keytable to get the remote operating as it previously had).