De-bouncing input signals?
I've heard that input signals to digital circuits should be "de-bounced", at least sometimes. What is de-bouncing? Why is it needed? When is it needed? What is bouncing around in the first place?
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Bouncing signals
When a mechanical switch opens and closes, there is often vibration in the contacts so that they open and close several times rapidly until the new steady state is eventually reached.
Bouncing is perhaps easier to visualize for a switch closure. Two conducting things (contacts) that start physically apart are brought together so that they touch. These contacts have inertia as they move towards each other. At the microscopic level, there can be some bouncing when the contacts first touch, just like a ball bounces when it is first dropped onto a floor.
The same thing can happen as the contacts move apart when the switch opens. There is always some springiness and elasticity of the materials at the microscopic level.
The result is that the contacts close and open multiple times electrically, until finally settling in the new state. The resulting electrical signal therefore transitions between the two states multiple times, until finally settling in the new state. The resulting signal can look like this:
Time scale
Mechanical switches for ordinary common uses bounce from a few ms to a few 10s of ms. Large power switches ususually bounce longer. Most small switches and pushbuttons I have measured bounce from 5 to 20 ms, but I've seen a few that bounce for nearly 50 ms.
What does this mean in human terms? I have done tests on this, and found that 50 ms is about the minimum time humans notice. For example, if a pushbutton causes an LED to light, humans will still consider the action instantaneous with up to 50 ms delay. 100 ms delay is noticable, but usually not annoying. Multiple 100s of ms starts to get annoying when an instant response is expected.
Why it matters
For some applications, like switching a light bulb, it doesn't matter. The light switches in your house almost certainly exhibit bouncing, but that doesn't cause trouble. Generally, the light doesn't respond as fast as individual bounces, and it wouldn't matter if it did anyway. The light still goes on and off "right away" in human terms. Basically, lights are slow to respond, and we don't care on that time scale anyway.
However, digital circuits can respond much faster than individual bounces. Suppose a device has a pushbutton to initiate a single action every time the button is pressed. If nothing is done, each press and release could result in multiple events.
A great experiment is to connect a pushbutton to a digital counter, or even a microcontroller that counts pulses. Have the counter increment on each released to pressed transition of the button. Go ahead and actually try this. You will find that it's pretty much impossible to get just one count each press of the button, and none for each release.
How to fix it
Bouncing happens when ordinary dry contacts open and close. Switch designers can and do attempt to limit the bouncing period, but totally eliminating it is impossible or impractical for reasonable cost. There are such things as mercury-wetted switches which greatly reduce bouncing, but those are too expensive for most applications.
Fortunately, interpreting a bouncing signal into a single state change isn't very hard or costly. The common strategy is then to let the switch bounce, and to deal with the bouncing signal afterwards.
Electrical debouncing
Back in the pleistocene before user inputs were handled by a microcontroller, debouncing had to be done electrically.
One method is to low pass filter the signal (resistor in series, capacitor to ground), then have that drive a Schmitt trigger (hysteresis) input. The filter would smooth out the signal, not reacting much to individual bounces. The hysteresis threshold would be more than the filtered result of a bounce pulse.
Another common method used a retriggerable "one-shot" (monostable multivibrator).
I'm not going to go into details on these methods because they are rarely used today.
Firmware debouncing
Today, user inputs from pushbuttons are generally handled by a microcontroller. The raw bouncing signal is fed directly into a microcontroller digital input, and the rest is done in firmware. This adds no cost due to extra electrical components.
Many times, the microcontroller already has a regular clock tick interrupt for other reasons. I usually use a 1 ms (1 kHz) interrupt for global system timing.
The most common debouncing algorithm I use is to require the switch input to be in a new state for 50 consecutive 1 ms interrupts before that is considered the official debounced state internally. All other code only looks at the official debounced internal state, not the actual digital input state.
This method only requires a single byte counter of state for each input to debounce. Each 1 ms clock tick, the instantaneous input state is compared to the internal debounced state. When they are the same, the counter is reset to 50. When they are different, the counter is decremented by 1. When the counter reaches 0, the debounced state is updated and the counter reset to 50.
I use 50 ms debounce time, even though most switches bounce for much less than that. First, I have seen a few pushbuttons that do bounce almost that long. Second, 50 ms still feels instantaneous to humans, so there is no harm in it.
In some rare cases, it may be important to capture the timing of a button press more accurately than human perception time. A stopwatch is a possible example. In that case, you transition to the new state when it is first detected, but then don't allow further state changes for the debounce interval. A drawback to this approach is that it is susceptible to short noise glitches. For that reason, I only recommend this method when timing is critical.
Summary
Mechanical contacts bounce when opening and closing. Digital circuitry is faster than these bounces, and will "see" a single high level switch open/close as many individual open/close transitions. To get a single event from a high level switch state change, we "debounce" the signal, usually in firmware nowadays. 50 ms is a good debouncing time, as it's longer than just about all switches bounce, but just short enough to not feel like a delay to humans.
Regarding the paragraph "in some rare cases...", maybe they are just the cases where it may be judicious to pass the switch operation with an analog Schmitt trigger, as you've described previously.
Whether you use an analog or digital filter, you still have a tradeoff between noise attenuation and response time. If you want instant response, then you're going to be susceptible to noise glitches.
You can perform low pass filtering followed by hysteresis in firmware too. I've actually done just that in one case where the input could also be pulses, not just switch closures. In the case of the pulses, the on/off information was in the duty cycle.
Another hardware solution
There is another hardware debouncing technique widely used in the past. It is implemented by an SPDT push button driving (buffered by) an RS latch.
This configuration can be thought of as an "electromechanical timer 555" since it is based on the same idea - "artificially created hysteresis". Here the hysteresis is mechanical (the distance between the end contact surfaces) while in 555 it is electrical (the difference between ⅓ and ⅔ voltage levels). The same idea is implemented by the so-called "limit switches" where the hysteresis is determined by the distance between them.
In my opinion, it is the most reliable debouncing technique but it needs a more complicated switch, two pull-up resistors and an RS latch.
Mixed solution
But in these "micro times", we can implement the RS latch by the micro software so only the SPDT button will be needed… and, of course, two port inputs. The one of them will serve as an S input and the other - as an R input. Simply speaking, we remove the latch and connect the two output button terminals directly to the port. The software will write "1" in a memory cell (flag) when the S input is affected and "0" when the R input is affected.
Useful debouncing
There is such an inventive principle - use something harmful for some useful purpose. Let's try to apply it here.
The bouncing push button produces a random number of pulses; it acts as a "fading away pulse oscillator". So, if we drive a counter by a push button, it will counter a random number of pulses when pushing the button… and this arrangement will act as a random number generator.
0 comment threads