HX711 produces noisy data with Boron

Hardware
1

Ever since I got my Borons 6 months ago, I’ve been having trouble getting good stable readings from my HX711 weigh sensors. With my Electrons, the readings were always rock-solid. This is a typical example of measurements using the HX711ADC library where I’m averaging 20 readings (constant weight, but no offset applied).
weight%20with%2020%20average
When I reduce the number of times the data are averaged to 1 (i.e. no averaging), the output is considerably more stable, but the outliers are greatly exacerbated (constant weight, offset applied). Clearly the risk of a bad data point increases with the number of reads.
BB1%20with%20filtering
I have investigated many possible causes, incl.:

  1. RF interference. I’ve experimented with placing the antenna at increasing distances from the Boron, incl fitting external antennas up to 3m away. No difference.
  2. Tried different Borons (six) – no difference
  3. Tried different HX711 ADC’s (eight) – no difference
  4. Tried different strain gauges (six) – no difference
  5. Tried different libraries (both Particle community libraries as well as a library I uploaded myself. Used standard example code too – no difference
  6. Tried slowing down the rate at which bits are clocked in. This is apparently a problem with MCUs which have fast clock speeds (see here). However, as I understand it, the Boron’s clock speed is slower than the Electron (64MHz vs 120MHz resp)? In any case, adding extra 1ms delays between clocking in bits did not stop the outliers.
  7. Tried swapping pins on the Borons (from D3 and D4 to A2 and A3) - no difference
  8. Tried filtering out bad data points with an IF statement. That helped considerably but new bad values still occur, and besides, this doesn’t get to the root of the problem.
    At this stage, I’m out of ideas as to what could be causing the outliers and what the fix might be. Has anyone else been having problems with Boron and HX711 outliers? Any help greatly appreciated!
1 Like
2

Hi, did you ever identify the cause of the problem?

3

No, not yet! I’m still keen on hearing from anyone who is using the HX711 weigh sensor with any of the mesh devices.

4

I don’t have a definitive cause or solution yet, but thanks to @blub, I do have an adequate work around. The work around involves using median values to effectively filter out the spikes. See post #46647.
Some sample data to show how well it works:

Single_raw Av_raw (50) Median_raw(50) Calibr_Wt (kg)
-55 516215 -51 0.00
-32 50972 -15 0.00
8307487 22228 -1 0.00
-2 59 8 0.00
-30 254021 -29 0.00
87 48455 -9 0.00
-81121 23 12 0.00
-41 20 -6 0.00
-81121 9980 -12 0.00
-38 -6 -26 0.00
-6 415389 -1 0.00
-11 65 -32 0.00
69 415412 -10 0.00
-55 22235 6 0.00
76 22 9 0.00
19 5 1 0.00
-81121 27 0 0.00
-50 857 8 0.00
2 205729 18 0.00
-10 30 51 0.00
-20 23094 31 0.00
-81121 100 54 0.00
51 2560 74 0.00
64 2575 33 0.00
89 -4008 47 0.00
77 22222 39 0.00
-26 214931 57 0.00
63 424561 32 0.00
10 59 48 0.00
26 100838 71 0.00
64 45 43 0.00
72 9332 40 0.00
25 57480 28 0.00
-81121 2632 60 0.00
102 63 56 0.00
53 32 66 0.00
40 96815 51 0.00
103 48410 51 0.00
34 621085 46 0.00
14 22232 54 0.00
8307487 75 78 0.00
4113183 129 59 0.00
114 353 110 0.01
113 191 130 0.01
213 145 139 0.01
202 415490 118 0.01
145 195 147 0.01
77 172 135 0.01
86 1086 119 0.01
169 1075 132 0.01
162 2665 140 0.01
212 135 130 0.01
8307487 233 155 0.01
8307487 141 135 0.01
159 148 149 0.01
119 133 137 0.01
152 268 139 0.01
108 161 118 0.01
5

I believe I’m having the same issue, but I’m using an Argon instead of a Boron. I discovered the fast clock speed post as well before finding this thread, but like you, when I tried the adding the delays, it didn’t help.

I’m at the point where I’m filtering out the extremely bad data points with an if statement, but it still would be better to get this solved.

6

Have you tried wiring the sensor with a shielded cable and connecting the drain (bare, usually silver colored) wire only at one end to ground? This is designed to EM interference to ground.

7

Thanks for the suggestion. No, I haven’t tried a shielded cable yet. At this point, I’m actually suspecting the HX711 is getting into a bad state, because when I see a bad reading, it takes several hundred milliseconds longer before the ready signal is asserted again.

I think the next step needs to be check the signals with a scope to see what is happening.

8

Maybe someone here can get to the bottom of this. I am experiencing the same problem for months now. I have put a bandage ever the problem with a median calculation, but I am unhappy with the bug. I have tested the code I am using separately on an Arduino Uno and I get perfect results. Once I replace the Arduino with my Boron, the bug emerges.
For anyone experienced with the HX711 library, I have made an observation which may point towards the problem: The time it takes to take the reading increases while reporting a bogus data point. Please see the attached image.

Boron_HX711_output
Boron_HX711_output437×984 5.8 KB

This Output was regenerated using this short Code:

#include <HX711ADC.h>
#define calibration_factor -7050.0 //This value is obtained using the SparkFun_HX711_Calibration sketch
#define DOUT  3
#define CLK  2

HX711ADC scale;

long time1 = 0;

void setup() {
  Serial.begin(9600);
  Serial.println("HX711 scale demo");

  scale.begin(DOUT, CLK);
  scale.set_scale(calibration_factor); //This value is obtained by using the SparkFun_HX711_Calibration sketch
  scale.tare(); //Assuming there is no weight on the scale at start up, reset the scale to 0

  Serial.println("Readings:");
}

void loop() {
  
  time1 = millis();
  Serial.print(" Reading: ");
  Serial.print(scale.get_units(), 1); //scale.get_units() returns a float
  Serial.print(" kg      Time to take reading = "); //You can change this to kg but you'll need to refactor the calibration_factor
  Serial.print(millis() - time1);
  Serial.println();
}

Can anyone give me a few suggestions as to how to address this?
Thanks.