Input push buttons - how long do you debounce for?

pacman

Input push buttons - are there some guidelines for 'good' debounce times?

For a momentary button what vales do you use?

For a 'push and hold' button (like say on the radio memory button on a car stereo) what sort of debounce times and delay times do you use.

Not a biggie, just wondering if the collective intelligence of the group could save me some frigging about time....

Thanks

potatohead

Seems to me, the right answer depends on the rate of input required. A few hundred milliseconds would do it for most things.

W9GFO

I use a separate cog for monitoring buttons since there are some actions that take a second or two and I don't want to miss a button press.

The time the button is pressed is saved in a variable (btn1) and checked accordingly.

I use the constants Short, Medium and Held to describe how long they are pressed.

if btn1 > Short
xxdoSomething
if btn1 > Medium
xxdoSomethingElse
if btn1 > Held
xxReturnToMenu

Not sure what the actual times are for each, it doesn't take long to adjust the constants to your liking.

Rich H

Leon

It depends on the buttons, some manufacturers specify it. 20ms is quite common.

localroger

I've been using 50 msec since about forever, just seems to work.

Ravenkallen

100ms is what i use...I just like to be extra cautious..

LukeH

It depends what kind of switch you use. The small tact switches that Parallax sells are pretty good and have a very short bounce duration. Some large pushbutton switches especially with mechanical spring-loaded contacts can have long bounce durations. Sometimes you can look at the output of the pushbutton on an oscilloscope to get an idea of how long you'll need to debounce for. Try pressing the button gently then slamming it hard - there may be a significant difference in the bounce behavior.

20ms seems to work well for me with the small tact switches. Don't forget you may want to debounce on key-up as well as key-down, depending on how you design your human interface mechanization.

I have one device which requires a key press AND release before it will do anything - so you can hold the button as long as you want, but it won't do anything until you let go. This requires a debounce on both sides. I run 20ms of 'down' debounce and 20ms of 'up' debounce and it works great.

If I find a switch that needs more than 100ms of debounce, I look for a different switch. Debounce too long, and your device may appear laggy or unresponsive. The brain begins to perceive delays longer than this - remember 100 ms is 1/10 of a second. Think of how long you depress a button on a keyboard while typing: it's usually a very short interval: you strike the key then quickly let go.

Also, you can debounce your inputs with hardware; there are many ways to do it. Although very effective, hardware debounce obviously adds to your cost, weight, and power requirements.

W9GFO

LukeH wrote: »

I have one device which requires a key press AND release before it will do anything - so you can hold the button as long as you want, but it won't do anything until you let go. This requires a debounce on both sides. I run 20ms of 'down' debounce and 20ms of 'up' debounce and it works great.

Can you explain more about what problems you run into if you don't debounce on release? I can't see why it would be necessary.

Rich H

LukeH

Rich - you're probably right, since the switch-closing event was already debounced, and the next event to trigger something will be the switch opening whether it bounces subsequently or not (the opening bounces shouldn't trigger the debounced closing logic). I chose to include it to be on the safe side, because many switches do bounce quite a bit on opening.


Here is a good article about switch debouncing, for anyone who might not already have seen it.

http://www.ganssle.com/debouncing.htm

potatohead

Re: Slow, and perception of delay.

The 50ms number is a solid one to me. That's a minimum, as a rapid human input would rarely drop below this number. Typing, is one exception I can think of however.

I like the longer times, because I like systems that limit input, because that cuts down on error cases. Where possible, I like to latch things too, so that input is simply ignored, until needed again.

I also think it's good to avoid states on input where possible too. Modal things can get confusing, simply because people don't always remember the state of things, particularly where the input may be complex. Those are like push once for this, twice for that, three times to reset...

The best cases are where the input is repeatable, discoverable, intuitive, consistent. Not always possible, of course, but if possible, preferable.

Another way to look at things is whether or not the response time, or allowable input time, actually adds value. If there isn't any value add, there is a solid case for just insuring that nothing new happens, or that's where "the problem" will be with the input process, means and methods.

kwinn

I use a pasm routine that reads the state of the switch(es) once every millisecond and sets the switch status as high (or low) if it was high (or low) for 10 consecutive reads.

Have never had a problem with false switch readings while using this method.

PS - I have also used a spin loop to read a switch until it was high (or low) for 10 consecutive iterations. Also works well.

Beau Schwabe

20,50,100ms .... I tend to do it by 'popular vote', meaning that I will sample an input for 16 or 32 times (usually a binary weight ; makes it easier in assembly) , and add the switch value to an accumulator. At the end of the loop, I will shift the accumulator right by 4 or 5.

Example:

      repeat 32                 'Button Debounce ; read the "A" and "B" inputs 32 times
        InputA  += ina[0]        
        InputB  += ina[1]
      InputA >>= 5              'Divide "A" value by 32
      InputB >>= 5              'Divide "B" value by 32