Searching \ for '[OT] Switch bounce characteristics' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=switch+bounce+characteristics
Search entire site for: 'Switch bounce characteristics'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Switch bounce characteristics'
1998\06\11@030452 by Michael Park

flavicon
face
As I prepare to try my hand at debouncing a switch input, I'm curious to
know if anyone has characterized mechanical bounce in terms of typical
frequencies and durations.  If that information is not directly
available, my question then becomes one of pragmatics: What sampling
frequency have you successfully used, and how many samples did you need
before declaring a switch settled?
Scott Dattalo, on his amazing debounce technique[1], talks about the
"vague terms" surrounding debouncing in general.  I'd like to get a feel
for the numbers that real-world practitioners use.

Reference:
[1]
http://www.interstice.com/~sdattalo/technical/software/pic/debounce.html

--
Michael Park
http://www.seattlerocketworks.com

1998\06\11@032405 by Gordon Couger

flavicon
face
From: Michael Park <spam_OUTsrwTakeThisOuTspamSEATTLEROCKETWORKS.COM>


>As I prepare to try my hand at debouncing a switch input, I'm curious to
>know if anyone has characterized mechanical bounce in terms of typical
>frequencies and durations.  If that information is not directly
>available, my question then becomes one of pragmatics: What sampling
>frequency have you successfully used, and how many samples did you need
>before declaring a switch settled?
>Scott Dattalo, on his amazing debounce technique[1], talks about the
>"vague terms" surrounding debouncing in general.  I'd like to get a feel
>for the numbers that real-world practitioners use.


I have used a number of ways to debounce switches. The best is to
buy switches that don't bounce. The do make them. The next best
is to do it in hardware. It take a lot less processor time.

I have used a couple of  software solutions that work farily well. The
simplest is just to tie up the processor with a for loop after it detects
a change. The best performing is to sample the switch a number of
times and judge it high if 80% of the sample are high. This handles
noise spikes as well.

Good luck
Gordon

Gordon Couger .....gcougerKILLspamspam@spam@rfdata.net
624 Cheyenne
Stillwater, OK 74075
405 624-2855   GMT -6:00

1998\06\11@033444 by tjaart

flavicon
face
Michael Park wrote:

> As I prepare to try my hand at debouncing a switch input, I'm curious to
> know if anyone has characterized mechanical bounce in terms of typical
> frequencies and durations.  If that information is not directly
> available, my question then becomes one of pragmatics: What sampling
> frequency have you successfully used, and how many samples did you need
> before declaring a switch settled?
> Scott Dattalo, on his amazing debounce technique[1], talks about the
> "vague terms" surrounding debouncing in general.  I'd like to get a feel
> for the numbers that real-world practitioners use.

Hmmm. If Scott has said anything about a PIC, it is gospel, but heregoes another approach :
If you have a timed interrupt, it becomes extremely easy to debounce
switches. In your ISR, you sample the input. If it is 'true', increase a
counter, say InputDebounce. If it is 'false', clear it. If it reaches a pre-set
value, you set flag , say InputDetected. The next time the input is sampled,
it increases InputDebounce to one over the pre-set limit, and must not be
increased again. Since the flag will only be set if InputDebounce = pre-set
value, you don't have to worry about repeated triggers.

Interrupt Service Routine :
********************
Check input
Is input true ?
   Yes : Is InputDebounce<Pre_set ?
         Yes : Increase InputDebounce
               Is InputDebounce=preset ?
                     Yes : set InputDetected
   No : Clear InputDebounce


Main Routine :
**************
Your code....
Is InputDetected true ?
   Yes : Service the input
         InputDetected = false
Your code....

Why go to all this trouble (it is a lot of code!) ?
1) You can debounce many inputs with different debounce periods simultaneously.
2) Your main routine is held up with little delays that screw up your timing.
3) You can use this technique to debounce keypads with nice and exotic options like multiple keys
etc.

Drawbacks :
1) One byte and one bit  RAM needed per input.
2) You need a TMR0 interrupt (not avaiable on all PICs)

--
Friendly Regards

Tjaart van der Walt
tjaartspamKILLspamwasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....0832123443KILLspamspam.....wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\06\11@035117 by Clyde Smith-Stubbs

