johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Tue Feb 11, 2020 12:20 am

I've built a brewery mash system with a RPi 3, two temperature sensors and a flowmeter. A GUI interface displays current temperatures and flow and allows the user to set a thermostat temperature. An electric heating element is switched on and off a calculated number of seconds to raise and then maintain a set temperature.

All works well until the mash temperature reaches about 145F, when the flow rate starts oscillating, while averaging a lower value. The system is being tested with just water, and the valves are not being touched, so the flow should be unchanged and steady.

Thinking the problem may be in time.sleep() functions used to count interrupts for the flow rate and for cycling on/off the heating element, I tried using pigpio for the flow meter and RPi.GPIO for the heater pin and temperature probes.

The plots attached show the test runs for each program version. The flow rate is plotted on the same scale as the temperatures (Liters/hr). The pigpio version is an improvement over the RPi.GPIO version, but not perfect- in a real brewing session, flow rates change when the mash is stirred or gets compacted, etc., so measurements need to be consistent. When I stop the programs and run a simple command line program to return temperatures and flow, the flow is reported correctly.

My attempts at fixing all this amount to guesswork. I've researched multi- threading and processes. The attached zip file contains the python programs and the data logging files for the two tests. Any advice is greatly appreciated!
TestPiGPIO20200210.png
TestPiGPIO20200210.png (58.31 KiB) Viewed 908 times
Test3V20200208.png
Test3V20200208.png (49.35 KiB) Viewed 908 times
Attachments
RPiMashRIMScontrol.zip
(20.12 KiB) Downloaded 12 times

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Tue Feb 11, 2020 10:10 am

Have you tested the flow meter by itself?

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Tue Feb 11, 2020 3:46 pm

"When I stop the programs and run a simple command line program to return temperatures and flow, the flow is reported correctly." The flowmeter worked fine with my earlier system that consisted of an arduino connected to a netbook. My objective was to eliminate clutter and wires of two devices and focus on just a RPi with a touchscreen, using the gpio pins for the sensors.

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Tue Feb 11, 2020 4:35 pm

The I suggest you start from your simple program as a base and add functions to that one at a time. Either it will work or you will know which step created a problem.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Wed Feb 12, 2020 4:36 am

So, I tried another test using 120VAC for the heating element instead of 240VAC, wondering how much slower the water would heat up. I discovered the flow meter problem started occurring at about 1 hr running time. Looking back at the other tests, I notice the weird behavior also started about 45 minutes or a bit longer.

Again, I wonder if something about the time.sleep() function is somehow losing track of time after a while. Any thoughts about how I can count interrupts without using the time.sleep function? Thoughts on how I could test the sleep function over an extended period of time?

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 4:21 am

Managed to perform a few more tests.

The weird flow readings are definitely related to temperature of the water flowing thru and the use of the RPi. When I use my old setup of Arduino and netbook, the flow rate stays rock solid, regardless of temperature. When I switch over to the RPi, with the water still warm, I get the low, inaccurate flow reading.

My only guess at this point is perhaps the 3.3v of the RPi GPIO pin used is not sufficient compared to the 5v of the Arduino. The flowmeter specs state 5v, but other posts/google searches said 3.3v would work because on/off is binary regardless of voltage.

Any advice on how to use a level shifter(?) to supply 5v to the flowmeter is appreciated.

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 9:44 am

Flow meters and Hall effect sensors are often open collector outputs. That means the output line is either pulled to ground (low) or allowed to float to the external voltage (high). If that is the case with your sensor you can quite safely power it from 5V. The external voltage in this case is any pull-up applied to the GPIO connected to the output line.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 2:03 pm

Thanks for the reply. I assume then that, using the attached level shifter, I would connect the HV to the 5v RPi pin and also connect, say, the second RPi 5v pin to the flowmeter. Ground is ground is ground, regardless of voltage. The output wire from the flowmeter would be connected to, say, B1, and A1 would be connected to the RPi GPIO pin I'm currently using. Thanks for your help!
Attachments
LevelShifter.jpeg
LevelShifter.jpeg (82.64 KiB) Viewed 712 times

User avatar
bleep42
Posts: 169
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 2:32 pm

