Go Down

Topic: Simple Button Input Floating Problems - New User (Read 8872 times) previous topic - next topic

Jack Christensen

Apr 20, 2011, 11:46 pm Last Edit: Apr 20, 2011, 11:51 pm by J Christensen Reason: 1
No, I'm afraid I don't see.  If the switches are just sitting there, not being touched, not changing state, they will not bounce.  At least not any switch I've ever met.  Bouncing is a transient phenomenon that happens when a switch is switched.

Now, what you say may well be true, debounce logic may indeed fix the problem, but in this case it's addressing the symptom, not the underlying cause.  I'd rather understand why the signals are changing when the thing is just sitting there untouched.  If I understand the situation correctly, this is not normal switch behavior (but yes, bouncing is normal switch behavior).


Yes you are correct that debouncing does not explain why the phenomenon is happening, but it will fix the problem, which seems good enough to solve the OP's woes...I would guess the problem is due to EM noise or an issue with the button you are using.

Jack Christensen

LOL, well I am just about ready to give up and call Mulder and Scully anyway.  This must be the Haunted Arduino.  Either that or there are a dozen arc welders in the next room!


Not really, it could be an unstable USB supply, poor grounding....etc.
At least the phantom emails wont be bothering the OP anymore.

Jack Christensen

Yes, good points.  woodsby, any chance of taking the Arduino to a friend's house or something, to see if it exhibits the same behavior?

I do have a crazy EMI story.  Had a treadmill that didn't get along with my DSL internet connection.  Every time someone fired it up, my connection would go down, but once the treadmill was running at a more or less constant speed, things were OK.  Took quite a while to figure out the cause.  Once I did, I reran all the phone lines in the house with CAT5 cable, and even put it in EMT as much as possible, but to no avail.  When that treadmill was running, AM radios were unusable within a couple hundred feet of the house (and the treadmill was in the basement!)  Never did manage to mitigate it.  Luckily the treadmill died (kid on the cross country team did it in) and the replacement (different brand) doesn't bother the DSL.  Just saying, it could be something totally unrelated.


OK, first, you can call me @woodsby... OP seems so formal... lol
Second, I think I may  have found the problem!

Third, this method of "debouncing" will not work for me for a couple reasons.  Most importantly, what I'm monitoring (stuff around the house, specifically the doorbell is the problem here) occasionally closes relay contacts for less time than the "floating" input takes to float back.  Second, I am using 2-way serial interface, so I have two options - be able to handle "time-intensive" code (delays, etc)  and incoming serial data in the loop, and interrupt with the doorbell; or handle light code and incoming serial as well as the doorbell (and other momentary) inputs in the loop.  If I use the interrupts (my preferred method for things like the doorbell), I can't use delay for debouncing, and millis resets so it won't work for long-term applications.  If I try to catch and debounce inputs in the loop, couldn't I miss some incoming serial data?  I haven't played around with serial.available enough to see if it holds multiple characters until they are read.

ANYWAY, while I was taking pictures of my breadboard to post here, I semi-subconsciously noticed something.  In my workspace in the basement (my man-cave), I have a mini-fridge about 8' from my bench.  It occasionally makes a clicking sound like it's about to turn on and it doesn't.  And it dawned on me tonight that over the last week, everytime I heard that clicking, my phone would vibrate (email notification for the pin input i'm watching).  SO, I decided to play around with the fridge temp knob and spin it on and off really fast.  In one minute, and some really aggressive knob-handling, I got my inputs on both boards to float back and forth 5 times.  I am going to unplug the fridge for 24-hours and see what happens.

Jack Christensen

Interesting.  Either that fridge is related to my old treadmill (RFI) or it's putting some serious hash on the power line.  Are the lights dimming?   XD

Anyhoo, this one here has been going almost six hours without anything unexpected.

I have a project that has some tact switches and also does some slightly time-critical processing, I'm using 10mS to debounce the switches and haven't noticed any issues.  But this little experiment has pointed out that the tact switches I have are much better behaved than I might have imagined.

Doesn't seem right that simple switches tend to be one of the nastier things to handle.  You could always go to hardware debouncing.


The fridge sounds like the likely culprit. If some ferrite beads or a surge surpressor don't fix ur problem, however, I think the debounce code will work fine. U said the bounces last for a few ms. What kind of doorbell only gets pressed for a few milliseconds? The debouncing doesn't use delays, so my reccommendation is just to do everything from the loop and just don't use any delays.


I am plugged into a surge protector, and actually, both arduino boards that I'm testing with are plugged into laptops, so the boards shouldn't be seeing surges.
As for the doorbell, I have the AC from the doorbell going through a bridge rectifier and voltage regulator to pull the coil on a 5v relay. In the tests i've done, I've had doorbell presses change the pinstate for anywhere from 10ms to 1s depending on how long the doorbell is pressed - longer if you hold the doorbell of course. I know I can "debounce" both the hardware and the code to solve this, but I still don't feel comfortable with that. Nothing outside of the circuit should cause the pin to change state. As mentioned above, this doesn't fix the problem, it just circumvents it.
As for millis debouncing, the millis counter cycles back to 0 over time, correct?  That won't work, since this will be running permanently.
Since unplugging the fridge, I have not had any issues. When I get home tonight, I am going to plug the refridgerator into a different ciruit. But leave it sitting where it is. I'm curious what will happen.

