Hall sensors in parallel, and/or perhaps too high pulse rate?

[Nicola]

Hi,

I have two of these 3-wires hall sensors connected in parallel to OS 2.3 (2.11 firmware):
https://www.amazon.com/gp/product/B00VKAT50U/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

As I irrigate alternatively from two different water sources I need to monitor both flows, thus the two sensors. They never work at the same time.

What I am seeing:

1) flow counts are unreliable: sometimes a number is displayed, sometimes nothing: could it be because the two sensors are affecting each other? I understand the 2-wires seonsors use reed contacts and it may happen that even the unused sensor may remain parked with the reed contacts closed, thus affecting the other sensors; but these are hall sensors, if they are not working they should produce no signal, or not?

2) Even when one sensor only is connected to OS, flow counts rarely make sense, sometimes they are even negative! The parameter I set in the settings that more closely approximate the verified flow is 0.39. Now I read here that these 3-wires hall sensors may produce more pulses that OS can handle (is there a specific limit, and can we tell from the specs I pasted above?) and they are not fully supported; replacing the sensors with DAE or EKM 2-wires flow meters in out of the question, not because of the cost but because of the length, I have no room in the pipes;
So I wonder, what could I use to condition the signal, for instance reduce its frequency? Every search for frequency divider points to audio equipment. I have access to Arduino but no time to play with it, is there a ready-to-upload sketch that would do what I need?

Thanks!

[Ray]

Unfortunately the three wire sensors are difficult to read reliably. Part of the problem is they generate too much click counts per minute. Also there are too many different types we can’t possibly test the controller with all of them.

Negative values are probably a UI bug, because the read count is stored in a unsigned integer variable so cannot possibly be negative. It must be the UI when its displaying the data changed it to signed integer hence negative.

The 2 wire type sensors are more expensive but are more reliable because they generally much less click counts per minute.

[Nicola]

Not the UI, I am getting negative numbers in the email body sent via IFTT, for instance:

Station Z4 Acqued Lato W closed. It ran for 5 minutes 0 seconds. Flow rate: 1818.-90

[Ray]

Ah, ok, I will check, it’s probably part of the code that sends data to IFTTT. Again, this is usually a sign the click count is excessively high.

[Nicola]

I found the data sheet of my Hall effect 3 wires flow sensor: it produces a square wave, with frequency [Hz] = 0.5 x Q [liter/min]. As I know my typical irrigation flow is 100 liters/min (recommended range of my 1.5″ flow sensor is 10-150 l/min), the maximum frequency is 50 Hz = 50 pulses per second. Is this too much to handle for the OS ? Also I am irrigating in 15 minutes cycles, so total flow count is something like 50x60x15 = 45000, too high ? Thanks for checking into this.
Again I would gladly go with the 2-wires flow meters, but at 1″ thick they are 10″ long, I have no room in the pipes to install them.

[Nicola]

Also: I understand OS may miscount the pulses from the sensor, but once it gets that figure, right or wrong it may be, the rest of the math should add up.
If my sensor really does (per datasheet) 50 pulses / sec when the flow is 100 l/min, the “Flow Pulse Rate” parameter to configure in OS UI should be: (100/60) L /sec = 50 pulses –> 1.67 L = 50 pulses –> 0.033 L/pulse; the UI allows 0.03 and 0.04, so I set it at 0.03 L/pulse. From practical testing, monitoring the level of the reservoir, I figured that the correct figure was somewhere between 0.03 and 0.04 so close.

I then irrigated 120 seconds, and from IFTT I get two emails at the end of cycle:

First email: “Station XYZ closed. It ran for 2 minutes 0 seconds. Flow rate: 1363.91”
Second email: “Flow count: 2852, volume: 85.56”

My OS is set to Metric. What’s the unit of measurements of these three figures?

