search

tatobari / hx711py

HX711 Python Library for Raspberry Pi.
Apache License 2.0
208 stars 154 forks source link

HX711 readings #7

Closed karl16 closed 5 years ago

karl16 commented 7 years ago

Tatobari,

So I was wondering if you knew a way to speed up how fast it takes readings, because I had read that it should be able to take about 80 readings per second. Yet I can only get about 2 readings per second. So if there is anything that I can do to get the amount of readings to be much higher it would be highly appreciated.

Update: I changed the argument in the get_weight method to 1 instead of 5 and now I can get 6 readings per second. I also commented out the power_down, power_up, and the time.sleep parts. Also I am using a Raspberry Pi Zero if that helps

Thanks Karl

tatobari commented 7 years ago

Hi Karl, By the way, just call me Tato.

Is there any chance you could share the part of your code where you call the getWeight method?

My example.py is quite convervative. It resets the HX711 by powering up and down and waits a lot of time between readings. However, hx711.py actually let's you call the hx711 without limitations, except for the HX711's state (lines 55 to 58):

while not self.is_ready():
    #print("WAITING")
    pass

The HX711 takes little bit of time to get the next reading ready. I'm not sure how much time it take. You can uncomment the print("WAITING") line to see how long it takes on your console, I guess.

Anyway, if you can share some code, I might come up with something to suggest.

Tato

karl16 commented 7 years ago

The code is almost identical to your exampleHX711.py

import RPi.GPIO as GPIO
import time
import sys
from hx711 import HX711

def cleanAndExit():
    print "Cleaning..."
    GPIO.cleanup()
    print "Bye!"
    sys.exit()

hx = HX711(5, 6)

hx.set_reading_format("LSB", "MSB")

hx.set_reference_unit(92)

hx.reset()
hx.tare()

endTime = time.time() + 1

while time.time() <= endTime:

    val = hx.get_weight(1)
    print(val)    

       # hx.power_down()
       # hx.power_up()
        #time.sleep(0.5)

cleanAndExit()

The only difference is that I used a timer. Even when I do it how you originally had it I only get a few values per second. I think that the data rate is set to 10 samples per second because I am pretty sure it is the default. But I am not sure how to change this to 80 samples per second. This is what the data sheet says under Clock Source Options

By connecting pin XI to Ground, the on-chip
oscillator is activated. The nominal output data
rate when using the internal oscillator is 10
(RATE=0) or 80SPS (RATE=1).

tatobari commented 7 years ago

Karl, There is a RATE pin in the HX711 chip. I'm not sure how it's set on the typical green or blue breakout boards. My best guess is that it's probably set to 10. I'd try to find a tester and check the voltage on that pin. As far as I understand, anything above 2.0 volts means that the RATE is set to 1.

If it's set to 0, then you will be needing a standalone chip so that you can wire it yourself.

I'll see if I can find a standalone one in my local stores, I'll try to make some tests during this week and come back to you with results.

Regards, Tato

tatobari commented 7 years ago

Hey, I couldn't find any standalone chips here. Did you manage to make it work?

Regards, Tato

faurepa commented 7 years ago

Hello, I am looking to write a calibration routine, but I can't seem to get hx711 to reset and use the new reference_unit. Currently, I initialize without reference_unit, and determine what the reference unit should be. Then go back to check it, but I can't seem to apply it. Here is the code that I have at the moment. Any thoughts, suggestion would be greatly appreciated.

import RPi.GPIO as GPIO
import time
import sys
from hx711 import HX711

GPIO.setmode(GPIO.BCM)

def cleanAndExit():
    print "Cleaning..."
    GPIO.cleanup()
    print "Bye!"
    sys.exit()

hx = HX711(27, 17)
hx.set_reading_format("LSB", "MSB")
#Follow steps from here:
#https://github.com/tatobari/hx711py/issues/2
#1- comment out reference unit
#2- record average value
#3- Add known weight and take another average
#4- Subtract two difference, and divide by the known weight.
#5- Apply result to "reference_unit", or
#hx.set_reference_unit(5460.0)  #added b6+b6*(1-ave)

counter=0
SumValue=0
Average=0

hx.reset()
hx.tare(30)

for x in range (0,10):
    val_bare = float(hx.get_weight(15))
    SumValue = SumValue+abs(val_bare)
    counter = counter+1
    print val_bare
Ave_Bare = SumValue/counter
print ('Ave_Bare:',Ave_Bare)
print "add weight"
Cal_Weight = float(raw_input('What is the weight of the Calibration piece? ' ))

counter=0
for x in range (0,10):
    val_weighted = float(hx.get_weight(15))
    SumValue = SumValue+abs(val_weighted)
    counter = counter+1
    print val_weighted
Ave_Weight = SumValue/counter
print ('Ave_Weight:',Ave_Weight)

