(So far, 188 people got it right out of 378 for a success rate of 49%)
(Thank you to Clive "Max" Maxfield for submitting this question. Make sure to have a look at his "Cool Beans" blog and to read everything by Max imagining a strong British accent.)
A lot of engineers underestimate the problems associated with switch bounce. The oscilloscope screenshot below shows the trace from NO (normally open) terminal from a SPDT (single pole, double throw) switch when the switch is closed, thereby connecting the NO terminal to 0V (GND). Observe the switch bounce on the NO signal. The QB signal trace represents the debounced signal coming out of an SR latch.
A friend of mine - a well-known embedded systems designer - took a bunch of switches out of his "treasure chest" of spare parts. He then proceeded to test them to determine how long they bounced. The question is, what was the maximum switch bounce duration he observed?
- Write a Comment Select to add a comment
I actually use Jack's hardware debouncer shown in figure #3. When I don't mind about transition asymmetry, I delete the diode from the circuit. It's cheap and easy to calculate. I usually calculate it for 250ms max bouncing period.
Of course, when delay is an issue, I go for the SR latch debouncer but, for most applications I have worked on, the ~250ms delay is better than just "good enough".
One of the things I want to do is write a full column on the various debouncing techniques, including the chips from www.LogiSwitch.net (which I now use in all of my own projects.
Howdy, I'm SO on board with this - Both hardware And software methods of addressing the issue. I've tried a Stupid number of them and have found a combination of hardware "damping" and software "not fooling me" to work best. But before Toto raises my wizard curtain, I'd like to see others answers (I may learn something...). <<<)))
P.S. Never heard of LogiSwitch (learned something already).
I was aware of the 157ms "Little Red Switch" of Ganssle's. I asked him to send it to me so I could analyze it. He hadn't saved it unfortunately.
As far as I am concerned 157ms of chatter is beyond the point of switch bounce. Any switch that is unable to settle before 157ms is defective.
I don’t see the timebase for the ‘scope traces. Did I overlook something or is it referenced in another post
Hi there -- sorry, I cut the timebase off -- this image was only intended to provide a depiction as to what switch bounce is -- since the question is asking about maximum switch bounce duration, I didn't want to provide a timebase that ended up being a distraction.
Active high is always an easier answer - once seen, bounce is usually irrelevant.
Active low is the problem and here's where I am of piqued interest of others answers.
I wrote a software method that's proven reliable across a couple decades of projects. Hint: response time is proportional to bounce. Not exactly rocket science, but a good answer. L8R <<<)))
I'd love for both of us to be in the same room with a (BIG) whiteboard so we could bounce ideas back and forth. One day...
I wrote a foot switch debouncer a while back. The foot switch in question had a rather large capacitor (10 uF!) attached to it so that there would be a nice smooth ramp-up and no bounce. Needless to say, an analog ramp signal applied to a digital circuit wreaked havoc in the bounce category. Rather than pop the cap off of 500 foot switches, I was tasked to make a debouncer. Switch pressed, interrupt generated. Disable foot switch interrupts for 100 mS. Signal still there? Reenable interrupts and call it pressed. Signal not there? Somebody is playing gas pedal so no switch press. And with some of the switches, I saw "bounces" well over 100 mS.
10 uF? Sheesh!
When reading a signal with a slow ramp, there's also the possibility of trying to read it when it's in the middle and triggering a metastable condition. Wouldn't it have been better to feed this signal into a Schmitt trigger and use the output of that?
10 uF? Sheesh indeed! :-)
It would be nice to add the Schmitt trigger, but we used generic boards with a foot switch input that were used across a number of product lines, and since this is a small company, a respin wasn't in the forecast.
Originally the foot switches came without the cap but one of the legacy (20+ year old) products showed occasional starts followed by immediate stops when the foot switch was pressed. All other products were Don't Care since hitting the foot switch caused a one-time function to occur that lasted far longer than the bounces.
So tests were done and the best operation was seen with the 10 uF cap. So a massive order was done for foot switches with caps and eventually the ones without the cap were completely sold out.
The foot switches were then sent out with a much newer version of the product using a newer board and problems started showing up. Popping the cap out solved most but not all since there was still some bounce. Since it was far easier to fix the problem in software, I wrote a debouncer that would work with both foot switch versions.
Those newer boards were designed about 10 years ago and are still in use today.
This sounds like a classic engineering design tale to share with younger engineers -- the funny thing is that the topic of switch bounce/debounce affects just about every embedded engineer, yet there is no definitive solution (or suite of definitive solutions) -- it's mostly word of mouth :-)
To guess the answer is a little bit pointless without knowing what kind of switches we are talking about. Could be an old WWI morse key ... ;)
Fair enough -- I should have specified "the sort of toggle switches and push-button switches you might expect to find in the typical engineer's treasure chest of parts" :-)
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: