robert-hh / hx711

MicroPython driver for the HX711 load cell interface.
MIT License
46 stars 8 forks source link

Intermittent spurious values returned from pio version versus gpio version #5

Closed dakin80 closed 1 month ago

dakin80 commented 1 month ago

I'm getting intermittent spurious values returned from pio version versus gpio version. I'm using a Raspberry Pico W with a run-of-the-mill hx711 board and a 1kg shear beam loadcell in a test mount. Plus of course the important 455g tin of peeled plum tomatoes used as a calibration weight and which is left on the rig for these tests.

pio code:

from machine import Pin, I2C
from time import sleep

from hx711_pio import HX711

pin_OUT = Pin(19, Pin.IN, pull=Pin.PULL_DOWN)
pin_SCK = Pin(18, Pin.OUT)

hx711 = HX711(pin_SCK, pin_OUT, gain=128)

offset = hx711.read()

print("Add calibration weight")
sleep(5)
print("Calibrating")

scale = (hx711.read() - offset) / 455.0

print("Calibrated")

samples = 0

while True:
    if (hx711.is_ready()):
        value = (hx711.read() - offset) / scale
        samples += 1
        if abs(value-455) > 1.0:
            print(samples, value)
    sleep(0.1)

The output:

MicroPython v1.22.0 on 2023-12-27; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> %Run -c $EDITOR_CONTENT
Add calibration weight
Calibrating
Calibrated
24 463.75
32 463.75
34 463.75
119 463.75
155 459.375
180 459.375
230 463.75
292 463.75
297 463.75
472 463.75

On changing the pio library to the gpio one I get no spurious values.

Is there a problem with the pio version of the library or am I doing something wrong?

I also note that the values of the pio version seem to have a granularity in the measurement. Note how the values always end in "75". This seems odd.

robert-hh commented 1 month ago

Thanks for the note. I'll check that. It seems you do not use the most recent versions of the driver from beginning of June 2024? There was a change to deal with the situation, that the HX711 issues conversion ready pulses at the data line even if a data transfer is taking place. That pulse can cause a huge deviation in the values. As part of the change is method is_ready() was dropped. So you do not have to call it. The driver will wait itself for the data being ready.

dakin80 commented 1 month ago

Have replaced classes with latest versions and that has corrected the problem. Thanks for the quick response. I had downloaded the code a fair while ago and had done a quick test but not noticed the difference in behaviour of the two methods. Have now nearly finished a weighing tipping bucket rain gauge to add to a weather station and the problem became apparent. Again, many thanks.