YF-B5 unstable pulses, huge difference between actual and nominal values

[cjacky475]

Hello, recently I've tried to calibrate my YF-B5 sensor, but when I launch the program for calibration, I face two issues:

1. The current flow rate is shown abnormally huge, also the difference between real & nominal values are somewhat doubled or tripled. As example: filling the cup of 500 millilitres shows a nominal value of around 1L. When opening the tap all the way, it's showing 60-120 l/min, even though my sensor is max at 30 l/min as per documentation (also I've tested with the bucket, I can fill around 15L per minute with the tap all the way). Is this supposed to be like that with the big difference between real/nominal values? Should I continue calibrate and mark (as per first example of 500 millilitres) a proportion as 0.5? Thanks.
2. I cannot get the stable reading of water flow. Whenever I open the tap on the same level, the flow rate just starts jumps, leaving a +- 2 litres gap. For example, it could be showing 2.19 l/min, 3.45 l/min or 5.41 l/min (when tap running slow, approx. 2L/min). Is there anything I can do? Or should I just approximate this example as, let's say, 3 l/min as it would be 5 percent of my capacity, mark the real & nominal values and continue calibrating?
3. If my template's flow rate columns are 3, 6, 9... 30, how to correctly carry out this calibration, when (looking at my first issue) the flow rate is too big comparing to the real one. The tap all the way showing 60-120L/min.

My sensor's properties at the beginning of calibration: FlowSensorProperties MySensor = {30.0f, 6.6f, {0.4, 0.25, 0.2, 1, 1, 1, 1, 1, 1, 1}};

Sensor's datasheet (not sure if this this authenticate and really true, but the flow model is correct): https://media.digikey.com/pdf/Data%20Sheets/Seeed%20Technology/114991175_Web.pdf

Thanks for the help.

[sekdiy]

Hey,

I haven't worked with the YF-B5 (or any of their brass siblings with axial impeller) yet.

But I assume they are compatible with this library.

When opening the tap all the way, it's showing 60-120 l/min, even though my sensor is max at 30 l/min as per documentation

Thanks for all the information you've given so far. But let's rule out setup issues first, please.

• What microcontroller model and software platform are you using?
• What supply voltage are you operating at, what's your I/O voltage level?
• What's your connection diagram?
• How long is your wiring, how's the electromagnetic interference situation?
• Are you using the library as intended (i.e. can you post your source code)?

I've found hints at different versions of the YF series flow sensors. They apparently come in 3.3V, 5V or 24V. The regular version uses a 5V compatible hall effect sensor, the 3.3V and 24V versions are advertised as custom order variants. Seeedstudio simply says 5–15V…

My sensor's properties at the beginning of calibration: FlowSensorProperties MySensor = {30.0f, 6.6f, {0.4, 0.25, 0.2, 1, 1, 1, 1, 1, 1, 1}};

Okay, let's pick 30l/min as capacity and 6.6 as kFactor from the 'datasheet' for now.

Your mFactor values look all over the place. :) Did you really start with these m-factors or did you arrive at them somehow?

With your capacity at 30, your first mFactor entry (0.4) affects the flow range ca. 0–3l/min, the second entry (0.25) then affects the range ca. 3–6l, and so on. There's no smoothing going on, so the jump from 0.4 to 0.25 would make flow measurements extremely jumpy at around 3l/min. You can look at this calculation around line 54 within the tick() method. The math behind it is derived here.

Using mFactor values only makes sense if they are relatively close to each other and relatively close to unity (1.0), because the compensation/calibration feature is kept very simple. So if all the mFactor values deviate heavily from 1.0 and all in the same direction, that's a reliable indicator that the kFactor is off.

Now, since we kind of know that the kFactor is off anyway, let's start with the above questions in order to rule out voltage level, speed/timing and interference related errors, etc.

Cheers, Sebastian.

[cjacky475]

Hi, thanks for your reply.

What microcontroller model and software platform are you using?

