# Debouncing non-algorithms

To avoid being accused of making a hardware question into a somewhat software-related thread I'm moving this spinoff of the discussion here.

looking at this stuff:

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

I find any kind of averaging or multi-sampling procedure to be either scary or useless depending, let's say at least in context where there is no non-switching related noise. Look at switch g. Ok, yes that switch's time scale is 2ms so averaging, or agreeing on 16ms samples would probably work, but not because the averaging or sampling is clever, but just because 16ms is long enough for that particular switch to settle completely anyway, and certainly 16ms times three is.

Looking here:

http://forums.parallax.com/discussion/126074/input-push-buttons-how-long-do-you-debounce-for

Most people just ask "what is enough debouncing time". And the answer in a sense depends on the hardware, if you want an aggressive answer. However, if you're satisified with a conservative answer, it seems 50ms is enough for any switch, which is great because that's also fast enough to not be a problem for humans.

Now if it turned out that we want to accommodate all kinds of switches and even the most horrible ones, and if it turned out some of those really horrible ones bounced for say 150ms, then maybe we wouldn't want people with good switches to have such sluggishness, so we'd try to detect the early stability in those good switches faster while still accommodating those horrible switches. I'd be very afraid that still wouldn't work super reliably for the horrible ones, and would only work for the good ones because you sampled on 16ms instead of 2ms (and still other switches work fine at 5 micro-seconds). So it still comes down to what's long enough, or at least what's 1/3rd of long enough. As for that 1/3, if it wasn't that you actually were pretty sure that 3 times that was really long enough, and if there was a real possibility to still have random bouncing for three consecutive samples, then well just throwing dice, there's a 1 out 8 (correction: 1 out of 4) chance that three random readings agree. That doesn't spell dependability to me anymore than the noinit, hope 4 bits don't naturally settle to 0 (they sometimes do) did.

Fortunately I don't see any reasonable evidence of any reasonable switch that remains bouncy longer than 50ms. So instead of needing some complicated algorithm that takes extra bytes and still might not always work, just wait. In every one of those pictures after 30ms you can safely sample the switch ONCE and get the right answer.

"Easy to filter? Sure. But not by code that just looks for a couple of identical reads."

No, it's easy to filter by just waiting long enough until there's no concern.

One reason I didn't look for a debouncing algorithm, is that I don't believe in using one. By the time it's called an algorithm, it's already too clever. You can disagree, but you can't say I ignored other people's code. I just wasn't looking for an "algorithm". It just takes time for the switch to settle. That's it.

https://stackoverflow.com/questions/7969553/switch-debouncing

Bistro HD has tight constraints on what it can do with a small power budget with only a 47uF cap to power the mcu. Nonesense superspeed switch fidgeting will get interpreted as fast presses usually, or maybe not, and either way that's fine, since I have no idea anyway what the user wants if they attach a vibrator to the switch. Is there even a right answer then? Real switch press and holds will get read as that, and real switch press and release get read as that even with normal switch bouncing and I have plenty of time to decide if it released. And nothing will activate crazy fast interrupts faster than they can return because the delay prevents that.

That's all I need, and a bit extra actually.

Maybe it's not perfect for any need in any context, certainly not for high noise, maybe not in buck drivers. But people going off on me calling me arrogant and ignorant for using it my endeavor, an endeavor they haven't even studied? Wow.

Next up...

Debunking debouncing non-algorithms.

I know you were just being funny, but, it's hard to debunk what is actually working just fine. Dead simple, no averaging, no looking for a string of agreement, and no problems. It doesn't filter true noise, which could possibly be a problem on a buck or boost, but I'd be a bit surprised actually. I've probably clicked this light 1000 times. Bouncing is all gone.