Anyone with SparkFun OpenScale experience?

  1. ‹ Older
  2. 9 weeks ago

    Steve K

    Jul 24 Melbourne, Australia

    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:
    3.53,kg,

    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.begin(115200);
      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.set_scale();
      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.
    Serial.println(zero_factor);
    }
    
    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: ");
      Serial.print(calibration_factor);
      Serial.println();
    
      if(Serial.available())
      {
        char temp = Serial.read();
        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?

  3. Steve K

    Jul 24 Melbourne, Australia

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

  4. Eugene D

    Jul 24 Pre-Release Testers, Xojo Pro Canada scispec.ca

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

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

  5. 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
     GND -> GND
      
    */
    
    #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.begin(9600);
      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
    
      Serial.println("Readings:");
    }
    
    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
      Serial.println();
    }
  6. 8 weeks ago

    Steve K

    Jul 26 Melbourne, Australia
    Edited 8 weeks 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.

    -image-

    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.

  7. Eugene D

    Jul 26 Pre-Release Testers, Xojo Pro Canada scispec.ca
    Edited 8 weeks 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.

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

    -image-

    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.

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

    to

    #define DOUT  2
    #define CLK  3
  10. Steve K

    Jul 30 Melbourne, Australia
    Edited 8 weeks 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:
    https://forum.sparkfun.com/viewtopic.php?f=14&t=48362&p=199866#p199866

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

    Interesting.

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

  12. Steve K

    Aug 1 Melbourne, Australia
    Edited 8 weeks 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.

  13. 7 weeks ago

    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.

  14. 6 weeks ago

    Steve K

    Aug 11 Melbourne, Australia
    Edited 6 weeks 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:

    -image-

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

  15. 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: http://www.walkingmelbourne.com/building476_amp-building.html

    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.

  16. Steve K

    Aug 11 Melbourne, Australia
    Edited 6 weeks 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.

  17. 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.

  18. last week

    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.

  19. Eugene D

    Sep 13 Pre-Release Testers, Xojo Pro Canada scispec.ca

    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.

  20. 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.

  21. 7 days ago

    Eugene D

    Sep 15 Pre-Release Testers, Xojo Pro Canada scispec.ca
    Edited 7 days 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.

    -image-

    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:
    -image-
    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: LoadBar.zip

or Sign Up to reply!