It's a ESP-WROOM-32D ESP32-DevKitC development board (https://www.amazon.com/ESP32-WROOM-32-Development-ESP-32S-Bluetooth-Arduino/dp/B084KWNMM4). I use Visual Studio Code via PlatformIO to write code and upload to my board.

What supply voltage are you operating at, what's your I/O voltage level?

Please see the connection diagram below. I power up my sensor via 5V pin. Since ESP32 pins are not 5V tolerant, I then use 3v3 pin as a pullup for signal line (since the sensor's signal is coming as 5V).

What's your connection diagram?

In the diagrams I showed not YF-B5 (lack of sensors in the Fritzing app), but I do use YF-B5.

Schematics:

Breadboard:

How long is your wiring, how's the electromagnetic interference situation?

In the breadboard I use those small Arduino jumper cables (+- 10 cm). I power up my sensor via USB cable, which is around 60 cm. Previously I had problems with unstable pulses count - when the sensor was idling, I received some pulses in my logs, but no water was running. Then I added capacitors of 0.1 uf (see diagrams above), now I do not receive any interference, seems fine. Just that the water meter calculations are off from the real values.

Just for the reference if it has any influence, the inaccuracy as far as I have collected is (these pulses are not taken from Your app, but mine which I previously had, but I used the same simple logic for getting them via attachInterrupt): If I ran my tap fast, it showed me 185 pulses (482 millilitres), in reality it was 500 millilitres. Lowering the tap speed decreased the pulses to 181 (472 millilitres), in reality it was 500. Very low speed resulted in 135 pulses (353), in reality it was 500.

Are you using the library as intended (i.e. can you post your source code)?

I just copy-pasted your code in my VS Code and run it for calibration. I changed only MySensor variable.

#include <FlowMeter.h>

#define LED 3 // LED pin

// enter your own sensor properties here, including calibration points
FlowSensorProperties MySensor = {30.0f, 6.6f, {0.4, 0.25, 0.2, 1, 1, 1, 1, 1, 1, 1}};
FlowMeter *Meter;

// timekeeping variables
long period = 1000;   // one second (in milliseconds)
long lastTime = 0;

// define an 'interrupt service routine' (ISR)
void MeterISR() {
    // let our flow meter count the pulses
    Meter->count();
}

void setup() {
    // prepare serial communication
    Serial.begin(9600);

    // Initialize the LED pin as an output
    pinMode(LED, OUTPUT);

    // get a new FlowMeter instance for an uncalibrated flow sensor on pin D13
    Meter = new FlowMeter(digitalPinToInterrupt(13), MySensor, MeterISR, FALLING);

    // Blink to indicate start
    digitalWrite(LED, HIGH);
    delay(1000);
    digitalWrite(LED, LOW);
}

void loop() {
    // do some timekeeping
    long currentTime = millis();
    long duration = currentTime - lastTime;

    // wait between display updates
    if (duration >= period) {

        // process the counted ticks
        Meter->tick(duration);

        // output some measurement result
        Serial.println("FlowMeter - current flow rate: " + String(Meter->getCurrentFlowrate()) + " l/min, " +
                       "nominal volume: " + String(Meter->getTotalVolume()) + " l, " +
                       "compensated error: " + String(Meter->getCurrentError()) + " %, " +
                       "duration: " + String(Meter->getTotalDuration() / 1000) + " s.");

        // prepare for next cycle
        lastTime = currentTime;
    }
}

Your mFactor values look all over the place. :) Did you really start with these m-factors or did you arrive at them somehow?

I did not really meant to paste these m-factors, since I have just been trying it out (I really did test it until 8 - 10 l/min), that's why I filled only 3 intervals. Basically as I've explained earlier, my flow is not constant and for testing the beginning of the interval ( 3l/min ), your app showed me a 0.99 as nominal value. Please see the pic attached below at what I have arrived so far. I did not continue, because I was sure something is not going to be right with this.

Jacky.

[sekdiy]

Thanks for posting the details of your project. :)

I'd like to pick up on the following:

