Anyone with SparkFun OpenScale experience?

  1. ‹ Older
  2. 6 months ago

    Steve K

    Jul 26 Melbourne, Australia
    Edited 6 months ago

    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.


    @Eugene D Thanks Steve, I'll use a metal ball to test the scale.

    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.

  3. Eugene D

    Jul 26 Pre-Release Testers, Xojo Pro Canada
    Edited 6 months ago

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

    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 :)

    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. :)

    Edit: Correct Spelling Mistakes.

  4. Steve K

    Jul 27 Melbourne, Australia

    @Eugene D
    . . . 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'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.

  5. Langue R

    Jul 28 Answer

    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
  6. Steve K

    Jul 30 Melbourne, Australia
    Edited 6 months ago

    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 D

    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.

    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.


  7. @SteveKelepouris
    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).

  8. Steve K

    Aug 1 Melbourne, Australia
    Edited 6 months ago

    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 :) . . . 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.

  9. 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> / "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.

  10. 5 months ago

    Steve K

    Aug 11 Melbourne, Australia
    Edited 5 months ago

    With your help Langue, I've now got the SparkFun OpenScale device spilling out data at 80Hz with no glitches. Great!. it's really a nice unit.

    @ Eugene

    Dropping a small (6gm) steel ball from 30cms onto a flat steel plate has its consequences:


    You can clearly see the indentations (outlined in red) where I moved the plate to ensure the ball didn't land in the same spot. The indentations show that the steel ball was the "harder" of the two.

    I'm certainly not saying that I fully understand Newtons laws, but Newton's third law states: "For every action, there is an equal and opposite reaction". The Law seems to suggest that via dropping the ball, the earth itself would move (ever so slightly) in the opposite direction. There is theoretical formula but I could never understand it.

    What I do understand is that the indentations reveal a loss of energy, ie. energy is converted into heat through the smashing of metals.

    Ummm... what does it all mean? Not much really, except to say that my Xojo Software Application is pretty damm good to record and evaluate such events. Not bad for a novice :).

    Now it's back to writing the user help system. It's no wonder I can't finish it, because I keep getting side-tracked!!! :)

  11. Those are great results. What is that plate by the way? It looks like some sort of building address plaque or something. There is a floor and tower reference, and somewhere in Melbourne Australia. Something like this maybe:

    Anyways looks cool. I ended up building myself a mini-scale with the Openscale gizmo just to make use of it and give me a reason to print some 3d stuff.

  12. Steve K

    Aug 11 Melbourne, Australia
    Edited 5 months ago

    It's is a gravure plate/block. Used in the printing industry. Very old and interesting. It's approx. 90mmW x 50mmH x 15mm deep and weighs around 350grams and used (in the distant past) for a printed business card.

    The letters are indented into the metal, then filled with ink. A "doctor" blade scrapes off the surface, leaving the ink in the shallows. The block is then pressed onto a piece of paper which reveals the readable text.

    I'm in the printing industry, but this is way way before my time, but I do understand the concept and method.I can't remember how it came into my hands.

    A bit silly that I used the front surface for my tests. However the block was worn anyway.

    The company that the business cards (or perhaps notepaper/letterhead) were produced for was NEWMONT Australia. A mining company that is still around I believe.

    I think it would be Nickle Plated.

  13. I know it is completely unrelated, but the plate looks pretty cool. I wonder if it was nickel or some mix with lead. That explains the indentations, aluminum should not deform like that.

  14. 4 months ago

    Steve K

    Sep 13 Melbourne, Australia

    Been a while and thought it useful to report back on my progress.

    With the help of my brother, the SparkFun OpenScale is now able to deliver data up to 160Hz reliably. So thanks for all your help Langue, it would not have been possible without your ideas, code examples and advice. :)

    @Eugene D
    You eluded to a scenario that could access the SparkFun device directly through Xojo without having to use the Arduino IDE?

    Maybe I read something into it that wasn't there, but if it could be done, well that would be something.

  15. Eugene D

    Sep 13 Pre-Release Testers, Xojo Pro Canada

    Good morning Steve,

    Yes, you are correct that I mentioned that I should be able to get something working. Unfortunately the parts from China never arrived. I’m shopping for local parts available in Canada.

    The other part is ‘life happens’ and it’s been busy at my day job. Sorry, as I should have been better at keeping you updated.

    This project is not forgotten, just delayed. I am glad to see that you were able to increase the sampling frequency.

  16. Steve K

    Sep 13 Melbourne, Australia

    No need to apologise Eugene - life happens and we get thrown from one thing to another, and sometimes end up back where we started, or on a new tangent to somewhere unexpected.

    All good.

  17. Eugene D

    Sep 15 Pre-Release Testers, Xojo Pro Canada
    Edited 4 months ago

    Hi Steve,

    I have some good news and some bad news. The bad news is that it will take about 4-weeks to have the HX711 delivered. The good news is that I spent a little time and created a TTL (Transistor-Transistor-Logic) example that has a Measurement-Per-Second (MPS) rate of about 600. This was created just for fun, and I'll work on a driver for the HX711 when it arrives.

    There is noise which seems to be coming from the MCP 3008 (Analogue-to-Digital Converter) chip, which makes the resolution ok, but could be better. In this example, I have not calibrated the voltage-to-weight ratio to develop a formula to calculate the weight in the mathematical form: y=mx+b.


    Here is a link to directly download the schematic (its much clearer than the online version):
    Schematic Download

    Here is a screengrab of the working prototype where I am dynamically changing the MPS during runtime:
    The voltage reading is 1.527539, and Measurements-Per-Second are 608.

    The higher resolution video can be downloaded here: LoadBar.MP4 . Unfortunately, the video is 90 degrees counter clockwise.

    This circuit is taking the small voltage change from the LoadBar and amplifying the voltage with a basic Instrumentation Op-Amp circuit. The amplified voltage signal is then converted to a digital signal with the MCP3008, and this digital signal is received by the Raspberry Pi and the voltage is shown on the screen.

    If I had time to create an analogue-to-digital signal converter to the Raspberry Pi, then the resolution would likely increase along with the measurement cycles.

    Edit: Oops, here is the Xojo program that shows the data:

  18. 3 months ago

    Eugene D

    Oct 7 Pre-Release Testers, Xojo Pro Canada

    Hi Steve,

    The HX711 arrived early, in 3-weeks instead of 4-weeks. I am able to retrieve data from the HX711 and am only able to get the data at about 10 Hz maximum. At 10 Hz the HX711 is starting to throw errors. According to the data sheet, the board should be able to have either 10- readings per second, and up to 80 readings per second, which is below what you want for your application. Data from the HX711 is 24-bits in length and is properly converted to a Two's Complement form. Below is a screen grab of the running program.


    Data is retrieved as 'counts' from the HX711, where the starting value from a load bar is somewhere between 0 and 16,777,215. If the value goes over or under the minimum and maximum range, then the value starts at the other value. An example of this is my load bar had a zero-load count of 80,398 and adding weight to the load bar lowered the value to 0, and a value below zero then had the number continue at 16,777,215 and then continued to decrease as more weight was applied. Removing the weight then returned the count value back to 80,398. A zero-factor can be programmatically created in Xojo with an integer variable that would either subtract or add from this value.

    Wiring of the HX711 was fairly easy, and below is the schematic.


    Here is the Xojo program that makes this work. This uses MediaFire and may show a popup ad (just ignore it). I am looking for a way to have files download without an unwanted ad showing up.


    The program can be used with different load cells with varying weights, and to calculate the wieght, the following formula can be used:

    weight = HX711Counts*MaxWeight/16777213

  19. Steve K

    Oct 7 Melbourne, Australia

    Thanks for your continued interest Eugene.

    I'm already at a reasonably advanced stage. At this point I have the SFOS (SparkFun OpenScale) running at 160Hz. I'm able to change the calibration through Xojo.

    However, the calibration is only short lived. Meaning when the device is reset, the calibration number is lost. I can get around this by saving the calibration factor in my preferences file, then pulling it up when needed. For all intents and purposes this works fine and the user needs not know.

    HOWEVER, this does not permanently write the calibration factor to the EEPROM. As far as I've read, you need the Arduino IDE to permanenty write to the EEPROM.

    If you have a solution to write the calibration factor directly to the EEPROM via Xojo, then I'll go gay. Meaning I'll be very happy - Not that there''s anything wrong with that.

  20. Eugene D

    Oct 8 Pre-Release Testers, Xojo Pro Canada

    Hi Steve,

    I am glad to hear that you have the OpenScale working the way you want.

    @SteveKelepouris If you have a solution to write the calibration factor directly to the EEPROM via Xojo,

    Sorry, I don't have a solution for this.

    Your project looks great, and I am glad your enjoying the fun with electronics!

  21. Steve K

    Oct 9 Melbourne, Australia
    Edited 3 months ago

    @Eugene Dakin Sorry, I don't have a solution for this.

    Thanks Eugene, it seems like that's the case. It's not a big deal unless the user uses my hardware device with some other application, then the calibration will be incorrect. Although this could be reset using the Arduino IDE.

    You are using the HX711 chip, I'm using the SFOS board which includes the HX711 and also the ATMEGA328 chip that contains the bootloader and EEPROM which allows you to write to it - that's my understanding.

    Therefore you can easily reset the tare point via Xojo:

    Xojo Code:

    If Serial1.Open Then
    End If

    SFOS Code:

    void loop()
    // ---------------------------------------------------------------------------------------------------
      // This continually spills out the data read off the ADC (in whole grams).
      Serial.println((scale.get_units()*1000), setting_decimal_places);
     //check for an incoming character - If there, break out of the loop to the appropriate function.
     char incoming;
      if (Serial.available() > 0) //if a character is available evaluate and continue...
      incoming =; //get the character
        if (incoming == tare_character) //"t"
        tare_hardware(); //call the function
    // Functions ----------------------------------------------------------------------------------
    // write to EEPROM (temporary)
    void tare_hardware(void) //tare the hardware if we have to
      scale.tare();  // Reset/tare the scale to zero when called (from Xojo SRS Software)

    scale.tare() is the function to call which is part of the main firmware.

    My original prototype electronics contains:

    • Top right: An Arduino Uno (compatible)
    • Left: An analog load cell amplifier
    • Bottom right: Circuitar module to increase the bitrate from 10-12 (similar to an adafruit module)


    The bottom left of the image shows the SparkFun OpenScale in proprtion to my original prototype.

    When you look at all that, and then include the fact the my original prototype requires 12-18vdc to run the amplifier, yet the SFOS runs off the usb port, and is about the size of a cigarette packet and is 24bit . . . well, that's pretty damm good.

    The only downside is the resolution, which at this stage seems like 160Hz is the best you'll wring out of it which is good enough but nice if it was 500 or even 1000.

    I don't know much about the electronics side of things. My brother is the one who has modified the SFOS. My original prototype is a "flatpack" version, where you just assemble modules together.


    The thing to do next is to perform the same impulse response "drop" test as previously described - then a final conclusion can be made. For all I know, ramping it up to 160Hz may cause an issue in the AD conversion times.


or Sign Up to reply!