Have a weird one, and it's probably just me being dumb. I have a cup anemometer w/a reed switch (it's purchased, and I'm not going to hack it for a hall sensor). Anyway, if I just hook this to a meter, I can see the switch closing twice for every rotation. The switch is extremely bouncy. I have it on an interrupt handler and am debouncing there, I've checked in the interrupt handler that the last time it was called is at least 20ms from the last time we counted a state change. If I move that to 100ms, I don't get any difference, so 20 should be fine for now.
Anyway, for every rotation using the FALLING param to my attachInterrupt, I get 4 increments. That's odd to me as I'd expect 2 falling edges if the switch contacts twice. If I mod my call to make it interrupt on CHANGE, I get the same amount, 4....that makes more sense, as I'd have two rising edges and two falling edges. What am I missing (cause I'm sure there's something :o).
Depending on how fast the anemometer rotates in the air speeds you're measuring the debounce delay could be getting in the way of correctly catching each rotation. 100ms twice a rotation is only 300 RPM. I had problems with a much slower rotating device with a reed switch, it theoretically closed once a rotation, but due to the magnet's positioning would sometimes flag twice close together, add that to the bounce and it got really confusing as too what was a contact and what wasn't. Putting a slow hardware debounce (R-C) system on it cured it completely.
Thanks for the reply. I may have to get a cap and give that a try.
I would think the debounce delay though would make it miss legit changes, not multiply what's expected. This isn't measuring anything yet though...it's literally just me spinning it once around with my hand at a slow enough speed to know that it doesn't spin more than once, and it counts 4 falling edges. It's very consistent, it's just twice what I think it should be. I guess the CHANGE version of my interrupt seems to be doing what I think it should, so I think I can use that and divide by 2....hmmm....
The switch bounces both as it opens and as it closes. The bouncing causes the falling edges. Therefore you will get falling edges both as the switch opens and closes.
So two falling edges for every change is inevitable? I could almost see that being true. The debounce example uses digitalRead in loop(), something I can't do in an interrupt handler.
You're right and I don't know why I thought I couldn't. This seems to count properly. If a do a digitalRead in the isr and only count if that's high (so it's on its way down), that seems to do it. THANKS!