Invalid reading from HX711

torbacz commented 2 years ago

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:

ESP32 Dev Kit
HX711 module
4 load cells in wheatstone bridge configuration Full guide here: https://everythingsmarthome.co.uk/building-a-bed-occupancy-sensor-for-home-assistant/

How to reproduce

Make sure you are using correct pins for communication.

For arduino example:

Download https://github.com/EverythingSmartHome/mqtt-bed-sensor/blob/master/Scale_Calibration/Scale_Calibration.ino
Replace line 31 from 'Serial.print(scale.get_units(), 2);' to 'Serial.print(scale.read(), 2);' - we want raw data from sensor, without offset
Flash ESP with code
Check serial output

For nanoFramework:

Use HX711 code
Change HX711.ReadValue to public

Use code bellow

public static void Main()
{
  Console.WriteLine("Test");
  ///////////////////////////////////////////////////////////////////////
  // When connecting to an ESP32 device, need to configure the SPI GPIOs
  // The following mapping is used in order to connect the WEIGTH module
  // to a M5Core device using the Grove port A
  // MOSI: connects to Grove pin 1
  // MISO: connects to Grove pin 2
  // CLOCK: connect to any free port as it's not used at all
  Configuration.SetPinFunction(16, DeviceFunction.SPI1_MOSI);
  Configuration.SetPinFunction(4, DeviceFunction.SPI1_MISO);
  Configuration.SetPinFunction(23, DeviceFunction.SPI1_CLOCK);

  // setup SPI connection settings
  // the clock value was adjusted in order to get the typical duration expected by the PD_SCK ~1us
  var spisettings = new SpiConnectionSettings(1, 5)
  {
      ClockFrequency = Scale.DefaultClockFrequency
  };

  // create SPI device
  var spidev = SpiDevice.Create(spisettings);

  // create scale
  var scale = new Scale(spidev) { Gain = GainLevel.None };

  // power up WEIGHT module
  scale.PowerUp();

  // set scale tare to get accurate readings
  scale.Tare();

  // loop forever outputting the current reading
  while (true)
  {
      var reading = scale.ReadValue();

      Console.WriteLine($"{DateTime.UtcNow} Weight: {reading}");

      Thread.Sleep(2_000);
  }

}

Expected behaviour

The returned data should be the same
or the returned data should not jump from +50xxx to -16718538

Screenshots

No response

Sample project or code

No response

Aditional information

No response

torbacz commented 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?

josesimoes commented 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?

The author (which I happen to know closely 😁 ) has no idea what could be wrong there...

torbacz commented 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?

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.

Ellerbach commented 2 years ago

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

josesimoes commented 2 years ago

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

torbacz commented 2 years ago

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

lsd-techno commented 2 years ago

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

josesimoes commented 2 years ago

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

josesimoes commented 2 years ago

Looks like this is working after all... 🤷🏻‍♂️

nanoframework / Home