My application is counting water usage from my tank. I would like to use a water flow sensor. The output is a pulse and the more pulses, the higher the flow rate. e.g.
but the water flow is highly intermittent, could last for 30s and I read here that pulse counting is blocking. pin.read() | Dev Center
This is very strange. I just want a counter that is on all the time so I can read the counter and calculate total water flow since the imp turned on. Why is pulse counting blocking in electric imp? It’s as if the counting is done in software instead of with a hardware counter. Should I just buy a hardware counter instead of potentially blocking the CPU for 30 seconds while I wait for the water to stop flowing?
EDIT: I should also mention that this CPU blocking pulse count call is annoying because I planned to have four tanks connected to my imp at once and if two flow at once then only one will be counted.
I have helped a friend with a similar issue. He was using a spinning flow sensor with magnet pickup. It worked pretty good for a while, but a couple of times the spinner got some hair-like fibers or string stuff wrapped around it. Other times it seemed like more water was flowing past it than it was sensing.
I don’t know of your situation, but since his 55 gallon drum tank full of water weighed about 550 lbs with the drum, we decided to build a platform with 4 load cells and put the drum on top. The input and output lines were flexible stainless hose. He is amazed at the accuracy of flow measured by weight over time. Weight going in during filling and weight coming out. We used a load cell board that has 4 load cell summing with a UART output of a decimal value. Noting the empty weight and full weight so alarming, drum fill, or other triggers can be dealt with at any level.
The one thing he found out right away … he was losing water all the time through a siphoning effect on a pump. He never noticed that with the flow sensor because it didn’t spin when the water moved too slowly. But the weight on the data collected showed the loss dramatically. His data collection was the imp sending the decimal value to a website every 10 seconds during a specific process and a logged data point every 60 seconds when the process was on hold. During the night when the process was not running, the data was only logged every 10 minutes. Any over-fills, or low levels triggered text messages to his phone.
This does not answer your question, but it may trigger some different ideas … I just wanted to throw in some thoughts and ideas.
Yes, that is a good idea to use weight instead of an inaccurate flow sensor that stops functioning at low flow. That was my first idea but it was shot down because apparently the location of my tanks change and the tanks are thrown around inside a fridge.
I should also mention that this CPU blocking pulse count call is annoying because I planned to have four tanks connected to my imp at once and if two flow at once then only one will be counted.
What was the UART load cell board you found? I haven’t found any tailor-made solution like that for load cells, so I’m just using a postal scale platform with an HX711 amplifier.
He actually pulled a board out of a scrapped Toledo industrial scale. It had an RS232 interface. But I see no reason you couldn’t use an HX711. It has the i2c interface and there are imp libraries for that.
Your situation with loose tanks and possible load cell damage might be an expensive way to measure. If you had a large aluminum platform that all of the tanks sit on at the same time, you could weigh the whole thing. You would not know if one or more tanks were empty. One might be full, another empty.
Perhaps you will have to enforce some ‘administrative controls’. A specific cubby hole or a place for each tank that will control where it is weighed. If someone throws them around or doesn’t do it right, they can find another job.
This is really a tough one because it sounds like you don’t have much control over how other people handle the products.
Another “outside the box idea”. If the temperature of the liquid in the tanks is somewhat different than the ambient temp, you could put an IR camera inside the fridge and view it remotely. You will see the level in each tank by the line created from the temp on the outside of the tank where the liquid sits in the tank. Sort of a crude method, but just another idea. It would not matter where they put the tank as long as you can see it with the view of the camera.
I recently came up with some interesting pulse interval code - using the UART timing mode to essentially time-stamp falling edge events.
The example code is for RPM counting, but it should be pretty understandable. Each time there’s a falling edge, the UART sees a start bit and we get a microsecond timestamp since the last event. The byte is malformed (there’s no stop bit so technically there’s a framing error) but I just ignore that. As imps tend to have plenty of UARTs this is a nice way to build a totally background RPM counter.
Obviously, to just count pulses, you simply need to count received bytes - as long as the minimum low period is >1 bit time, and the minimum high >9 bit times (configure the UART appropriately) youl won’t even need to use timing mode. This should work fine for fairly high pulse rates - what’s the range you’re looking at?
I ended up deciding to use a dedicated I2C counter IC called the S-35770. My application uses four UARTs already and I plan to have 4 counters so I think I also have to use an I2C switch.
Alternatively I could have used a cheap FPGA and combined all counters together but I’ll just do it this way instead. It’s probably the same cost.
If this the application I’m aware of, you would likely be better off using the UARTs for pulse counters, and I2C to talk to the 4 remote devices via an I2C multiplexer… we can discuss more when we have some more detail on requirements.