From the flow count = 2582, as it run for 120 seconds, the sensor was giving 21.5 pulses/second. I presume all the calculation start from 2582, right or wrong it may be, so now:
1) Since I set 0.03 L/pulse, 2582 * 0.03 = 77.46 L total: why is volume showing as 85.56? The math just does not ads up..?
2) What’s the unit of measure of the flow rate? L/hr? L/what? Still gallons? Because if I take for granted 85.56 L / 2 minutes, that is 2566 L / hr. Where is 1363 coming from?

[Ray]

I would say 50 pulses per second is really quite high. A lot of the 2-wire water meter probably only generates 50 pulses per minute, not per second. Due to the way the flow count interrupt routine is implemented, ideally the click count should be less than 10 clicks per second. Not sure if you can get a different sensor that generates less clicks. Usually those that are meant for higher volume flow rate will produce less clicks per second.

The unit doesn’t really matter. By default it uses metric I think, so you can just ignore the unit and thus only the number itself matters.

[Nicola]

So it’s clear, too many pulses and the flow count (2582 in my example?) is or may be off. I will experiment with a 10 to 1 frequency divider.
But what about the math:

First email: “Station XYZ closed. It ran for 2 minutes 0 seconds. Flow rate: 1363.91”
Second email: “Flow count: 2852, volume: 85.56”

Whether 2852 is wrong or not, where are 85.56 and 1363.91 coming from? Irrigation time was 120 seconds.

[Ray]

If I remember correctly, flow volume is the flow count multiplied by the pulse rate (basically number of clicks multiplied by volume per click). Flow rate is the flow volume per unit time. In this case, the flow rate is flow volume per minute:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1422

[ronnie]

I’m testing the flow rate measurement capability of OSPI 2.2.0 on a raspberry pi zero 2w. I’ve attached a pulse generator to pin 8 (GPIO14) and set the pulse rate to 1. Per your comment stating, 10 clicks per second max pulse rate, I set the rate to 4hz 50% duty cycle ( 4 pulses per second). I manually ran a zone for 15 minutes. The reported flow rate on the UI during the on time ranged from 190 to 224. Each UI update was different.

I next reduced the pulse rate down to 0.5hz ( 1 pulse per 2 seconds). The reported flow rate on the UI ranged from 26 to 78. Approximately every other UI update was different. The magnitude of the flow rate variance limits the usefulness of this measurement capability. Is there a way to improve the measurement accuracy ?

[Ray]

I’ve personally verified the flow sensing many times before on RPi and as far as my experiments went, it was quite accurate. I don’t have an RPi zero 2w so I cannot verify it for this particular version of RPi, but I’ve verified it on RPi 0 w, Rpi 2, Rpi 3 etc. What type of pulse generator are you using? Do you have a link? Also, what’s your version of raspbian?

[ronnie]

I’m running buster. The pulse generator is a FY Economic 5 multi-function signal generator. I have header pin 8 monitored on a scope with a signal frequency readout capability. I ran another test at 6hz. I have attached a scope screen shot. The scope reports a frequency range of 5.99978 to 5.99980 with changes every few seconds. The UI while running a one time program of 15 minutes reports a flow rate range of 264 to 310 changing every couple of report cycles. After running the one time program twice the log reports total water usage of 4268 and 3970 for the two sessions.

During running the one time program I’m viewing the UI which of course means the raspberry pi is continuously communicating via a local LAN wifi network with my pc. So it could be the Opensprinkler program time measurements could be affected.

I’ll try running a watering program twice with no UI connection.

Attachments:

1. 

   NewFile0.bmp
   

[ronnie]

Ok, my guess was right. I ran a program three times using a 2hz flow signal with no wifi UI connection. The total water consumed reported in the log was 1802, 1802 and 1801. So the wifi ui is definitely hosing up the flow time measurement capability of the opensprinkler program.

BTW I’m running buster Lite.
The wifi connected UI offered a hint as to the problem by closely watching the flow count updates being reported. Every so often the number would jump through two updates in a row in less than a second.

[Author]

Posts