Ultimate Guide to Switch Debounce
eejournal.com
eejournal.com
Many UI elements are all too eager to emit hundreds of state update events (like a slider) as the user is finalizing the input they want - but you wouldn't want to send 100 AJAX requests to the webserver while the user's fiddling around. So resetting a 200ms timer before sending the web request is a great analog to the process of physical debouncing.
Useful in interacting with rate-limits, unpredictable externalities that are not schedule bound, etc
It's all rather striking to me, as the concept of debouncing was one of the first things I learned while reading microcontroller code as a child. (No, I'm not kidding--that was the only book on computers I could find growing up in BFE.)
That we still haven't generally solved this in 2020 is appalling.
(There are lots of variations. There was an article in Software: Practice and Experience in the 90s (?) lamenting the UI race in most X interfaces (and probably all other GUIs). Briefly, lots of interfaces can pop up a dialog or whatever while the user is pressing a button underneath. The dialog often gets the press, resulting in the software executing some action the user did not even see, much less intend.)
Trying to pin down the number of milliseconds without context is a great example of bikeshedding.
For most devices it is enough to just probe the switch periodically.
Nobody is ever going to notice couple of milliseconds of lag. Other debouncing strategies also introduce latency as they need to observe the signal for some time.
It is important to set the check period to be longer than settling time.
Assume the switch is in stable state before the check, then there is check and then it is in another stable state. It does not matter which state the check finds as long as the state changes from one stable to another stable. Even if the switch is bouncing at the moment of the check it will be either interpreted as previous state before the switch or the next state after switch.
If you have delicate switch with good (for example gold plated) contacts, to extend the life of the switch it is then possible to only apply potential for a brief period of the check which means that during actual bounce the contact is very unlikely to see any sparks, extending the life of the switch. This does not work for some switches that rely on spark to remove oxides to get good contact.
We've used MAX7370 chip for keyboard applications. Comes with built-in debounce capabilities along with ESD protection, low quiescent current and interrupt-based signal to the MCU. It is expensive but well worth the hassle - it can handle up to 64 switches and saves you the pain of GPIO nightmare with custom matrix. In addition, it comes with a hardware memory buffer so you could do an n-key roll over. I've built stuff that I can mash with my palm - like jamming on a couple of dozen switches at the same time and this chip handles it all. Flawlessly.
I can understand this when this happens to a device that is created to monitor the switch (switch matrix controller, keyboard controller, etc.) but when this happens to a machine that may have something more important to do it feels at the very least inelegant.
Often you want to use interrupts instead of polling - well again, you can just ignore subsequent interrupts if they are within too short of an interval.
Fortunately on many MCUs you can just enable hardware debounce.
And you are really screwed if you have to do it with an extremely simple, and cheap IC, like 4 bit micros, because their CPU power may well be not enough for that, especially if they are to control something real time.
This is exactly why super cheap electronics uses conductive rubber buttons. Conductive rubber buttons don't bounce.
No, no, no, please don't. Almost all appliances I use ignore an estimated 60% of my usual button presses because they're polling in intervals just long enough to not recognise anything, and I absolutely hate it.
I always have to hold it down for a bit to make sure my input isn't just ignored. My laptop's power switch has this issue just like the washing machine, the dish washer and pretty much everything else that's not a PC keyboard, and it's one of the most infuriating UI issues I encounter every day, beside inactive text input fields with blinking cursors or selected text.
That's just sloppy design. "Periodically" has meant "every 20 milliseconds" for projects I've shipped in the past. Anything shorter than 100 ms or so should be imperceptible.
Part of the problem you're likely seeing is due to the rise of capacitive touch "buttons", which are terrible in so many ways. But, alas, they are cheap and give a smooth front face, so designers and product managers love them....
(About the only time they're actually a good solution is when you need a completely sealed button.)
You don't want your washing machine to start just because you bumped into the button. Give it a good press and it's ok. (Same with the mechanical sensitivity of the buttons itself, they're not the same as your phone touchscreen let's put it this way)
In the Third Edition, on page 802, Horowitz and Hill write "For physically large switches, the bounce can be as long as 50ms." That first quote is from a section on clocked debouncing, which can be made insensitive to contact bounce by digital means.
I like the data sheet for the automotive contact debouncing IC.[1] That's very cute. In dirty environments, you need a minimum current and voltage, maybe 10mA, 12V, to punch through dirt and water on the contacts. That IC does that, but it only turns on the power intermittently, so you don't drain the battery polling the dashboard switches.
I've hit that with the antique Teletype machines. They were intended to run with 120VDC on the keyboard contacts, and you need about 24V or so to get reliable punch-through.
[1] https://datasheets.maximintegrated.com/en/ds/MAX6816-MAX6818...
As other posters said another easy effective strategy is to just ignore inputs after the initial transition. You can do this and still pick up long presses too if you need to!
Adding a capacitor fixed it. Which reminds me that I should really invest in an oscilloscope to validate my (not so) educated guesses.
Great resource to read up on this topic, thanks.
As for "immediate", the switch closure feels immediate to human perception (supposedly limited to about 1/20 second, for touch). But to modern electronics, nanoseconds are easily countable; and switch bounce can be measured in microseconds, or even milliseconds for a big, heavy electromechanical component.
Here are some better articles.
https://www.allaboutcircuits.com/technical-articles/switch-b...
https://www.maximintegrated.com/en/design/technical-document...
So, while this switching is generally really fast, there is a period of time when the two metal plates are reeeally close, but not touching.
Small bits of dust, grit and/or oxide on the metal can get in the way while the plates are really close, but not touching, causing electricity to flow, then not flow, then flow...
Arcing can also happen when there's higher voltages used too.
This happens a lot when you're using a push button, and also when you're switching on something that uses lots of current. You can actually hear the problem if you deliberately turn on your light switch really slow... The buzzing you hear is when electricity is arcing across the plates (wearing them out somewhat). It's not a problem for the light, but it's a huge problem for, say, a large pump.
No polling required.
And here's a component values calculator: https://protological.com/debounce-calaculator
If you see the circuit this calaculator (sic) proposes, you'll see it won't debounce fully the closing the switch (and you'll have to invert the logic, which in principle it's ok).
Plus adding one component to the circuit (you'll most likely have the resistor anyway).
It might work for your case but you'll most likely need a software solution as well, depends on your switch and the logical gate input impedance.