Filter interrupt signal (debouncing interrupt)

Hello back everyone,

I need help adding some filtering to an interrupt signal.

What is happening is that I have a noisy square wave being applied to an interrupt and sometimes the interrupt is triggered a few times in a row, rather than just on the rising edge. I would happily use an RC filter, the problem is that the debounce needs to be longer at low frequencies, when the period is larger.

I cant use a delay BTW.

Any ideas?

Kind Regards

Could you post some code?

The code is part of something larger.

Basically what I do is to set up an interrupt and inside the ISR I increment a variable.

Presumably you also have variables available for the last time the interrupt was triggered and maybe one for the currently observed frequency.

It shouldn't be too difficult to write an algorithm to decide on a debounce time. If the current itteration of the interrupt falls within that time, just don't increment the variable.

Reposting the question because you didn't like the first answer will not do you any good.

Mark

I'm not sure why this was double posted :cold_sweat:

Ill mark the other one to be deleted.

KenF:
Presumably you also have variables available for the last time the interrupt was triggered and maybe one for the currently observed frequency.

It shouldn't be too difficult to write an algorithm to decide on a debounce time. If the current itteration of the interrupt falls within that time, just don't increment the variable.

I was thinking something along the lines of disabling the ISR and re-enable again. Or just point to a function outside where I could add a delay. Somehow. And by delay I mean timer generated interrupt not the delay function.

For example... clear a variable and use the ADC interrupt to check if the variable was set in the meanwhile... Guess Ill have to try it. The only issue is I need larger debounce time at lower frequencies and im not sure how to achieve this. The signal is just a pulse, not a square wave

I was thinking something along the lines of disabling the ISR and re-enable again.

Pointless.

Or just point to a function outside where I could add a delay.

Silly You can't use delay in an ISR or in a function called from an ISR.

clear a variable and use the ADC interrupt to check if the variable was set in the meanwhile...

WTF!

Mark

If you can work out how long you would disable the interrupt for, you could instead use that value to decide whether to do your increment, so no need to disable the interrupt.

holmes4:
Pointless.

Likely, I'm just brain storming. But I could use the output compare to set a delay based on the last two pulses received.

Silly You can't use delay in an ISR or in a function called from an ISR.

and I quote again:

And by delay I mean timer generated interrupt not the delay function.

which is no more than a checking if a flag is set.

clear a variable and use the ADC interrupt to check if the variable was set in the meanwhile...

WTF!

ADC interrupt. Set the ADC clock, with auto trigger enabled to start the conversion and run an interrupt to update an array with the results when the conversion is complete, rather than wasting time in the loop waiting for the ADC results. This can be used as a "delay" (surely there's a better word) as it happens at periodic intervals

This is far too complex. Save the time when you get the first interrupt. If you get another one shortly after it, ignore it.

Yes, that's the whole idea, but how do i check if the interrupt was shortly after?

mills function? This interrupt will be served at a maximum rate of 2500Hz.

mills function? This interrupt will be served at a maximum rate of 2500Hz.

Looks to me like you've answered your own question

My question is, how much overload will I add by enabling timer 0, all the timing functions and perform the calculations at a rate up to 2500Hz while still doing other stuff.

casemod:
Yes, that's the whole idea, but how do i check if the interrupt was shortly after?

mills function? This interrupt will be served at a maximum rate of 2500Hz.

In that case micros() would be more appropriate. It's still just a simple subtraction.

Not enough information here to know what's creating the noise and why it's more severe at lower frequencies. Anyways, perhaps you could use a filter that takes care of the high frequency noise then deal with low frequency "debouncing" in software.

Try using a 10nF or 22nF capacitor in this filter: