Hi folks!

I'm currently working on a little project that involves a Raspberry Pi (an old RPi 2 Model B) and a couple of buttons. I'm writing the software in Go(lang) with periph.io as abstraction over the GPIO layer. I have a couple of questions, which I've made bold below for your convenience

The library has a method to wait for edge events on a specified pin (WaitForEdge(timeout time.Duration) bool), and I'm noticing multiple edge events for single button presses. I am assuming I'm doing something wrong, but I'm not entirely sure what.

I have tried:

• Setting the pin to Pull Down and using the button to connect 3V3 and the GPIO pin.
• Setting the pin to Pull Up and using the button to connect Ground and the GPIO pin.

Both result in a varying number of edge events. Sometimes just two (expected, I'm watching both edges), sometimes 3, sometimes anywhere from 4 - 10. The button I actually intend to use is a three pin one (VCC, GND, S) which makes the S pin high on press, so I'm guessing the pull down option is the only viable one there.

Now this could be in the Go library I'm using of course, although I think it's pretty a pretty widely used and and if it had these kinds of issues, they would've probably surfaced before, so I'm still assuming I'm at fault and not the library (it claims to basically proxy the edge events straight from the OS/hardware).

Q1: Is there a way to read low level GPIO edge events directly on the Pi via SSH, so I can verify if there are indeed multiple edge events being triggered?

I have also seen examples online of people using capacitors in their button > GPIO circuits. Now I am currently working my way through an electronics course, but am doing so in parallel with practical experimentation and although I've learned roughly what a capacitor is/does, I'm not sure if and how it could aid in this button circuit.

Q2: Could a capacitor help create a steadier signal on the GPIO pin, so it'll more reliably trigger a single edge event on press and one on depress of the button?

Thanks in advance for your time and effort!

 

You seem to have discovered contact bounce.
You have a few options in software and hardware.
Your switch is unusual, most people use a SPST switch connected to ground with a pull-up resistor (some connect the switch to V+ and use a pull down -the effect is the same.
You can put a capacitor across the switch to filter out the contact bounce, but it won’t work if you are using a SPDT switch (You could just disconnect the V+ pin). If you do, then you must switch on the hysteresis in the GPIO.
Or you could tackle it in software by taking the first edge, then ignoring everything else for, say, 10ms.

 

This might help.

https://github.com/google/periph/blob/main/experimental/conn/gpio/gpioutil/debounce.go

 

@Ian0 Thanks a lot for the thorough (and quick) reply. The term contact bounce gave me was exactly what I needed in order to do some better Googling.

The switch seems unusual indeed, I bought them because they come on a small PCB that makes mounting them easier. I kinda regret it already (It's this one)

I'm going to look into adding a capacitor to filter the contact bounce out in hardware (because it seems both interesting to learn more about, and the cleaner option). In the meantime (I'm impatient by nature), I did a quick attempt at debouncing in software and that at least enables me to reliably detect a single button press. I'm also considering replacing the buttons with different ones. These don't seem ideal.

You've definitely helped me out here, appreciate it

@Yaakov Excellent, thanks a lot! Hadn't come across that one yet, and it's comforting to know that it's apparently a more common problem. There does seem to be a minor issue with the linked code (it's hardcoded to use gpio.BothEdges instead of the edge parameter), but it's given me great input for figuring out a software debounce solution.

 

@Ian0

The switch seems unusual indeed, I bought them because they come on a small PCB that makes mounting them easier. I kinda regret it already (It's this one)

That looks like a Diptronics DTS2 to me, and that is a SPST switch. Although it has 4 pins they are connected together in two pairs.
I use loads of them, and I avoid the contact bounce by only sampling them twice a second. OK so the customer doesn’t get a absolutely immediate response when he presses the button, but he needs to be patient!
I don’t know what the third connection on the pin header does. Is there a pull-up resistor on the little pcb?

 

That looks like a Diptronics DTS2 to me, and that is a SPST switch. Although it has 4 pins they are connected together in two pairs.
I don’t know what the third connection on the pin header does. Is there a pull-up resistor on the little pcb?

According to the website I bought them from, there's a pull down resistor on board. There's also an LED on board btw, which lights up on press.

 

You can waste your time with clever algorithms to avoid contact bounce if you want to. Or you can do it the easy way--just read the button at some fixed rate, controlled by a timer. 30msec intervals is about right. That's all you need to do.

 

You can waste your time with clever algorithms to avoid contact bounce if you want to. Or you can do it the easy way--just read the button at some fixed rate, controlled by a timer. 30msec intervals is about right. That's all you need to do.

@John P Fair point, as a software developer I guess it's in my DNA to stay away from busy loops wherever I can, but it is indeed worth considering here. With polling the button state every 30ms, there's still a small risk of missing a really quick/short press, plus a (probably unnoticeable) delay in registering the press if it happens right after the last poll. I admit these are both very theoretical/principal concerns and not practical ones. I currently have a *very* crude debounce solution that works pretty well, I'm gonna continue validating that a little bit and keep the polling busy loop as a backup option.

Thanks!

 

With polling the button state every 30ms

Using a timer to do it makes this easy.

 

With polling the button state every 30ms, there's still a small risk of missing a really quick/short press,

If a human could press a button within 30mS, he'll be some kind of ninja....

I beep a sounder for 250mS ( to tell them to let go )... Wasting cycles isn't a bad thing..

 

Haha, fair enough, it is indeed a purely theoretical concern

 

If the button was only pressed for 30ms, then it is most likely that the customer did not intend to press it.