these pulses are not taken from Your app, but mine which I previously had, but I used the same simple logic for getting them via attachInterrupt

What I understand here is that it worked alright before you started using my library. :D

Before we dig in deeper, let's verify the pulse counting behaviour. I'd like to make sure that all the pulses are counted correctly.

The getCurrentFrequency() method allows you to print the pulse rate (pulses per second, not number of pulses total). That's basically the raw data, just as a frequency.

You could accumulate the total pulses by printing the current frequency and then summing over the duration.

Could you modify the example code to also print the value of getCurrentFrequency(), run it and pass 500ml through the sensor, sum the individual pules (per second) to a total number of pulses (per 500ml)?

Cheers, Sebastian.

[cjacky475]

Hi Sebastian,

What I understand here is that it worked alright before you started using my library. :D

I just compared raw pulses from the sensor with the calculated flow using formula and actual values - they are indeed misleading. That's why I am here to calibrate the sensor for it to show me correct values.

Could you modify the example code to also print the value of getCurrentFrequency(), run it and pass 500ml through the sensor, sum the individual pules (per second) to a total number of pulses (per 500ml)?

I have tried multiple times, these are the results of total frequency per 500 ml:

1. 2011
2. 1929
3. 1994
4. 2073
5. 2153

Throughout these tests I filled 500 ml cup, the error could have been +- 10 ml. Also, to keep in mind as the documentation says, the sensor could be wrong +- 5%, right? Also, here I have pasted the results from the terminal, maybe they are going to be necessary as well.

Thanks, Jacky.

[sekdiy]

I have tried multiple times, these are the results of total frequency per 500 ml:

Thanks for your effort! :D

