Question about debouncing - delay of state change

I have a very simple project where I needed to debounce a button (in software). Logically, my thought process is:

• If the state's been stable for a while, and it changes, then immediately signal an event.

• Ensure that the next state is stable before allowing another state change.

So if a button isn't pressed and has been that way for a while, but all of the sudden I read a changed input, I don't think I should need to wait to confirm that the changed input has been stable (I know that there has been an actual physical change to the button state). I can simply signal an event, but disallow new events for some set period of time to prevent false button bounces from signaling events.

Here's arduino code for a function getAction() done this way:

static int buttonBounceState = BUTTON_STATE_UP; // "Bouncing" state
static int buttonState = BUTTON_STATE_UP; // Debounced state
static unsigned long lastChangeMillis = 0; // Time of last state transition
unsigned long currentMillis;

if (buttonBounceState != buttonState) {
// Only allow state change if it's been 20 millis since last
currentMillis = millis()
if (currentMillis >= lastChangeMillis + 20) {
buttonState = buttonBounceState; // Change state
lastChangeMillis = currentMillis; // Only update timings at state transition
// Button state has changed, so return an action
if (buttonState == BUTTON_STATE_DOWN) return ACT_PRESS;
else return ACT_RELEASE;
}
}
// No button state change. Return no action.
return ACT_NONE;


However, it seems that everywhere I look, the way debouncing is done is that the initial state transition needs to become stable before actually performing a software state change/event signaling. For example, the bottom picture here: https://www.baldengineer.com/arduino-de-bounce-a-button-with-micros.html

My question: is it better to do debouncing this way? Is there something about my method that might fail that I'm not thinking about - i.e., some sort of noise while button is stable-open or stable-closed? If not, it seems that my method would give more accurate timings; and I don't miss very quick button taps (but delay until stable would). Also, how do these two software methods relate to hardware debouncing. How would a hardware debouncer be implemented that can time things similar to my method?

• What happens if you get noise that changes the input for just a cycle or two as you read the input? Now it returns the press and then after 20ms blanking, the release. – Phil G Apr 18 '19 at 20:37
• There are many different justifications, none over-riding others. It depends on the circumstances. On some instrumentation I've worked on, it's quite possible for someone to accidentally "brush by" the equipment without intending anything. And it's also quite possible, since switches are sometimes not on the circuit card itself but removed from it and installed on a chassis, to have noise that may in some circumstances be large enough to trigger an event that should be ignored. So, you make decisions based on other knowledge and experience. Few bright lines exist. – jonk Apr 18 '19 at 21:53

If you debounce by reacting immediately and blanking the button (ignoring subesquent stage changes for a pre-specified time), the benefit is low latency. The drawback is vulnerability to induced noise which can make or break some systems.

People don't react fast enough to notice a 10ms latency so I think it's usually best to debounce by checking that a change-of-state is stable for a few ms before reacting. That way you can prevent unexpected noise issues.

The main reason I sometimes debounce with "react immediately then blank" is when I am writing something quick and dirty test code which will ultimately be removed. I find it's usually simpler and less invasive to code the debounce this way so its faster to write and easier to remove from the final code.

Some hardware debouncers like the MAX6816 use hard-wired timers and counters. The MAX6816, in particular, waits for the state to be stable for a certain amount of time before passing it through.

On an FPGA it is also hard-wired in the sense timers, counters, and sampling register are used. You can have it react immediately then blank, or wait until the switch as stabilized before passing the signal through.

JK-flip flop debouncers change state immediately then "blank". I put blank in quotes because they do not use a time interval to ignore subsequent changes. Rather, it relies on something more akin to mechanical hysteresis. It immediately change state if and only if positive contact electrical is made. It does not react if contact is merely lost. Therefore, if contact is lost inside the switch (like due to a bounce) but no new positive contact is made, they do not change state. The switch should never be able to bounce so hard that flies far enough in the opposite direction to hit the other contact. This is similar to conservation of energy where a dropped ball should never bounce back up to the height from which it was dropped.

There are other methods of debouncing too like using low-pass filters and comparators which sort of relies on the switch to be stable for long enough, but can also be falsely triggered if the switch bounces too many times and the time constant is chosen to be too short since the capacitor will continue to charge or discharge as the switch makes contact with each bounce.

• Well, JK flip flop debouncers can't be used with a SPST switch anyways. They require a SPDT switch. – DKNguyen Apr 19 '19 at 13:38
• Ah, sorry, read what you were saying a bit out of context, whoops – ThreePhaseEel Apr 19 '19 at 14:29
• Well, it's a good point to bring up anyways. Rules out JK-FF debouncers in most instances. – DKNguyen Apr 19 '19 at 15:39

There's absolutely nothing wrong with doing "leading edge" debouncing as you describe it — in fact, it's the method that I prefer in my own projects.

As you say, as soon as you see the first edge, you know that the user has initiated an action, so there's no reason to delay acting on it. The system will "feel" more responsive to the user.

The only reason to use "trailing edge" debouncing (the kind you've been finding) would be if there's some reason (EMI, ESD, etc.) that an input might glitch that isn't actually caused by user action.

• Thanks for this. I know plenty about software, but venturing into electronics I find that it's sometimes difficult to find information simply because of a lack of vocabulary - e.g., "leading edge" and "trailing edge" (though I'm sure these concepts come up in purely software domains as well) – BobIsNotMyName Apr 18 '19 at 23:13

There is no better way as each case can have different switches, different environment or different requirements. Your solution will work fine, if there is no false pulses for some reason. One example would be a normally closed connection, but under mechanical vibrations it might open and cause occasional false triggers, and reacting to every edge would just amplify the problem. It is a delicate balance between debouncing enough to keep unwanted noise away and not spending too much time, like polling in a tight loop for 10 milliseconds that the IO pin really stays active during that time before believing it is pushed.

If you search hard enough, you can find many complicated systems for debouncing.

Few of them outperform the very simple just wait.

Your system will have a response time requirement, you have to perform faster than, or react to pulses shorter than some threshold time, called $$\t_{min}\$$. The just wait algorithm polls the switch a little faster than this, and totally ignores it between times.

If your switch actually bounces for longer than this time, then your switch is not good enough to meet your system requirements. No arbitrarily complicated debounce scheme can disambiguate a short pulse the system should respond to from a long bounce.

In the simplest version, we just poll the switch every $$\t_{min}\$$. There will be a variable latency depending on exactly when the switch was pressed, which could be noticeable and upsetting if $$\t_{min}\$$ was bigger than 100mS or so.

In a more responsive and barely more complicated version, we poll much more frequently, and act on a change of state of the switch. Once the state has changed, we wait for $$\t_{min}\$$ before polling the switch again.