Reed Relay contact bounce

Guys

A little bit of assistance, please.

I have always been led to believe that reed relays are amongst the worst switches for contact bounce, so have always avoided using them, except for things like door open/closed.

I recently got a tipping bucket rain gauge, which is fitted with a reed. First response was to look at replacing with a unipolar hall effect, but no go, as the magnet uses its N pole for the reed.

Next option was to use s/w debounce, but I keep coming across references to the fact that millis and digitalRead don't work well in an ISR. So h/w seemed to be the way to go.

Checking with the scope, I found that the pulse is between 100-120mS, with switch bounce occuring for approx. 60uS. This suprised me as numerous contributers to the forum seem to advocate allowing 5-10mS switch debounce.

So my solution is pin set to INPUT_PULLUP, with an external 10k to 5v and 100nF to Gnd, giving me a time constant of 667uS. Any comments?

As an exercise, I ran this sketch, without the debounce.

const byte pulsepin = A0;

void setup()
     {
          Serial.begin(9600);
          pinMode(pulsepin,INPUT_PULLUP);
     }
void loop()
     {
          Serial.println(digitalRead(pulsepin));
     }

This didn't show any spurious +ve pulses, but I realise that Serial.println and digitalRead both take finite amounts of time, so very short duration glitches could well be missed.

As another exercise, I would like to see what is happening on every iteration of the loop, with minimal time 'lost', ie no Serial or digitalRead. I am guessing that this would require lots of bit bashing, but at this point, with my experience, I am totally out of my depth.

Any suggestions or comments?

TIA

Fof

Next option was to use s/w debounce, but I keep coming across references to the fact that millis and digitalRead don't work well in an ISR.

They work just fine. It is trying to use millis() to work around the fact that delay() doesn't work in an ISR is what doesn't work, because the value returned by millis() doesn't change while interrupts are disabled, as they are when an ISR is called.

This suprised me as numerous contributers to the forum seem to advocate allowing 5-10mS switch debounce.

For mechanical switches that don't bounce long. Reed switches and mercury switches can bounce for a long time.

but I realise that Serial.println and digitalRead both take finite amounts of time, so very short duration glitches could well be missed.

Correct.

As another exercise, I would like to see what is happening on every iteration of the loop, with minimal time 'lost', ie no Serial or digitalRead.

Not using Serial makes sense. Not using digitalRead() does not.