flavicon
face
On Wed, Jun 10, 1998 at 11:30:24PM -0700, Michael Park wrote:
> As I prepare to try my hand at debouncing a switch input, I'm curious to
> know if anyone has characterized mechanical bounce in terms of typical
> frequencies and durations.  If that information is not directly

I can offer you one data point (i.e. I looked at one switch). It was
a momentary pushbutton and the contact bounce lasted around a millisecond.
The duration was relatively constant across activations.

There was no dominant frequency, it was very noisy. Since then I've tended
to allow 10ms or more debounce time and never had a problem with any switches
but there are bound to be some that differ substantially.



--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: EraseMEclydespam_OUTspamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamspam_OUThtsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1998\06\11@055623 by Leon Heller
flavicon
picon face
In message <@spam@357F7980.1EEDB451KILLspamspamseattlerocketworks.com>, Michael Park
<KILLspamsrwKILLspamspamSEATTLEROCKETWORKS.COM> writes
>As I prepare to try my hand at debouncing a switch input, I'm curious to
>know if anyone has characterized mechanical bounce in terms of typical
>frequencies and durations.  If that information is not directly
>available, my question then becomes one of pragmatics: What sampling
>frequency have you successfully used, and how many samples did you need
>before declaring a switch settled?
>Scott Dattalo, on his amazing debounce technique[1], talks about the
>"vague terms" surrounding debouncing in general.  I'd like to get a feel
>for the numbers that real-world practitioners use.

Small switches bounce for about 1 ms, some manufacturers actually
specify the duration. The bounce frequency is irrelevant, and won't be
constant, anyway. I think I used a 5 ms delay the last time I debounced
a switch.

Leon
--
Leon Heller: RemoveMEleonTakeThisOuTspamlfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM    Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of a simple AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.

1998\06\11@061500 by James Cameron

picon face
I solve bounce with a sledgehammer ...
... my 'wait for a contact to close' function looks like this;

       - delay for 100ms
       - wait for contact to open
       - delay for 100ms
       - wait for contact to close

This gives me immediate response to a contact closure, and tends to
ignore any bounce.  Of course, any induced noise may trigger it, but
that's not a bounce in my books.  I fix noise in other ways.

--
James Cameron                              (spamBeGonejames.cameronspamBeGonespamdigital.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\06\11@065401 by Keith Howell

flavicon
face
I use mechanical rotary shaft encoders.
Contacts typically bounce for 1ms when new.
I believe switches can get bouncier as they wear out in their life.
So the data sheet quotes a maximum of 3ms.

This seems consistent with other postings which
say switches bounce for about 1ms and debounced over
10ms. Or 5ms if you wish to squeaze the time down a bit.

For my rotary encoder, the stable states don't last long -
typically about 3 ms, same as the bounce period,
at one turn per second.

I get my PIC to sample the rotor switches every milisecond.
If they are the same for two consecutive samples,
I count this as stable.

1998\06\11@094336 by Thomas McGahee

flavicon
face
Michael,
Switch debounce is quite ON topic. For the PIC or any other
digital processor.

The bounce parameters vary from switch to switch. Dry switches
are the worst. Mercury wetted switches are virtually
bounceless. Some switches use a spring mechanism to
move the contacts. These have a narrower bounce. The
worst offenders are the really cheap pushbuttons that
rely only on finger pressure. These things bounce all over the
place if you only apply a very light pressure.

You get what you pay for :)

Typical debouncing periods range from 1 ms to 5 ms.

To debounce a switch you can use physical means or software
means.

PHYSICAL MEANS

Assume a SPST normally open pushbutton with one side tied
to ground. Tie a pullup resistor to the other side and place
a small capacitor in parallel with the switch. This gives
the switch the following characteristics: it will switch
to ground immediately upon closure. The current from the
capacitor will help keep the contacts operational so long
as the current is not excessive. When the switch physically
bounces, the capacitor will start to charge up. This will
take time. If the time to charge to 1/2 the supply voltage
is longer than the bounce period, then the switch will
be effectively debounced. The pullup resistor value and
the capacitor value determine the debounce period that can
be compensated for.

A Schmitt trigger input is useful when such capacitor
and resistor hardware debounce is used, but it is not
absolutely necessary.

