AthulSNair:
For every liter water flow , sensor will produce 4.5 Pulses(as per your program, some other programs use 7.5) and by counting number of pulses for a minute and dividing it by 4.5 will give the amount of water in liters passed per minute.
By divding it with 60 will give number of liters per hour, right??
No, you multiply by 60. But if you really need to know the flow per hour, why don't you count the pulses per hour?
// Because this loop may not complete in exactly 1 second intervals we calculate
// the number of milliseconds that have passed since the last execution and use
// that to scale the output. We also apply the calibrationFactor to scale the output
// based on the number of pulses per second per units of measure (litres/minute in
// this case) coming from the sensor.
flowRate = ((1000.0 / (millis() - oldTime)) * pulseCount) / calibrationFactor;
can you please explain this step?
It is what it says, the count time may not be exactly a second it may be slightly over
void loop() {
if((millis() - oldTime) > 1000)
doesn't say "if it is a second, do", it says"if it is over a second, do", and it may be 1.002 second.
Pulse frequency (Hz) = 7.5Q, Q is flow rate in Litres/minute
Flow Rate (Litres/hour) = (Pulse frequency x 60 min) / 7.5Q
I have a doubt in it, Why is there Q in denominator ??
Good question - the equn is nonsense and, on the strength of that, I wouldn't have anything to do with the programme, or Hobbytronics.
Since
Hz=7.5Q
then Q=Hz/7.5 and so if Hz=75 then Q=10 l/min and so how hard can it be to determine that
flow rate l/hr = Q*60 = 600?
But (75 * 60)/(7.5 * 10) = 60
Exactly what you want to do is not clear. If you want rate of flow, using the interrupt pin like everybody else does is probably a good idea. If you just want flow, then simply counting the pulses should suffice.
Further, I submit that
// Every second, calculate and print litres/hour
is probably a sign that the programmer has no actual experience of these devices. The output varies so much that reading it at one second intervals is a futile exercise, even on a serial monitor, but the overall output over a sensible period is remarkably accurate. You may be better off displaying an average over ten seconds, or having a ten second count window. You could use the same readings to count for one hour update, which would be very accurate.