Interrupt routine for button somehow respondng to room lamp turning off and on

Question

I have a sketch that has been running fine on an Uno 24x7 for a few months now. The part of interest is an interrupt routine associated with a momentary contact switch [on pin 2]. When pressed, the interrupt routine handles debouncing and simply toggles a boolean variable. The main routine checks status, takes action, warbles a buzzer, and does a Serial.print of the event.

Today, I moved the unit to the other side of the room and plugged it into a different PC via USB. Whilst it was running, I happened to turn on a nearby fluorescent light [not connected to anything but a 120v outlet].

The Uno buzzer went off, and appropriate msgs were written to the serial connection. I flipped the light back on, and got the same kind of results. I repeated this numerous times and got the same. I could flip the light or push the button attached to the Uno, and the results were indistinguishable.

I unplugged the USB cable and used the power jack instead. I got the same results, sans the print msgs to the serial connection.

The board itself has only a DS3231, an 8x8 LED matrix, a button, two LEDs & resistors, and a buzzer.

What is happening? How can I resolve the problem? [If another person had posted this, I would be disinclined to believe it, but surely someone out there understands the situation.]

I can readily supply a minimal code set and a Fritzing if it would help, though I suspect it would not.

• 6v6gt: Long wires to your switch, missing pullup/down resistor are possible causes of sensitivity to electrical activity near by. Polling a switch rather than triggering an interrupt is more usual.

Answer 1

Yours is a problem of EMI (electromagnetic interference). The ballast from the fluorescent light may interfere via two mechanisms:

1. Conducted EMI through the power lines (unlikely). In order to rule out this condition, power your Uno through a battery or a battery-powered device (a laptop disconnected from mains). If EMI effects disappear, then you have a problem of conducted EMI and you must use some kind of power-line filter. If it doesn't disappear, then it's a problem of radiated EMI (continue reading).

2. Radiated EMI (most likely). There are some things you can do to mitigate its effects:

   • Use wires as short as possible.
   • Twist wire pairs whenever possible.
   • Avoid operating conditions that leave inputs unterminated (be sure they're always either pulled up or low). This can easily happen when switchs are used and they leave an input in a high-impedance (disconnected) state.
   • Increase the debouncing time or use a more robust, glitch-tolerant debouncing routine.
   • Consider polling the input instead of using an interrupt. However, doing this will be of little use if you don't improve your debouncing routine.
   • Consider adding hardware debouncing.

Regarding the last three points, I recommend you to read this this. You'll have a better grasp about the art of debouncing inputs.

SPOILER: One thing you can do to make your debouncing routine far more robust is to wait for N consecutive readings with the same value (to happen during a given time T = N x Interval) before considering it good, instead of just waiting for a second reading after a constant time T.

• KC Tucker: Thank you, very informative. I'm sure I can handle it from here. As a note, I used battery power and experienced the same problem, as you predicted. I also noticed that actually disconnecting the switch has no effect as long as the lead wires [ about 12"] are still in place. I can easily change the configuration and shorten them considerably.

Answer 2

My guess: pickup on the input line from interference. (I'd expect this more if the switch were on a long cable away from the Arduino.)

If the button uses an external pull-up resistor, try a smaller value (maybe 5k?). If it uses the internal pull-up, try adding an external one.