Ref_Unit=(Ave_Weight - Ave_Bare)/Cal_Weight
print ('Ref_Unit:',Ref_Unit)

print "Remove Weight"
wait = raw_input('Hit enter when ready to proceed' )
hx.set_reference_unit(Ref_Unit)
hx.reset()
hx.tare(30)

print "put weight back on"
wait = raw_input('Hit enter when ready to proceed' )

Weight_wrong = 1;
print "Checking Calibration"

while Weight_wrong == 1:
    try:
        counter=0
        for x in range (0,10):
            Check_Weight = float(hx.get_weight(15))
            SumValue = SumValue+abs(Check_Weight)
            counter = counter+1
            print val_weighted
        Check_Weight = SumValue/counter

        if (Cal_Weight > (Check_Weight*(0.9998))) and (Cal_Weight < (Check_Weight*(1.0002))
            Weight_wrong = 0
            break
        else:
            New_Ref_Unit = Ref_Unit + Ref_Unit*(1-(Cal_Weight/Check_Weight))
            print ('New_Ref_Weight:',New_Ref_Unit,Cal_Weight,Check_Weight)

        wait = raw_input('Remove Weight, Hit enter when ready to proceed' )
        hx.set_reference_unit(New_Ref_Unit)
        hx.reset()
        hx.tare(5)
        wait = raw_input('Add Weight, Hit enter when ready to proceed' )

    except (KeyboardInterrupt, SystemExit):
        cleanAndExit()

Ref_Unit = New_Ref_Unit
cleanAndExit()
tatobari commented 7 years ago

Hey @faurepa I've read your code really quickly. If it's correctly written and the logic makes sens, then the error you're handling is a bit too optimistic. The multipliers 0.9998 and 1.0002 may not be enough to find a stable value. Maybe they are, but I honestly can't really review your code right now. I'll try to take a look at it during next week.

I'll keep the issue open meanwhile.

faurepa commented 7 years ago

Hello, Thank you for taking some time to look at my code. The "fine" tuning of the multipliers still need to be accomplished. The issue that I am seeing is that when I try to get the "real" weight, I only get the bit representation. I can't seem to get hx.get_wieght to use the hx.reference_unit value after the program has been started. I tried to do a hx.reset in the middle of the code, but it doesn't seem to work help.

Here is what I see; When I start the program with out reference_unit, I get the bit representation. When I start the program with reference_unit applied, I get the weight in grams, which is correct.
The problem is that when I want to change from bit to grams in the middle of the program, I only get the bit representation. There is probably something that I have over looked.

Thank you for your help.

faurepa commented 7 years ago

Hello, I was wondering if you had had the chance to review my code? Where have I gone wrong? Thank you

faurepa commented 7 years ago

Hello, I found my error. I was using the wrong variables to check my reference weight. I have attached my updated code, thank you for your help. The attached file is a python code, just need to change the extension. calibration.txt

normanjw commented 6 years ago

Hi Tato,

I am trying to run your script and I can't get the readings to change -- just getting a constant value, even if I apply different weights. Ie, I don't think it's reading anything; I have gpio 5 connected to D_OUT and gpio 6 connected to PD_SCK. Do you have any ideas? I read some discussion about clock speed of the hx711 and MCU being the issue, not sure if I can troubleshoot that via your script.

Also, what is the parameter that goes into get_weight()?

Thank you

faurepa commented 6 years ago

Hello, Without seeing the actual configuration, and your code. I don't know. I can tell you the pit falls that I ran into: 1- Make sure that you have D_OUT and PD_SCK the correct way round, 2- Make sure that you have GPIO.Setmode correct.

What I have done in some cases was to start to pepper my code and the hx711 code with print commends. Make sure that every variable has the correct information.

get_weight() is the number of measurements to "average" before reporting. I have set it to 3, and tare =5. that is a trade off between speed and accuracy that you will need to play with. After playing with my code, I found that lines 65 to 97 don't really help, and makes the coding longer and more difficult than required.

Hope that helps.

normanjw commented 6 years ago

Hey, thanks so much for your response. I got it working... the issue was really simple, serial communication was not enabled on the raspberry pi.

However, the values I am getting right now are quite inconsistent so I can't determine the correct scaling factor. Ie. standard deviations are large, and every time I restart the program, the values are in a different range. Do you have any suggestions? I tried changing from 5V to 3.3V and this made the values a little more consistent but still not usable. I also did try changing the LSB/MSB order, but that made the output worse (positive and negative values).

Below is data from a test run.

test with VCC = 3.3V, weight = 2kg after 10 outputs, recalculates average, standard deviation and weight t(s) | avg | stdv | wt(kg) |   10.18 | -237.45 | 63.03 | 1549.8 |   19.33 | 905.07 | 494.77 | -201.09 |   28.48 | -67.5 | 110.4 | -1362.96 |   37.63 | -5298.32 | 2727 | -80.78 |   46.79 | -102.4 | 24.16 | -7597.66 |   55.94 | 12166.19 | 12456.61 | -139.73 |   65.09 | 4172.65 | 4722.72 | 24291.04 |   74.24 | 22678.72 | 577.59 | 4032.41 |   83.38 | 3927.61 | 44.14 | 22304.66 |   92.53 | 22326.97 | 305.84 | 3976.98 |   101.68 | 3883.51 | 157.71 | 21234.91 |   110.83 | 21054.15 | 159.22 | 3811.6 |   119.98 | 3769.85 | 46.74 | 21187.05 |   129.13 | 21217.87 | 218.5 | 3781.62 |   138.28 | 3795.36 | 23.09 | 21447.24 |   147.43 | 21846.44 | 699.25 | 4023.08 |   156.58 | 4048.61 | 19.13 | 22130.06 |   165.73 | 22243.77 | 133.18 | 4104.88 |   174.87 | 4146.66 | 34.5 | 22584.44 |   184.02 | 22459.04 | 327.04 | 4106.68 |   193.17 | 4180.72 | 54.7 | 22496.6 |   202.32 | 21898.71 | 306.42 | 4152.3 |   211.46 | 4111.96 | 22.58 | 21645.64 |   220.61 | 21387.19 | 215.91 | 4142.76 |   229.76 | 4046.23 | 47.3 | 20954.81 |   238.91 | 20837.85 | 105.41 | 4037.56 |   248.06 | 4037.27 | 20.61 | 20615.91 |   257.21 | 20477.38 | 60.6 | 4062.04 |   266.37 | 4037.87 | 13.91 | 20449.89 |   275.53 | 20420.04 | 82.42 | 4050.63 |   284.69 | 4067.07 | 13.5 | 20700.41 |   293.84 | 20910.21 | 166.33 | 4081.36 |   303 | 4051.75 | 20.04 | 21080.77 |   312.15 | 21158.85 | 119.24 | 4079.05 |   321.31 | 3975.38 | 31.12 | 21054.09 |   330.46 | 20680.29 | 240.04 | 3902.85 |   339.61 | 3938.81 | 23.08 | 20626.53 |   348.77 | 20491.84 | 89.28 | 3968.51 |   357.92 | 3960.29 | 15.57 | 20511.63 |   367.48 | 30756.2 | 31394.46 | 2706.19 |   376.64 | 12628.34 | 31362.08 | 6630.8 |   385.79 | 6593.91 | 17.87 | 12668.05 |   394.94 | 12380.51 | 252.47 | 6342.55 |   404.18 | 6365.78 | 20.18 | 12404.14 |   413.33 | 12498.3 | 45.02 | 6330.46 |   422.49 | 6282.24 | 30.65 | 12398.76 |   431.64 | 12346.78 | 55.39 | 6260.42 |   440.79 | 6354.69 | 41.09 | 12355.91 |   449.94 | 12442.03 | 117.75 | 6424.68 |   459.09 | 6326.77 | 54.64 | 12365.87 |   468.24 | 12353.05 | 25.91 | 6307.27 |  

tatobari commented 6 years ago

@normanjw Did you manage to have it working more stable? I'm starting to think there might be an overflow problem somewhere in the code but I'm not sure. I'd have to wire everything up and run some tests.

tatobari commented 5 years ago

And error that caused overflows was fixed:

Not tested. Actually, I didn't even test the syntax. If you do, please let me know if you find any errors.

faurepa commented 5 years ago

Hello,

I downloaded the latest copy of the code and tried to run it. Python failed as it was trying to load the file.

Here is where it failed.

Traceback (most recent call last):   File "scale.py", line 4, in     from hx711 import HX711   File "/usr/local/bin/python/hx711.py", line 77     24BitMSBIndex = 1                 ^ SyntaxError: invalid syntax

Attached a copy of scale.py. I will try to find out, and will report back when I have more details.

Philippe

Quoting tatobari notifications@github.com:

And error that caused overflows was fixed:

  • Commit 22b6d7c[1]

  • Commit 4d3cb55[2]

    Not tested. Actually, I didn't even test the syntax. If you do,
    please let me know if you find any errors.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[3], or mute the thread[4].

Links:

[1]
https://github.com/tatobari/hx711py/commit/22b6d7cfa158a36dbabfa772c568fd9c9e310e09 [2]
https://github.com/tatobari/hx711py/commit/4d3cb558e7af6e167d4c5fac6e67b7e6721012c5 [3] https://github.com/tatobari/hx711py/issues/7#issuecomment-439168178 [4]
https://github.com/notifications/unsubscribe-auth/AZmjLPP31PqNQ6HSMgakLY36cbT0t_CPks5uvcWagaJpZM4LqjXX

faurepa commented 5 years ago

Hello Tato,

I found it.  Python doesn't support numbers at the beginning of
variables. So I swapped the variables and put the "24" and "32" at the
end of the variable instead of the beginning.

Now a new issue.

Traceback (most recent call last):   File "scale.py", line 21, in     hx = HX711(27, 17)  #1   File "/usr/local/bin/python/hx711.py", line 32, in init     self.set_gain(gain)   File "/usr/local/bin/python/hx711.py", line 48, in set_gain     self.read()   File "/usr/local/bin/python/hx711.py", line 67, in read     dataBits[j][i] = GPIO.input(self.DOUT) IndexError: list index out of range

Will keep working on this.

Philippe

Quoting tatobari notifications@github.com:

And error that caused overflows was fixed:

  • Commit 22b6d7c[1]

  • Commit 4d3cb55[2]

    Not tested. Actually, I didn't even test the syntax. If you do,
    please let me know if you find any errors.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[3], or mute the thread[4].

Links:

[1]
https://github.com/tatobari/hx711py/commit/22b6d7cfa158a36dbabfa772c568fd9c9e310e09 [2]
https://github.com/tatobari/hx711py/commit/4d3cb558e7af6e167d4c5fac6e67b7e6721012c5 [3] https://github.com/tatobari/hx711py/issues/7#issuecomment-439168178 [4]
https://github.com/notifications/unsubscribe-auth/AZmjLPP31PqNQ6HSMgakLY36cbT0t_CPks5uvcWagaJpZM4LqjXX

faurepa commented 5 years ago

Hello Tatobari,

I had a look at the commit for 22b6d7c Changing the self.LSByte definition from [ 2,-1,-1] to [3,0,-1]
wouldn't work, since the array "databits", is only a 3 x 8 array
(defined on line 61), which is addressed as follows.

  0 1 2 3 4 5 6 7 0 x x x x x x x x x 1 x x x x x x x x x 2 x x x x x x x x x

When runing through the j loop, range starts at 3, but it needs to
start at 2, which would explain why I get the "List index out of
Range" error.

What were you trying to fix with taht update?

Philippe

Quoting tatobari notifications@github.com:

And error that caused overflows was fixed:

  • Commit 22b6d7c[1]

  • Commit 4d3cb55[2]

    Not tested. Actually, I didn't even test the syntax. If you do,
    please let me know if you find any errors.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[3], or mute the thread[4].

Links:

[1]
https://github.com/tatobari/hx711py/commit/22b6d7cfa158a36dbabfa772c568fd9c9e310e09 [2]
https://github.com/tatobari/hx711py/commit/4d3cb558e7af6e167d4c5fac6e67b7e6721012c5 [3] https://github.com/tatobari/hx711py/issues/7#issuecomment-439168178 [4]
https://github.com/notifications/unsubscribe-auth/AZmjLPP31PqNQ6HSMgakLY36cbT0t_CPks5uvcWagaJpZM4LqjXX

tatobari commented 5 years ago

Sorry fellows, something went wrong. I'll check this tomorrow.

tatobari commented 5 years ago

Sorry Everyone! Lot's of things where wrong with this code. I had to refactor a lot of stuff. I rarely use Python. I usually work with NodeJS or C++ (for Arduino, barely). So, here are the updates on the last commit.

IMPORTANT NOTE: The typical green HX711 breakout board has a very big negative offset. The raw value is close to -8.000.000 (negative 8 million). As a result, you can apply a lot of force/weight to the load cell and this negative value will increase as you increase the applied force/weight.

However, if you apply a negative force (installing the load cell the other way round, inverting the load cell A- and A+ cables or pull up instead of pressing down), the values may get a bit crazy because an overflow happens. The green breakout boards have the HX711's electronic implementation like this for a reason which escapes me.

Anyway, I have schematics to reduce this offset (thanks to a real genius guy from Kiev, Ukraine). I'll see if I can publish them to people interested on fabricating their own breakout boards.

Sorry to everyone for the inconveniences caused and thanks for using this library.

PS: Next time, I'll work on a separate branch and test before committing.

faurepa commented 5 years ago

Thank you Tatobari, I will give it a try this evening.  I will use the latest version of the code, and set the reading format
as you indicated below. Yes, I have noticed the "odd" value, from time to time, and just try
to code around it.  I will see if it still occurs with the new code.

Thank you again for your help.

Philippe

Quoting tatobari notifications@github.com:

Sorry Everyone! Lot's of things where wrong with this code. I had to
refactor a lot of stuff. I rarely use Python. I usually work with
NodeJS or C++ (for Arduino, barely). So, here are the updates on the
last commit.

  • It works. HX711 returns a Two's Complement formatted signed
    integer. Until this commit, that wasn't supported and this resulted
    in nonsense values from time to time.
  • Use hx.set_reading_format("MSB", "MSB"). It's the default so
    you don't really need to change this unless you're using a device
    with reversed endian /(very rare cases)/. I realized I had a concept
    error and swapped the configuration of MSByte with LSByte.
  • hx.read_np_arr8() returns the raw response from the HX711.
    Until then, it hasn't been treated to support Two's Complement.

  • hx.read_long() is where the bits are handled to make the long
    negative if the returned value from the HX711 is negative. This is
    thanks to a global variable called self.isNegative which is
    calculated at the end of hx.read().

    IMPORTANT NOTE: The typical green HX711 breakout board has a very
    big negative offset. The raw value is close to -8.000.000 (negative
    8 million). As a result, you can apply a lot of force/weight to the
    load cell and this negative value will increase as you increase the
    applied force/weight.

    However, if you apply a negative force (installing the load cell
    the other way round, inverting the load cell A- and A+ cables or
    pull up instead of pressing down), the values may get a bit crazy
    because an overflow happens. The green breakout boards have the
    HX711's electronic implementation like this for a reason which
    escapes me.

    Anyway, I have schematics to reduce this offset (thanks to a real
    genius guy from Kiev, Ukraine). I'll see if I can publish them to
    people interested on fabricating their own breakout boards.

    Sorry to everyone for the inconveniences caused and thanks for
    using this library.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

Links:

[1] https://github.com/tatobari/hx711py/issues/7#issuecomment-439492173 [2]
https://github.com/notifications/unsubscribe-auth/AZmjLE1V8ZFuv-zuQRSxwXNXR1JzWL28ks5uvwqSgaJpZM4LqjXX

tatobari commented 5 years ago

Take into account that now, the idle value is very close to the 24-bit negative range limit value, so you'll need to recalibrate.

Thanks for the patience!

faurepa commented 5 years ago

Hello,

I used your code over the weekend.  I let it run for 650000 samples. 
I was trying ot see if the "odd" value would show up.  normally, I
would get an odd sample every 1000 samples or less.  Now it ran for
650000 without issues. I had a look at the code and I agree that the
median solution is better than the mean, that used to be used.

Now what I found strange was the distribution of the measured values. 
I was measuring a plastic cup (5.9grams) and the system wasn't doing
any other processing.

I have attached two plots. 1- a histogram for the distribution of the measured weights 2- a plot of the measured weights in the order in which they were acquired.

I was wondering if you had an idea of what might be causing this odd
drift in performance?

Thank you

Philippe

Quoting tatobari notifications@github.com:

Take into account that now, the idle value is very close to the
24-bit negative range limit value, so you'll need to recalibrate.

Thanks for the patience!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

Links:

[1] https://github.com/tatobari/hx711py/issues/7#issuecomment-439525621 [2]
https://github.com/notifications/unsubscribe-auth/AZmjLIdANN_cGnxA4HH7RrgtKMLrlWyXks5uvydLgaJpZM4LqjXX

tatobari commented 5 years ago

Hi Phillippe! If you attached the plots by email, then they aren't here. You have to post them on the page. Let me know if you can do it.

faurepa commented 5 years ago

Hello,

I thought that they were attached to the email. I will try to post them tonight.

Philippe

Quoting tatobari notifications@github.com:

Hi Philippe! If you attached the plots by email, then they aren't
here. You have to post them on the page. Let me know if you can do it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

Links:

[1] https://github.com/tatobari/hx711py/issues/7#issuecomment-440013313 [2]
https://github.com/notifications/unsubscribe-auth/AZmjLAtdm-hJQZgola4GD5XzPfR7rU5sks5uwwaBgaJpZM4LqjXX

faurepa commented 5 years ago

Attached to this comment are the two pictures from my comment a few hours ago Picture below shows the histogram distribution of the measured samples. screenshot2519

The following picture shows the measured value as they were acquired. I don't know why they drifted. screenshot2520

tatobari commented 5 years ago

@faurepa So, if you are referring to this upwards drift overtime which I very rudimentary pointed with a red "line" (I tried to draw a straight line) on this screenshot from your picture, then I think it's a "warm up" drift.

image

Both, the HX711 circuits and the load cell's resistors (load cells are Wheatstone bridges tend to gain heat overtime. Since we're dealing with resistors here, which basically dissipate heat, hence spoil energy reducing the power, this increase on the temperature affects the value read by the HX711's internal ADC.

Keep in mind that the HX711 is an "amplified ADC", which means it deals with millivolts and not Volts, which is a magnitude very sensible to almost everything.

Anyway, that's my best guess. I have this poorly evaluated idea that an external oscillator implemented on the HX711 circuitry could reduce these kind of imprecision issues but that's just a wild guess. I'll probably try it in the feature if I happen to find issues on the project I'm working on with a guy from Serbia that, to my understanding, doesn't actually know about electronics, he know black magic and therefore can design any circuit. I'd recommend him to anyone.

faurepa commented 5 years ago

Hello,

Thanks for the reply.  It wasn't the gradual drift that I was
concerned with, but the two spikes  found at 100000, and 400000 sample
roughly. I find it quite strange, since each measurement should be
independant of any previous measurement.

If I need a circuit, I will let you know.

Thank you for your help.

Philippe

Quoting tatobari notifications@github.com:

@faurepa[1] So, if you are referring to this upwards drift overtime
which I very rudimentary pointed with a red "line" (I tried to draw
a straight line) on this screenshot from your picture, then I think
it's a "warm up" drift.

[2]

Both, the HX711 circuits and the load cell's resistors (load cells
are Wheatstone bridges[3] tend to gain heat overtime. Since we're
dealing with resistors here, which basically dissipate heat, hence
spoil energy reducing the power, this increase on the temperature
affects the value read by the HX711's internal ADC.

Keep in mind that the HX711 is an "amplified ADC", which means it
deals with millivolts and not Volts, which is a magnitude very
sensible to almost everything.

Anyway, that's my best guess. I have this poorly evaluated idea
that an external oscillator implemented on the HX711 circuitry could
reduce these kind of imprecision issues but that's just a wild
guess. I'll probably try it in the feature if I happen to find
issues on the project I'm working on with a guy from Serbia that, to
my understanding, doesn't actually know about electronics, he know
black magic and therefore can design any circuit. I'd recommend him
to anyone.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[4], or mute the thread[5].

Links:

[1] https://github.com/faurepa [2]
https://user-images.githubusercontent.com/7002585/48748893-3dec3400-ec57-11e8-96f4-c4b9418503b3.png [3] https://en.wikipedia.org/wiki/Wheatstone_bridge [4] https://github.com/tatobari/hx711py/issues/7#issuecomment-440122442 [5]
https://github.com/notifications/unsubscribe-auth/AZmjLNcyjKV4KVJgEPIL5QhnKEOviaaSks5uw3N-gaJpZM4LqjXX

tatobari commented 5 years ago

@faurepa Oh! Ok, then, if I had to guess, this is an overflow issue. Questions:

  1. Is there any chance that your load cell is being affected by positive and negative forces (pushing and pulling)?
  2. Could you try reversing the A- and A+ cables of the load cell and see what happens?
  3. What is the idle raw value you're getting from the HX711? I mean, with hx.set_reference_unit(1), set_offset(0)) and no force being applied to the load cell?

Thanks!

faurepa commented 5 years ago

Hello, 1- I don't know what would have caused a .5g gradual shift, and then another gradual shift back again. Those samples would have been collected during the night, so I don't know what would have caused that. 2-, No, I wouldn't be able to complete that with these units, but I will give it a try on the next scale that I build. 3- I can try to re-run the test and output that record those values.

tatobari commented 5 years ago

Hi Phillippe,

1- I don't know what would have caused a .5g gradual shift, and then another gradual shift back again. Those samples would have been collected during the night, so I don't know what would have caused that.

What is your load cell's range?

2-, No, I wouldn't be able to complete that with these units, but I will give it a try on the next scale that I build.

Wouldn't be a waste of time to check that out at long as it isn't that complicated. Are the cables currently soldered to the HX711?

3- I can try to re-run the test and output that record those values.

This would definitely help a lot.

faurepa commented 5 years ago

1- 200g load cell 2- Yes, it is soldered, I will be building another unit, and can try at that point. Will have to get back to you on that one. 3- Hopefully this weekend

tatobari commented 5 years ago

  1. OK. 0.5g is not that much in a 200g load cell. It's only a +/- 0.25% accuracy error. Pretty much what you'd expect from a cheap ADC-A like the HX711. Other a bit more expensive ADC-As will definitely be more accurate. I don't know about the load cell, but that error is still small for pretty much most of the standard ones.

  2. Ok, thanks.

  3. Cool!

faurepa commented 5 years ago

Hello,

I have set the following: hx.set_reference_unit(1) hx.set_offset(0) hx.set_reading_format("MSB", "MSB") hx.reset() then ran a loop with the following: val = hx.get_weight(3)

I added to the hx711.py code a print statement on 106 (print dataBytes.) just so that I can get a little more information, than just the median value. thought it might help.

I removed all objects from the load cell. then I got the results as seen in the attached file. raw values 2018-11-25.txt

Just out of curiosity, I pushed down as hard as possible on the load cell to see what the MAX value would be and the following values were printed. (the number after the ":" is just a counter)

[255, 255, 127, 0] [255, 255, 127, 0] [255, 255, 127, 0] 8388607.0 : 12

I left the program running, and can get a larger sample set tomorrow if required, just let me know.

Thank you for your help.

Philippe

tatobari commented 5 years ago

Thanks for sharing the readings. Let's analyse this. From HX711 DataSheet:

Output Data Rate and Format [...] The output 24 bits of data is in 2’s complement format. When input differential signal goes out of the 24 bit range, the output data will be saturated at 800000h (MIN) or 7FFFFFh (MAX), until the input signal comes back to the input range.

About 7FFFFFh

About 800000h

Signs in 24-bit Two's Complement and 32-bit Two's Complement

The sign is the MSB (Most Significant Bit).

Note: I'm using X where there are no bits so that the text is aligned.

Now, 32-bit Two's Complement numbers have the following range:

Since the HX711 returns a 24-bit Two's Complement number, I need to make sure the my 32-bit Two's Complement number is not above or below the 24-bit Two's Complement range (MAX: 8388607 and MIN: -8388608.

Conversion

To convert the 24-bit Two's Complement into a 32-bit Two's Complement, I do the following:

  1. I get the Most Significant Byte, which is the one with the sign (SBBBBBBB BBBBBBBB BBBBBBBB).
  2. I check if the S bit is 1 or 0 and save this information in a variable called this.isNegative.
  3. Then I switch the S bit to a 0 so that now I've got BBBBBBBB BBBBBBBB BBBBBBBB.
  4. I add the extra byte so that we now have 32 bits. This byte I'm adding is now the Most Significant Byte: SBBBBBBB BBBBBBBB BBBBBBBB BBBBBBBB.
  5. I check this.isNegative and make sure the S bit is 1 for this.isNegative == True and 0 for this.isNegative == False.

uint32_t

This array has the bytes in reverse order, so [255, 255, 127, 0] corresponds to:

00000000 01111111 11111111 11111111 and this value is equal to 7FFFFFh (MAX).

Conclusion

This could mean one of the following things:

Theory 1: HX711 Implementation

For some reason, the load cell is saturating the HX711 with a signal higher than the supported range. Could you send a picture of the HX711 you're using and the load cell?

In this case, I'd check that the power supply is stable, that the load cell is in good shape and that there isn't anything creating unstable shortcuts on the circuitry.

The HX711's implementation could generate an offset which is positively too high. Being too strictly, each load cell should require a different offset resistor but we all buy the classic green HX711 breakout board or the red one from Sparkfun.

One thing that may give you a temporary solution is to swap the load cell input cables (A+ and A-) and see what happens. We would need to multiply the long value by -1 to get positive results.

Theory 2: Software issue (discarded)

If the bytes were [255, 255, 255, 0] we could say that the software is not handling the "not ready state" described on the HX711 Datasheet, which states:

Serial Interface [...] _When output data is not ready for retrieval, digital output pin DOUT is high. Serial clock input PDSCK should be low. When DOUT goes to low, it indicates data is ready for retrieval. [...]

However, you're values are [255, 255, 127, 0], not [255, 255, 255, 0], so this is not it.

faurepa commented 5 years ago

Hello, Here are two pictures of the board and load cell. Power is being supplied from the 3.3V rail of a PC power supply. img_20181127_213003 img_20181127_212902

tatobari commented 5 years ago

@faurepa I'd recommend that you rebuild your wiring from scratch. Those connections, as they are, will most certainly be unstable. Make sure you use proper connectors or, at least, 2.54mm pin headers with the corresponding connectors. Also, I'd recommend that you check some YouTube videos on how to solder and get the right tools, including flux, solder (with flux, 60/40, maybe) and all the necessary tools. There are many YouTube videos that you can watch to learn how to do this in a cleaner way.

I'm closing this issue.

faurepa commented 5 years ago

I am just curious why resoldering will stop the offset that I am seeing? I am just trying to understand.

Thank you

tatobari commented 5 years ago

Those are not spikes, those are out of range signals as I've explained before. Bad connections can cause that kind of issues.

Vrinda73 commented 5 years ago

Hello ! Thank you so much for this wonderful library. I was able to get some numbers from the load cells. However I am stuck at a point. I want to make a ROS topic which will display the weights from the load cell. When I go to do "import rospy" at the top of example.py , I get an error saying name 'rospy' is not defined. Please can you help me regarding this. Thanks much !

Vrinda73 commented 5 years ago

Hello ! I got it to work. I added #!/usr/bin/env python at the top of both example.py and hx711.py to convey to ROS that these are executable python scripts. I followed link to make a ROS node displaying the weights. I put the hx711.py in another package and example.py was placed in a script in my package.

Vrinda73 commented 5 years ago

Now , I realized that I want the data at min 80 Hz for my project. I don't know how to increase the frequency. Any help is appreciated. Thanks much !

inders commented 5 years ago

Was anyone able to get readings at 80hz, if so how? Any help/pointers would be highly appreciated.

tatobari commented 5 years ago

Hi @inders @Vrinda73 To use the HX711 at 80 SPS (Samples per second) you need to make a different electronic implementation of the IC (Integrated Circuit) on the PCB. It's not a software issue that a library con solve.

However, this library has only been tested at 10 SPS because at 80 SPS, the precision is significantly reduced and an external clock source such as an oscillator is needed. 10 SPS is already quite a good resolution. In case 80 SPS was needed, there are changes that should be made to this library in order to make it work.

In case you want more information, please, include a picture of your HX711 and how it is wired. That always makes it easier for me to answer questions.

parovelb commented 4 years ago

Hello Tato, First I would like to thank you for the code. It is working in a project of mine with an RPi2 and the green HX711. However there is the issue of unstable values at the output. I tried them all, from shielding to LDO, grounding, battery supplies, PC supplies, adding decoupling capacitors and filters but still no change. I a measuring 50g on a Tedea 1004 load cell. Here are some of the readings:

Original setup | GND to frame | 10nF on Vcc | -EXC to frame | LM1117DT-5 | hx711 shielded 0.00592323487601 | 0.0217185278787 | 0.85492023377 | 0.0197441162534 | 67.8244712675 | 67.529277496 0.011846469752 | 0.035539409256 | 0.702890538619 | 0.017769704628 | 67.8738347744 | 67.41574143 49.7847891328 | 0.0651555836361 | 0.693018480493 | 0.0710788185121 | 67.764247789 | 67.5006466619 50.0019744116 | 0.011846469752 | 50.4936029063 | 79.3812193966 | 67.7968277036 | 67.4641176668 49.8400726583 | 0.00987205812668 | 50.9042805244 | 50.6021955457 | 67.8491530209 | 67.5401374675 50.015795293 | 0.0848996998894 | 50.7522508293 | 50.2468014532 | 67.813611296 | 67.479913989 50.0552835255 | 1.0365661033 | 51.1115937451 | 50.0750276418 | 67.8600129925 | 67.4769521786 49.8637655979 | 52.4048333597 | 50.8944084663 | 50.0651555836 | 67.7454896564 | 67.7099479314 49.9032538304 | 50.094771758 | 50.8726899384 | 50.1619017533 | 67.8086749453 | 67.5352011168 50.0019744116 | 50.189543516 | 50.906254936 | 50.126362344 | 67.799789514 | 67.55790833 50.0059232349 | 50.1006949929 | 50.8134575896 | 50.110567051 | 67.813611296 | 67.5361883869 49.9407676512 | 50.1362344021 | 51.0108987522 | 50.031590586 | 67.813611296 | 67.5519847092 49.8993050071 | 50.1540041068 | 50.9832569894 | 50.2349549834 | 67.8195349168 | 67.5944373251 49.9269467699 | 50.2448270415 | 50.8509714105 | 50.2803664508 | 67.8432294001 | 67.5776537328 50.031590586 | 50.1638761649 | 50.8845364082 | 50.3435476228 | 67.7800441112 | 67.579628273 50.1520296952 | 50.2270573369 | 50.843073764 | 50.3711893856 | 67.7306806043 | 67.4700412876 50.0078976465 | 50.1145158743 | 50.8075343548 | 50.2408782183 | 67.7839931918 | 67.4947230411 49.9763070605 | 50.1184646975 | 50.8766387616 | 50.2764176275 | 67.8274330779 | 67.6339281307 49.8203285421 | 50.0809508766 | 50.9417943453 | 50.448191439 | 67.7899168126 | 67.6497244529 49.889432949 | 50.0513347023 | 50.953640815 | 50.0770020534 | 67.7721459501 | 67.6023354862

The values jump +/- 0.2 g. I can not find the cause. Would a software filter help?

caroline95-web commented 4 years ago

Hello Tato Thank you for your script. I am doing a calibration as well, and I have some troubles with my output since a get large signal value output interval from the raspberry 3. I have been calculating the signal values to kg, by using the linear equation y = ax + b.

But unfortunately, I get signal values from 28687 to -1508217, wich corresponds to -0.4 kg and 24 kg wich should not accrue since I only was adding 2.6 kg to my loadcell.

BTW: I chanced getweigth(5) to getweigth(1) and out commented I also commented out the power_down, power_up, and the time.sleep in example.py

Hope you can help:)

jayden540 commented 4 years ago

Hi Tato, firstly, thank you for creating this library. You mentioned that you got the HX711 to take 10 SPS. Currently I can only get it to take around 5 SPS with your program. Could you please let me know how to adjust the code to get it to take 10 SPS? Thanks.