Reed switch - to de-bounce or not to de-bounce

Hi,

I'm working with a weather station anemometer that uses a reed switch and magnet. I've wired it up to an interrupt pin on a mega (plus a resistor) and it seems to work fine. I spin the anemometer and my code detects the interrupts in the circuit and give me a realistic-looking value for anemometer speed.

When I rotate the anemometer slowly by hand I know I get one interrupt per revolution (as expected) and when I spin it very fast, I get I plenty of interrupts, but I have know idea of how many (if any) are 'proper' interrupts, and how many may be caused by the reed switch bouncing.

I have couple of questions, firstly how do I know if I need to apply de-bounce to the switch (without a attempting to calibrate the anemometer in a wind tunnel).

Secondly if I do need to add de-bounce circuitry, what sort of extra components should I add? What's the difference between a simple capacitor across the switch, and something a bit more elaborate, like in this posting? http://forum.arduino.cc/index.php?topic=14397.0

Fix your code.

It is for this very reason, foolish to use interrupts for this sort of application, extremely slow inputs.

De-bouncing in code is far more effective than adding superfluous components; I can give you the code if you wish.

foolish to use interrupts for this sort of application, extremely slow inputs.

Before I learned about interrupts, I did use a non-interrupt based solution, but this would miss pulses from the reed switch when the application was busy doing other stuff (for example reading serial data from a GPS). When I posted a question about this on this forum I was told to always use interrupts to avoid missing pulses!

Also, although this anemometer spins relatively slowly, I use the same library with tiny little hand-held anemometers, that spin like a spiny-thing even in low winds and generate multiple pulses per rotation. If I modify the library to de-bounce in the code instead of the hardware, then there’s a danger the library will stop working in the faster applications

Again, I think it's in the code.

The serial read code is already interrupt driven and buffered, so it should not take significant time to execute. The problem with "libraries" is that they are often written in the expectation that you do not need to do anything else at all. And you would always call Serial.available before attempting to read data from the GPS.

What library is involved here? And how come you need to simultaneously count wind speed and verify GPS location? How many other things do you need to do as well?

Which reminds me - you do not use a wind tunnel to calibrate an anemometer - you use a motor car and a GPS!

All mechanical contacts can bounce, don't rely on luck - the contacts only have to separate by a microscopic
amount to break the circuit and mechanical things move on millisecond timescales, electrons on nanosecond
timescales... Reed relays are usually spec'd to bounce quickly (perhaps 1ms or less), much faster than
ordinary relays and switches (10's of ms) - tune the debounce code appropriately.

Bounce noise can cause many interrupts to occur, even for this reed switch which has 0.3ms bounce.

Your if the maximum RPM of your anemometer is say 1800 RPM (like here), then the minimum pulse period is 0.56ms. When using hardware debounce, make sure the RC time constant >= maximum bounce time of the reed switch and <= minimum pulse period.

In the debounce circuit you’ve referenced, the rise time would be near instant (due to the diode) and the decay time would be about 1ms. For this circuit, the interrupt should trigger only on the rising edge of the signal. Also, 1ms time constant limits the maximum input frequency to about 1000Hz (RPM of anemometer).

Myself, if interrupts are required, I always make sure these signals are clean.

And how come you need to simultaneously count wind speed and verify GPS location?

The weather station is designed to be very mobile, it's easiest to build the GPS position into the logging function rather than manually noting the position each time it's set up.

How many other things do you need to do as well?

Pressure, temperature, humidity and light level.

The serial read code is already interrupt driven and buffered, so it should not take significant time to execute.

A GPS with a baud rate of about 56000 will fill an 65 character buffer in about 1 m/s, so unless the serial input buffer is being polled pretty frequently there's a danger that data will overflow the buffer and be lost. This becomes much more likely when you bear in mind that a write to an SD card can take over 100ms, and even getting the pressure from a BMP085 pressure module can take from 17-30ms

It looks like I'm going to need two separate libraries, one for my high-frequency hall probe generated interrupts (which don't require de-bounce) and one for my low frequency reed-switch driven interrupts that do require de-bounce.

So as I rather suspected, there is no need at all to have the GPS read and the anemometer monitoring at the same time.

there is no need at all to have the GPS read and the anemometer monitoring at the same time.

to calibrate the anemometer using the method you suggested (good idea BTW) would require logging of both the GPS position and the apparent wind speed at the same time.

As far as can see, if the code is going to do anything more than just monitoring a reed switch interrupts really do need to be used, otherwise there's the danger of 'look away and you've missed it'.

Even writing to a LCD takes a few milliseconds, and if pulse from the reed switch occurs on a non-interrupt pin during this then it's likely to be missed.