Anyone with SparkFun OpenScale experience?

This is a hardware question, so I posted here. I’ll move it to Off-Topic later if required.

At the moment I’m using an Arduino Uno board attached to a load cell + load cell amp. I’ve written code in Xojo Desktop which records incoming data via the usb port and creates a graph for evaluation - this is all working pretty good.

However, I need to get others to test the software + hardware together. Creating another Arduino based “hardware device” is more complicated than needed. Someone put me onto the SparkFun OpenScale board which already has a built in amplifier (HX711) which seems like a simple solution for my purposes.

It’s a bit of a pain to setup and I don’t want/need the user to have to do this. From what I understand new code/firmware can be uploaded. This is the part I’m struggling with. There is not a lot of info out there about this device. I’ve asked questions on the SparkFun Forum but thought I would ask here as well.

If anyone has some experience using OpenScale, then I’ll ask some relevant questions and explain what I need it to do.


for me it is a simple arduino with a 24 bits adc. pretty sure you upload the firmware like you program an arduino ?

Hi Steve,

I haven’t had a chance to work with the OpenScale board yet. I am interested in working with the load cell and load cell amp. Could I ask for you to let me know which load cell and amp you are using? I’ll order the parts and see if I can build a driver for them.

If the documentation is poor for the SEN-13261 then it may be difficult to build a driver, and I’ll give it a try. Building drivers for individual components (load cell and amp) is much easier than building a driver for a system board (OpenScale) which usually is because of poor or lacking documentation.

It usually takes two-weeks or so to get the parts once ordered.

I’ve changed the channel to off-topic.

That does seem to be the case Jean-Yves. The problem I’m having is finding libraries that I can use - or that work for the HX711 or the OpenScale. I did read that a particular library that I need may require an earlier version of the Arduino IDE. There is not much info out there. I’ve asked the question on the Sparkfun forum - no replies after a few days. :frowning:

It’s been around 2 1/2 yrs or more since I wrote the Arduino code, so getting back into looking at what I did then, took a bit or remembering. Although, the initial Arduino code is only about 15 lines of code. Very simple.

[quote=397385:@Eugene Dakin]Hi Steve,

I haven’t had a chance to work with the OpenScale board yet. I am interested in working with the load cell and load cell amp. Could I ask for you to let me know which load cell and amp you are using? I’ll order the parts and see if I can build a driver for them.

If the documentation is poor for the SEN-13261 then it may be difficult to build a driver, and I’ll give it a try. Building drivers for individual components (load cell and amp) is much easier than building a driver for a system board (OpenScale) which usually is because of poor or lacking documentation.

It usually takes two-weeks or so to get the parts once ordered.[/quote]

Cheers Eugene. The load cell and amplifier were purchased off ebay. Chinese made and cheap. I don’t have the links to where I purchased them from (2 1/2 years ago). The load cell in the hardware prototype (below) is 40kg max. In the end I’m getting 1 gram resolution over 32 kilos.

If you are interested about the device, then I suggest having some alcohol (or a cup of tea), laying back, and read the link:

The device was built first, and I used the Arduino serial monitor to get readings. I then looked around for software to enable me to create a solution, ie. record data, evaluate, edit and draw a graph. I ended up using Xojo. :slight_smile:

The OpenScale is much simpler than what I’ve used in my prototype, and much smaller as well (also only requires one power supply, ie. usb port). The only negative is the 80Hz resolution - but for a simple device used for beta testing, then it’s perfect. I just can’t sort out how to get it up and running in the way I need.

[EDIT] Well of course the images don’t work in the link above unless you sign in. However, the video in post #6 seems to work fine.

This one is very similar to the load cell amp I use:

This Parallel Load Cell is similar to the one I’m using:

Thanks for the links and additional information Steve.

Parts are ordered and I am looking forward to the parts so that I can play :slight_smile: The video is good and I will drop something (tennis ball?) and do a impact/response test to see what the values are.

I see what you mean about the 80 Hz resolution, that works out to a reading of every 12.5 milliseconds which seems a little slow.

There are a couple of options to graph the data: 1) Excel , or 2) Roger Mieres Dataplot Classes at Dataplot

A tennis ball won’t be any good - there is too much give. You need a small steel ball or similar dropped onto a very hard surface. Mine were done from around 30cm height.

Post #13 in the link above give details about how the tests were done. This is basically the same response test graph:

I’m aware of Rogers Dataplot classes, but I wanted my own custom look. Hence the creation of the SRS (Stark Reality Solutions) Impulse Recorder Software :slight_smile: :

Here’s the hardware:

