Debouncing SPDT Switches
Single-pole, double-throw switches enables many debouncing options when using all three terminals, and it is a shame that companies like Logitech that use SPDT switches in most of their mice do not take full advantage of them. In every Logitech mouse I have opened, only the common and NO contacts are used; the NC pin is only present for mechanical support. The simplest analog debounce method is to tie the NO contact to VCC, the NC contact to ground and connect a resistor-capacitor (RC) filter on the common (blade) contact for the output. This way, the capacitor holds its voltage whenever the blade is in-flight between contacts.
This awfully simple implementation already eliminates most of the bounce noise that would be seen by the controller's input. If I didn't tell you that the waveform was created using the crusty old switch, it could be easily be mistaken for a new one (unless you looked at the flight time, which is still around eight milliseconds between the beginning of the hump indicating initial break with the NC/ground contact and the first peak indicating contact with NO/VCC). Here, the hump is due to leakage current through the mouse because I hooked up the switch in-circuit instead of desoldering it. That's not ideal, since feeding power through the controller's inputs and outputs might fry them. But if I do fry something, I still have a spare. With a 1kΩ resistor in-circuit, though, damage is unlikely since five milliamperes is well within the tolerances of ESD protection diodes on input pins and CMOS transistors' body diodes on output pins. If the controller uses transistor-to-transistor logic (TTL), then less than 5V current-limited to less than 5mA is not going to hurt anything either.
Is it possible to do better than this? Of course. Instead of relying on a capacitor to hold the value, you can use a Schmitt trigger buffer or equivalent, which can easily be integrated into a chip to eliminate external components.
I used the 74LS14 (hex Schmitt-trigger input inverter) as my Schmitt buffer since that was the first chip I found in my parts box with Schmitt inputs. Given that it is an inverter, I put two in cascade to simulate a non-inverting Schmitt trigger. Internally, a Schmitt behaves like a comparator with positive internal feedback to create hysteresis, reducing susceptibility to noise. Once the input passes the high threshold, typically 1.6V in this case, the output goes high and won't go low again until the input drops below 0.7V. The feedback resistor in my circuit keeps the input from going floating while the blade (common) is bouncing or in-transit between contacts, since leaving the pin floating would let it pick up random noise or let it get pulled up/down by leakage currents.
The way this works is simple: as soon as the switch touches the NO contact, the Schmitt trigger goes high and holds its own input there until the switch is done bouncing. The same process repeats on the NC side when the switch is released.
How simple would it be to implement inside an integrated circuit? In this specific application, we aren't even interested in the full Schmitt trigger functionality, only the decisive switching characteristic and the value-hold from the feedback resistor. Reduced to CMOS transistors, two inverters back to back with a feedback resistor translates to the following:
What is this? Nothing more than an elemental static memory cell. If the input drive is stronger than the second inverter's weak drivers, such as a switch making contact with the NO or NC contact connected to VCC or ground, and it brings the first inverter's gate voltage over its threshold, the cell switches state to match the input. Otherwise, it holds its current state. As far as semiconductors go, it does not get much cheaper and simpler.
The two D-type flip-flops (DFFs) to the right are a standard interface between two different clock domains (asynchronous input versus clocked logic in this case) to eliminate glitches that might occur when the input changes within the D-flop's setup-and-hold window around clock edges: when a timing or input signal level violation occurs, the DFF may oscillate for hundreds of picoseconds. Putting two DFFs in cascade lets the first one oscillate and settle before the second one clocks in that stable state for the rest of internal logic to use.
Is it possible to do even better? Sure. The two previous options only required one controller pin each. If you can afford two pins per switch input, then you can use set-reset (SR) latch debouncing.
What does an SR latch do? The simplest tool to help explain it is the good old truth table.
|SR Latch Truth Table|
When both S and R are low, the latch holds whatever its previous output (Q') was. When S (set) goes high, Q goes high, when R (reset) goes high, Q goes low. If both S and R are high at the same time, behavior is technically undefined but many implementations have a dominant input to avoid oscillation or other unstable states. How do you use that for debouncing an SPDT switch? It is very simple.
When the blade touches the NC contact, the SR latch gets reset, when it touches the NO contact, the latch gets set. When the blade is in-flight for whatever reason, the pull-down resistors keep both inputs low and the SR latch holds whatever value it previously had. In an integrated circuit, the resistors would get replaced by more space-efficient FET current sinks.
Short of a mechanical failure, it is physically impossible for the blade to simultaneously touch both the NO and NC contacts, which means no need to worry about the undefined behavior case when both inputs are high. Since an SR latch manufactured on a sub-micron process has nanosecond-scale reaction time or faster, while switches bounce at least three orders of magnitude slower in the microseconds time scale, glitching an SR debouncer through mechanical means is nearly impossible. Moreover, the first bounce should be the hardest with all the moving components' inertia and spring force behind it, guaranteeing firm initial contact to set or reset the latch. Once the latch has been set or reset by that first bounce, any other bounces on that side cannot glitch the SR latch since that input becomes a “don't care” (no effect) until the other one goes high, which is physically guaranteed not to happen within hundreds of microseconds by travel time. With soft, worn switches, that might turn into milliseconds.
In my implementation, I used a CD4043. We can see that SR debouncing produces glitch-free output on the first bounce. If mouse manufacturers used SR debouncing with their SPDT switches, the glitchy button problem would be history. The single-pin Schmitt/SRAM debounce would achieve this goal too without the expense of an extra pin per switch; all it needs is the SPDT switches wired to both VCC and ground. This is one more example of perfectly good theory not getting used in practice to save pennies per unit and also to perpetuate planned obsolescence. That is, sales would drop if you no longer needed a new mouse every two to four years as a result of glitchy buttons.
In all three SPDT debouncing cases, there is also the slight disadvantage that switch release cannot be detected until the blade has returned in the NC position, which may translate into a few milliseconds of extra input latency on button release for the blade's return trip. Is that a big deal? Unlikely, since the press/make input latency is typically far more important than the release, and travel time in both directions is roughly the same. I would not mind trading four milliseconds of release latency for never having to worry about button presses randomly releasing ever again.
That's one common type of switch taken care of; there's one more to go.