They taught me a lot of things at university. Unfortunately, they neglected to mention the topic of switch bounce. If you are a practicing engineer working with electronic systems, you will almost certainly have run into this problem. If you are new to the field, you can be assured that the delights of switch bounce are lurking out there waiting for an opportunity to bid you a cheery “Hello!” Be afraid; be very afraid.

If they think about it at all, most non-engineers visualize the operation of a switch as being similar to dropping a chunk of Play-Doh on a wooden desk. When the Play-Doh lands, it goes “splat” and stays where it is. In reality, operating a switch is more like dropping a ping-pong ball onto the desk. In this case, the ball will bounce multiple times before eventually settling down. Similarly, when we operate a switch, it also bounces one or more times before coming to rest in its new state.

This switch bounce occurs both when the switch is closed and when it opens again. It also occurs in toggle switches, rocker switches, pushbutton switches, and so-forth — pretty much everything apart from the switches most of us never use anyway, like mercury tilt switches, for example.

In the case of a light switch on the wall, we don’t notice the fact that it bounces because everything occurs too fast for it to register on our eyes and in our brains. It’s a different story when the switch is connected to a microcontroller (MCU) that can sample its inputs millions of times each second. In this case, the MCU may see the switch being toggled as comprising multiple events. If you were in charge of pressing a pushbutton every time someone entered a room for example, then the MCU might count each press as comprising anywhere from one to twenty (or more) events.

Just to increase the fun and frivolity, each switch is different. This not only by type, although that may play a factor; switches of the same type can behave in contrary ways. Even worse, an individual switch may vary its characteristics depending on the temperature, humidity, time of day, direction of the prevailing wind, and the color of your plaid polyester golf trousers.

If a switch is connected to some safety-critical or mission-critical system, and the system’s designers haven’t adequately addressed its switch-bounce characteristics, then the chances are that someone, sometime, is going to have a “very bad hair day.”

If a system can be negatively affected by switch bounce, then someone is going to have to deal with the issue, either in hardware or in software. Now, if you aren’t a designer working in the trenches (perhaps you are a manager, bless your little cotton socks), you may mistakenly assume that, since we are all aware this is an issue, we are also all cognizant of the answer to the problem. Would that it were so; unfortunately, there is no “one size fits all” solution.

The way things used to work in the not-so-distant past is that junior engineers were instructed as to the switch-bounce solution(s) favored by their more senior colleagues. In turn, those fonts of knowledge were instructed by their mentors, and so on and so forth deep into the mists of time. As a result, there are now so many solutions scattered around the internet — where most young engineers now go to satiate their craving for knowledge — that it makes your head spin. On the bright side, some of these offerings actually work; on the downside, their working may be due to chance rather than design.

How bad is this problem? It’s rampant. Have you ever pressed the Up or Down channel selector on a TV controller, only to have it skip through multiple channels? If so, the controller’s designers probably didn’t account for switch bounce as well as they thought they had. Just a few days ago as I pen these words, I was discussing this issue with the legendary embedded guru Jack Ganssle, who said, “I agree about people not knowing this stuff. In fact, I own a small FM transmitter that is hard to turn off because its power switch bounces so much.”

I asked Jack to elucidate (it’s OK, he’s a professional), and he replied as follows: “We live pretty far out in the country, and my hearing protectors, which have an FM receiver, can’t get Baltimore’s classical station. In the olden days, a half-dozen vacuum tube radio would be all one would need to listen to the radio. Instead, I now use an old iPhone that streams the station. The phone is plugged into a 100 mW FM transmitter that broadcasts on an empty frequency to my hearing protectors when I’m using noisy tools (tractor, sawmill, chainsaw, etc.). So, instead of a half-dozen vacuum tubes, I’m now using the 100 billion or so transistors in the iPhone! The transmitter itself is a cheap Chinese device. When I press the power button to turn it off, half the time it goes off and then comes on again — a classic case of switch bounce.”

Just What is a Switch?

Before we proceed, we should perhaps note that, in the context of electrical engineering, the term “switch” refers to a component that can “make” or “break” an electrical circuit, thereby interrupting the current or diverting it from one conductor to another.

We should also note that there is a mind-boggling variety of switch types, including toggle switches, rocker switches, slide/slider switches, rotary switches, pushbutton switches, tactile switches, micro and limit switches, knife switches, magnetic switches, reed switches, mercury switches, smart switches, and… the list goes on (you can peruse and ponder my Switch Types column to see images and discover more).

Hardware vs. Software

As we alluded to earlier, there is a wide range of solutions one can use to address the switch bounce problem. One approach is to pre-process the switch signal in hardware so as to pass a “clean” (debounced) signal to the computer. An alternative technique is to feed the “dirty” (bouncing) signal from the switch directly into the computer, and to “clean it up” (remove the bouncing) in software.

Prior to the introduction of the microprocessor circa the 1970s, there were relatively few computers around, and these were typically of the mainframe (“big iron”) variety. Just renting a mainframe computer circa the mid-1960s could cost tens of thousands of dollars a month (goodness knows what buying one would cost). Thus, at that time, price was not an issue with regard to a solution to debounce the switches; what was an issue was consuming precious memory and clock cycles.

Although the mainframes of the 1960s were physically large, they were extremely limited in terms of memory and performance (at least, they were by today’s standards). For example, the IBM System/360 Model 30, which was introduced in 1964, came equipped with only 8 to 64KB of memory and could perform only 34,500 instructions per second. Not surprisingly, programmers at that time didn’t want to waste any of their precious memory or instruction cycles doing something so mundane as debouncing switches (the situation wasn’t helped by the fact that the programmers probably weren’t aware of switch bounce in the first place).

The solution of choice, the crème de la crème (as it were) of hardware debouncing solutions was to use… but no! There are so many tasty tidbits of trivia and savory nuggets of knowledge pertaining to the myriad hardware and software solutions available that we will save them until my next column. In the meantime, do you have any stories you’d care to share regarding problems caused by bouncing switches?