Do not make this debounce period TOO long, or you will
over-compensate, and then two rapid switch closures will be
seen as only a single closure. In practical terms, you
can simply adjust the charge time to be about 1/2 the
absolute minimum time you would ever expect between VALID
switch closures.

Physical debouncing has the advantage of eliminating much
of the software overhead. Just look for the make and the break.
Physical debouncing DOES cost you a resistor and a capacitor,
but we are talking pennies here.

SOFTWARE-ONLY MEANS

This is for the hardware minimalists who believe that
absolutely everything should be done in software. It is
"free" only if you don't need the processor resources for
anything else. Use hardware AND software for the
ultimate in de-bouncing.

Best method is to begin with the closure, and in a count
loop accumulate how many of the loop cycles result in a
reading of CLOSED. For example, let's say that you loop
120 times and only get a CLOSED indication 10 times. You
probably just had noise. 64 counts or more you would consider
a closure. Wait for switch to open, delay for 1 ms
and process exit. <<Total loop time should greater than
bounce time.>> BTW, you can test for >64 counts by testing
a single bit... the one that represents 64. Always try
to keep things simple.

Next best method. Let's assume a 1 ms max bounce period.
Upon initial closure, time out for 1.5 ms. If the switch
is open, it was just noise, so ignore it and exit. If it
was still closed, then wait until the switch opens,
delay 1.5 ms and process the closure.

Hope this helps.
Fr. Tom McGahee


----------
{Quote hidden}

1998\06\11@102049 by tjaart

flavicon
face
Bill Cornutt wrote:

> Mr Tjaart van der Walt's fine description of debounce code
> should include a provision to insure that the InputDebounce
> counter does not count through zero and back up to the 'pre-set'
> count and set InputDetected a second time for the same event.

It won't actually. It can reach a maximum of pre_set + 1.
(look at the pseudo code)

> Else there would be a automatic 'key repeat'.  (Which could be
> made into a 'feature'.)  This could be accoumplished by masking
> off one or more high order bits, or if a carry out (or zero),
> reset InputDebounce counter back to a value of 'pre-set'.
> <SNIP>
> > Why go to all this trouble (it is a lot of code!) ?
> > 1) You can debounce many inputs with different debounce periods
> > simultaneously.
> > 2) Your main routine is held up with little delays that screw up your timing.

I screwed up here. I actually meant the delay techniques hold up your main program.

> > 3) You can use this technique to debounce keypads with nice and exotic options
> > like multiple keys
> > etc.

Key sequences are also a pissy to do this way. You only need one flag
extra per extra key in the sequence.

Another two advantages that came to mind :
1) You can forget about the actual debouncing. You just check for a flag.
2) You can sample as many times as you like without any difference in your main program.

The main disadvantage is, of course the ROM used. Scott
or Dmitry could probably squeeze it into 10 words though....;)

