read an high precision adc like hx711 #6401
Replies: 1 comment
-
Posted at 2016-05-18 by @gfwilliams Hi - there's actually another post just today on interfacing the HX711 - it might be some help: http://forum.espruino.com/conversations/287032/#comment12991616 Have you tried it? I'd be a little surprised if the timeout was such that it didn't work. If it does need pulsing that quick, you have a few options:
Hope that helps! Posted at 2016-05-18 by AaronB Hi,
It does point out that I should have typed >0 in the for statement not 1... Many thanks, Aaron Posted at 2016-05-18 by user64817 sorry, I've mistaked. Posted at 2016-05-19 by user64817 Hi. I've tried with the Gordon get()'s fonction. Posted at 2016-05-19 by @gfwilliams That's a shame - I'd have thought that especially the code posted above, when compiled, would be more than fast enough. The other option is something like:
Posted at 2016-05-19 by user64817 I just tried. values read with espruino are more stable, but still much less stable than the arduino values. Posted at 2016-05-20 by @gfwilliams Ok, use hardware SPI - it should provide a steady train of pulses. Instead of:
do:
you'll just have to choose pins like B3 and B4 that work on SPI1: http://www.espruino.com/Pico#pinout Posted at 2016-05-20 by user64817 the value are still not stable. Posted at 2016-05-23 by @gfwilliams I don't have an HX711 to test with - you could post your code up here though in case I can see anything wrong with it. Have you tried different baud rates? It could also be a power supply issue - as on Arduino you may be running it from 5V, but you're using 3.3V on Espruino? However as I said in the other thread, you're reading a 24 bit value, so it could give anything up to 16 million back. The number might be changing by 6000, but that's only 0.0375% - which is a pretty small variation. How about trying it with some load on it, and seeing if it actually works? Posted at 2016-07-20 by drpapp Hello, Posted at 2016-07-20 by user64817 you have here all the versions, tests I've made. Attachments: Posted at 2016-07-20 by drpapp Thanks, I'll give it a try. Posted at 2018-07-13 by jijidad After reading this thread I almost didn't even bother to try to use an HX711 with espruino, but I somehow decided to give it a go anyway, and I'm glad I did. It is possible to get nice stable and accurate (and precise!) readings from an HX711 chip and a load cell using espruino. I'm using a shielded HX711 breakout board (from Amazon: http://a.co/ge0HhQR) and a balanced 4-wire load cell. I'm connecting the standard Red,Black,Green,White wires from the load cell to the board pins like this: Red --> "Out+" (that's how it's labeled on this particular board) From the board to the espruino, I have the following connections: Here is the code I'm using:
I get the same accuracy and better precision than my cheap store-bought digital kitchen scale. I'm getting about 0.1g precision reliably. Note that as long as I wait a while between reads, I get very consistent values back. If I do multiple reads one after the other without waiting in between, then I get high variability. I don't know why that is. Earlier in this forum thread there was talk about needing to follow the 24 pulses with 1-3 pulses for selecting the gain level, but that was problematic for me, as it caused erroneous readings when I tried that. Maybe I didn't do it right. But for my needs, with a simple wait between reads, I'm getting great results. I currently force it to wait 1 second between reads, which is more than enough, and not too slow of a sample rate for my application. Posted at 2018-07-16 by @gfwilliams That's great! Thanks for letting us know - is it ok if I turn that code into a module for Espruino? Posted at 2018-07-17 by @allObjects ...once more: flakyness comes from power supply... as experienced a while back when the ESP8266 became available and communication was flaky... either with Espruino combined or Espruino on ESP8266... Espruino once again has proven to be rock solid! PS: The waits... could they be needed because reading is triggering another convert from the sensor and storing the value in the register from where it is read? Also, switching between idle and operate may play an issue - fluctuation in current... I did not read up HX711's internals... Posted at 2018-07-17 by jijidad Hi Gordon, a module would be fantastic! Your modules are so nicely designed and their plug-and-play nature really saves a developer like me lots of time and headache, making the espruino such a great platform to build on. Posted at 2018-07-24 by @gfwilliams Thanks! Please can you try:
and see if it works for you? I don't have one to test with here so it's guesswork really. The module itself is here if you want to take a look at what's available: https://github.com/espruino/EspruinoDocs/blob/master/devices/HX711.js I tried to make it so that it will output the correct number of pulses - I think you probably hit issues because if the delay is too great between pulses it can really throw it off. I also added Posted at 2018-07-24 by jijidad For some reason, your module has the variability issue that I first ran into and was trying to fix. Although, to be fair, your module's variability is not that bad, and probably acceptable, but my implementation gets better results and I'm not sure why. I did a simple test. I ran the code and let it sit for several seconds, then placed a 28g weight on the load cell. I captured a screenshot comparing both your module and my original code: Note the high variability on the left and the low variability on the right. Also, the multiplier is the same 0.00103123388 for both, so it's interesting that the module says the 28g weight is twice as much (56g). That might be a clue as to what is going on? I also noticed that I'm sending a string of 1's ([0b11111111,0b11111111,0b11111111]), but in your module, you added zeros between the ones ([0b10101010,0b10101010,0b10101010,0b10101010,0b10101010,,0b10101010]), and added the finalClk at the end as well. The other difference is software vs hardware SPI. Gordon, let me know what I can do to help get this to the end zone of a nice working module. Posted at 2018-07-25 by @gfwilliams Thanks - that is interesting... The 2x difference in readings may be because the gain is set differently - the number of clocks sent specifies the gain and channel to be used for the next reading. I have no idea what 24 clocks does as it's not in the datasheet, but 25 clocks would be 128x gain and 27 clocks is 64x gain. Of course it could be to do with the serial data as well... What I'm doing with 0b10101010 is I'm using the data line as a clock, since if I used the actual clock line it'd only be able to output a multiple of 8 clocks. Sadly the JS execution speed isn't fast enough to simply clock the data in using JS code at the moment (as if it's too slow the ADC will just reset itself). Could you try copying the module code out of https://github.com/espruino/EspruinoDocs/blob/master/devices/HX711.js into the IDE and changing:
to
That'll change the point at which the data line is sampled (as it might have been read too quickly). Maybe you could also print Posted at 2018-07-25 by jijidad I made your function change, Gordon, but I'm getting pretty much the same results. I see what you are trying to do with using mosi to send data as clock ticks. However, when I dig into it, it doesn't look to be very "clock like". I hooked it up to a scope, and here's what I'm seeing: The yellow on the bottom is the actual spi clock (sck), and the cyan on the top is your mosi 0b10101010 data. If you were to scroll rightward along time, you'd see 6 of those 0b10101010 waveforms followed by the finalClk. This image only captures the first two bytes. A few things to note:
You probably have some additional tricks up your sleeve which I'm more than happy to try. In the mean time, If you are okay with it, I'd like to modify your module to use hardware SPI1, and to use the actual SPI clock to send the 24 ticks. It seems to work great even though, as you say, the data sheet doesn't specify what 24 clocks does. It also doesn't allow one to change the gain, etc., but it's very stable and seems to work really well with whatever gain 24 clocks is resulting in... Posted at 2018-07-26 by jijidad I've been testing more after changing line 38 in your module from:
to:
The 2x scale factor is removed and the variability has gone down and it's actually quite good now. If I round to the nearest 0.25 grams, its quite stable, and that's all the resolution I need for my application. I'm thinking it would be fine to release this as a beta version of the module with just line 38 changed. Don't change line 41 to what you had me test. The original ex() function works better. Cool! Posted at 2018-07-26 by @gfwilliams That's really interesting. Which pin are you using? And you're on the MDBT42Q with 1v99 firmware? I actually hooked it up to a scope before posting to check it was doing the right thing, and I see the opposite of you (0v normally on mosi with 4 pulses) so I'm very surprised it's got inverted somehow. There is the ~30uS gap between pulses as you note, but looking at the datasheet that should be ok. SPI should normally transmit most significant bit first, so if the lowest bit is 0, that should be the state the MOSI line is left in... Posted at 2018-07-26 by jijidad Yes, I'm using MDBT42Q with 1v99 firmware. I'm using pins D14 and D15. Using D14 for the clock. I just restarted the board by disconnecting the battery and reconnecting. I'm now no longer getting the inverted mosi! I've tried for the last hour to reproduce getting that inversion back, but I haven't been successful yet. Any ideas on how it got into that state? Some internal pullup or something that didn't get reset? It probably would go unnoticed for most SPI situations since during the clock ticks, the voltage is correct. It's just in between the bytes that it goes high. But, after resetting, I'm not able to reproduce. Argh!! If you think that might be a bug somehow, I'm happy to try things that will help track this down if you want me to. With more testing, I did catch something that I didn't catch before which might be causing the variability in the readings. There appears to be an intermittent variability in the gaps between the mosi bytes. Normally, it's 30uS, but sometimes it's much higher. Here are a couple of examples: Notice that there can sometimes be over 100uS gaps. Have you run into this with software SPI? These longer gaps seem relatively infrequent. I'm wondering if this is causing the variability in the weight readings due to the ADC timing out or something. I haven't yet been able to correlate these two things though. Sorry. I feel like this is muddying the water instead of adding clarity. Posted at 2018-07-26 by jijidad For what it's worth, here is the version of the module that I'm using. It's the most stable and precise of all the versions I've tested so far. It uses the SPI clock to send 24 ticks, and it uses hardware SPI1, which appears to be twice as fast as software SPI. It doesn't allow changing of the mode, as that requires a nonmultiple of 8 ticks. Here it is:
Below is an example of using it where I call tare() after 1 second and then spit out the weight measurement every second after that. Note that if you tare() too quickly, it'll not be accurate. Sometimes I need to tare again because the zero was off. This appears to be normal behavior since my kitchen scale is the same way (requiring multiple tares to get a stable zero). You can't do reads too close together in time or it'll introduce variability. This might be because the ADC needs to time out since I'm only sending 24 ticks or something... It appears that if you wait at least 30ms between reads, you'll be fine. Here I'm waiting 1000ms:
Here are some readings with nothing on the scale:
And here are some sample readings with a 33 gram weight:
If you round to the nearest 0.1 gram, it's quite stable. Rounding to the nearest quarter gram is extremely stable. Since you can sample every 30ms, one could easily increase sampling rate and return an average over multiple reads to reduce noise even more. That's probably what I'll do for my current application. Hope this helps others who want to use an HX711. Gordon, I'm available to investigate things or do tests, or otherwise help in any way. Posted at 2018-07-27 by @gfwilliams Thanks! I have no idea what caused the inversion. There is code in Espruino to handle inversion in software, but it reads whether to do the inversion from flash, so that shouldn't ever be able to get modified. That 120uS pause would definitely cause the instability - unfortunately it's very difficult to avoid with software SPI since the Bluetooth stack needs to be able to interrupt things to keep the Bluetooth timing correct and keep the connection up. Do you think you'd be able to keep the code I'd used with the 0b10101010 and try it with hardware SPI? Posted at 2018-07-27 by jijidad Aha! Got the inversion back after trying your technique with hardware SPI. I reset the board and tried with the following isolated test case:
Gordon, can you try the above and take a look at D14 on your scope? Do you also see a normally high MOSI line? Please tell me I'm not crazy. Or, at least, show me what I'm doing wrong here... Posted at 2018-07-30 by @gfwilliams Ahh - yes, you're right. This looks like it's actually to do with the nRF52's SPI hardware! It seems that data is output MSB first, as you'd expect. However after outputting all data the state of the output line returns to the state that was in the top bit! So I guess either we'd have to move to At this point I think it's probably best to just go with your method and drive it with 24 bits of data despite what the datasheet says. If it's not going to cause any trouble and it works reliably :) Posted at 2018-07-31 by jijidad I'm having success with my hardware SPI clock method. But I agree. It isn't spec friendly. I'll report back when I do larger scale testing in schools and let you know how it holds up to real world use. Posted at 2019-01-26 by santac89 Hey guys! Were you able to get any more progress on this? I'm currently working with a HX711 also, connected to an NodeMCU ESP8266 and I'm just starting in this. I have used both of your modules and getting different results from both. For a 177g object I'm getting around 70g readings but if I lift it I get zero so it seems to be calibrated but the calibration factor is off or something like that. Thanks in advance! :) Posted at 2021-02-22 by @MaBecker Did some test with HX711 module and PuckJS running 2v08.82
Added an overview and detail screenshot for a Does that HX711 return look correct? Attachments: Posted at 2021-02-23 by @MaBecker Question: Is there a fix to eliminate the pause between sending the next byte? Posted at 2021-02-23 by @gfwilliams It might help if you changed Posted at 2021-02-23 by @MaBecker
It does - Thanks! Now there are 25 pulses for "A128" without any delays in between and pulse width is valid compared to the datasheet Attachments: Posted at 2021-02-25 by @MaBecker First approach to tare a scale with multiple calls and median filter.
Any hints and tweaks are welcome. Posted at 2021-02-26 by @gfwilliams Looks good! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-18 by user64817
Hi,
I've tried to connect the hx711 to espruino to measure a loadcell
unfortunately, the hx711 pd_sck pin asks for a pulse of 1 and 0 (24 to get the bits of reading) then 1-3 bits for the gain setting.
and the max time for the 1 period is 50microseconds (pcd_sck high time)
cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
and the espruino min delay for a digitalwrite is 160 microseconds. I've measured with my oscilloscope.
so the hx711 is "too fast" for the espruino.
Do you have an idea how I can get the adc values ?
Beta Was this translation helpful? Give feedback.
All reactions