Jack Christensen

Apr 21, 2011, 01:06 pm Last Edit: Apr 21, 2011, 01:15 pm by J Christensen Reason: 1

As for millis debouncing, the millis counter cycles back to 0 over time, correct?  That won't work, since this will be running permanently.

Correct, but the debounce logic could detect the millis() rollover and act accordingly.  OTOH, since the millis() rollover interval is about 50 days, the chance of a button push coinciding with it would be exceedingly remote, so it could probably be safely ignored if there isn't life or limb at stake.  Still, being a bit OCD, I might jump through that hoop anyway ;)

Anyway, glad you found the source.  I'd be interested to hear if you find a fix.  But in the meantime, and much more importantly, how will the beer stay cold?


@J, you're right - don't know why i didn't think about that, but I can account for the reset. But I keep coming back (in my mind) to the fact that this circuit should be bullet-proof and should not trip due to outside sources.  And, I really don't know that debounce is the right term for what this is anyway.
It has been almost 24 hours, and no false notifications.  Looks like the fridge is definitely  the problem.  I was planning on moving it up to the garage anyway, but first, I am experimenting to determine what the real problem is and how I can fix it anyway... again "bulletproof".  I have it plugged into a different circuit now, but left it in the same location.  Once, it cools down enough, I will "knob-handle" it again to see if I can reproduce.


I understand what you are saying about "bulletproofing", but sometimes software is part of a solution too. In fact, its probably wise to implement debouncing anyway. And yes, a bounce is exactly what you are experiencing.


Apr 22, 2011, 11:17 am Last Edit: Apr 22, 2011, 01:18 pm by woodsby Reason: 1
Definition of Debounce:
To remove the small ripple of current that forms when a mechanical switch is pushed in an electrical circuit and makes a series of short contacts.

What is being proposed is to use additional hardware to extend the amount of time of a true contact closure, and then use software to time contact closures for true closures. Different concept, though a similar solution. 

Also, what's to say I don't experience the "noise" for longer than a few ms? That's why I am looking for a "bulletproof" solution to the real problem here.

Jack Christensen

But I keep coming back (in my mind) to the fact that this circuit should be bullet-proof and should not trip due to outside sources.  And, I really don't know that debounce is the right term for what this is anyway.

Agree with the bullet-proof idea.  I'm pretty surprised that the fridge can throw enough of a spike, or hash, or whatever (since we don't really know how it's doing it) to change the input levels.  Especially since you have surge protectors and such in place.  (Idea: try one on the fridge)

Debounce: Depends on the definition.  I always think "mechanical bounce" ... Which is why I disagreed with bilbo, but maybe what he means is that the signal is bouncing.  Which is certainly one way to look at it.  Although in this case the cause is not the mechanical characteristics of the switch that's part of your circuit, but some external effect.

I'm still pretty curious about this situation, and whatever you can find out.  MCUs are not supposed to be terribly fragile in real-world situations.  Not sure what equipment you have available.  A scope on the power line would be a first step.  I'd also try an AM radio, listen to what happens when the fridge kicks in.

Another thing to consider, even though we've been focused on measuring what the input pins are doing: Most likely the effect (whatever it is) is not selectively targeting only the inputs.  So while a debounce solution might fix it from an input perspective, there's no guarantee that other effects won't appear, that could be even worse (interfering with the MCU clock, etc.)  How's the general condition of the electrical wiring at your place?  Another thing to try is one of these inexpensive outlet testers, make sure everything is wired properly.  A floating ground can cause all kinds of weirdness.  One more idea, run the MCU on batteries.  If the problem goes away, then that would point to a power line route.  If the problem continues, then maybe we're dealing with EMI.

Found an interesting item on debouncing here: http://www.ganssle.com/debouncing.htm


@J, it's funny you should ask - I am in the electrical trade.  Every outlet in my house has been replaced and tested.  It's a new house and all-in-all the wiring was done pretty well - Neutral's in every box, 3-ways wired properly.

Plugged into a different circuit, but left in the same place, I have only had one oddball input trip. Unplugged, I haven't had any.  As for the circuit - I'm not plugged into the same outlet as the mini-fridge, but on the same circuit.  The mini-fridge is plugged into a surge protector.  The Arduinos that I've been testing are plugged into two separate laptops which are plugged into another surge protector.  That said, there are two surge protectors, the house panel has surge protection (not helpful here), and the laptops have some isolation from the 120V anyway.  To make things even more confusing, I have another larger fridge plugged into the same circuit, and it doesn't seem to cause any problems.

As for the inputs - when I pull an input high with the internal pullup, and don't plug any wires into it, that input does not float back and forth.

Go Up