One of the first frustrating situations a beginning microcontroller programmer will come across is the issue of debouncing switches. Microcontrollers are faster than switches, and the switch has yet to be built that can change state in zero time like they can on paper. This hurdle is easily overcome, but soon we are all faced with another issue: filtering noise from an analog signal. Luckily [Paul Martinsen] has put together a primer of three different ways to use an Arduino to filter signals.
The first (and fastest, simplest, etc.) way to filter an analog signal is to sample a bunch of times and then average all of the samples together. This will eliminate most outliers and chatter without losing much of the information. From there, the tutorial moves on to programming a running average to help increase the sample time (but consume much more memory). Finally, [Paul] takes a look at exponential filters, which are recursive, use less memory, and can be tweaked to respond to changes in different ways.
[Paul] discusses all of the perks and downsides of each method and provides examples for each as well. It’s worth checking out, whether you’re a seasoned veteran who might glean some nuance or you’re a beginner who hasn’t even encountered this problem yet. And if you’re still working on debouncing a digital input, we have you covered there, too.
If you’ve ever turned a rotary encoder or pushed a cursor button and had it skip a step or two, you’ve suffered directly from button bounce. My old car stereo and my current in-car GPS navigator both have this problem, and it drives me nuts. One button press should be one button press. How hard is that to get right?
In the last session of Embed with Elliot, we looked into exactly how hard it is to get right and concluded that it wasn’t actually all that bad, as long as you’re willing to throw some circuitry at the problem, or accept some sluggishness in software. But engineers cut corners on hardware designs, and parts age and get dirty. Making something as “simple” as a button work with ultra-fast microcontrollers ends up being non-trivial.
And unsurprisingly, for a problem this ubiquitous, there are a myriad of solutions. Some are good, some are bad, and others just have trade-offs. In this installment, we’re going to look at something special: a debouncer that uses minimal resources and is reasonably straightforward in its operation, yet which can debounce along with the best of ’em.
In short, I’ll introduce you to what I think is The Ultimate Debouncer(tm)! And if you don’t agree by the end of this article, I’ll give you your money back.
Continue reading “Embed with Elliot: Debounce your Noisy Buttons, Part II”
“Psst…hey buddy! Wanna see the sweetest little debouncing routine this side of Spokane? C’mon over here. Step right over those bit-shift operators, they don’t bite. Now look at this beauty right here: I call her The Ultimate Debouncer(tm)!”
Everybody who works with microcontrollers eventually runs into the issue of switch bounce or “chatter”, and nearly everyone has their own favorite solution. Some fix it in hardware, others fix it in software. Some hackers understand chatter, and others just cut-and-paste the classic routines. Some folks even try to ignore it, and they might even get lucky, but everyone’s luck runs out sometimes.
In the next two “Embed with Elliot” installments, I’ll look a little bit at bouncing, look into doing hardware debouncing both the simple way and the right way, and build up a basic software routine that demonstrates some of the principles and which works just fine, though it’s not optimized. We’ll be laying the groundwork.
In the next installment, I’ll let you in on my personal favorite debounce routine. It’s a minor tweak on a standard, but with some special sauce that’s worth spreading around. I’ll call it the Ultimate Debouncer(tm), but will it stand up to the scrutiny of the Hackaday commenteers? (How’s that for a cliffhanger?!?)
For now, though, let’s look into switch bounce and the standard ways to fix it in hardware and software.
Continue reading “Embed with Elliot: Debounce your Noisy Buttons, Part I”
The Progressive Snapshot is a small device that plugs into the ODB-II port on your car, figures out how terrible of a driver you are, and sends that data to Progressive servers so a discount (or increase) can be applied to your car insurance policy. [Jared] wondered what was inside this little device, so he did a teardown. There’s an Atmel ARM in there along with a SIM card. Anyone else want to have a go at reverse engineering this thing from a few pictures?
[Alex]’s dad received a special gift for his company’s 50th anniversary – a Zippo Ziplight. Basically, its a flashlight stuffed into the metal Zippo lighter we all know and love. The problem is, it’s battery-powered, and Zippo doesn’t make them any more. It also uses AAAA batteries. Yes, four As. No problem, because you can take apart a 9V and get six of them.
‘Tis the season to decorate things, I guess, and here’s a Hackaday snowflake. That’s from [Benjamin Gray], someone who really knows his way around a laser cutter.
HHaviing trouble wiith a debounce ciircut? HHer’s a calculator for just thhat problem. Put iin the logiic hhiigh voltage level, the bounce tiime, and the fiinal voltage, and you get the capaciitor value and resiistor value.
A harmonograph is a device that puts a pen on a pendulum, drawing out complex curves that even a spirograph would find impressive. [Matt] wanted to make some harmonographs, but a CNC and a printing press got in the way. He’s actually making some interesting prints that would be difficult if not impossible to make with a traditional harmonograph – [Matt] can control the depth and width of the cut, making for some interesting patterns.
The Mooltipass, the Developed On Hackaday offline password keeper, has had an interesting crowdfunding campaign and now it’s completely funded. The person who tipped it over was [Shad Van Den Hul]. Go him. There’s still two days left in the campaign, so now’s the time if you want one.
This wooden box is a wireless pinball controller and tablet stand. The idea is to set it on a workbench to give you some of the thrill of standing and playing the real thing. [Jeff] has been rather addicted to playing a pinball app on Android lately, and started the journey because he needed a way to give his thumbs some relief.
An Arduino monitors buttons on either side of this wooden controller. [Jeff] is new to working with hardware (he’s a Linux Kernel developer by trade) and was immediately struck with button debouncing issues. Rather than handle this in software (we’ve got a super-messy thread on that issue with our favorite at the bottom) he chose a hardware solution by building an SR latch out of two NAND gates.
With the inputs sorted out he added a BlueSMiRF board to the project which allowed him to connect a Nexus 7 tablet via Bluetooth. At this point he ran into some problems getting the device to respond to his control as if it were an external keyboard. His stop-gap solution was to switch to a Galaxy Tab 10.1 which wasn’t throwing cryptic errors. Hopefully he’ll fix this in the next iteration which will also include adding a plunger to launch the pinball, a part which just arrived in the mail as he was writing up this success.
We’ve embedded his quick demo video after the break.
Continue reading “Wireless pinball controller for tablet gaming”
Last month we asked you to send in your debounce code. You didn’t disappoint and it’s time to share the code received. There were some guideline for sending in code so if you don’t see yours here, it probably didn’t follow the rules, sorry. We also tried to weed out code that using delay loops for debounce. These tend to be a poor way to handle inputs because they monopolize the processor.
We wanted to add upvote/downvote buttons to each set of code to give some idea of a group consensus on code quality but there’s no good system available for multiple up/down vote widgets on one wordpress page. This results in a huge code dump for any one person to go through. If you’ve got any ideas on how to better organize this let us know: email@example.com.
We make no guarantees that this code is safe to use, or that it even works. Test it carefully before using for important tasks.
Join us after the break for a whirlwind of code examples.
If you’ve ever designed an embedded system with at least one button you’ve had to deal with button debouncing. This is also know as contact bounce, a phenomenon where a button press can be registered as multiple button presses if not handled correctly. One way to take care of this is with a hardware filter built from a resistor-capacitor setup, or by using a couple of NAND gates. We find that [Jack Ganssle] put together the most comprehensive and approachable look at contact bounce which you should read through if you want to learn more.
We’re interested in software solutions for debouncing buttons. This seems to be one of the most common forum questions but it can be hard to find answers in the form of reliable code examples. Do you have debounce code that you depend on in every application? Are you willing to share it with the world? We’d like to gather as many examples as possible and publish them in one-post-to-rule-them-all.
Here’s some guidelines to follow:
- Please only include debounce code. Get rid of other unrelated functions/etc.
- You should send C code. If you want to also send an assembly code version that’s fine, but it must be supplementary to the C code.
- Please comment your code. This will help others understand and use it. You may be tempted to explain the code in your email but this info is best placed in the code comments
- Cite your sources. If you adapted this code from someone else’s please include a note about that in the code comments.
As an example we’ve included one of our favorite sets of debounce code after the break. Please note how it follows the guidelines listed above.
Continue reading “Open Call: send us your Debounce code”