I've got a funny problem with interrupts and PWM signals that's causing false interrupts to trigger. What exactly is happening is that I'm using a hardware debounced quadrature rotary encoder. The pulses from the encoder are connected to interrupts which then I can determine the direction of rotation. Pretty standard routine. This works fine on it's own. Debounced Rotary Encoder

Now, I introduce a PWM output into my project. In this case, lets say I am dimming an LED. I load my program and the led works fine. When I rotate the encoder one "click", It appears that there are multiple interrupts that are triggered on the encoder..on the order of about 16 times the amount expected.

I've simplified the code all the way down and I've tried different different combinations of PWM and Interrupt pins and the response is always the same. The one bizarre thing I notice is that if I disconnect the jumper wire from the PWM pin to the LED, the problem goes away and the encoder starts behaving like it should. I'm baffled and can't figure out what's going on here?

How can I debug or test this? What's with the PWM jumper unplug and interrupts working properly? What does this sound like?

Also, I've asked this question on the Netduino and GHI electronics forums and haven't received any solutions.


simulate this circuit – Schematic created using CircuitLab

Actual Circuit: Actual Circuit

Update: Based on the help in the comments, I've uncovered that there is some type of noise induced in the PWM jumper wires which affect the jumper wires connected to the rotary encoder. When the PWM jumper wires are near the encoder jumper wires, the problem condition exists. How to I eliminate this noise, other than keeping the jumper wires apart from each other. Furthermore, how do you eliminate this noise in the case of PCB traces?

  • \$\begingroup\$ My guess is that you have a layout problem. The currents flowing in the PWM circuit are causing ground bounce, coupling, or level shifting such that the interrupts get triggered. Better layout, decoupling and routing of the high current and high dv/dt signals should solve there problem. \$\endgroup\$
    – John D
    Apr 14, 2014 at 18:06
  • \$\begingroup\$ Have you got an oscilloscope you can look at the signals with? That would be a good start. \$\endgroup\$
    – John U
    Apr 14, 2014 at 18:42
  • \$\begingroup\$ What amount of current does the LED draw and how is it connected to the Netduino? Did you use extra decoupling around the LED driver? Also take a look at this electronics.stackexchange.com/questions/90971/… \$\endgroup\$
    – jippie
    Apr 14, 2014 at 19:09
  • \$\begingroup\$ @JohnU I'm working on getting an oscilloscope ASAP, BUT I do have a logic analyzer which shows the expected behavior for each click of the encoder. I recognize an oscilloscope is really what I need, but FWIW the logic analyzer giving expected results. \$\endgroup\$
    – GisMofx
    Apr 14, 2014 at 19:14
  • \$\begingroup\$ What exactly are we seeing in your diagram? I'm assuming: A and B are connected to your input pins, C is connected to ground? \$\endgroup\$
    – John U
    Apr 14, 2014 at 19:22

1 Answer 1


Use software debouncing: In your interrupt routine deactivate interrupts (so no other interrupts after the current one are fired) and then set a flag, that the interrupt was called.

In your Main routine check for the flag, act on it and then enable interrupts again. Maybe add a small delay before enabling interrupts again.

This seems to be another solution to software debouncing:

 private static void Button1_OnInterrupt(uint data1, uint data2, DateTime time) {
        // glitch filter. events within 50 milliseconds of the first event are discarded
        if (Button1LastPushed.AddMilliseconds(50) > time)
        // Debug.Print("Button 1 Interrupt");
        Button1LastPushed = time;
        // actions on interrupt here

Of course you need to adapt it to your PWM.

PS: LEDs have a small backward current, this could be the source of your problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.