(Isn't it disgusting how these guys harass the poor Status byte? <GRIN>)

--
Friendly Regards

Tjaart van der Walt
tjaartEraseMEspam.....wasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS EraseME0832123443spamwasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\06\11@134045 by Martin Green

flavicon
face
    I can't give you general rules, but I'll tell you what worked for me.
    I sample the switch input pin every 5ms. If the pin reads the same 4
    times in a row (15ms from the first sample to the last) I consider it
    a valid change.

    I keep a counter for each pin to be debounced. I read all pins at once
    into a register (you don't have to do this, but it guarantees all
    switches are sampled at exactly the same time), if a given pin is read
    at the same state I already have recorded for it, I reset the counter
    to 4. If it reads opposite to the known state of the switch, I
    decrement the corresponding counter. If the counter makes it to 0, it
    is a valid state change, and I reset the counter to 4 and record the
    new state of the switch.

    If you have a lot of pins to debounce, and/or are short on free
    registers (who isn't), you can set up vertical counters instead. Say
    you need to debounce 8 inputs. you can do this with just two registers
    by "stacking" them, one on top of the other. The bit at location 0 in
    register 1 and the bit at location 0 in register 2 makes a two bit
    counter that you can decrement with software. Likewise, the bits at
    location 1 in both registers make another 2 bit counter, etc., etc.
    When you read in a switch state that is the same as the one you have
    saved, clear the bit at the corresponding location in both registers.
    If the switch is read in at the opposite state, use sofware to
    decrement the two bits in the two registers, as if they were bit 0 and
    1 in a single register. After decrementing, if both bits are cleared
    it is a valid switch change. Using 3 registers allows a count of up to
    eight for a valid change.

    If you are debouncing a matrix keyboard, the vertical counter
    technique works here as well. Use enough registers to have one bit for
    each key, for a 4x4 matrix for instance, you would need 2 registers
    (at 8 bits per register) times 2 (for a 2 bit counter), making a total
    of just four registers for debouncing all 16 keys.

    With RegHigh holding the high order bits of each 2 bit counter, and
    RegLow holding the corresponding low order bits, do this to decrement
    all 8 counters at once:

       XOR RegHigh, complement of RegLow (result into RegHigh)
       Complement RegLow

    ..or this to increment all 8 vertical counters:

       XOR RegHigh, RegLow (result into RegHigh)
       Complement RegLow

    Obviously extra code is needed to decide which vertical counters
    should be decremented and which should be reset, but this should give
    you an idea of how to manipulate vertical counters easily.

    Many people have successfully debounced a switch by only sampling it
    twice. If it reads the same way both times it is valid. I prefer my
    method instead, I think it is more reliable.

    You can experiment with sample times and # of same-level reads
    required for a valid change, but this should give you a starting
    point.


    HTH - Martin.


______________________________ Reply Separator _________________________________
Subject: [OT] Switch bounce characteristics
Author:  pic microcontroller discussion list <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU> at
Internet
Date:    6/10/98 11:30 PM


As I prepare to try my hand at debouncing a switch input, I'm curious to
know if anyone has characterized mechanical bounce in terms of typical
frequencies and durations.  If that information is not directly
available, my question then becomes one of pragmatics: What sampling
frequency have you successfully used, and how many samples did you need
before declaring a switch settled?
Scott Dattalo, on his amazing debounce technique[1], talks about the
"vague terms" surrounding debouncing in general.  I'd like to get a feel
for the numbers that real-world practitioners use.

Reference:
[1]
http://www.interstice.com/~sdattalo/technical/software/pic/debounce.html

--
Michael Park
http://www.seattlerocketworks.com

1998\06\11@151727 by Mauro, Chuck

flavicon
face
Michael,

While during my stay at the big M in Redmond, we had an entire research
program to study ALL of the electrical and mechanical parameters of a
very large variety of low cost switches over the life of the switch
(this is what you do when you have untold *billions* lying around).  We
literally tested all of the switches out to several million cycles, and
recorded the results over many hundreds of samples per switch variety.
There are a *lot* of crummy, noisy switches out there!  Choose your
brand carefully.  Most switch manufactures would be happy to give you
their specifications, but I found that the *real* numbers are always
different the published specifications.  Most switches revealed the
noise growing from initially about 1-2ms when new, to about 3-4ms (or
more) after 100K samples or so.

In general, most of the garden variety low-cost devices out there (the 2
or 3 terminal "microswitch" typically found in pointing devices for
example, of the snap-acting or dome variety) can have up to 4-5 ms of
"bounce" during the pressed state, and usually  even have between 1-5 ms
of "chatter" during the released state.  I've used sample rates of about
2ms to both detect an initial change, and usually counted 4 samples @
2ms to determine the final state.  Most switches can be successfully
sampled under 10ms.  I've never needed more than that on even the
noisiest brand I've encountered.  These numbers should accommodate at
least a 3 sigma process variation on the switches, perhaps more.

I'd say that Scott's vertical counter technique that Martin describes
below is your most efficient technique for any 2 terminal switch, and
you could do even better (code size and time-wise) if you can use both
sides of a 3 terminal switch (SPDT).  But, of course, that requires
twice an many inputs per switch (if you're lucky enough to have them
left over and just lying around doing nothing)!  The 2 input method is
time independent, and requires only one pass through the code to
debounce a switch.

Cheers,

Chuck

------------------------------------------------------------------------
--------------------------------------
C.S. Mauro, Jr.
Amateur Radio Callsign: KD7BWP

"I tell you, we are here on earth to fart around, and don't let anybody
tell you any different."

Kurt Vonnegut



> {Original Message removed}

1998\06\11@163337 by Scott Dattalo

face
flavicon
face
Michael Park wrote:
>
> As I prepare to try my hand at debouncing a switch input, I'm curious to
> know if anyone has characterized mechanical bounce in terms of typical
> frequencies and durations.  If that information is not directly
> available, my question then becomes one of pragmatics: What sampling
> frequency have you successfully used, and how many samples did you need
> before declaring a switch settled?

Michael,

As many others indicated, switch bouncing varies from switch to switch.
I used to work for a company that made SCADA equipment for the
electrical utility industry. One of the boards that we designed was a
"Digital Input" board that could handle 32 inputs. 99 times out of a
100, the inputs consisted of relay contacts. We had no idea what kind of
relay that our customers would use, but they typically had those big
puppies that require a sockets. Furthermore, the relay contacts tended
to anodize over time and thus change the bouncing characteristics. So to
accomodate this wide variety of bouncing behavior we did two things:
1) Provided customer selectable debouncing time constants and 2)
Provided different DC biasing voltages.