I believe Joan is actually saying, if your output is open collector, you will not require a level shifter, because the open collector will only pull down to ground, or 'float' upto whatever the GPIO pull up is connected to, which is 3.3v
Regards Kevin.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 4:21 pm

Thanks for your reply. However, I'm still confused. If I connect the 5v and ground pins to the sensor and connect the output from the sensor to the RPi GPIO pin, don't I run the risk of damaging the RPi? When I was first designing my circuitry, I inadvertently bricked my RPi, trying to do something like this.

The relevant code:

pi.set_mode(FLOW_GPIO, pigpio.INPUT)
pi.set_pull_up_down(FLOW_GPIO, pigpio.PUD_UP)

while True:
global flow
callback = pi.callback(FLOW_GPIO) # default tally callback
time.sleep(2)
flow = callback.tally()*2.1

Again, this code works for room temperature flowing water, but when the temperature gets to about 140F, the flow measured decreases even though nothing has changed in the physical system (except the temperature.) BTW, the sensor power is currently from a 3.3v pin.

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 4:29 pm

Look up open collector on wiki. If the sensor has an open collector output it will not feed 5V into the Pi.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Sun Feb 23, 2020 9:48 pm

Hmm, this discussion is getting above my grade level. Another forum post suggests:

Red ------------- 5V


+----- 3V3
|
10K
|
Yellow ----+----- gpio


Black ----------- Ground

Will this work? Does my working python code indicate the sensor being "open-collector"? Pull-up Pull-down???

User avatar
bleep42
Posts: 169
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 1:11 pm

Without knowing what your colours mean it's impossible to say.
If I assume that RED and BLACK are the power input to your device, then yes that's fine.
If the YELLOW is an open collector output from your device then again yes that is fine, though I believe the GPIO has its own pull up, but having another 10k resistor pull up to 3.3v will do no harm & may even improve the speed of the voltage edge produced. NB the BLACK or Ground must be common to both the 5v & 3.3v power supplies, if both come from the Pi or its power supply then they will be common already.
You really need to find out if your output is Open collector, from the spec. or the supplier.
Regards Kevin.
Last edited by bleep42 on Mon Feb 24, 2020 6:24 pm, edited 1 time in total.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 6:21 pm

Thanks for the help. Try as I might I can't determine if the flowmeter is open connector- none of the spec sheets for the product mention that. Does the fact that the code specifies PUD_UP mean the sensor is open connector? Another post when I first started this project stated that PUD_DOWN did not work and UP had to be used. Am I correct to think that PUD_UP means the GPIO pin supplies the voltage and the sensor provides a series of grounds, so the 3.3v and resistor combination is OK?

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 6:37 pm

The PUD_UP is suggestive but not conclusive. If you have a meter measure the voltage on the output line when the output line is not connected to the Pi. If it stays at 0V during flow then it is likely open collector.

User avatar
bleep42
Posts: 169
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 6:39 pm

Hi,
It's Open Collector, not connector.
See link https://en.wikipedia.org/wiki/Open_collector
If you have a circuit of the output from your device, does it have a Transistor or FET in the configuration shown in the link.
IE the Collector input to the transistor is floating with no connection, ready for you to connect your pull up and GPIO to, and the other side of the Transistor goes to Ground.
Regards,
Last edited by bleep42 on Mon Feb 24, 2020 7:04 pm, edited 2 times in total.

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 6:40 pm

Alternatively see if it works with PUD_DOWN. If it does not work with PUD_DOWN but does with PUD_UP I would assume it is open collector.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Mon Feb 24, 2020 8:19 pm

OK, so the sensor works with both PUD_UP and PUD_DOWN. I assume, therefore, that the flow meter is NOT open collector and that I should use a level shifter.

Back to my earlier post:

Thanks for the reply. I assume then that, using the attached level shifter, I would connect the HV to the 5v RPi pin and also connect, say, the second RPi 5v pin to the flowmeter. Ground is ground is ground, regardless of voltage. The output wire from the flowmeter would be connected to, say, B1, and A1 would be connected to the RPi GPIO pin I'm currently using. Thanks for your help!

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Thu Feb 27, 2020 5:32 am

