Question: Using this with WM-PD Water Meter

[czuvich]

I'm wanting to use this library with the following meter: https://www.flows.com/wm-pd-series-low-flow-water-meter/ https://www.flows.com/content/literature/Datasheets/WM-PD%20Datasheet%20V2.pdf

The datasheet states .05 pulses per gallon. I was looking at your docs, and I was wondering if that means the kFactor is 0.0881? 20 pulses per gallon or ~5.284 pulses per liter, divide by 60 and then I came to .0881. The datasheet does provide different error calculations for a few different flow rates. Is that something I need to add as well?

Thanks!

[sekdiy]

20 pulses per gallon or ~5.284 pulses per liter

Okay, that sounds legitimate and it's something we can work with.

Looking at the properties wiki page, let me go through the relevant things quickly.

Let's assume your unit of measure is either l/min or gal/min (as opposed to liters or gallons per second or hour), as that is what the library uses internally.

The WM-PD meter's capacity appears to be stated as 825 gal/h = 13.75 gal/min ≈ 3.62797 l/min for the WMPD-050 and 1320 gal/h = 22 gal/min ≈ 5.80475 l/min for the WMPD-075, respectively.

If you're only interested in the low-flow region (and thus choose to ignore the full capacity), you can give the maximum expected flow as a value for the parameter capacity during initialisation (also see below).

The K-Factor is the most important figure you'll need. It has to be expressed as pulses per second per unit of measure. Internally that is assumed to be (1/s) / (l/min)) (pulses per second per liters per minute).

divide by 60 and then I came to .0881

Yes, I'm also arriving at K ≈ 0.08807.

Turndown ratio can be derived from the datasheet as 825 / 4.13 ≈ 200 for the WMPD-050 and 1320 / 6.6 ≈ 200 as well for the WMPD-075.

That appears to be a relatively large range (200:1). It is absolutely normal that the sensor cannot be linear over this whole range.

This also means that choosing a certain region of flow for your application effectively leads to a lower usable turndown ratio (range).

The datasheet does provide different error calculations for a few different flow rates.

In the document you linked I spot a diagram that plots accuracy over flow rate.

I didn't see a calculation in particular.

Is that something I need to add as well?

You don't technically have to. The datasheet states 5% accuracy in the low flow region. If that's something you can live with, don't bother calibrating.

Otherwise, the m-factor(s) (in the struct FlowSensorProperties) could be applied from the diagram, expressed as a normalised coefficient (i.e. +1.5% becomes 1.015, -1.2% becomes 1/1.012 ≈ 0.988).

If you don't want to use this feature, just set all the mFactor values to 1.0.

If you'd like to apply a correction, the library allows a form of piece-wise linear approximation of a correction/compensation curve by providing up to ten m-Factor 'hints'.

All you'd need to do is determine your expected range of flow (which could be the meter's full range), provide the upper end of that range as the capacity and then pick ten equidistant points from the accuracy diagram between zero and capacity as mFactor points.

Important: If a correction via m-factors is applied, the capacity parameter is used in the calculation. Thus every set of m-factors can only correspond to a particular capacity: different capacity, different set of m-factors (since different calibration points would have to be chosen).

[czuvich]

Thank you so much for the detailed explanation!

If you're only interested in the low-flow region (and thus choose to ignore the full capacity), you can give the maximum expected flow as a value for the parameter capacity during initialisation (also see below).

Are you suggesting that I only populate the capacity in the structure if I'm interested in low-flow applications (which I am)? I typically put it in there anyways for the last 2 meters I've tested. I saw in the code it's using the capacity to factor in error calculations.

*** EDIT -> Nevermind. I see it's only used in the m-factors as you said. Again.. thank you so much!!!

[sekdiy]

Yes, the capacity only comes into play once at least one of the ten m-factor values deviates from one.

It doesn't hurt that you populated the capacity parameter before, though.

[czuvich]

