pigpio: Glitch filter creation causes unexpected level change callback

The following code seems to trigger a callback, when I would expect no callback to be triggered.

I’ve been able to reliably cause this when running the script from a remote computer connected to the pi, but have also seen this on the pi itself (but much less often). It seems like it might have to do with setting the glitch filter since I have not been able to reproduce the behavior with the glitch filter lines removed.

I haven’t done a full investigation yet, but I would like to get some feedback on whether this is expected or not.

I’m using a raspberry pi model 3B+ with pigpio version 1.46 and python 2.7.

This is what I see when I run remotely (I would expect to see no output):

$ python test.py
gpio = 25, level = 0, tick = 2990614791
gpio = 25, level = 1, tick = 2990638556
import pigpio
import time

def cbf(gpio, level, tick):
    print("gpio = {}, level = {}, tick = {}".format(gpio, level, tick))

if __name__ == "__main__":
    pi = pigpio.pi("pi")

    pi.set_mode(24, pigpio.INPUT)
    pi.set_pull_up_down(24, pigpio.PUD_OFF)
    pi.set_glitch_filter(24, 0)
    pi.set_mode(24, pigpio.INPUT)
    pi.set_pull_up_down(24, pigpio.PUD_UP)
    pi.set_glitch_filter(24, .1*1e6)

    pi.callback(24, pigpio.EITHER_EDGE, cbf)

    pi.set_mode(25, pigpio.INPUT)
    pi.set_pull_up_down(25, pigpio.PUD_OFF)
    pi.set_glitch_filter(25, 0)
    pi.set_mode(25, pigpio.INPUT)
    pi.set_pull_up_down(25, pigpio.PUD_UP)
    pi.set_glitch_filter(25, .1*1e6)

    pi.callback(25, pigpio.EITHER_EDGE, cbf)

    # Phantom callback usually occurs within the first 2s
    time.sleep(2)

(This code is a distillation of what gpiozero is doing when setting up a Button with a pigpio backend, so it might look a little strange)

Thanks for this great library, I appreciate the great documentation and hardware capabilities.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 34 (19 by maintainers)

Most upvoted comments

@BTPankow , sorry this has taken some time - I’m just now preparing for the next release (v77). I reviewed your PR and it appears to be very well done - following the contrib guideline and providing test case(s). Its not often this happens so a big thank you!

…it would be nice to know the cause of the timing difference.

I’d prefer to remove the possibility for timing problems and do the initialization in alertGlitchFilter …

I’m satisfied the latter explains the former.

Yep, that’s usually what happens, the initialized tick is greater than the “older” samples causing diff to be negative and greater than steadyUs (resulting in okay behavior). It’s only when the samples are newer in alertGlitchFilter that the problem occurs (diff less than steadyUs).

I think you’re on the right track to getting close to my understanding of the problem. Not sure about the underlying timing inconsistencies, so if you help with that, that would be appreciated.

I’ll update the title and probably submit a pull request with the current fix and a test to reproduce the issue a little later.