Closed torbacz closed 2 years ago
I've tried to debug, but no luck so far. Also this is new lib, it was implemented like 1/2 weeks ago, maybe the author will know what can be wrong?
I've tried to debug, but no luck so far. Also this is new lib, it was implemented like 1/2 weeks ago, maybe the author will know what can be wrong?
The author (which I happen to know closely š ) has no idea what could be wrong there...
I've tried to debug, but no luck so far. Also this is new lib, it was implemented like 1/2 weeks ago, maybe the author will know what can be wrong?
The author (which I happen to know closely š ) has no idea what could be wrong there...
I saw you name by the commit, but i thought it was someone else š I'll try to find out why my setup is not working.
@torbacz just as a side note, quite a lot of the Arduino libs are not working properly. Not saying that this one is in this case but in general, the quality is far from being really good. That's the case for most of the magnetometer or giro and other IMU for example. I've been there many times! What's complicated as well is to understand if the lib your using is a correct one or not and except knowing the topic and having read the datasheet, plus some understanding of the hardware, it's not that easy.
@torbacz I'm trying to use this library again to find out that's not working for me... it doesn't get past the WaitForConversion
just sits there on the while loop.
@josesimoes Sad to hear that, but I haven't change anything there. @lsd-techno implemented fix. And I've checked that after and it is working for me.
@josesimoes I suspect SPI changes related to display support could be involved is there any specific firmware to test with? While browsing SPI implementation I found that all CS pins are software controlled pins. That would be good option to have NULL CS pin assignment for such implementation like in this driver.
@lsd-techno can't NULL CS, that's in int
. We're using -1 for "manual" handling of CS. In this specific binding that shouldn't matter.
On the above: @JORGEGO he's the one using this one, so he'll be able to confirm the issue.
Let's use this Discord thread for discussions about this matter.
Looks like this is working after all... š¤·š»āāļø
Library/API/IoT binding
nanoFramework.Iot.Device.Hx711
Visual Studio version
VS2022
.NET nanoFramework extension version
No response
Target name(s)
ESP32_REV0
Firmware version
1.8.0.289
Device capabilities
No response
Description
When comparing data from HX711 Arduino library against nanoFramework there is a mismatch in returned data. It won't be a problem, but with certain weight it's returning negative values.
Raw reading without any weight applied to loadcell. Arduino: -51877.00 Nano: 16724520
When applying pressure to loadcell, it fails at certain point. 01/01/1970 00:05:49 Weight: -131 01/01/1970 00:05:51 Weight: -127 01/01/1970 00:05:53 Weight: -187 01/01/1970 00:05:55 Weight: 20227 01/01/1970 00:05:57 Weight: 28671 01/01/1970 00:05:59 Weight: 33924 01/01/1970 00:06:01 Weight: 43217 01/01/1970 00:06:03 Weight: 52202 -OK 01/01/1970 00:06:05 Weight: -16718538 -negative value, overflow?
Used hardware:
How to reproduce
Make sure you are using correct pins for communication.
For arduino example:
For nanoFramework:
Use code bellow
Expected behaviour
Screenshots
No response
Sample project or code
No response
Aditional information
No response