"Slowing down" interrupts?

Hey guys, I'm trying to have an interrupt detect pulses from a lightning detector circuit I have. It pulls the pin low whenever it detects a strike, however my trigger value flies up rapidly, meaning that the interrupt is somehow being triggered multiple times from each strike.

Is there a way I can check whether the interrupt has already been triggered in x timeframe, and if not, the value won't increment?

EDIT: I've managed to slow it down using this little snippet of code:

static unsigned long last_interrupt_time = 0;
  unsigned long interrupt_time = millis();
  // If interrupts come faster than 200ms, assume it's a bounce and ignore
  if (interrupt_time - last_interrupt_time > 200)
  {
    ... do your thing
  }
  last_interrupt_time = interrupt_time;

Thanks

Things: Hey guys, I'm trying to have an interrupt detect pulses from a lightning detector circuit I have. It pulls the pin low whenever it detects a strike, however my trigger value flies up rapidly, meaning that the interrupt is somehow being triggered multiple times from each strike.

Is there a way I can check whether the interrupt has already been triggered in x timeframe, and if not, the value won't increment?

Thanks

Sounds like the same problem people face when dealing with switch contact bounce, and probably the same solutions apply, either external hardware bounce filtering or software debouncing function. There was a post just a day or two ago on this subject. When it's in context with an external interrupt pin it's a little more complex as you have to be careful how much time you waste inside a ISR function.

I've done a post about interrupts:

http://gammon.com.au/interrupts

Search on that page for "debounce" for a technique for dealing with switch bounces.

however my trigger value flies up rapidly, meaning that the interrupt is somehow being triggered multiple times from each strike.

Are you sure you are triggering the interrupt off an edge like falling / rising and not a logic level like LOW?
If you trigger off a LOW then it will keep re-triggering the interrupt until it goes high.

I'm aware that what we think of as a "single" lightning strike is often multiple events. Sometimes they are slow enough and/or last long enough to see. Maybe 200ms isn't long enough of a "debounce" time. Then there might be a risk of missing another independent but temporally close strike in an active storm.

Producing lighting on demand to test this one is gonna be a bear, and will probably run the electric bill up some XD

Producing lighting on demand to test this one is gonna be a bear

Well not for our God members.

Grumpy_Mike:

Producing lighting on demand to test this one is gonna be a bear

Well not for our God members.

Ha! You know, it’s not a thing I’m particularly touchy about, but I’m thinking about spamming the forum just to get past that “title”. ]:slight_smile:

Things: Hey guys, I'm trying to have an interrupt detect pulses from a lightning detector circuit I have. It pulls the pin low whenever it detects a strike, however my trigger value flies up rapidly, meaning that the interrupt is somehow being triggered multiple times from each strike.

Is there a way I can check whether the interrupt has already been triggered in x timeframe, and if not, the value won't increment?

If you don't mind the interrupt service routine being called multiple times, do what you already appear to be doing already, i.e. in the ISR check whether enough time has elapsed since the last one for you to want to record it. If you want to prevent multiple interrupts occurring, then you can disable or detach the interrupt within the ISR and use a polling loop in the main program or a timer interrupt to re-enable or re-attach the interrupt after a period of time.

@Things You may want to notice those multiple strikes - they can be an indicator as to how much energy is being expended, which translates pretty directly to storm intensity.

I don't know much about Cairn's weather, but in my area severe thunderstorms bring tornados, and what you're trying to eliminate would be considered a feature here. Just saying...