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:
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.
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
I'm not going to go into details on these methods because they are
rarely used today.
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.
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.