We experimented with different relays to see how the bouncing was
manifested. It's hard to describe without drawing a picture, but
essentially what would happen is that the input would oscillate/bounce
anywhere from none to a dozen times. Sometimes, there would be a fairly
high frequency oscillation right at the transition (e.g. like several
cycles 10us wide). But eventually the bouncing would stop.

To make matters worse, we also had to support a feature called "Sequence
of Events" or SOE. As its name indicates, we had to time tag with 1ms
resolution when switch states were detected. The approach we took was
(not too suprisingly) similar to the debounce code on my web page
(although the processor was a Hitachi 647180 - one of those z80
derivatives). Algorithmically, we did something like this:

1) Initialize a timer to interrupt every 500us.
2) When the interrupt occurs, read the 32 inputs. Also, the time of the
interrupt was also recorded.
3) Filter the 32 inputs. If an input has changed states since it was
last sampled, then record that time. When an input has been quiescent
for a programmable amount of time then declare it filtered.
4) Exit the interrupt.

If changes of states were detected, we would buffer that information and
send it via a local 485-based network to a central computer. There
wasn't much time to mess around!
But we left the job of choosing the debouncing time up to the customer.

Scott

1998\06\11@174945 by David VanHorn

flavicon
face
An often-overlooked point with mechanical switches is that they specify a
MINIMUM current.
Many designs ignore this, and run only 1-2mA through their switches.
This will cause really nasty switch bounce, and switches that mysteriously
open for a few
seconds, then close again later.

1998\06\14@215506 by Anthony Tekatch

flavicon
face
I recently got away with a very simple method of software switch debounce:

Sample the switch(es) at about 60Hz and store the result in a register,
the result is a debounced contact.
- I used the timer interrupt to give me the 50mS.
- this method provides quick enough response so that a human can't notice
any delay. - no special counters or tables are required.
- The only possible problem I can think of is that this method may pick up
spurious noise that may be present on the input (which is cleaned up by
hardware in my case -- low enough pull-up resistor value).



Another method (hardware based):
Use a double throw switch with each end tied to +v and Gnd (respectively)
and the middle goes to the microcontroller input (with a 0.1uF cap to
gnd). the result is a debounce switch contact. The disadvantage is that
there is a current spike from charging the cap.



RemoveMEanthony.tekatchspam_OUTspamKILLspamsympatico.ca

1998\06\14@215535 by ezines

flavicon
picon face
On the topic of Switch and bounce, i have a lovely working Combination
Lock project which i completed for my GCSE electronics. The only
unimplemented feature is that the code cannot yet be changed via the
lock <g> http://www.sleepi.demon.co.uk/lock.zip
--
Ben Isaacs
(comments via email please!)

1998\06\14@215555 by Wim E. van Bemmel

picon face
Hello,

did I miss the simple hardware solution, or is it too simple?

find 2 2-input NAND or NOR gates, connect them to make a flip-flop, and use a
SPDT switch connected to the remaining inputs. The output of one of the gates
is perfectly debounced. Choose one, they are each others complement.

Michael Park wrote:

{Quote hidden}

--
 Regards,

 ------------------------------------------------------------------
 Wim E. van Bemmel
 No Unsollicited Commercial RemoveMEbemspanTakeThisOuTspamspamxs4all.nl
 Life is about Interfacing ....
 ------------------------------------------------------------------

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...