6 ms·

The simplest strategy I have been using successfully since forever is one that I found on some device I have repaired. For most devices it is enough to just pr

The simplest strategy I have been using successfully since forever is one that I found on some device I have repaired. 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.

fermienrico 7y ago
When you have more than a dozen switches to debounce, it is best to opt for a hardware solution unless you're making something in the 100k+ quantities. 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.
- castratikron 7y ago
  If you are doing this for a Linux platform, there's actually a gpio matrix keypad driver that works really well. The driver shows up as a regular keyboard input device that can interface with any program that knows how to read /dev/input things.
  - lmilcin 7y ago
    I do not like the idea of sending an interrupt and cause a havoc on OS side every time two metal plates bounce off each other. 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.
    - fermienrico 7y ago
      Agreed, just as encapsulation/abstraction is an important and indispensible concept in software engineering, it is also equally if not more critical in hardware applications. For most electronics, there is usually an IC that can solve a problem better than you can develop, often cheaper. 25 discrete components can be encapsulated by a single IC sometimes (with a couple of bypass caps).
pantalaimon 7y ago
> For most devices it is enough to just probe the switch periodically. 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.
- baybal2 7y ago
  > 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. 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.
  - ksangeelee 7y ago
    Conductive rubber buttons absolutely do bounce (though I presume that was a joke).
    - baybal2 7y ago
      ??? for as long as I remember, all and everybody was using them exactly for that reason. Slow raising edge can be considered a bounce by some logic, but that is easily fixable by Schmitt triggers
      - ksangeelee 7y ago
        Thanks, that's interesting. I suppose they specifically choose contacts with a high resistance.
mrob 7y ago
There's no need for debouncing to introduce latency under normal circumstances. React immediately to state changes, and whenever you observe a state change begin temporarily ignoring further state changes for long enough for the bouncing to settle. The only added latency is on the falling edge of extremely short presses (or rising edge of extremely short releases), which in practice doesn't happen because of limited speed of the human hand. But note that latency-adding debouncing methods double as noise filters, which this technique does not, so you might want to add a bit of noise filtering (and associated latency) too.
- Cerium 7y ago
  I think of this as "non causal debouncing". You debounce before the event happens.
alpaca128 7y ago
> For most devices it is enough to just probe the switch periodically. 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.
- jimktrains2 7y ago
  Power buttons, like on a PC or washing machine, often require being held as a means of preventing accidental activation.
  - alpaca128 7y ago
    I don't mean just power buttons. When I said almost every button not on a PC keyboard I meant it. On the washing machine every single button has to be held almost half a second or it won't do anything. It's super frustrating. But of course it's possible to mess this up the other way too - one of my devices reacts quick to button presses, but you have to wait about half a second until it will react to the next press.
- deleted 7y ago
  [deleted]
- exmadscientist 7y ago
  > 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. 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.)

fermienrico 7y ago

When you have more than a dozen switches to debounce, it is best to opt for a hardware solution unless you're making something in the 100k+ quantities. 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.

castratikron 7y ago
If you are doing this for a Linux platform, there's actually a gpio matrix keypad driver that works really well. The driver shows up as a regular keyboard input device that can interface with any program that knows how to read /dev/input things.
- lmilcin 7y ago
  I do not like the idea of sending an interrupt and cause a havoc on OS side every time two metal plates bounce off each other. 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.
  - fermienrico 7y ago
    Agreed, just as encapsulation/abstraction is an important and indispensible concept in software engineering, it is also equally if not more critical in hardware applications. For most electronics, there is usually an IC that can solve a problem better than you can develop, often cheaper. 25 discrete components can be encapsulated by a single IC sometimes (with a couple of bypass caps).

pantalaimon 7y ago

> For most devices it is enough to just probe the switch periodically. 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.

baybal2 7y ago
> 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. 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.
- ksangeelee 7y ago
  Conductive rubber buttons absolutely do bounce (though I presume that was a joke).
  - baybal2 7y ago
    ??? for as long as I remember, all and everybody was using them exactly for that reason. Slow raising edge can be considered a bounce by some logic, but that is easily fixable by Schmitt triggers
    - ksangeelee 7y ago
      Thanks, that's interesting. I suppose they specifically choose contacts with a high resistance.

mrob 7y ago

There's no need for debouncing to introduce latency under normal circumstances. React immediately to state changes, and whenever you observe a state change begin temporarily ignoring further state changes for long enough for the bouncing to settle. The only added latency is on the falling edge of extremely short presses (or rising edge of extremely short releases), which in practice doesn't happen because of limited speed of the human hand. But note that latency-adding debouncing methods double as noise filters, which this technique does not, so you might want to add a bit of noise filtering (and associated latency) too.

Cerium 7y ago
I think of this as "non causal debouncing". You debounce before the event happens.

alpaca128 7y ago

> For most devices it is enough to just probe the switch periodically. 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.

jimktrains2 7y ago
Power buttons, like on a PC or washing machine, often require being held as a means of preventing accidental activation.
- alpaca128 7y ago
  I don't mean just power buttons. When I said almost every button not on a PC keyboard I meant it. On the washing machine every single button has to be held almost half a second or it won't do anything. It's super frustrating. But of course it's possible to mess this up the other way too - one of my devices reacts quick to button presses, but you have to wait about half a second until it will react to the next press.
deleted 7y ago
[deleted]
exmadscientist 7y ago
> 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. 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.)