SFE’s OpenScale’s board seems to be built around their HX711 load cell amplifier. The library seems to be pretty straight forward. Did you take a look at the information for the HX711 and the examples on how to use it.

Some useful comments from the HX711 library:

[quote]How to Calibrate Your Scale
1.Call set_scale() with no parameter.
2.Call tare() with no parameter.
3.Place a known weight on the scale and call get_units(10).
4.Divide the result in step 3 to your known weight. You should get about the parameter you need to pass to set_scale.
5.Adjust the parameter in step 4 until you get an accurate reading.

Applicable library links:
Original HX711 Library
SFE’s HX711 Library

Thanks Langue,

I ended up removing the libraries I had and downloaded the ones from your links above.
I’ve been mucking around for a couple of hours and not getting anywhere.

I’ve opened the supplied HX711_Calibration code, uploaded it, ran it and don’t get any readings, well I mean I get zero. Seems a bit odd not to get something.

I get:
Reading: 0.00 kg calibration_factor: -7050.00

I’m aware that the calibration_factor is the one that needs changing to suit MY load cell, and the number does change when using the + or - keys, but the reading doesn’t.

With the original firmware I was at least able to tare and calibrate and get a reading, albeit not in the exact format I wanted.
It was sort of close - for a weight of 353 grams I was getting 3.53 kilos formatted as:

I thought if I could multiply the reading by 100, remove the decimal point, commas and the text kg, then I would end up with what I need:
353 (grams is assumed)

This is the Calibration code and uses steps similar what you posted above. I thought I would start with that, then modify it.


#include “HX711.h”

#define DOUT 3
#define CLK 2

HX711 scale(DOUT, CLK);

float calibration_factor = -7050; //-7050 worked for my (HIS) 440lb max scale setup

void setup() {
Serial.println(“HX711 calibration sketch”);
Serial.println(“Remove all weight from scale”);
Serial.println(“After readings begin, place known weight on scale”);
Serial.println(“Press + or a to increase calibration factor”);
Serial.println(“Press - or z to decrease calibration factor”);

scale.tare(); //Reset the scale to 0

long zero_factor = scale.read_average(); //Get a baseline reading
Serial.print("Zero factor: "); //This can be used to remove the need to tare the scale. Useful in permanent scale projects.

void loop() {

scale.set_scale(calibration_factor); //Adjust to this calibration factor

Serial.print(“Reading: “);
Serial.print(scale.get_units(), 1);
Serial.print(” kg”); //Change this to kg and re-adjust the calibration factor if you follow SI units like a sane person
Serial.print(" calibration_factor: ");

char temp =;
if(temp == ‘+’ || temp == ‘a’)
calibration_factor += 10;
else if(temp == ‘-’ || temp == ‘z’)
calibration_factor -= 10;
I would have thought it should work.

Maybe I’ve got an older or new version of the HX711 library?

Well I did have a bit of a win of sorts - a “happy accident”.

After fiddling around with the new code (which I couldn’t get working) I decided to reset the device and do a double check to ensure all was working as it did previously. The instructions for a hard reset didn’t work (ie. grounding rx on restart).

So then I realised I had no firmware code whatsoever to upload to get it back to it’s original state!!

So I found some code online (the original firmware - I think) uploaded it and everything was reset back to normal and my original code was reinstated and working as it was yesterday.

After going through the tare and calibration sequence all was looking good. I turned it all off. Checked again, then I realised that it now retained the tare point and the calibration!!! :slight_smile: which was one of the absolute requirements.

So now I’m left with the format (0.00,kg,…3.53,kg, etc…) . I “could” in a rather “grubby” method just strip the unwanted characters in Xojo. Afterall it is coming in a string of characters. I’d prefer not to do it that way, but trying to decipher the firmware code (approx. 10 x A4 pages long!) and determine the point where the code can be changed, would be a hard task.

It’s a means to an end. That is, there is no way I’m going to make another hardware prototype as in that last image posted. This HX711 device is only for the purpose of a user to test the software with a “substitute” hardware device. They’ll use their fingers to press on the load cell, they won’t be mounting a rocket motor. It’s about how the software, help system and hardware work all together.

I will however give myself a few days (hours) and look into the HX711 commands as suggested by Langue and see if I can nut it out. I’d prefer not to have the “grubby/dirty” method.

Thanks Steve, I’ll use a metal ball to test the scale.

I left the following on the SFE forum. I think it should work to just read stuff without any fluff.

Example HX711 code using OpenScale

This example demonstrates basic scale output. See the calibration sketch to get the calibration_factor for your
specific load cell setup.

Arduino pin
3 -> HX711 CLK (modified to work with open scale, use pin 2 for HX711 breakout)
2 -> DAT (modified to work with open scale, use pin 3 for HX711 breakout)
5V -> VCC


#include “HX711.h”

#define calibration_factor -7050.0 //This value is just a guess for this example

#define UNITS_KG 0
#define UNITS_LBS 1

#define DOUT 3
#define CLK 2

HX711 scale(DOUT, CLK);

void setup() {
Serial.println(“OpenScale demo”);

scale.set_scale(calibration_factor); // This value was the gues from before
scale.tare(); //Assuming there is no weight on the scale at start up, reset the scale to 0


void loop() {
Serial.print(“Reading: “);
Serial.print(scale.get_units(), UNITS_LBS); //scale.get_units() returns a floatl units will be in LBS
Serial.print(” lbs”); //You can change this to kg but you’ll need to refactor the calibration_factor, or this can be omitted alltogether

Thanks for posting that code Langue. Unfortunately it was unsuccessful. However, I did get things working by finding the point and editing the code, the original long (very long) pages of code. I got rid of the formatting and now have just basic data, ie. grams being presented to the serial bus. This is good.

However, now that that has worked, I’ve changed the sample rate to 80Hz (which is what I want) and have seen some weird readings. I’ll try to be brief.

I get some “random” readings which are way off scale. Everything else if perfect, but within a period of a minute or so recording, there can be 3 to 4 samples that are way off, like -3,995 grams, or +17,591 grams etc. Although not many, I can’t use it this way.

I can’t see that this is a software issue, to me that’s a hardware fault. I’ll continue this conversation in the SFE forum if I still have the mental strength (I’ve put too much time into this) and I do appreciate your time.

Yep, a good idea Eugene. I am intrigued by exactly what it is you are doing.

The tests I did were reasonably precise. I made an apparatus to hold the steel ball. I used a magnet, then pulled it away to ensure that the ball dropped from the same height (+/- 0.1 mm I would say). Posted below is the final results. An average of 10 tests at each sample rate.

The results are very clear. A higher sample rate has more of a chance of recording the impact of when the ball hits the load cell, and when the AD conversion is taking place.

Although, it does throw up a few questions regarding chance and probability. There is no reason that after doing 10 tests of each that the ball hitting the load cell just happened to strike at the exact same time the ADC reading was taking place (at 100Hz) and with the 250Hz tests, the ball hit the load cell inbetween when the reading took place.

If that happened (which it could), then the above graph would look the opposite, and I would be wondering why. (but I now do know why).

Fortunately the tests confirmed what I thought. You can clearly see the “overthrow” with the 250Hz tests (red line). The load cell was loaded with 400grams (for both tests) and the mass itself is moved. This aligns with the “theoretical”, but given a number of tests, then by pure chance, I can’t see why the results couldn’t show the opposite at the “right” point in time.

If you get what I mean.

I am going to attempt a couple of different ways to get the data, and I am not sure if any of them will work :slight_smile:

  1. Attempt #1 will be to use the Load Cell and Amp and build a driver with Xojo that may work at a higher sampling rate. My guess (which could be completely wrong) is that I’ll be able to get up to 1000 Hz.
  2. If the above doesn’t work, then I’ll try and build a driver for the OpenScale board. This may take considerably more time, as I’ll be trying to convert C code to Xojo.

I won’t be able to preload the load cell and I’ll drop the steel ball at 30 cm. Is the weight of the steel ball 1-gram?

I see what you mean about the overthrow of the load cell, which seems to be the rebound of the cell when the load has been removed.

Your SRS graph looks very professional, well done! I am very impressed at the granularity of the waves near the end of the graph at about 2.10-2.46 seconds, as there seems to be wave resonance being captured and recorded by the load cell.

I also ordered a load cell and amplifier from sparkfun, as the quality of their electronics has always been very good. So I’ll get to check the quality of the readings and test data from similar tests with different equipment from electronic suppliers in two different countries.

Thanks for the tip about using a magnet to release the steel ball and keep the data consistent. :slight_smile:

Edit: Correct Spelling Mistakes.

[quote=398040:@Eugene Dakin]

. . . Is the weight of the steel ball 1-gram?

I see what you mean about the overthrow of the load cell, which seems to be the rebound of the cell when the load has been removed.

Your SRS graph looks very professional, well done! I am very impressed at the granularity of the waves near the end of the graph at about 2.10-2.46 seconds, as there seems to be wave resonance being captured and recorded by the load cell. . . .[/quote]

I’m not sure what the weight of the steel ball was, it’s probably in some written notes somewhere and I no longer no where the ball is, but probably around 6gm I would think.

The Impact/Response test shown above was drawn using Illustrators graphing tool and “smoothed”. Nevertheless, you can see the “bounce” as the 400gm mass moves, then settles down.

At the moment I’ve got the OpenScale working with my software:

You can see that 1kg is applied over a period of approx. 1 minute. Unfortunately there are a few “random glitches” as can be seen in the graph. The random readings only last for one sample, some negative 27 kilos to positive 28 kilos. This is unacceptable. I can’t see how this is a code problem, but hopefully I’m wrong.

I’m currently in the process of trying to sort this out.

I got an OpenScale (just because Amazon is speedy quick). The simple program I provided above should’ve worked; if I had noticed the mistake on the #define (which I corrected on the comment section, but missed on the actual #define).

you can see it working by changing

#define DOUT 3 #define CLK 2

#define DOUT 2 #define CLK 3

Yes Langue, that got it working. I did already have it working (but with the glitches described above). In any case, that error in your code is replicated in some other code examples that I’ve downloaded over the last week or so.

I’ve posted my findings in the SparkFun forum:

@Eugene Dakin

Well, that would be interesting to see how you get 1000Hz out of that device. I’m not saying you can’t (I’m not sure either) but if you do, I’d be very interested to know how. External clock?

However, If someone came up with a library to use in Xojo that you can write to the SparkFun OpenScale EEPROM without having to use the Arduino IDE, then that would be something I’d probably pay for. Although considering that it’s unlikely at this point that I’ll ever get paid any monetary value for my software solution, then that justification may be limited.

Anyway, this has been solved. I’m now getting the OpenScale spitting out data at 80Hz formatted as grams (pure numbers). The resolution is whole grams over 20Kg which is perfect for my “test device”. The thing I like about the OpenScale is it’s recognised as a standard FTDI serial device and therefore does not require a separate driver. The Arduino requires the user to download a driver before they can use my software to record. Although that does depend on the device they are using.


@Steve Kelepouris
I am glad you got it working. I placed some code I played with over the weekend at the SFE forum. It was a neat experiment to play with. The OpenScale platform is not that bad, documentation could be better, but most of it is there. The sample rates are designed into the HX711 chip. To get faster rates you would have to increase the clock speed; which according to the datasheet is set to 11.0592MHz internally, but you can potentially increase it up to 20MHz by using an external clock . The only caveat with this is that the output settling time is set by the ADC, so you will have more jitter on the output (specially if you don’t average your results).

Thanks Langue, I did look at your code in the SFE forum, and very nice work, especially in the area of calibration. Much better to jump in bigger increments if required.

Also great to realise that the DOUT/CLK code mix-up is related to if you are using the HX711 breakout board or the HX711 embedded in the openscale board. That difference should really be highlighted in your post as well as in the code comments as you have already done. It’s an easy trap to fall into.

I will upload your code at some time and test it, but you can understand my reluctance at this point having got things working the way I want.

One thing that confuses me about the openscale code (which I believe is written in C) is what are commands and what are the variables. For example:

#define DOUT 2 #define CLK 3
Are DOUT and CLK commands, or are they variables, constants etc.? If they are commands, where is the list of commands and explanations of what they do? I can’t find it.

The external clock does sound interesting. After trawling through lots of info over the last week or so, all I can remember about it, is using a crystal clock chip which that can be powered by the openscale board (I think). Do you have any other details?

Ideally it would be nice to have a sample rate of 100Hz - maybe dividers would be necessary?

Anyway, I’m happy that this is now working - although I’m just as happy to get sidetracked… again :slight_smile: . . . But reality suggests that all I need do now is mount the load cell and electronics (easy) so I can have someone test my software in a “real world” situation. Afterall, my Xojo Software is the main point of my project.

Steve, you are most welcomed. When I get a bit more time I will try to add even more comments to the code so it is easier to follow. I will leave some pointers here.

The #define is like a constant definition, during compile time it is one of the first things to get done and being a constant it is added to the assembly language as a static assignment, not a variable. In this case for Arduino it is used to assign the pin numbers that will be allocated for the data and clock. Those are fixed in the design (because they are wired already - via traces) so they have to map/match the actual layout.

The / “include” are used to call external libraries (or definitions) that will be used on the program. Those are also handled by the compiler very early as they are also static assignments (for the most part).

According to the hx711 datasheet the clock can go up to 20MHz. In theory, 100HZ is achievable. One would have to feed an external clock to the hx711 of a little more of 12MHz.