From your terminal output I understand that you added: • the value from currentFrequency(), labeled as current frequency and • the cumulative sum over time, labeled as total frequency (although it's more like the total pulse count).

It looks like your sensor frequency is zero at rest, so you only seem to count any pulses while there's actual flow. Good.

But the number of pulses is an order of magnitude too large, which is something I can't explain away with a mismatch in kFactor or mFactor (because they are out of the equation when looking at the pulses/frequencies).

You already stated that without using the library you arrived at 185 pulses per 500ml at fast flow. The average of your five runs using the library is 2032. That's a factor of (just) above 10.

And another detail caught my eye: there are no low values (i.e. you're only ever measuring values that are too large to make sense).

Are you absolutely certain that the setup was the same in both measurement situations? Can you confirm that your original 185 pulses per 500ml are still reproducible without the library using your current setup?

I'd suspect… contact bounce, but that only makes sense if it is independent of the software being used.

Do you perhaps have a way to look at your sensor signal (e.g. using an oscilloscope)?

Throughout these tests I filled 500 ml cup, the error could have been +- 10 ml. Also, to keep in mind as the documentation says, the sensor could be wrong +- 5%, right?

You're right.

Once the issue with the factor of around ten in pulse counts is resolved, it'll make absolute sense to look at these kinds of errors. :)

[cjacky475]

Are you absolutely certain that the setup was the same in both measurement situations? Can you confirm that your original 185 pulses per 500ml are still reproducible without the library using your current setup?

I've redone the tests and the results were different, not sure how exactly how I got those previously mentioned results, but the ones that I've done with the current setup are here (total flow is in millilitres, all the tests were made as previously (using 500 ml cup)). I mean, these results are just ridiculous, there are no correlation between actual flow and pulses - the values are all over the place. The code I've used is here. At least looking at the results gotten from your library are consistent - that is ~2000 pulses in total per 500 ml, not sure if this is a good thing or not, comparing to my code and results?

Do you perhaps have a way to look at your sensor signal (e.g. using an oscilloscope)?

Sadly I do not have this device.

Once the issue with the factor of around ten in pulse counts is resolved

Now I am not sure what to do? As I have mentioned, your results are at least consistent when looking at the total pulses, mine - all the values are just all over the place without any correlations.

[sekdiy]

I've redone the tests and the results were different

I see...

From what I see, you still get zero output during no flow. Good.

There are two declarations and one implementation of a blink() function in your program. I'm assuming you're not using that during your test.

We're both configuring the digital interrupt pin as INPUT_PULLUP. You mentioned that you're using an external resistor (R1, 2.2kR) as well. Does the behaviour change if you set the pin mode to INPUT (without the PULLUP) in your code?

You initialize the interrupt mode as FALLING. Is there a particular reason? Does the behaviour change if you set this to RISING?

What purpose does the 0.1uF capacitor serve between SIG and GND? Together with R1, it should form a low-pass filter (of somewhat unknown bandwith, since we don't know the sensor's source resistance as well as the total pull-up resistance). Maybe you're experiencing low-pass filter behaviour ('lost pules' phenomenon) at higher flow rates... Does the behaviour change when you remove this capacitor?

Now I am not sure what to do? As I have mentioned, your results are at least consistent when looking at the total pulses, mine - all the values are just all over the place without any correlations.

I suggest we quickly check what's what before trying other approaches.

The datasheet states K = 6.6, corresponding to 6.6 Hz for a flow of 1 l/min. I'm actually assuming it's supposed to be 400 pulses per liter, which corresponds to 400/60 = 6.6̅

Let's take a look at your '1st try' using the library. I'm estimating that the flow was active for approximately 7 s. You state that you collected 0.5 l during this amount of time. That corresponds to 14 seconds per liter or around 4.25 l/min. With a K factor of 6.6 that would mean just above 28 Hz (or pulses per second). You collected 2011 pulses during these approximately 7 s. That would correspond to an average of around 280 Hz (or pulses per second). While this frequency seems crazy, it's off by a factor of almost exactly ten. With K = f / Q, we can calculate: Q = f / K = 280 / 6.6 ≈ 42.5 = 10 * 4.25

Now let's look at your 'slow flow from tap' using your program. I'm estimating that the flow was active for approximately 11 s. Assuming 0.5 l again, that corresponds to 2,7 l/min. You collected 1785 pulses during these approximately 11 s. That would correspond to an average of around 180 Hz (or pulses per second). Again, crazy, but also off by a factor of almost exactly ten again. With K = f / Q again, we can now calculate: Q = f / K = 180 / 6.6 ≈ 27 = 10 * 2.7

To sum this up so far, it's not really that inconsistent, just off by a constant factor. :) I recommend that you scale back your mFactor values, because they might be a large contribution to the jumpiness and they might also explain what I referred to as high pass filtering. Could you start over with the unmodified Simple.ino example first, then the unmodified Calibration.ino example second (adjusted for your input pin, of course) and report back? It would be interesting what deviations you're actually facing with a kFactor of 6.6f and 66.0f, respectively (leaving all the mFactor coefficients at 1 for now).

It would be interesting to find out what causes the issue, but without access to your setup I can only speculate… Can you rule out timing issues in your setup, e.g. a mismatch between assumed and actual ESP clock speed, etc.?

[cjacky475]

I'm assuming you're not using that during your test.

Yes, I do not use that function.

What purpose does the 0.1uF capacitor serve between SIG and GND?

Without this capacitor, from 10 to 60 minutes I have received some random pulses (could be 2, 10 or whatever). This capacitor made sure I do not receive any pulses when the water is not running.

Does the behaviour change if you set the pin mode to INPUT (without the PULLUP) in your code? Does the behaviour change if you set this to RISING? Could you start over with the unmodified Simple.ino example first, then the unmodified Calibration.ino example second (adjusted for your input pin, of course) and report back?

Please see the results.

Can you rule out timing issues in your setup, e.g. a mismatch between assumed and actual ESP clock speed, etc.?

Could you please elaborate on this question? I am not sure what I am supposed to do.

Thanks.

[sekdiy]

Does the behaviour change […]

Please see the results.

So it looks like the issue went away as soon as you removed that capacitor.

From what I see in your results, you ended up with measured flow rates between 3.6 and 10.6 l/min and total volumes between 0.48 and 0.58 l. That's completely reasonable.

It also seems that using Calibration.ino provided better results than Simple.ino (which is not surprising, due to the coarse use of delay() instead of actual time-keeping in the simple example).

In your 'Removing 0.1uF capacitor between SIG and GND' run, you arrive at 392 ml ('slow') and 421 ml ('fast'), respectively. That's also much better than the 4.5 l when including the capacitor.

To sum this up: Without the capacitor between SIG and GND and when using the time-keeping scheduler in the calibration example, you arrive at 0.48 l and 0.49 l, respectively. Assuming 0.5 l again, that's an error of 4 % and 2 %, respectively. Good. :)

Also, the pin mode and interrupt mode settings don't seem to be part of the problem.

Please confirm if I'm reading that right. Because if I do, that means we can resolve this issue and conclude with an actual calibration attempt. ;)

Can you rule out timing issues in your setup, e.g. a mismatch between assumed and actual ESP clock speed, etc.?

Could you please elaborate on this question? I am not sure what I am supposed to do.

When a microcontroller measures input with a time-keeping error that is a constant factor, one possible explanation can be that the assumed clock frequency deviates from the actual clock frequency by this very factor. For some microcontrollers, the clock frequency needs to be part of the software project/compiler configuration, which makes it a source of error.

If it turns out that the 0.48 and 0.49 l are legit, you might not need to worry about this any further.

[cjacky475]

If it turns out that the 0.48 and 0.49 l are legit, you might not need to worry about this any further.

Yes, I've tested multiple times with same cup, the value was around 0.5L.

• But what about the outliers? Please check here. It's just an example of water running very slow, but I've filled the same 0.5L cup and it shows 0.25 L.
• Also, I've tried flushing down the toilet, in reality it was ~3.3L, sensor showed me 3.9L. I have even tried opening multiple taps and reach ~20-30L/min for 1 minute. The sensor was pretty much off by ~0.7-1L. Can I do something about this? I mean, since it's Your calibration library, I might need to calibrate as you have explained in your documentation, right? I am pretty sure your Calibration.ino with the capacity of 60f and kfactor of 5.5 is somewhat influencing this (the outliers), or am I wrong about that?
• Another thing, would you mind knowing what should I do with these random pulses that might occur from 10 to 60 minutes? Since the capacitor I have removed helped me removing them. Should I try lower/higher capacity capacitor or this needs to be resolved in a different way?

Thanks for the help.

[sekdiy]

But what about the outliers?

What outliers? :D

Seriously though, at very low flow, an error of 50% is not uncommon with this type of sensors.

It is not without reason that this device is being sold for under 10 $ and comes without an actual datasheet. I searched only briefly, but I couldn't even determine who manufactures them...

As an example, let's look at the result 'current flow rate: 0.55 l/min, nominal volume: 0.01 l'. The sensor is specified with 6.6 Hz at 1 l/min. So at 0.55 l/min for the duration of one second (that's 0.0092 ≈ 0.01 l of volume flown within that second), the sensor will have provided just one pulse within that second. That's the lowest value possible if your resolution is one second.

Thus, at very low flow, measuring over short durations creates a huge measurement error simply because there aren't enough pulses that would occur within that duration.

Additionally, internal friction will add drag to the impeller and increase the error even further. It is absolutely reasonable to assume that half of the water will flow through the sensor casing without actually moving the impeller. As a matter of fact, you could probably determine the influence of the impeller's friction by making the flow rate so low that the sensor fails to count any pulses at all…

Also, I've tried flushing down the toilet, in reality it was ~3.3L, sensor showed me 3.9L.

That's might still not be too bad for this type of sensor, even though it seems a bit surprising that the measured value is too large. What type of flush is it (e.g. tank, low pressure vs. tankless, high pressure)?

If you don't mind me asking: how do you determine the amount of water that runs down your toilet? :D

I have even tried opening multiple taps and reach ~20-30L/min for 1 minute. The sensor was pretty much off by ~0.7-1L.

That's around 3%, well within spec. This sensor probably works exactly like the manufacturer promised.

Can I do something about this?

Being out of spec at the limits of the specified flow range (close to zero and close to 100%) is absolutely normal. That is why an upper limit is given in the first place.

My first recommendation is that you make yourself aware of the demands that your intended application puts on the sensor. It's possible that the YF-B5 can't fulfill them.

Next, consider that it might not be ideal to use a single sensor for the whole range. Having only one sensor and expecting precision over a huge range of flow rates requires a high quality sensor. But all sensors will be limited at the extremes of their specified flow range. So if you want to cover up to 30 l/min while also getting high precision below 1 l/min, that's going to be tough.

the capacity of 60f and kfactor of 5.5 is somewhat influencing this (the outliers), or am I wrong about that?

The capacity of 60 l/min is not taken into the calculation as long as the mFactor values are at 1.

The kFactor of 5.5 instead of 6.6 Hz per l/min can certainly be tweaked, perhaps shifting things a bit towards more accuracy for some parts of the flow range.

I might need to calibrate as you have explained in your documentation, right?

The calibration process as described in the wiki will help you tweak the kFactor to the actual frequency of your sensor specimen. It will also enable you to optimise linearity for a specific flow range by determining mFactor values specific to that flow range.

It will enable you to make more out of your sensor. But it will unfortunately not be able to turn it into a better sensor…

Another thing, would you mind knowing what should I do with these random pulses that might occur from 10 to 60 minutes?

Can you elaborate about this? Did I overlook something?

What exactly is happening and how do you measure it?

Since the capacitor I have removed helped me removing them.

Do you have a source for calculating the value of this resistor in your application?

I can imagine that an RC circuit in this location dampens spurious signals, but since it introduced new issues, shielding the wiring might be a more promising approach (e.g. using a cable with four wires plus shield).

[cjacky475]

If you don't mind me asking: how do you determine the amount of water that runs down your toilet? :D

Well, there is a main house water flow meter, so it has absolutely great accuracy. Basically it got installed by out water providers. I mean, if only it had some sort of data cables, would be awesome... I could connect it to my sensor, hah. Answering your question, before I flushed it, I checked the value on it, then after I flush it - simple. I also made sure the cup is 500 ml. by checking on that main water flow meter.

Having only one sensor and expecting precision over a huge range of flow rates requires a high quality sensor.

When I first started this project, I really did not think about that just a simple sensor would not be able to cover my demands. Well, as you mentioned, it is literally under 10$.

Can you elaborate about this? Did I overlook something?

Basically when my sensor stands still, water does not run, sometimes it detects pulses and logs them. And it occurred from every ~10 to ~60 minutes. When I added that capacitor, I did not receive any more random pulses, when the water was not running.

Do you have a source for calculating the value of this resistor in your application?

I do not. I had a thread opened on Arduino forum for this problem, I then got this schematics created with the help. After I solved the problem with random pulses, I got recommended this library to solve the issue with incorrect values. But you mentioned that this sensor is just not able to fulfil my requirements, because it's cheap. Well, it does its job like the manufacturer promised.

So as I understood, the only thing I can do now is try to calibrate it to make more of my sensor, but I will not be able to do anything the very slow and very fast rate. Also, the problem with capacitor could be solved by shielding the wiring?

As per side note, do you have any recommendation on a more accurate sensor which would be more appropriate for my needs (I wish I could monitor really slow rates, and possibly up to ~20/30L per minute). I am doing a project just to monitor my house water usage, but this sensor is really not fulfilling much...

Thanks for the help again.

[sekdiy]

Well, there is a main house water flow meter, so it has absolutely great accuracy.

Okay, I suspected as much. :)