Back again. I re-configured my circuits to provide 5v to the sensor and used a voltage divider to step down the signal output to a 3.3v RPi GPIO pin. My problem still has not gone away. With the 5v circuit, the wild flow rates trend up instead of down, e.g. when I was using 3.3v. I've also determined the issue is not with temperature.

After 20 minutes or so of continuous operation, the flow rate becomes unstable, jumping up and down, trending up. If I stop the python program and start it up again, the flow rate is normal.

The flow is calculated by counting the number of pulses in two seconds:

callback = pi.callback(FLOW_GPIO) # default tally callback
time.sleep(2)
flow = callback.tally()*2.1

At this point, I can only guess that after 20 minutes of operation, the time.sleep function loses/gains time. If not, then the callback.tally function starts messing up, implying that something funny is going on with the GPIO. I'm using GPIO_22, pin 15. I hope someone can help me. I'm beginning to regret having switched from an Arduino to a RPi.

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Thu Feb 27, 2020 9:28 am

You suspect the code falls over after a time. Perhaps provide a small script which demonstrates the problem and tell us what inputs are required to make it fall over. That would gives us something to look at.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Fri Feb 28, 2020 2:04 am

Here you go- I stripped down the python code to simply monitor the flow and log it to a file. I ran the program for an hour, then stopped it and started again. The flow after restarting reverted to its proper value.
Attachments
RPiFlowCodeLog.zip
(5.39 KiB) Downloaded 15 times
flowlogTest20200227.png
flowlogTest20200227.png (36.52 KiB) Viewed 432 times

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Fri Feb 28, 2020 9:26 am

The code is creating a new callback for GPIO 22 every two seconds (in the while loop). I'm not surprised it falls over. I'm pleased it keeps going so long. After 10 minutes there will be 300 callbacks in operation for the GPIO. It will increase at that rate until the system runs out of resources. Python will be processing all those callbacks so I expect it will be getting pretty busy.

Move the callback creation outside the loop.

In the loop either subtract the old tally from the new tally to get the two second reading or reset the tally in each loop.

In summary change

Code: Select all

    while True:
        global flow
        
        callback = pi.callback(FLOW_GPIO) # default tally callback
        time.sleep(2)
        flow = callback.tally()*2.1
to

Code: Select all

    callback = pi.callback(FLOW_GPIO) # default tally callback
    while True:
        global flow
        
        time.sleep(2)
        flow = callback.tally()*2.1

        callback.reset_tally()

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Fri Feb 28, 2020 5:22 pm

Some progress. I made the code changes as suggested. The simple program with the modifications runs solid, that is, after an hour of run time, the flow rate measured is steady and at a value (~90 L/hr) that is expected.

Making the same change to the original script, with temperatures, a dynamic plot, thermostat control, etc., had 2 effects. First, the flow rate measured was way higher than expected. (~160 L/hr, I suppose I could recalibrate the count to L/hr factor, eg. 2.1) Second, as the attached plot shows, the flowrate is much more volatile and seems to be cycling in some range.

I'm stuck. Would it be worthwhile to try to break apart the flow measuring into a separate thread or process or daemon that the main program would reference/call/query? Would developing my application in something other than python work better? Maybe much more drastic and use an arduino nano for the interrupt counting and connect to an RPi GPIO?

I'm getting more and more frustrated, but I do greatly appreciate your help.
Attachments
TestVdivide20200228Callback.png
TestVdivide20200228Callback.png (36.18 KiB) Viewed 384 times

User avatar
joan
Posts: 14766
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Fri Feb 28, 2020 6:09 pm

Not sure what to say. If the flow rate is as expected with one script but not with another you have to examine the script differences. It sounds as it is back to starting simple and add functionality until it breaks - then correct the fault.

johnzbesko
Posts: 23
Joined: Sat Jan 09, 2016 2:35 am

Re: pigpio vs. RPi.GPIO Hall sensor interrupt odd readings

Fri Feb 28, 2020 7:57 pm

Thanks for the reply. If I'm going to guess, I'd say the plotting functionality of the program is at fault. It uses matplotlib and I encountered memory leak issues with it.

Return to “Advanced users”