Go Down

Topic: When to use switch debounce? All switches? Or just PB switches? (Read 629 times) previous topic - next topic

Doug101

Silly questions, but when is switch debounce used.

In all of the tutorials I've completed I never really thought about switches and debounce.

But now that I'm working on my first "real" project I'm realizing there are really two types of switches.  Door bell push button and snap action micro switches.

Should debounce be used with all switches?  I'm thinking maybe not.  Isn't a micro switch a snap-action switch which doesn't require debounce?

Where as a door bell push button switch probably needs debounce.  There's no snap action with a PB switch so maybe that's when debounce should be used.

But then again maybe debounce is used only for special applications.

Need a bit of assistance.

larryd

For 99% of my sketches I use Mr. Gammons SwitchManager library.
It handles debouncing, change in state and timehandling for long and short pushes.
If you handle all switches with a common task, it becomes a piece of cake.
http://forum.arduino.cc/index.php?topic=350287.0   

 Jack Christensen has a nice library too.
https://github.com/JChristensen/JC_Button   




No technical PMs.
The last thing you did is where you should start looking.

Paul_KD7HB

Any of the so-called snap-action switched will probably require either hardware or software debounce. The reason is the energy stored in the blade making the contact will cause the contact end to bounce off the fixed contact.

You can tell if you need it if your program tries to do what the switch tells it to do more times than you move the switch. If your code does something that takes quite a while, perhaps 1/2 second, then there is no need for debounce.

Another place to debounce is a reed switch operated with a magnet. If the magnet is a bar magnet and is parallel to the reed switch, the switch cannot bounce. Other types of magnets and other orientations will require debounce.

Hope that helps a bit.

Paul

ReverseEMF

Paul_KD7HB pretty much covered it, but to elaborate:

For the example of the Doorbell -- no debounce needed, because even if the switch bounces, you're not going to hear the difference in the Doorbell.  Switch bounce typically happens within a 20mS window [with ~5mS the most common period I've seen -- with occasional longer periods].  It's unlikely you will hear such quick transitions in a Doorbell.  And even if you have super human ears, it's still going to, pretty much, register as someone at the door.

For the snap action micro switch, it depends on the application.  If more than one quick transition, before the new switch state settles in, will cause erratic behavior, then, by-all-means, debounce the switch.   If not--no need. 

If, for instance, the switch merely turns on an indicator light, or stops a count [i.e. gates a counter], then debounce probably isn't required.  But, if the switch action triggers some sort of transitioning application, then, definitely debounce the switch!  For instance, if the switch serves as the clock for a counter, then bounce will cause spurious counts, when you actually want only one count per switch transition [or per switch close, or per switch open]. 
"It's a big galaxy, Mr. Scott"

Please DON'T Private Message to me, what should be part of the Public Conversation -- especially if it's to correct a mistake, or contradict a statement!  Let it ALL hang out!!

wvmarle

Indeed.
If you care about the number of presses: use debounce.
If you just need to know pressed or not: no need to debounce.

Note that debounce can also be done in hardware by connecting a small (100 nF or so) cap across the switch contacts.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

ReverseEMF

Indeed.
If you care about the number of presses: use debounce.
If you just need to know pressed or not: no need to debounce.

Note that debounce can also be done in hardware by connecting a small (100 nF or so) cap across the switch contacts.
But, consider that adding capacitance can cause slower rise or fall times, which can cause edge triggered inputs to not recognize the transition.  Examples of edge triggered inputs are: fast rising, or falling edge interrupt, and edge triggered clock.
"It's a big galaxy, Mr. Scott"

Please DON'T Private Message to me, what should be part of the Public Conversation -- especially if it's to correct a mistake, or contradict a statement!  Let it ALL hang out!!

wvmarle

Usually slower rise times (wired with pull-up resistor), so only a small delay upon release of the button. 100 nF and 30k pull-up (the built-in ones) makes for about 3 ms (1x RC) delay.

In my experience interrupts have no problem with slower rising when timing the charging of a capacitor. It's when the voltage reaches a certain point that the pin goes from HIGH to LOW or the other way around.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

Doug101

Thanks - Good point about using a cap for hardware debounce.

For my applicaiton I'm trying to measure human repsonce time to a visula stimuli, a LED lighting.

I have a series for 40 LEDs being chased in a circle.  Human needs to time the hitting of the button to when LED 22 is lit.


Human visual responce time is about 25 ms.
 

Isn't Arduino Loop time about 1 ms?  Or roughly 1 ms per line of code?






Paul_KD7HB

Thanks - Good point about using a cap for hardware debounce.

For my applicaiton I'm trying to measure human repsonce time to a visula stimuli, a LED lighting.

I have a series for 40 LEDs being chased in a circle.  Human needs to time the hitting of the button to when LED 22 is lit.


Human visual responce time is about 25 ms.
 

Isn't Arduino Loop time about 1 ms?  Or roughly 1 ms per line of code?






Most humans are very quick to anticipate what you are doing and will nullify your test even on the second loop.

Paul

Doug101

Thanks - Good point about using a cap for hardware debounce.

For my applicaiton I'm trying to measure human repsonce time to a visula stimuli, a LED lighting.

I have a series for 40 LEDs being chased in a circle.  Human needs to time the hitting of the button to when LED 22 is lit.


Human visual responce time is about 25 ms.
 

Isn't Arduino Loop time about 1 ms?  Or roughly 1 ms per line of code?


Sorry I should have mentioned once the button is pressed that's it, loop stops.






avr_fred

Quote
Isn't Arduino Loop time about 1 ms?  Or roughly 1 ms per line of code?
No. With modern programming languages, there is no correlation between a "line of code" and time. Many years ago, plc's where measured this way but that's about the only practical example I can think of.

The AVR processors in the Uno and similar Arduinos are RISC based and as a result, they can execute one assembly language instruction in one clock cycle which means a simple assignment instruction in C can execute in 62.5 nanoseconds with a 16MHz clock. That's about where any correlations end as any high level constructs could be arbitrary in time requirements.

FWIW, it's very easy to measure code execution time on Arduinos using the micros() and millis() functions.

Doug101

No. With modern programming languages, there is no correlation between a "line of code" and time. Many years ago, plc's where measured this way but that's about the only practical example I can think of.

The AVR processors in the Uno and similar Arduinos are RISC based and as a result, they can execute one assembly language instruction in one clock cycle which means a simple assignment instruction in C can execute in 62.5 nanoseconds with a 16MHz clock. That's about where any correlations end as any high level constructs could be arbitrary in time requirements.

FWIW, it's very easy to measure code execution time on Arduinos using the micros() and millis() functions.
Got it, thank you.

wvmarle

I have a series for 40 LEDs being chased in a circle.  Human needs to time the hitting of the button to when LED 22 is lit.


Human visual responce time is about 25 ms.
Then all you're testing is how well they can anticipate when exactly that specific LED is lit, and it has nothing to do with reaction time.

Now lighting up random LEDs and asking them to press the button when a specific LED is lit, that would be reaction time, but you would get no-where near 25 ms. More like 500-1000 ms for a normal person to react to an event.

Quote
Isn't Arduino Loop time about 1 ms?  Or roughly 1 ms per line of code?
Depends on your program. Can be less, can be a lot more. One line of code can evaluate to a single instruction, or a thousand instructions (floating point calculations are huge, as can be lines that call external libraries).
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

Wawa

For my applicaiton I'm trying to measure human repsonce time to a visula stimuli, a LED lighting.
If you want a short resonse time, then don't use debounce.

Detection of the button press should start with the first actual contact.
If it bounces 100 times after that should be ignored by the code.
Leo..


Go Up