I am using a Raspberry Pi 3 and in my particular case, I am using it to sense when either a button is pressed, or power is dropped, both using the same GPIO input.

Both functions work, however, there are small glitches that trigger my shutdown circuit, like plugging into the audio jack or plugging in the HDMI, or lights in the room, looking at it etc...

I've attempted hardware fixes like a cap on the input, to no avail.

I am led to believe that I need to use the pi.set_glitch_filter to eliminate this issue, however I do not know how to implement it into my code..

Please have a look at what I am working with and hopefully someone here can clear this up some for me.. The particular piece in my code is "acandbutton"


import sys

import RPi.GPIO as GPIO
import xbmc

powerholdPin = 24   # board pin 36
acandbuttonPin = 23     # board pin 37

def acandbutton_callback(channel):

class Main:
    GPIO.setup(acandbuttonPin, GPIO.IN, pull_up_down=GPIO.PUD_UP)
    GPIO.setup(powerholdPin, GPIO.OUT)
    GPIO.output(powerholdPin, GPIO.HIGH)
    GPIO.add_event_detect(acandbuttonPin, GPIO.FALLING, callback=acandbutton_callback, bouncetime=300)

    while not xbmc.abortRequested:

class TidyUp:

if (__name__ == "__main__"):


The part on the right does everything that it needs to.. The part on the left is getting the spurious activity. It runs well if nothing else electronic is plugged in or switched, like a light in the room, or even my phone plugged into it's charger. It's that sensitive. The power to the PI is consistent and even powered when unplugged due to the UPS, although the intention is to have a clean shutdown when the wall power is either lost or due to a button press. (which both work). It's seeming to pick up on static or other micro-changes also.

Here's a link to another thread of similar issue perhaps..

gpiozero: Ignore false positives/negatives

  • What power supply are you using on your Pi3 ? – CoderMike Oct 4 '17 at 6:24
  • 1
    Anecdotely, I've never had this problem and don't recall anyone here reporting it either, so you may want to double check, e.g., there isn't something loose in the circuit (bad solder joint etc) that is being affected by vibration. – goldilocks Oct 4 '17 at 6:52
  • 1
    I can't comment on the code, but you have given no detail of what is connected to the Pi. This is a high impedance circuit (relying on internal pullup). I would be looking at applying established engineering practice to minimise any interference before trying to apply a software solution. – Milliways Oct 4 '17 at 7:49
  • I am using "The official and recommended universal micro USB power supply for Raspberry Pi". The spurious activity occurs regardless of the peripherals connected. Flipping a light switch in the room will activate the ShutDown sequence. – Scott Cox Oct 4 '17 at 13:17
  • As with other commenters, I think this is a HW issue with your circuit. My guess is that your pull-up / pull-down associated with the buttons is missing or insufficient. Without details of the HW configuration, however, all we can do is guess. – Brick Oct 4 '17 at 13:26

I think information about the circuit is more important. Because your problem does not make sense, I will edit the answer if you add more info.

This functionality is not exposed to the python library you are using. Your best and simplest option is to check the state in your callback function.

The function pi.set_glitch_filter is a pigpio function, the functionality is described in the documentation

This requires running additional software (pigpiod - a gpio server), which may or may not be compatible with the library you are using

Note: By deglitching I assume you mean ignoring spurious events, i.e. ones that are short and not "real". As opposed to debouncing which is when a "real" transition is followed shortly by many rapid transitions due to mechanical action.

Neither pigpio, nor RPi.GPIO implement a real glitch filter.

RPi.GPIO runs a polling loop, and therefore there is an inherent glitch filter in that events shorter than the poll time (probably a few ms, but haven't checked) are never detected.

pigpio is a socket based protocol, and the 'glitch' fliter enabled with pi.set_glitch_filter is software filtering.

This filter affects the GPIO samples returned to callbacks set up with callback and wait_for_edge.

It does not affect levels read by read, read_bank_1, or read_bank_2.

Switching to callbacks using pigpgio may be sufficient, even if it is software deglitching.

Real Hardware deglitching exists, but is poorly documented in Raspberry Pi. This is deglitching done on the clock cycle level (e.g. signal must be stable 2 PIO clocks before latching), configured directly via registers, and is used in hardware drivers and kernel side interrupt handlers. This is means interrupts as fast as possible while filtering many spurious events.

| improve this answer | |

I use falling edge to reboot. Pin 11 and gnd.

import RPi.GPIO as GPIO

import os



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

GPIO.wait_for_edge(channel, GPIO.FALLING)

os.system("sudo reboot")

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.