So... I thought I'd post a few things here on my experience interfacing with pulse output meters. First off, I'm not a hardware guy, so I wasn't aware that reed switches require debouncing. Second, I originally developed the firmware in such a way that I was counting pulses using the hardware TIMER for the original Hall Effect sensors. I did that because I did not want to tax my software with interrupts.

Long story short, I was finally able to get an accurate measurement across both PC and PD meters by just debouncing the input with 500ms intervals and using interrupts for the pulse outputs (I kept the hardware timer on the Hall Effect sensor since I don't think it requires debouncing). I found the magic debounce number here. I was surprised it was so high.

All that to say, it may be a nice feature to add debouncing to your library. Again thanks for your help!

[sekdiy]

A valid remark: debouncing.

It's difficult to debounce within concurrent interrupt routines, though.

I'm a user of mysensors.org since many years, but hadn't come across their flow sensor example yet.

What @tekka007 does is skip pulses by taking time stamps and skipping half a second after each accepted pulse.

The timeout would have to be a dynamic parameter, of course, since different sensors have different pulse rates.

That's a good approach if the node only runs one sensor, but taking time and doing multiple floating point operations per ISR call is something I actually wanted to avoid.

Beefy Arduinos and ESPs support tens of interrupt pins and time spent within an ISR could mean skewed timing in the rest of the loop (because you can't keep timestamps in every line of the loop code…).

I'm a fan of hardware debouncing, though. Since an interrupt pin should have a pull up/down resistor anyway (e.g. trough pinMode(digitalPinToInterrupt(2), INPUT_PULLUP);), all that's needed is a small ceramic cap in order to accomplish the same thing and more (e.g. protection against high frequency interference that can't be distinguished from bouncing).

Maybe software debouncing can be an optional feature that is disabled while no sensible timeout is configured.

[sekdiy]

Which reminds me: did you use pull up resistors?

[czuvich]

Which reminds me: did you use pull up resistors?

I use the internal pull-up via INPUT_PULLUP.

but taking time and doing multiple floating point operations per ISR call is something I actually wanted to avoid.

I actually posted my problem on Arduino forums and received some pretty good feedback. The gist of it was not to use ISR to do debouncing, and I see why now. It's difficult to determine a "good" reading. The ISR interval check between pulses is probably not the best approach. So, adding something like that to your code-base is probably not a good idea.

I had no idea debouncing was that involved since all of the examples I see online use the ISR check. For my specific application, moving to the loop is better since I don't receive that many pulses from those meters.

However, I didn't think to try a cap. Is there a certain value for the cap that is acceptable or is it very specific to my application? Someone posted on the forums 0.1uF across the INPUT and GND pins. Would I still need to debounce at all? Thanks and sorry for the noob question.

[sekdiy]

No problem, all valid questions. 👍

In your application (only 20 pulses per gallon) with only one or two flow sensors per board, software debouncing is probably absolutely okay.

It's difficult for a (general purpose) library to do in the library implementation though, because there is no single time constant fitting all sensors.

Personally, I haven't yet encountered a sensor that needed debouncing in the first place.

If you want to go the hardware debouncing route, 100nF (0.1µF) seems like a good starting point.

The thing you're trying to implement is a time constant by means of an RC filter.

It's important to have a current limiting resistor in front of the capacitor, or else the switch within the meter would short out the capacitor every time it closes.

The formulae it boils down to are these (courtesy of the Wikipedia article):

That means τ (in seconds) = R (in Ohm) * C (in Farad).

In reality τ will turn out to be slightly different, because both the meter pulse switch as well as the microcontroller input will have a small resistance and capacitance influencing the actual time constant.

I had no idea debouncing was that involved

The issues with it are probably as old as connecting switches to electronics. :)

[czuvich]

Thanks for the info!! I forgot about the RC filter. I think I used the same formula to open/close the valves. I have to step up the voltage from 3.3V to 12V, and I used 2 large caps and a resistor in series to help "kick" the valves open. Thanks again for taking the time to help and develop the library.

[sekdiy]

Thanks again for taking the time to help and develop the library.

Thanks for using it! :)

Since it's working for you for now, I might as well close this issue until something new comes up.

Feel free to reply if you have new info.