# RPi GPIO relay interference with input

I'm trying to use a RPi3 to output/control a lamp using this relay module.

I also want to be able to read from a push button and a switch.

The problem I'm having is that it looks like switching the relay is introducing noise in to the GPIO input and creating false positives.

The RPi and relay module are in a outdoor enclosure 190mm x 145mm x 140mm. They are right to each other.

I tried using a solid state relay and that solved the problem of the interference, but I would prefer to use a conventional relay because of size and pricing.

I have tried to see the noise picked up by the GPIO using a cheap Hantek digital USB oscilloscope, but unfortunately wasn't able to see anything. Still waiting to check with my analog oscilloscope. In addition, I'm thinking about trying shielded cable from the pushbutton and switch to the GPIO and also wrapping the relay module in grounded metal mesh to create a Faraday cage.

Till now I've tried putting a low-pass filter for each inputs.

The first circuit I tried was: C1 - 10n and 100n

simulate this circuit – Schematic created using CircuitLab

Then I tried a low-pass filter:
R1 - 100 and 1k
C1 - 1u, 10n, 100n

simulate this circuit

Also I tried with GPIO pull-up on and off

In any case none of them improve the result.

On the software side of things I'm using Python, RPi.GPIO event_detect; I tried increasing the bounce time and inserting a delay after event-detect to "filter" human generated events, but this would only work for the push button case, not switch.

Any advice would be appreciated.

UPDATE: This Relay Module insert a lot of noise, I tried with the RPI HAT slice of realy and tha same code worked fine, could detect any false positives on a quick test run.

this is the code:

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BCM)
GPIO.setup(24, GPIO.OUT)
GPIO.setup(26, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.setup(20, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)

print "GPIO 2"

print "Button"

print "Switch"

if __name__ == '__main__':

while True:
pass


Regardless I'm still looking for how to be able to use that board.

• Are you trying to control this relay directly from Raspberry Pi? Anyway I just barely understand what and why you trying to do, and what is the problem – Andrey Pro May 29 '17 at 16:26
• While not strictly debouncing since the cause is not contact bounce, you could try to just ignore the input for a half second after every change in the relay. However it would be worth suppressing electrical effects as they could cause cumulative damage to the logic circuitry, even if they don't destroy it immediately. – Chris Stratton May 29 '17 at 17:09
• Ignoring the input while switching output is a good idea. I'll give it a try. – maco1717 May 30 '17 at 10:39
• I dont know how I'll be able to implement that using events, I'll have to think about it. – maco1717 May 30 '17 at 10:49
• @AndreyPro - Yes trying to control the relay directly from the Rpi, which works fine. Only that by doing so the general functionality of my application is being affected. – maco1717 May 30 '17 at 10:57

You should be able to debounce your switch in software. It is always a good practice to "pull" the input in the opposite direction of your switch action using a 10k ohm or so resistor.

Regarding the relay switching transients, it appears that there are snubbing diodes across the relay coils. So I would try placing a 100 uF capacitor or larger directly across the power supply terminals of the relay board. This will help "hold up" the 5 volt supply to the board when the relay is energized.

• Are you saying to put a cap between vcc (3.3) and GND of the relay board? obviously both come from the RPi... also the relay are active low, I dont know if that will affect. – maco1717 May 30 '17 at 10:43
• On the debounce switch by software I suppose you mean something like storing the previous value of switch see when it changes, wait a few mS and then take action. correct? – maco1717 May 30 '17 at 10:47
• Yes, I would recommend a cap at the relay board as you describe. It provides local energy storage so that the relay turn on does not need to pull the peak current through the bus. – Glenn W9IQ May 30 '17 at 11:51
• You have the software debounce concept correct. A wait time of 50-75 mS usually does a good job. If you make it too high, the user will feel it is not responsive and if too low, you can get multiple triggers. – Glenn W9IQ May 30 '17 at 11:54
• Im suspecting this relay inserts "more that usual" EMI as I have tried with RPi realy HATs with other relay and dont create this problem, I going to run some test latter when I get back from work on the Pi HAT see if it's actually less noisy (EMcally speacking) – maco1717 May 30 '17 at 12:08

I've faced exactly the same problem and just before going insane, I found the root cause and the solution.

Your problem is that the edge detect is very, very, very, very sensitive for voltage spikes. You probably will see false detections even when you switch on or off other equipement in your house as well.

To overcome this problem, just put a 10ms sleep delay in your callback definitions and read the pin status again; if still same than perform action, otherwise it was just a spike. Capacitors can help, but have to be designed in a specific way so the timing is perfect, also they have a different loading and unloading behavior, so this is rather difficult!

Please have a look at: https://www.raspberrypi.org/forums/viewtopic.php?t=134394 for some real proper information! Hope you will succeed!

• Thanks, I wanted to avoid using "delayed check". I did experience the false detecting with switching on/off equipment in my house. Specially things with heaters and motors... the oven was beautiful... Thanks. – maco1717 Mar 15 '18 at 18:19

I am not sure whether it applies, but there are multiple possible problems with these relays.

1. They have 5 V coil, thus requiring level shifting from RPi's 3.3 V GPIO.
2. The coil resistance is only 70 Ohm, which would cause to draw large current from the GPIO pins, possibly destroying it. This could be solved together with p. 1
3. A Relay needs a flyback diode to protect GPIO pins from potentially destructive EMF.

Unless the relay module provide for them (couldn't find the module data sheet), you must do it yourself. Now, given that the module is designed for Arduino, which, AFAIK, has 5 V GPIO, there is high probability that at least p. 1 is on spot. That is, the module expect 5 V as control voltage and trying to control it with 3.3 V RPi GPIO leads to unstable operation.

• I belive the board come with a snubbing/flyback diode, I requested the reseller to provide some documentatation. I'm using the 5V from the pi. – maco1717 May 30 '17 at 18:39
• The RPi GPIO is 3.3 V, or you mean you do level-shift? It is hard to prove anything without data sheet, or at least a schematioc of the board. – Andrey Pro May 30 '17 at 18:52
• Oh I see what you mean, I tought u meant power. As RPi has 5v power pin aswell. You think if I controll a transistor to on/off via GPIO and output from the RPis 5V it might solve the issue? – maco1717 May 30 '17 at 19:57

At last a 100uf cap on the relay board between VCC and GND solved the issues of false positives.

No level shifting needed.

Thanks to all.

UPDATE: False alarm! was testing whitout a load (LAMP) it dosnt work with the relay module or RPi HAT.

I'm starting to believe that I'm traying to do something imposible. think I only have the options of SSRs and/or software "debouncing" left...