Page 1 of 1

Pulse input debounce? (Omnimeter Pulse v.4)

Posted: Fri May 15, 2020 3:48 pm
by jaholmes
Might be another silly question: I've been watching my Omnimeter's pulse count and comparing it to the reading on the face of the meter. It's consistently registering 10-15% more pulses within a 24-hour period than what I'd expect to see given the differences in meter readings. I suspect switch bounce in the meter is to blame. Unfortunately this particular meter only pulses once per 10 gallons, so catching it in the act is a bit of a pain. Given the very slow pulse rate expected, is there something that can easily be done to debounce this setup? A setting? Maybe putting a small capacitor across the pulse input terminals of the Omnimeter? I can't imagine how I'd ever see two legit pulses within ten seconds of each other, so super speed definitely is not required, heh.

Thanks for any help / suggestions!
Very best,
Aaron

Re: Pulse input debounce? (Omnimeter Pulse v.4)

Posted: Fri May 15, 2020 4:50 pm
by Jameson
Hello Aaron, not a silly question at all! :lol:

First thing I would check is to make sure that water only flows in one direction through the water meter. If you have an air pocket in your lines, or some other reason water in your lines can surge forward then a little bit backward, there is a chance that the water meter will put out 2 pulses in this case.

Do you have your water meter connected to the Push system or to the EKM Dash software? If so, will you post a screenshot of your data in the chart?

I dont imagine this would be a debounce issue, we have not seen issues with debounce with our Omnimeter Pulse v.4 pulse inputs. I'll give it some thought to see if I can think of anything else that might be going on. Strange that it is "consistently registering 10-15% more pulses within a 24-hour period", this would not have to do with loose wiring or bad connections. Well anyway, strange. Thanks for letting us know, hopefully we can get to the bottom of this.

Re: Pulse input debounce? (Omnimeter Pulse v.4)

Posted: Sat May 16, 2020 11:01 am
by jaholmes
Hi, Jameson! Thanks for your quick reply. That's good to know about the debounce. Your suggestion of the meter running backwards is a good one. I ought to have thought of that. Yes, if I sit and watch the meter, there will occasionally be times where it runs forward and then bounces back and forth a little--sort of an oscillation in the line.

For context, this meter is at a well that supplies ten houses, so there are a couple thousand feet of pipe between the meter outlet and all the various points of consumption. Only a few houses are occupied full-time, however, so the total daily draw is not very high--usually on the order of about 350-400 gallons, and because the meter only pulses on the tens, that means only about 35-40 pulses per day. Consequently, the extra pulses don't really stand out in any obvious way when you look at the graph in the Widget. I did recently install a Push, and my intent is to build a leak warning system that sends text messages when certain hourly thresholds are crossed. I decided to first double-check that the pulse counts were in agreement with the meter, so I started logging the two side by side. That's the only way I'd have noticed the discrepancy.

Given that the meter only pulses on the tens, I guess I'm a little surprised that I'd see more than a handful of extra pulses over the course of several days, as it would seem like quite a coincidence for an oscillation to happen right as the reed switch is transitioning from open to closed on a ten-gallon mark. That said, I can't deny that such a thing is definitely possible. The good news is that we're not billing anybody based on this data, and are mainly looking for evidence of some catastrophe. I'd certainly rather have a few extra pulses than a bunch of missing ones! :)

Is there any provision for artificially throttling the pulses in software? If not, that would be a grand feature to have for situation like this where the meter suffers from occasional whiplash. In our case, multiple pulses within the span of say, five seconds, is just physically impossible.

Re: Pulse input debounce? (Omnimeter Pulse v.4)

Posted: Sat May 16, 2020 8:15 pm
by Jameson
Hello Aaron,

Good idea about the rate limiting of the pulse counts, its a good idea, but there is not way to do this as it would have to be done by the pulse counting EKM Omnimeter Pulse v.4. The Omnimeter is not setup to be able to take a setting to limit how fast it is able to count pulses.

I think this would be better solved by using a check valve before your water meter, this would make it so that water could only flow in one direction through your meter. This should fix the issue you are seeing of water flowing backwards and causing erroneous pulse outputs.

Ideally the water would come from your tank, to a valve, then to a T-drop or filter (to clean out sand and grit), then to a check valve, then to the water meter.

Hope this helps,

Re: Pulse input debounce? (Omnimeter Pulse v.4)

Posted: Thu Jul 21, 2022 7:33 pm
by eventhorizons
jaholmes wrote: Sat May 16, 2020 11:01 am ...as it would seem like quite a coincidence for an oscillation to happen right as the reed switch is transitioning from open to closed on a ten-gallon mark.
I apologize for reviving an old thread but I saw this and I'm picturing a slowly turning magnet next to a reed switch.

All mechanical switches bounce. The real question is what is the low-pass filter on the input? If the maximum input frequency is 1KHz then a 1mS bounce could be counted.

The way a reed witch works is that it acts as as part of the magnetic circuit. The field causes the blades of the reed switch to become magnetized and to attract each other and close. This helps make good contact and creates an amount of hysteresis that avoids some contact bounce.

But not all! As the magnetic poles moves at a snails pace into (and out of) the switch that there absolutely will be some contact bounce.

Also, the magnet will be on the end of a gear train with a certain amount of backlash. You even identified that there was sometimes a small amount of "back-and-forth".

If you truly want to mitigate the bounces then you will need to implement a R-C or some other low pass filter with an appropriate time constant.