The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions.  We hope you enjoy it.  If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to[email protected].
Switch bounce
Why would a switch bounce?  Switches are made of metallic parts (conductive material) that are either in contact, closed, or not in contact (open).  The problem we see is during the transition.  Metal has a certain amount of compliance.  This elastic deformation means that it will act like a spring when struck.  The metal compresses, stores energy, then releases most of the energy in the rebound.  The amount of energy transferred is typically large enough to separate the two materials.  This is a bounce, figure 1.
If you have a metal bearing ball you can drop it on a hard surface and watch the results.  The ball does not drop and immediately stop when it comes in contact with the surface, but will usually bounce a few times before it remains comes to a rest.  The same happens when a switch is closed.  The two halves of the switch will come in contact and separate several times before staying together.   Actually, there are two times when a switch will bounce, when it is closed and when it is opened.  The number of bounces and the total time the switch bounces varies from product to product.

Figure 1 A typical switch closure showing three bounces.

Why is this a problem?

You might wonder if the switch on the wall bounces when you turn on the room light.  The answer is yes.  Switches take anywhere from a few tens of uS to a few hundred mS to stop bouncing.  But you will not see the light flicker.  Even if your eyes could perceive changes in light that quickly (which they cannot) the lights will not transmit the bounce because of how they are made.  An incandescent bulb is still heating up when the bouncing occurs, for example.
It is not a problem with house lighting, but when that switch is connected to a computer, well that is a different story.  If a computer, or microcontroller is watching a switch, it does not see the switch go from one state to another just once, but many times.  If the switch is connected to a counter, say in the example shown in figure 1, the counter would not advance 1, but 4 times.  Even if this switch was connected to a circuit with not MCU it would have the same problem.

What to do?
What are we to do with such a flawed device?  You would think that someone would have fixed this by now.  There are many, many ways to debounce a switch.  A simple approach is to form some kind of low pass filter. This can be done with a few resistors and a capacitor.  Typically, in these simple circuits, you find that the filter time is different when opening the switch from closing it.  You can add a diode to fix this.  Then you will want to speed up the circuit or provide some kind of drive for the output, which can be accomplished with a Schmitt trigger. All of a sudden you have a half dozen components just to operate a switch.  There must be a better way!
Hardware or software?
One easier to implement solution is provided by Maxim.  They have the MAX6816/17/18 which are single, dual and octal debouncers.  This is a really nice solution.  Connect the switch between the IC and ground.  You need one bypass cap on the power supply and you are good to go.  The downside? There is always a downside. It cost $3.41 in small quantities.  Also, Maxim has a bad reputation for losing interest in a product. You might design a product around one of their devices only to find you can no longer get the part you need.
What about software?  Can’t this be dealt with in code?  Sure.  If a human is throwing the switch you can assume that the change in value will not occur faster than about 500mS.  Then you wait 200mS or so after a state change before you declare the switch changed.  That can make it cheaper but does not cut the design cost because now the firmware engineer must write code to deal with the debounce problem.  It also incurs a cost in CPU time.  If there are more important things the CPU can be doing, the execution time and complexity of the code may not be worth the trouble.  It is a tradeoff that must be explored each time.

Where in the data sheet does it tell me how many times it will bounce and for how long?
Wouldn’t that be nice.  Unfortunately, the manufacturers never provide that type of information.  We are left to our own devices to figure out how bouncy a switch is.  The best thing to do is to hook up your new switch (or 10) to a resistor connected to a power supply.  Then connect a scope across the switch and see how bouncy a problem you have to deal with.  Doing 10 switches will give you a statistically significant result.
Final thoughts
This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan, Utah, which can be found on the web  You can find the newsletter on the company blog, LinkedIn or by subscribing.  Send your emails to The Celtic Engineer at:  [email protected].