I'm not so sure about the great accuracy part, btw. The inherent problems are the same as described above. These meters have a much greater flow range and good accuracy at the most important flow rates, but they also have their limits. One reason is that they need to be economical for the provider. After all, they only need to be good enough for billing, they aren't really safety devices or relevant for process control.

if only it had some sort of data cables

Well... :D • https://github.com/jomjol/AI-on-the-edge-device • https://www.youtube.com/watch?v=iUgxwbfkIqU

Basically when my sensor stands still, water does not run, sometimes it detects pulses and logs them. And it occurred from every ~10 to ~60 minutes.

The question here is: are these pulses really erroneous or does the impeller actually move?

Unexpected pulses tend to come from pressure variance or vibration (the impeller might be spinning back and forth slightly), which would essentially be 'hydraulic noise' in the piping. Professional water meters don't run backwards, which is a very important distinction.

Additionally, EMI might be a cause. Interference might induce current into the wiring, the resulting voltage spike might trigger an interrupt. Shielded and/or very short cabling effectively protects against that. RC filtering could also help with it, but designing a circuit that solves the problem without causing either ringing and/or missed pulses isn't trivial (due to the interaction between the hall effect sensor, the wiring and the microcontroller circuitry).

do you have any recommendation on a more accurate sensor which would be more appropriate for my needs (I wish I could monitor really slow rates, and possibly up to ~20/30L per minute).

