Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi GPIO interrupt debouncing not great #85

Open
flyte opened this issue Jan 24, 2020 · 4 comments
Open

Raspberry Pi GPIO interrupt debouncing not great #85

flyte opened this issue Jan 24, 2020 · 4 comments

Comments

@flyte
Copy link
Owner

flyte commented Jan 24, 2020

I've given the interrupts a test, and while they work, I get pretty bad bouncing on a simple switch (no hardware debouncing), which triggers the interrupt on almost every 'release' as well as each 'press'.

bounce

I've configured the software with interrupt: rising which should (and does) trigger when I press the button, however it also triggers quite often when I release the button. You can see why in the waveform above. The Pi's GPIO lib doesn't seem to be adequately protective of this, given that it should really discard the rising edge if it occurs within bouncetime of a falling edge.

I wonder if there's a neat way we can protect against this, which will work regardless of debounce implementations offered by the GPIO libs we use?

@BenjiU

@BenjiU
Copy link
Collaborator

BenjiU commented Jan 24, 2020

Do you have a pullup/down configured? I have the switch on a light bulb here and it works with the 100ms default bounce time, no double trigger.

digital_inputs:
  - name: LichtSchalterLinks
    module: raspberrypi
    pin: 17
    interrupt_payload: "1"
    pullup: yes
    pulldown: yes
    interrupt: both

@flyte
Copy link
Owner Author

flyte commented Jan 24, 2020

Yep, it's configured with a pulldown.

  - name: button3
    module: raspberrypi
    pin: 18
    interrupt_payload: trigger
    interrupt: rising
    bouncetime: 600
    on_payload: "ON"
    off_payload: "OFF"
    pulldown: yes

@flyte
Copy link
Owner Author

flyte commented Jan 24, 2020

I wonder if it's because you have interrupt: both, which will probably take into account the debouncing of both rising and falling edges. In which case, we'd need a way to establish whether the trigger was a rising or falling one in order to be useful.

@BenjiU
Copy link
Collaborator

BenjiU commented Jan 24, 2020

That's the problem, I guess: the library doesn't support, what interrupt occured... Then we would have to register to both interrupts (although only rising is configured) and try to recognize the interrupt level (with sleeps?!) and only transmit rising interrupts ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants