SparkFun Forums 

Where electronics enthusiasts find answers.

Questions &/or issues related to products in the Flex / Force category should be posted in this forum. includes Force Sensitive Resistors, Load Cells & Amplifiers, Pressure Sensors, etc
By ian759
#201878
Hello.

I am currently working on a project involving an OpenScale board and an Arduino for readings, and I'm having trouble with report rates.

I have cut the rate jumper from the OpenScale board to get an increased report rate as stated on the SparkFun OpenScale tutorial. However, I continue to get reads approximately every 100 milliseconds, as if the jumper wasn't cut. In comparison, an accidental upload of the above code to the Arduino board produces reads approximately every 4 seconds. When connected to the OpenScale board, the reads are extremely erroneous, ranging from -5 to 20 on no load. The output also freezes every few reads for about a second before resuming when the two are connected and powered via Arduino.

The two are connected through power, ground, and defined RX/TX ports as per a modified version of the code from https://www.electro-tech-online.com/art ... scale.859/. The only modifications are increased calibration values and some commented out lines of code in the readOpenScale() function.

Some additional information:
- The load cell is a 100 kg load cell in a 5 wire configuration
- Disconnecting the Arduino from the OpenScale board removes the freezes from the output but keeps the reads static
- The boards are powered by USB, except for the OpenScale when running the code on the Arduino (Run from 5V pin in that case)

I am fairly certain that the Arduino plays no part in the issue and could be removed if necessary, so any help with increasing the report rate on the OpenScale would be appreciated. Thanks.
By languer
#201881
The code on the electro-tech tutorial invokes averaging from the "HX711.h" driver, to provide more stable readings, which could limit the update rate. If you load the code from the electro-tech tutorial as-is; does the OpenScale work?

The averaging function is "mentioned" on SFE's Hookup Guide: "Average amount - This controls how many readings to average across. The default is four. Decreasing the average amount will allow for faster report rates but will increase the noise in reports." - In the electro-tech tutorial the averaging was actually set to 8 to get smoother results.

The code on the tutorial was tested independently on the following post (https://forum.sparkfun.com/viewtopic.php?f=14&t=48362) and served as launching point for much faster sample rates, so the initial question of "If you load the code from the electro-tech tutorial as-is; does the OpenScale work? " should provide some good groundwork.
By ian759
#201886
Hi langue, thanks for the reply.

I loaded the code from the electro-tech tutorial as-is, like you suggested, to see if the OpenScale worked. During the calibration sequence, it is producing reads at about the same rate as before during the calibration sequence. My modified code removed the delay in the readOpenScale() function, so I can't really say much about that.

I tried to change the average amount from 8 to 1 and observed no change.

Edit: I removed the delay and set the average amount to 1 and observed readings about 90 milliseconds apart. This was about the same as I observed before, and my previous runs on the Arduino were about 10-15 milliseconds apart. Is this unrealistic for the OpenScale?
By UhClem
#201888
The jumper changes the conversion time on the HX711 but nothing else.

You will have to tell the firmware the new higher reporting rate for anything to change. The SparkFun code checks to make sure that the requested rate is compatible with the serial data rate and sensors so be sure to use something higher than 9600bps.
By ian759
#201892
UhClem wrote: Wed Jan 30, 2019 10:08 am The jumper changes the conversion time on the HX711 but nothing else.

You will have to tell the firmware the new higher reporting rate for anything to change. The SparkFun code checks to make sure that the requested rate is compatible with the serial data rate and sensors so be sure to use something higher than 9600bps.
Thank you for this clarification. How would I do this using the program from the Electro-Tech link above? I have already set the serial data rate to higher than 9600.
By UhClem
#201893
The rate appears to be determined by "delay(1000)". Adjust as required.
Code: Select all
/************************* READ HX711 *********************************/
void readOpenScale() {
  Serial.print("Reading: ");
  Serial.print(scale.get_units(AVG_FACT), RESOLUTION); //scale.get_units() returns a float
  Serial.print(" grams");  //grams or kilograms depending on load cell
  Serial.println();
  delay(1000);
}
The code to read the HX711 has to wait for data to be available (data pin goes low) so if you remove the delay, that is what will set the reporting rate. That and the averaging.
By ian759
#201898
UhClem wrote: Wed Jan 30, 2019 1:32 pm The rate appears to be determined by "delay(1000)". Adjust as required.

The code to read the HX711 has to wait for data to be available (data pin goes low) so if you remove the delay, that is what will set the reporting rate. That and the averaging.
So from what I understand, removing the delay will give me the fastest rate possible, and cutting that jumper only increases the number of samples per reading. I guess I will have to make do with what I have. Thank you for the help!
By UhClem
#201899
No. The jumper sets the conversion rate of the HX711 to either 10SPS or 80SPS. The rate at which results are reported depends on other things: how long of a delay between loop iterations and how many samples are averaged into one report.

Delay long enough and you will miss samples. With a delay of 1000ms you miss a lot of samples and get a maximum reporting rate of 1SPS.

With no delay and averaging 4 samples the reporting rate would be either 2.5SPS or 20SPS, depending on the jumper.

But even at 80SPS don't expect much in the way of frequency response. The HX711 was designed to measure static loads.