ggurov / hx711 Goto Github PK

raspberry pi hx711 weight scale interface

C 85.41% C++ 14.18% Makefile 0.41%

hx711's Introduction

HX711
=====

raspberry pi HX711 weight scale interface
-----------------------------------------

this thing interfaces with 24-Bit Analog-to-Digital Converter (ADC) for Weigh Scales
https://github.com/sparkfun/HX711-Load-Cell-Amplifier/blob/master/datasheets/hx711_english.pdf

http://www.amazon.com/SMAKN-Weighing-Dual-channel-Conversion-Shieding/dp/B00FVGRZ42 = $10

Compile by running make, which effectively does: 
	gcc  -o HX711 HX711.c gb_common.o

Run it like so:

First time

./hx711 

It will display a bunch of stuff:

root@bare-rasberripi:~/hx711# ./hx711
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1 1 1 1 1 0 0 n:       7672     -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 1 1 1 1 1 0 n:       8060     -

*SNIP* 

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 1 1 1 1 n:       8126     -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 1 1 1 1 1 1 n:       8062     -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 0 1 1 1 n:       8142     -
8038

The final number is the 2nd average after throwing out out of range readings.

If there's nothing on the scale, this is the zero, tare, whatever. the number itself is a 24bit representation that comes off the converter.

Running it like so:

root@bare-rasberripi:~/hx711# ./hx711 8038
-66
root@bare-rasberripi:~/hx711# ./hx711 8038
-87
root@bare-rasberripi:~/hx711# ./hx711 8038
-138

With the argument being the average, removes the debug info, and subtracts the 1st argument from the 2nd average. 
Effectively, this is the actual weight reading around 0

In the example above, it is negative, which is entirely normal. The load cell will drift 
depending on temperature and humidity.

To actually be able to convert to any usable reading, you would have to calibrate the scale 
using a known weight. Easiest thing to do is to use water and a measurement cup. Once you have a few readings at uniform increments
you can determine how heavy "1" is. 


some code has been borrowed from the gertboard distribution to define the memory locations for GPIO_SET, CLR, and IN0, gpio setup, etc. 

at the top of HX711.c there two defines:

 #define CLOCK_PIN       31
 #define DATA_PIN        30
 #define N_SAMPLES       64
 #define SPREAD          10

CLOCK pin goes to PD_CLK (pin 11 on HX711, and SCK pin on shield)
DATA  pin goes to DOUT (pin 12 on HX711, and DT pin on shield)
N_SAMPLES is the number of samples read from the board
SPREAD is percentage around the average that defines a valid reading, the readings are averaged twice, first time to get a basic average,
       and 2nd time to get a better average that's within the SPREAD % (over/under).

on my raspberry PI, i have this hooked up to the unpopulated P5 header (+5v, GND, GPIO30, GPIO31)

I tested this with Etekcifty 5kg scale (http://www.amazon.com/gp/product/B00DGLU1SG = $10)
open up the scale, gut the electronics, and the battery crap from the case, and you end up with the load cell element, nicely positioned with a base, etc)
This will work for basically any weight scale you can find, most of the work on the same principle.
The load cell has 4 wires coming out of, they are colored: red, black, white, green.

The header on HX711 shield are, hook the load cell wires up to 
E+ - red
E- - black

A- - green
A+ - white

I have no idea how to hook it up to 3 wire load cells, normally found in the bathroom floor scales. But there are only 3 wires, so it can't be too difficult.

One note to keep in mind, this code is designed to run at 80 samples per second, the shield comes defaulted to 10 samples per second, This will manifest itself as
the whole process taking a fairly long time to complete. 

To switch to 80 samples per second, one has to desolder the RATE pin from the pad it's soldered to, lift it and solder it to +vcc on HX711 shield (pin 15). 
By default, this pin is grounded, which sets HX711 to run at 10 samples per second

Inherent problem with raspberry PI's gpio and talking to something that requires strict timing like the HX711 chip, is that linux running on the raspberry pi 
is not a realtime operating system. This can cause errors here and there, so there's a few safeguards in the code to reset the chip, etc etc.

hx711's People

Contributors

Stargazers

Watchers

hx711's Issues

no close /dev/mem

we need a "close(mem_fd)" at last, don't we?

Changing data rate selection on HX711

Howdy,
I read through your README file and I noticed the part the explains how to change the data rate

To switch to 80 samples per second, one has to desolder the RATE pin from the pad it's soldered to, lift it and solder it to +vcc on HX711 shield (pin 15).
By default, this pin is grounded, which sets HX711 to run at 10 samples per second

But I am confused as to where the RATE pin is on the HX711. And then also where exactly to solder on the VCC pin. Pictures would be great.

Thanks
Karl

Warning: implicit declaration of function 'usleep'

To get ride of this warning and get the program running I've to add in hx711.c the line:
" #include <unistd.h> "

read data when falling edge on sck, rather than rising edge

here:

for(i=0;i<24    ; i++) {
SCK_ON;
b++;
b++;
b++;
b++;
    if (DT_R > 0 ) { count++; }
    SCK_OFF;
b++;
b++;
b++;
b++;
    count = count << 1;

}

the Code read DT_R on rising edge, but hx711 datasheet says data availiable on falling edge, so read DT_R should put behind SCK_OFF.

And shift count should put before count++, or last bit will always be 0 and count doubled.

