Page 1 of 1

Arduino External Interrupt problem

Posted: Mon Dec 20, 2010 12:53 pm
by ADDandy
Has anyone worked with arduinos? im trying to write some example code for a friend, but it seems like the external interrupts are really noisy. i've added some debouncing which helps. and the signals connected to the external interrupts have a 10Kohm pulldown resistor.

Has anyone else found the external interrupts to be really really noisy? the next step is to scope it, but that means i have to bring the circuit to school to borrow a scope.

Cheers
-Andy

Re: Arduino External Interrupt problem

Posted: Mon Dec 27, 2010 9:09 pm
by Tetragrammatron
I am starting some arduino development as soon as possible. I'm curious how you accomplish your debouncing? As I said, I haven't begun development yet, but I'm curious how its accomplished on the arduino.

Re: Arduino External Interrupt problem

Posted: Wed Dec 29, 2010 1:27 pm
by ADDandy
the standard way to do debouncing, is to check for the pin to go high or low, then wait a period (5-10ms) and check to see if the pin is still in the correct state.
the problem with the arduino is that you can't use timers correctly inside ISRs. (unless you write your own wait function that NOPS)

You can do hardware debouncing (i think, i've never done this) by putting a lowpass filter (R-C pair) on the input, which should get rid of all the short suprious noise.

Re: Arduino External Interrupt problem

Posted: Wed Jan 12, 2011 12:59 pm
by JamesCooper
Here is a great link that explains the challenges of debouncing switched inputs. All switches (even things like relays) will oscillate between on and off as they transition to and from their opened and closed states. This transition time is usually considerably longer than a clock cycle on a microcontroller, so you can expect your interrupt to be triggered multiple times from a single switch transition.

The most common and basic solutions are either a R/C low-pass filter on the input (which tries to minimize the high-frequency noise) or a software algorithm that waits until the state read stays constant for a certain amount of time. The former can be tricky to tune (as it depends on the resistance of the switch and the capacitance of the input pin), whereas the software one can waste power and clock cycles.

Some nicer microcontrollers have built-in input debouncing, though it may need to be enabled by setting a flag in a register somewhere. These are usually the simple software debouncers, but built in hardware. They may or may not be available on interrupt pins, which are the most sensitive to bouncing, since they immediately cause a jump in software when a transition is detected.

No matter what you do, you have to trade-off the probability of false transitions with the speed at which you respond to that transition. The longer you wait to acknowledge the transition, the more likely that it's a proper transition, but the longer it will be until you can act on that transition.

The most important thing to know is how long your bouncing period is. You should be able to measure this easily with even a cheap oscilloscope. Flip the switch a bunch of times, have the oscilloscope set to trigger on an edge (either direction is fine), and look at how long the bouncing is before it settles out. Pick the worst, add some margin, and that's a good place to set your switching time.

If you are using an RC filter, the time it takes for the RC to charge up to 63% of the transition is T=R*C. You also need a circuit that will respond abruptly and stably to this slowly changing voltage. A Schmidt trigger will do this. Often, microcontrollers have built-in Schmidt triggers on their pins, but again, these may need to be enabled.

If you are using software, try to avoid using it on an interrupt, since it is very disruptive to the execution cycle to have an interrupt triggered multiple times. You'll probably also want to avoid a busy loop. Instead, use the sensing of the first transition to start a timer, set at some fraction of the total time you want to wait. Every time the timer goes off, check the input state, and keep a count. Reset it if the state changes. If the counter goes over the threshold, the input signal looks stable at whatever state you are reading. You'll want to try to make sure the timer frequency isn't similar to external noise sources, like 60 or 120Hz.

Re: Arduino External Interrupt problem

Posted: Wed Jan 12, 2011 3:23 pm
by Bergo
Hackaday recently (november?) had a big write up about debounce code. here is linkage:
http://hackaday.com/2010/11/09/debounce ... -them-all/

Re: Arduino External Interrupt problem

Posted: Wed Jan 12, 2011 7:12 pm
by ADDandy
so turns out the problem was because of the breadboard i was using. it was just crazy noisy. fixed with some debouncing (SW) and making better connections.

What i learned: Bread boards are not made equal, and cheap chinese breadboards are really really noisy.

Re: Arduino External Interrupt problem

Posted: Fri Jan 14, 2011 7:58 am
by JamesCooper
Breadboards are great for prototyping, but they certainly have their limits.

All breadboards consist of a bunch of long, parallel wires. Two other things consist of long, parallel wires: capacitors and antennas. Breadboards have considerable capacitance (enough that you often don't need to add caps to a crystal oscillator) and will happily pickup any nearby EMI. These can make for a great time debugging a noisy circuit and can cause a prototype to fail when you move it to a more permanent board.

It's worth using a multimeter to measure the capacitance of your board and see how much noise it tends to pick up. It's also a good idea to keep it away from strong electromagnetic fields, since it makes such a great antenna.