Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

80%
+6 −0
Q&A De-bouncing input signals?

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 reach...

posted 4y ago by Olin Lathrop‭  ·  edited 4y ago by Olin Lathrop‭

Answer
#4: Post edited by user avatar Olin Lathrop‭ · 2020-10-20T19:22:12Z (about 4 years ago)
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • ![Image](https://electrical.codidact.com/uploads/SLnbv35XhcTfro9UUps6QouF)
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • rarely used today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • ![Image](https://electrical.codidact.com/uploads/SLnbv35XhcTfro9UUps6QouF)
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • rarely used today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
  • <hr>
  • <blockquote>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.</blockquote>
  • 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.
#3: Post edited by user avatar Olin Lathrop‭ · 2020-10-20T17:25:30Z (about 4 years ago)
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • ![Image](https://electrical.codidact.com/uploads/SLnbv35XhcTfro9UUps6QouF)
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • largely unused today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • ![Image](https://electrical.codidact.com/uploads/SLnbv35XhcTfro9UUps6QouF)
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • rarely used today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
#2: Post edited by user avatar Olin Lathrop‭ · 2020-10-20T17:18:01Z (about 4 years ago)
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • <p><img src="a.gif">
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • largely unused today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
  • <h2>Bouncing signals</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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:
  • ![Image](https://electrical.codidact.com/uploads/SLnbv35XhcTfro9UUps6QouF)
  • <h2>Time scale</h2>
  • <p>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.
  • <p>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.
  • <h2>Why it matters</h2>
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>How to fix it</h2>
  • <p>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.
  • <p>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.
  • <h4>Electrical debouncing</h4>
  • <p>Back in the pleistocene before user inputs were handled by a
  • microcontroller, debouncing had to be done electrically.
  • <p>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.
  • <p>Another common method used a retriggerable "one-shot" (monostable
  • multivibrator).
  • <p>I'm not going to go into details on these methods because they are
  • largely unused today.
  • <h4>Firmware debouncing</h4>
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <p>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.
  • <h2>Summary</h2>
  • <p>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.
#1: Initial revision by user avatar Olin Lathrop‭ · 2020-10-20T17:17:15Z (about 4 years ago)
<h2>Bouncing signals</h2>

<p>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.

<p>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.

<p>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.

<p>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:

<p><img src="a.gif">

<h2>Time scale</h2>

<p>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.

<p>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.

<h2>Why it matters</h2>

<p>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.

<p>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.

<p>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.

<h2>How to fix it</h2>

<p>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.

<p>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.

<h4>Electrical debouncing</h4>

<p>Back in the pleistocene before user inputs were handled by a
microcontroller, debouncing had to be done electrically.

<p>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.

<p>Another common method used a retriggerable "one-shot" (monostable
multivibrator).

<p>I'm not going to go into details on these methods because they are
largely unused today.

<h4>Firmware debouncing</h4>

<p>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.

<p>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.

<p>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.

<p>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.

<p>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.

<p>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.

<h2>Summary</h2>

<p>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.