First of all, only use sensors that are safe for fresh (drinking) water installations! Your health is important.

Second of all, only use sensors that are approved for house installations! Your insurance coverage is important.

That essentially excludes virtually all cheap/simple sensors/meters, which is precisely why I only ever mention irrigation (because here it doesn't matter) and vending machines (because there the flow sensors are approved by their manufacturers) in my documentation.

The way most people do smart homey water measurement is by either reading out their official meter (see link above) or by using a proper meter with a pulse output in line (after the official meter).

The former is a completely different kind of project… The latter is basically an improvement of your current project by using better sensing hardware.

But please take great care to make sure that whatever sensor/meter you use is safe and approved for use in drinking water installations!

I can't really recommend a sensor, because it really isn't easy/cheap to get an approved one (that is also good).

PS: You might want to ask your water provider for smart metering. There are proper meters available which provide a pulse output. Who knows, maybe they are open to the idea...

[cjacky475]

Well... :D • https://github.com/jomjol/AI-on-the-edge-device • https://www.youtube.com/watch?v=iUgxwbfkIqU

I remember seeing those videos, but it did not attract me - it does not seem appropriate enough - what if the machine learning fails, what if I have different meter, so for and so on... I think great water meter is going to be way better than this.

The question here is: are these pulses really erroneous or does the impeller actually move?

If I add my capacitor and the pulses do not appear anymore, does that really make sense that impeller could have run and it did not detect those little pulses? I think it has something to do with electrical interference.

First of all, only use sensors that are safe for fresh (drinking) water installations!

This one scared me a little bit. I mean I do have it installed in my house right now, but looking in the internet it says it's suitable for vending machines or water dispensers. I have found this and this, it states it's suitable for many different applications. Well you can only hope what they write. Probably I will contact the suppliers from which I bought this sensor, they might have something.

You might want to ask your water provider for smart metering.

Will do. The idea with the machine learning does not seem ideal for me, I think a more expensive water meter would do me a trick. I hope it's not going to be very expensive or else I will stick with this and just have a working project open for future improvements.

[sekdiy]

If I add my capacitor and the pulses do not appear anymore, does that really make sense that impeller could have run and it did not detect those little pulses?

Absolutely, yes.

The capacitor – together with the source resistance of the hall sensor and the input resistance of the MCU – forms an RC circuit. Additionally, the reference to the 3.3V line might have interacted with the signal.

This is the step response of an RC circut (source: Wikipedia):

The original, rectangular single pulse coming from the hall sensor is rounded off at its leading edge. This makes it more difficult for the voltage level to reach the high-level threshold of around 4.5 V (according to the datasheet), particularly if the capacitor is mismatched (i.e. too large for the impedances involved). With a pulse train coming from the sensor due to continuous flow, the high-level threshold voltage is reached eventually.

This one scared me a little bit. I mean I do have it installed in my house right now, but looking in the internet it says it's suitable for vending machines or water dispensers.

The hard points here really are health and insurance coverage.

Manufacturing a part according to relevant regulations and testing it for safety is expensive. There's no one particular manufacturer for the YF-B5, which might indicate that there are multiple. No safety statements/certificates or hints at regulations are given. You can conclude that nobody will even think about guaranteeing anything. And most likely, there's a reason why (because adhering to regulations would be a feature the manufacturer would be able to advertise).

In my home country, Germany, the relevant body is called "DVGW". Anything not approved by them you can forget for household or drinking water applications. If you have water damage in Germany, the first thing an insurance investigator will look for is non-approved components in your installation.

I hope it's not going to be very expensive or else I will stick with this and just have a working project open for future improvements.

Why don't you move forward by doing the calibration? :D

In your situation I'd use a large bucket (at least 10 l) and a reliable scale (to determine the mass of the content in the bucket).

[cjacky475]

In your situation I'd use a large bucket (at least 10 l) and a reliable scale (to determine the mass of the content in the bucket).

Could you elaborate on this more on how exactly would I need to calibrate it with the mass of the content? Looking back at this (third post):

Is this how I should continue to calibrate it (as you have explained in the documentation?). As I believe now my values are gonna be closer to real values, and the proportion gonna be lower? Thanks.

[sekdiy]

I think you got the general approach just right.

But you might need to backtrack a step: if I remember correctly, your k-Factor was off to begin with.

I recommend that you quickly consult the FS400A calibration example, particularly the k-Factor paragraph.

It basically describes the same issue: uncertainty about the k-Factor.

Your table above seems to predict that the kFactor value in use was off by a significant factor, since the average proportion between nominal (expected) and actual (measured) mass/volume in your screenshot appears to be: (0.4 + 0.25 + 0.2) / 3 = 0.283̅ ≈ 1/3.53.

Ideally, the average of the individual m-Factors should be exactly one. This way, the k-Factor would exactly reflect the average frequency per flow and the individual m-Factors would reflect the non-linear deviations from that average within their respective flow ranges.

The latter is not technically required, as the correction is also applied correctly with any arbitrary kFactor value. But it's much easier to make sense of the sensor behaviour if it can be understood (and thus described) based on some normalised properties.

Could you elaborate on this more on how exactly would I need to calibrate it with the mass of the content?

What this basically boils down to is: how do you weigh a bucket of water. ;)

