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----- > From: Martin Green [SMTP:Martin_Green@CONSUMERSGAS.COM] > Sent: Thursday, June 11, 1998 9:13 AM > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: [OT] Switch bounce characteristics > > 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 > 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.ht > ml > > -- > Michael Park > www.seattlerocketworks.com