Another bug is

 for (i=32;i;i--) {
       printf("%d ", ((count-offset) & ( 1 << i )) > 0 );
  }

when you shift 32 times, you get 33rd bit in count.

I use your code for some time with success, weighting bee hives using Raspberry Pi B+, hx711 and low-cost weight sensors. So far, so good. But now I found out, that if something goes wrong with (probably) my wiring (Pi to hx711), cpu of Raspberry goes to 100% and is almost not responding etc...

How can one modify hx711.c for such a case? I tried to find out myself, but my programming skills are not good enough to manage it ;-)
After some testing I think that problem is in/near reset_converter(); just before reading first bunch of data...

Can someone help me, please?

Thanks. #kabjar

Timing problems in communication

Your code has trouble with timing the communication with the HX711 and you make a heroic effort to clean up the dirty readings. Timing is a tricky problem to solve but it has been solved very well in the pigpio library which can be used directly from c but also via a daemon and from other languages. There's even a an example HX711 reader written in python.

When I used your code it mostly worked but gave quite slow and erratic readings. When I used the pigpio code it was absolutely rock solid - and fast (frequent completion of readings) too.

So the issue: can you modify your code to use the pigpio library? It'll provide the timing-sensitive functions while your code already does the higher-level work.

Channel A (load cell) and Channel B (pyranometer) simultaneously?

I can read my load cell on channel A. But I want to read a pyranometer on channel B simultaneously.

How can I read two things at once? I do not get to read anything on channel B

Thank you

Getting error after make

Hi! Thanks for sharing this great project! I'm also a big fan of hivetool as a whole!

I'm getting the following errors after cloning the project to local folder and running make:

gcc -o hx711 hx711.c gb_common.o hx711.c: In function ‘main’: hx711.c:127:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=] printf("%d\n", (tmp_avg2 / j) - offset); ^ hx711.c: In function ‘read_cnt’: hx711.c:215:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=] printf("n: %10d - ", count - offset); ^ /usr/bin/ld: gb_common.o: Relocations in generic ELF (EM: 40) gb_common.o: error adding symbols: File in wrong format collect2: error: ld returned 1 exit status make: *** [hx711] Error 1

I'm using make correctly? Can I solve this issue by changing the int variables to long int ones?

Thanks in advance!

EDIT: I've managed to "make" it with gcc inside raspberry pi. It compiled as well. You can close this thread. Next step is to see why I'm getting "No data to consider errors". But I'm still trying to see if I've connected the pins the right way (still a bit confused using BCM I/Os on Rasp2 model B v1.1.

EDIT2: I've realized that pins in .c code were in "Board Numbering System", instead of "BCM Numbering system". On a raspberry 2 I've managed to wire the Dout and Sck into 12 and 11 board pins, respectively. Instead of "No data to consider" message, I'm receiving no output. The command line simply awaits for the command to respond. I think those pins are used for other thing on raspberry pi interface, which I'm going to use 37 and 38 Board pins, instead, to confirm that.

EDIT3: Implemented the commit from ComSubVie, which contained changes for the Raspberry PI. Now, all implementations and wirings just output "no data to consider". I feel that now I'm getting there.

Failing to read (No data to consider)

Hi,
I've connected an HX711 to my Pi, CLOCK on BCM pin 20 (J8-38) and DATA to BCM pin 16 (J8-36). I keep getting mostly what seems to be random reads, full of '1's, like this:

0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 n: -2 -
0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 1 1 0 1 1 1 1 1 1 1 n: -12546 -
0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 n: -262154 -
0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 1 0 0 0 0 n: -28704 -

The application then displays the "No data to consider", as expected due to the randomness of the reads.

The code has been changed accordingly (when I tried without updating the code, my Pi just hang and I had to disconnect the power supply to restart it).

I'm using a Raspberry Pi B+ and the exact same hardware configuration (HX711+Load Cell) works fine with Arduino.

Any idea of what could be wrong?

Regards,
Luiz

Got two data versions

Hello, I have got two data versions when I use it:
Is there any way to filter one version and keep only the second?
Warning: Unable to set high priority
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 n: -8288208 -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 1 1 0 1 n: 100378 -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 1 0 1 0 1 n: 100458 -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 0 1 0 1 n: 100426 -
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 n: 100352 -
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 n: -8288192 -
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 1 1 1 1 n: -8288162 -
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 n: -8288196 -
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 1 1 0 1 0 n: -8288140 -
0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 0 1 0 1 n: -8288214 -
No data to consider
Is it because it uses 100% of one core?

Why polling on DT_R?

I saw you poll on DT_R like following:

while( DT_R );

That's so bad for CPU usage.

You should at least insert a wait instruction inside the cycle in order to let the CPU free for other tasks.

But there's a better way: using WiringPi library you can use interrupts on data pins, so you can register a function for being called when the pin DT_R changes state with likely no CPU overhead.

I think i'll have to rewrite this library using WiringPi. That's a pity :(

Also I compile que hx711.c with different pinout:

define CLOCK_PIN 30

define DATA_PIN 28

But the response is the same all time.

I attach the picture of my raspberry and the sensor

Any help?

ggurov / hx711 Goto Github PK

hx711's Introduction

hx711's People

Contributors

Stargazers

Watchers

Forkers

hx711's Issues

define CLOCK_PIN 30

define DATA_PIN 28

Recommend Projects

Recommend Topics

Recommend Org