If you don't have a scale suited for this purpose, you could use a 10l bucket and a bathroom scale to measure the difference in mass between you holding the filled bucket and you holding the empty bucket. What the scale may lack in precision, the bucket more than makes up for with its larger volume. Bigger is better here, so a 20l bucket trumps a 10l bucket, two buckets trump one, etc…

Is this how I should continue to calibrate it (as you have explained in the documentation?).

Technically, yes.

But I recommend that you don actually continue, but start over.

I also recommend that you begin with an assumed spec of 400/60 = 6.6̅ as per the 'datasheet', thus: kFactor = 6.66666666f. It's also very important that you reset all of the mFactor values to 1.0f in case you haven't done so yet.

Dedicate the first run of ten measurements within the ten flow rate intervals (0–3, >3–6, >6–9, etc.) to determining your kFactor (i.e. determining your actual average frequency) like so:

For the interval 0–3 l/min, adjust the flow to 1.5 l/min, but 3 l/min will also work (just be consistent here). Next, take a proper bucket measurement. Go through all ten intervals this way. Then, look at the proportions and calculate their average value. Use this average to rescale your kFactor.

Once you got your kFactor dialed in, do further runs to determine the ten mFactor array values. They should all be very close to one now.

As I believe now my values are gonna be closer to real values, and the proportion gonna be lower?

That's what you'll find out by trying. ;)

The target goal is that the proportions have an average value of one!

Good luck!

PS: You might want to plan ahead for what to do with all the water!

[sekdiy]

I'm closing this issue due to inactivity.

If you have new information, please just reopen it.