arabull
Posts: 4
Joined: Tue Mar 01, 2016 3:35 pm

IR Corruption on Pi 2

Tue Mar 01, 2016 4:10 pm

tl;dr - Can the Pi board itself interfere with IR signals, but only temporarily?

I'm having a vexing issue with my Pi 2. I have an IR sensor wired up to the GPIO pins (3.3V, GND, and #18). I'm running Arch and using lircd to interpret the IR signal. 95% of the time, everything works great! But the other 5% of the time is really stumping me.

During that time, the system doesn't react at all when I send IR signals. By putting lircd into debug mode, I can see that it thinks it is receiving garbage. It simply can't decode the signals. I know for a fact that the remote is not sending garbage; I have two systems right next to each other, and one of them responds just fine. So the IR signal coming from the remote is fine.

A logical explanation would be IR receiver interference, but I think this is unlikely for a few reasons. First, the aforementioned system that is sitting right next to the failing system and working. Second, restarting the unit always clears the problem (but restarting lircd does not). It seems unlikely that any interference would coincidentally clear every time I restart (unless the interference is coming from the hardware itself; more on that shortly). Finally, I've seen this behavior in all manner of environments at all times of day and night (to rule out sunlight).

This behavior is by all appearances random (though logic tells me it can't be). The one interesting thing is that I can recreate the symptoms at will by disconnecting the HDMI cable for at least 60 seconds and then reconnecting it. (60 seconds is when my monitor times out; not sure if that's important or coincidence.) If I do that, lircd interprets any signals for the next 3-5 minutes (it’s not consistent) as garbage. After 3-5 minutes, it clears up and signals come through clean again. Oh, and just to totally confuse the issue, the garbage doesn’t happen if I wait 60 seconds and then send an IR signal immediately before reconnecting the HDMI. I have to go at least 60 seconds without sending any IR signals before reconnecting the HDMI to see the garbage. Huh? This makes absolutely no sense to me.

I’ve debugged every software layer I can think to debug, leaving me thinking I have a hardware issue here. And I have recreated this behavior on a large number of Pi 2 units, so I know it’s not just a bad unit or two. But the fact that it doesn’t fail all the time is what really confuses me. If the IR sensor were bad, it would never work. If the GPIO pins were bad, it would never work. Is it possible that the Pi itself could be interfering? That would explain why it clears upon reboot, but it doesn’t explain why firing an IR signal immediately before reconnecting the HDMI prevents it.

And just to be clear, disconnecting/reconnecting the HDMI simply produces the same symptoms. I don’t actually know if it’s the same root cause as when it happens at other times. But since I can’t pinpoint a way to reliably reproduce the issue any other way, it’s the best I can do to allow me to debug.

As a developer, every fiber of my being says there is a logical explanation for this, but I’m at a total loss to find it. Every theory I have has serious holes in it. So now I’m throwing this out to the community at large for help. I'm really curious if other folks can reproduce this, and if so, if they can do so on other OSes. One thing I haven't done is test on an OS other than Arch.

Thank you in advance for any ideas or leads you may have!

rzusman
Posts: 347
Joined: Fri Jan 01, 2016 10:27 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 8:32 pm

You need to scope both outputs (the working and non-working units) simultaneously and see if their outputs are identical.
If they are, it’s a software issue.
If not, it’s interference / power / noise.

arabull
Posts: 4
Joined: Tue Mar 01, 2016 3:35 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 9:07 pm

Thanks for the reply! I'll definitely try your suggestion. Being a software guy, we're already outside the realm of my knowledge, so I'll need to do some research to figure out how to "scope" the units. If you have any tips to save me time, I'll gladly accept them!

As a conceptual question to any hardware folks: is it within the realm of possibility that the interference is coming from the unit itself? And subsequently, is it within the realm of possibility that disconnecting/reconnecting the HDMI causes said interference? I just can't find any other way to explain it given the behavior I see.

For what it's worth, I know that some monitors cause interference, but I've replicated this on all sorts of monitors and even with monitors turned off, so I don't think that's what is happening here.

arabull
Posts: 4
Joined: Tue Mar 01, 2016 3:35 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 9:15 pm

Ah ha... I bet you are talking about piscope. This looks promising, thanks!

rzusman
Posts: 347
Joined: Fri Jan 01, 2016 10:27 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 9:16 pm

It’s certainly possible that the Pi is causing interference.
As for scoping the signal - the first thing you need is an oscilloscope, or logic analyzer. It doesn’t have to be very fast.
Just connect on channel to IR1’s output and another channel to IR2’s, and the connect the two Pi’s grounds together, and connect the ground lead of the scope to the Pi’s ground.
Set the scope for chop mode, and two-channel, and you should see the data when you fire the IR at the sensors. If you hold the transmit button down, you should see both IR sensors emitting the same data (the waveforms should be perfectly superimposed).

rzusman
Posts: 347
Joined: Fri Jan 01, 2016 10:27 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 9:17 pm

I’ve never used Piscope, but it’s worth a shot.
I find real oscilloscopes to be indispensable tools for this sort of thing.

arabull
Posts: 4
Joined: Tue Mar 01, 2016 3:35 pm

Re: IR Corruption on Pi 2

Tue Mar 01, 2016 9:19 pm

See, I told you I wasn't a hardware guy. :-)

Thank you so much for your suggestions. I'm going to give both the software (piscope) and the hardware (an oscilloscope) a shot.

Return to “Troubleshooting”