Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Debounce a Contact (2014)

ganssle.com

Post reply on HN
Print view View original

21–30 of 82 posts

Re: How to Debounce a Contact (2014)

#21

Post by nickcw »

> 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.

:-)

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.

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!

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.

Re: How to Debounce a Contact (2014)

#22

Post by ghusbands »

matheusmoreira wrote: post #15

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. 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 wh…

Debouncing doesn't need to delay a touchstart event, in general, so latency shouldn't really increase in a carefully designed system, especially if you can be animating in advance of the touchend event.

Re: How to Debounce a Contact (2014)

#24

Post by StayTrue »

geerlingguy wrote: post #4

This is one of the best treatises on debounce, I've read it a number of times and probably will again. 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.

Agree. Helped me (a software guy) when I needed it. Automatic upvote.

Re: How to Debounce a Contact (2014)

#25

Post by robinsonb5 »

khafra wrote: post #6

> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes. 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 subco…

And yet if manufacturers cared enough about UX it wouldn't take much for input failures to be subconsciously correctable again. All you need is some kind of immediate feedback - an arrow appearing on-screen for each button press, for instance (or a beep - but I'd be the first to turn that off, so for the love of all that is holy, don't make it always-on!).

What's crucial, though, is that mistakes or overshoots can be (a) detected (for example, if three presses were detected, show three arrows) and (b) corrected without having to wait for the channel change to complete.

Re: How to Debounce a Contact (2014)

#26

Post by the__alchemist »

I've been using the perhaps-too-simple:

  - 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)
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.

Re: How to Debounce a Contact (2014)

#28

Post by gosub100 »

somat wrote: post #16
khafra wrote: post #6

> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes. 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 subco…

nobody cares enough to actually do it. but what would it take to have near instantaneous channel changes again?, prestarting a second stream in the background? And realistically the linear array of channels is also dead so it really does not matter. so I guess the modern equivalent is having a snappy UI. A horrible idea, as if our current tv features were not already bad enough. the modern equivalent to quick channel…

I think it's irrelevant because TV is dead. But I do remember with rose tinted glasses the days of analog cable where changing channels was done in hardware and didn't require 1.5s for the HEVC stream to buffer

Re: How to Debounce a Contact (2014)

#29

Post by dpkirchner »

bambax wrote: post #13

> 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. It's impossible to guess how users will use…

This probably induced a lot of Object Thrown Operation (OTO) once word spread to everyone -- not just the lazy -- that it was possible to activate the buttons from afar.

Re: How to Debounce a Contact (2014)

#30

Post by Certified »

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.
Post reply on HN