> But some environments are notoriously noisy. Many years ago I put a system using several Z80s and a PDP-11 in a steel mill. A motor the size of a house drawing thousands of amps drove the production line. It reversed direction every few seconds. The noise generated by that changeover coupled everywhere, and destroyed everything electronic unless carefully protected. We optocoupled all cabling simply to keep the smoke inside the ICs, where it belongs. All digital inputs still looked like hash and needed an astonishing amount of debounce and signal conditioning.<p>:-)<p>I had a similar experience with a elevator motor and a terminal. The electronics worked absolutely fine, but when someone operated the elevator it occasionally produced phantom keypresses on the capacitive keypad.<p>This was perhaps understandable, but what really confused the users was that these phantom keypresses sometimes pressed the not fitted debug buttons (which weren't on the production keypad) which stuck the device into debug mode!<p>We learnt not to include the debug code in the production firmware and beefed up the transient suppression hardware and the debouncing firmware to fix.
> <i>Years ago a pal and I installed a system for the Secret Service that had thousands of very expensive switches on panels in a control room. We battled with a unique set of bounce challenges because the uniformed officers were too lazy to stand up and press a button. They tossed rulers at the panels from across the room. Different impacts created quite an array of bouncing.</i><p>It's impossible to guess how users will use a system until they can be observed in the wild.
> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes.<p>Orthogonally to the point of this excellent article, I found it striking how this was probably true, once--and then TVs got smart enough that it took seconds to change channels, instead of milliseconds. And then it was no longer possible for input failures to be corrected subconsciously.
This is one of the best treatises on debounce, I've read it a number of times and probably will again.<p>One of the best things I've done to help with really bad debounce is spend time testing a number of buttons to find the designs that have, at the hardware/contact level, much less bounce. Some buttons wind up with tens of ms of bounce, and it's hard to correct for it and meet expectations all in software.
I've been using the perhaps-too-simple:<p><pre><code> - Button triggers interrupt
- Interrupt starts a timer
- Next time interrupt fires, take no action if the timer is running. (Or use a state variable of some sort)
</code></pre>
Of note, this won't work well if the bounce interval is close to the expected actuation speed, or if the timeout interval isn't near this region.
Analysis is nice, although the graph style is very much 2005.
The conclusion is that as long as you don't get a crappy switch, 10mS debounce interval should be sufficient.<p>I would not pay much attention to the rest of the text.<p>The hardware debouncer advice is pretty stale - most of the modern small MCUs have no problem with intermediate levels, nor with high frequency glitches. Schmidt triggers are pretty common, so feel free to ignore the advice and connect cap to MCU input directly. Or skip the cap, and do everything in firmware, MCU will be fine, even with interrupts.<p>(Also, I don't get why the text makes firmware debouncer sound hard? There are some very simple and reliable examples, include the last one in the text which only takes a few lines of code.)
This is an interesting take on debouncing, but I found the choice of TV remotes as an example a bit confusing. From my understanding, the issues with remote controls aren’t typically caused by bouncing in the mechanical sense but rather by the design of the IR communication. Most remotes transmit commands multiple times per second (e.g., 9–30 times) intentionally, and the receiver handles these signals based on timing choices.<p>If there are problems like double channel jumps or missed commands, it’s more about how the receiver interprets the repeated signals rather than a classic switch debounce issue. There’s definitely a similarity in handling timing and filtering inputs, but it seems like the core issue with remotes is different, as they must already handle repeated commands by design.
I've been given a lot of suggestions for debouncing switches over the years. I'm just doing hobby stuff, either I have an endstop switch for some CNC axis, or more recently, some simple press buttons to drive a decade counter or whatever. My goal for one project was just to have a bit counter that I could step up, down, reset, or set to an initial value, with no ICs (and no software debounce).<p>I got lots of different suggestions, none of which worked, until I found one that did:
1) switch is pulled high or low as needed
2) switch has capacitor to ground
3) switch signal goes through a schmitt trigger<p>I designed this into its own PCB which I had manufactured and soldered the SMD and through-hole and ICs to that, and treat it as its own standalone signal source. Once I did that, literally every obscure problem I was having disappeared and the downstream counter worked perfectly.<p>When you look at the various waveforms (I added a bunch of test points to the PCB to make this easy) the results of my PCB produces perfect square waves. I found it interesting how many suggested hardware solutions I had to try (simple RC filter did not work) and how many "experts" I had to ignore before I found a simple solution.
My test whenever I get handed someone else's code with a debounce routine is to hammer the buttons with rapid presses, gradually slowing down. That shows if the filter is too aggressive and misses legitimate presses. I also see strange behavior when they're implemented wrong like extra presses that didn't happen or getting stuck thinking the button is still held when it isn't.
I saw this site in one of the comments on <a href="https://hackaday.com/2025/01/04/button-debouncing-with-smart-interrupts/" rel="nofollow">https://hackaday.com/2025/01/04/button-debouncing-with-smart...</a>
Be sure to read Jack’s mega treatise on low power hardware/software design if you haven’t yet.<p><a href="https://www.ganssle.com/reports/ultra-low-power-design.html" rel="nofollow">https://www.ganssle.com/reports/ultra-low-power-design.html</a><p>One of the best practical EE essays I’ve ever read, and a masterwork on designing battery powered devices.
I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.
Wish I had known about this article last year when developers added debouncing to the Sensor Watch project. I had to learn a lot of this from scratch in order to review and merge in their changes.<p>I'm still running their code right now on my watch. It uses timers to allow the switch to settle before triggering input events. Dramatically improved its usability. Latency noticeably increased but without it interfaces which required holding down buttons simply didn't work reliably.
I read through a whole page, wondering when we are getting to legal stuff, before I went back and re-read the title. "Contact" not "Contract"....
I've actually never really had much issue with switch bounces - I think many modern microcontrollers have built in gpio circuits which seems to help with this.
What's with the advice about interrupts and undebounced signals?<p>What does it mean that a flip-flop gets confused? What kind of undesired operation could that cause?<p>Because, quite honestly, if connecting directly means occasional transient failures, then having less hardware is a tempting tradeoff on small PCBs.
I've used that article several times in the past. I'll also note that many years ago, on projects which were not cost sensitive, we would often use the MC14490 IC for hardware debouncing (mentioned in part 2 of this article).
the evoluent vertical mouse I use has a notorious short lifespan because the switches aren't debounced or aren't debounced for a long enough period after only a year or two of wear. i demonstrated on an arduino that additional debouncing logic could fix the issue transparently to the user but never went further than that.