switch debouncing

Is there a standard or best way to de-bounce a switch?

After googling for a bit, this seems to be a good candidate:


VCC
|
\
R1 /
\
/
| Schmitt
| trig inverter
| |\
+---/\/\/--+-----| >-- out
| R2 | |/
S1 \ = C
| |
--- ---
GND GND


R2 might be 18 k, and R1 82 k, with a 1uF cap as per this article:

http://www.embedded.com/showArticle.jhtml?articleID=18902552

Seems like it should work. Any comments?

--Mac

 

He also wrote a somewhat longer piece a little later on, that year:

http://www.ganssle.com/debouncing.pdf

Jon

 

It should work as long as you don't need to know the exact instant that the
switch operated.

--
Dan Hollands
1120 S Creek Dr
Webster NY 14580
585-872-2606

www.QuickScoreRace.com

 

Is there a standard or best way to de-bounce a switch?

What is it with you people looking for a "standard way" all the time?

Pure "bit head" guess work. The worst case occurs when the switch opens
on bounce immediately after pulling the Schmitt input across its low
threshold and the circuit starts to recharge C back towards Vcc. You
obviously don't want the voltage to cross the positive threshold again.
Using VT+ as positive threshold, VT- as negative threshold, and VH as
hysteresis, a worst case calculation for the 74HC14 would look something
like this when you settle on a maximum bounce time an order of magnitude
larger than switch specification. This usually means less than one
chance in a billion of ever seeing a glitch aka switch has failed. A 5ms
switch calculation would look like so:
View in a fixed-width font such as Courier.

 

If it's going into a microcontroller, firmware is almost always the
best way.


Best regards,
Spehro Pefhany

 

Well, if you can arrange things with external hardware so that the
switch input is always valid, that is just that much less the firmware
has to do- especially if the switch input is a very infrequent occurrence.

 

But firmware is free!

If you sample the switch state periodically at a rate slower than the
longest possible bounce time, then you don't need to do any software
debouncing. Something like 5-10 Hz sample rate plays right into
typematic logic if you want to do that, too.

John

 

Timer-interrupt driven periodic (in the 100-500Hz range) polling uses
negligible bandwidth of a modern processor for any reasonable number
of keys. Even if its a frequent occurence. And it can filter out
electrical noise and momentary contact breaks due to shock or
vibaration as well, if you choose to write it to do so.

There is reason to add some external hardware (especially to deal with
ESD issues and possibly with the miserably small and variable current
that on-board pullups typically deliver) but not for the deboucing.
Even a crummy on-board RC clock will yield debouncing times accurate
within a few percent at zero additional cost, and les need to test the
board for missing parts.


Best regards,
Spehro Pefhany

 

John, John you are killing me and making me look bad to FB.
Let me try to answer these probing questions.

<100mS is ok.

True but input is transzorbed to protect resistors.

C is not ungrounded it is tied to AC ground thru G2 < 50 output R and forms a low pass input filter with R2. The low output R of G2 is vital to circuit operation.

Good point, the circuit shown is only conceptual. There is a 510R between G1's input and the C,R2 node. These ICs are rated +/-20ma input latching current so the two clamp diodes are not needed with large values of R2

Guaranteed, Let's calculate the voltage change necessary at the input to cause a miss trigger to propergate from G1 to G2.
Ein = Ehy*R2*C/Tpd= (1.0*1e5*1e-7)/1e-8 = 1,000,000 volts
This is a ROM and I did take liberties but you get the idea. Actually because of G2's output 50R and R2=1e5 we only need a 2000V input change to cross the 1V hytersis threshold.

That is exactly what my customer is talking about.

 

Well, that wasn't shown.

Neither end of C is connected to ground; both ends are connected to
semiconductors, and semiconductors are what's killed by esd zaps. 50
ohms won't impress a good arc, or G2 can be the IC that's killed. Of
course, the transzorbs fix that problem.

One of my pretty firm rules is to never have semiconductors connected
to the outside world, arcs included.

This schematic seems to have all sorts of invisible parts. Good, that
resistor definitely shifts the damage path toward G2.

Again, assuming R2 doesn't arc.

Well, if you analyze it carefully enough it should be OK. But simpler
circuits have less hazards. Without the transzorbs, this one would be
scairy.

John

 

You want debounce. See....

Newsgroups: alt.binaries.schematics.electronic
Subject: Switch Debounce (from S.E.D) - NoiseBlank-555-RC.pdf
Message-ID: <>

...Jim Thompson

 

Jim Thompson wrote...

I've seen switches with bounces 50 to 500x as long as yours.

 

Sheeesh, Win, It's just an example, dredged from a noisy voltage
signal application... change the RC already!

I have some EXTREME "debouncers" if anyone is interested.

...Jim Thompson

 

I'm not sure that could be called a debouncer- maybe more of a noise
blanker. You have that known V1 clock and corrupt it with much higher
frequency (1-V2V3/25). A switch debouncer does not have that luxury.

 

Did the OP say he was designing a wheel-well switch for the AirBus?

 

On Thu, 20 Oct 2005 03:50:39 +0000, Fred Bloggs wrote:
[snip]

Nope. ;-)

 

The sources are for illustration ;-) NOT "known V1 clock"... it's NOT
a clocked system... look carefully before leaping for a change.

...Jim Thompson

 

I had a temperature switch that bounced forever. It was mounted in a
tugboat, on the side of a diesel engine.

John

 

See "NoiseBlank.pdf" on the S.E.D/Schematics page of my website for
several different variations.

...Jim Thompson