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)
@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!
I’m satisfied the latter explains the former.
Yep, that’s usually what happens, the initialized tick is greater than the “older” samples causing
diffto be negative and greater thansteadyUs(resulting in okay behavior). It’s only when the samples are newer inalertGlitchFilterthat the problem occurs (diffless thansteadyUs).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.