Planet Arduino

In the first part we looked at the HX711 hardware for implementing weigh scales systems.

This part will cover how software interacts with the hardware, requirements for a library and how to write a weigh scale application.

All the code described in this article can be found in my libraries code repository as the MD_HX711 library and examples.

Requirements

The most basic components of weighing machines a weight sensor, processing device and an interface (for example, these could be a load cell/HX711, a microprocessor and a display, respectively). They usually also have a method for taring the weight (eg, a switch). Other advanced features can be built into the device but they are refinements on the basics.

The simplest user interface for the scale is to continuously send to the interface the measured value. For a display output this would be just shown (like bathroom or kitchen scales) and/or it could be output through an external interface such as a serial port. Many industrial weight scales work exactly like this.

Therefore to implement a minimal weighing system we need a software framework, such as an Arduino library, that:

1. Enables access to all the HX711 features (ie, both channels of data, resetting the device and Channel A gain selection).
2. Can work in the background so that the application code implementing the weight scale functionality is free from dealing with hardware related operations. Preferably this works by either periodically polling the HX711 or by external interrupt.
3. Allows the device to be tared and calibrated.
4. As a minimum provides the readings from the device as raw, tared or calibrated values.

There are many HX711 libraries available and many provide lots of functions above the basics outlined above. However, I could not find one allowed easy access to Channel B or worked using an external interrupt. So I decided that it was time to write my own.

Library Implementation

Reading Device Data

The core of the library is a function used to implement the device communication protocol described in the previous post. The HX711ReadData() code is a straightforward sequential implementation of the CLK/DAT sequencing and timing required by the interface. The function returns the 24-bit DAC number received as a 32-bit integer.

int32_t MD_HX711::HX711ReadData(uint8_t mode)
// read data and set the mode for next read depending on what 
// options are selected in the library
{
  // local variables are faster for pins
  uint8_t clk = _pinClk;
  uint8_t data = _pinDat;

  // data read controls
  int32_t value = 0;
  uint32_t mask = 0x800000L;
    
  do   // Read data bits from the HX711
  {
    digitalWrite(clk, HIGH);

    delayMicroseconds(1);   // T2 typ 1us

    if (digitalRead(data) == HIGH) value |= mask;
    digitalWrite(clk, LOW); 

    delayMicroseconds(1);  // T3 typ 1us
    mask >>= 1;
  } while (mask > 0);

  // Set the mode for the next read (just keep clocking)
  do
  {
    digitalWrite(clk, HIGH);
    delayMicroseconds(1);
    digitalWrite(clk, LOW);
    delayMicroseconds(1);
    mode--;
  } while (mode > 0);

  return(value);
}

Note that the microsecond timing in this function is moot given that digitalWrite() and digitalRead() are quite slow compared to native processor register read/write.

HX711ReadData() is called from readNB() (read non-blocking), which puts the correct library context around the hardware call. This includes:

• working out which channel we need to ask for in the next iteration.
• setting the gain for the channel being requested.
• managing the interrupt context.
• saving the data received to the correct internal storage register.

The reason that we have a non-blocking read is that this method is designed to be called safely by an ISR for an external interrupt.

void MD_HX711::readNB(void)
// NON-Blocking read the data from the HX711 in an IRQ 
// safe manner.
{
  uint8_t extras = 0;
  int32_t value;

  _inISR = true;

  // set the next read channel
  if (_enableB) _nextReadA = !_nextReadA;

  // now work out how many extra clock cycles send when reading data
  if (!_nextReadA)            extras = 2; // Channel B gain 32
  else if (_mode == GAIN_128) extras = 1; // Channel A gain 128
  else                        extras = 3; // Channel B gain 64

  // do the read
  noInterrupts();
  value = HX711ReadData(extras);
  interrupts();

  // sign extend the returned data
  if (value & 0x800000) value |= 0xff000000;

  // save the data to the right index value
  channel_t ch = (_enableB && _nextReadA) ? CH_B : CH_A;
  _chanData[ch].raw = value;

  // increment the counter
  _readCounter++;

  _inISR = false;
}

The last received data for each channel is stored in library registers and can be retrieved using the getRaw(), getTared() and getCalibrated() methods, depending on what data the application needs.

Device Reset

The HX711 is reset by powering it down using the CLK pin held HIGH then back up again a very small time later.

inline void MD_HX711::powerDown(void)
// Set the CLK to low for at least 60us.
{
  digitalWrite(_pinClk, HIGH);
  delayMicroseconds(64);   // at least 60us HIGH
}

inline void MD_HX711::powerUp(void)
// set the CLK to high
{
  digitalWrite(_pinClk, LOW);
}

This resets the device into a default state, so the library implements a reset() method that does the same and keeps the library and device synchronized.

void MD_HX711::reset(void)
// set defaults and power cycle the hardware
{
  powerDown();
  powerUp();

  // set the library defaults
  enableChannelB(false);
  setGainA(GAIN_128);
  disableISR();
  _nextReadA = true;
  _readCounter = 0;
  for (uint8_t ch = 0; ch < NUM_CHAN; ch++)
  {
    _chanData[ch].raw = 0;
    _chanData[ch].tare = 0;
    _chanData[ch].calib = 0;
    _chanData[ch].range = 0.0;
  }
}

Tare and Calibration

The values returned from the hardware are 24-bit ADC values converting the amplified Wheatstone differential voltage to a number. This number must be calibrated to convert the value to a meaningful reading.

To calibrate the readings we first need to assume the Wheatstone bridge provides a linear response to the changes in weight (ie, there is a simple proportional relationship). This is the blue line in the figure. We know this assumption is not correct (see this article) but it is close enough if we choose the right load cell for the application.

The first part of calibration is to tare the readings with no force on the sensor (autoZeroTare() or setTare() methods). This provides the information to shift the ‘raw’ blue response curve to the green curve (line A₀B₀ shift to A₁B₁) by subtracting the tare ADC value. This locks in the zero point for the conversions and returned by the getTared() method.

The next part is to calibrate the actual slope of the conversion line – moving the green curve A₁B₁ to the red curve A₁B₂ in the diagram. This is done by applying a known force to the sensor (such as a known mass) and noting the ADC value returned (setCalibration()).

By setting the zero point and one known point, and assuming a linear response in the range of values being measured, the converted value y can be easily computed for any ADC value x using the getCalibrated() method.

Polled or External Interrupt?

The library supports both a polled and an interrupt driven approach to obtaining data from the HX711. Up to four separate HX711 devices on unique external interrupts are supported, using the technique described in this past post.

The enableInterruptMode() method is used by the application to toggle interrupt mode on/off as needed.

Polled Mode

This is the default operating mode for the library.

In polled mode the public read() method is synchronously invoked to wait for and obtain the next value from the hardware. If channel B is enabled the library will alternate reading channels (A, B, A, B, etc). The read() method returns the identifier of the channel last processed and the data is retrieved with getRaw(), getTared() and getCalibrated(), as required.

As the read() method is synchronous (it blocks waiting for the next data to be available read from the hardware) the isReady() method can be used to determine if there is data ready for processing. This allows an application to check before calling read() to avoid unnecessary application delays caused by the library.

Interrupt Mode

In interrupt mode the library will process data received from the HX711 in the background, based on an interrupt generated by the device DAT signal going low.

Interrupt mode requires that the I/O pin connected to the DAT signal supports external interrupts (eg, for an Arduino Uno this would be pins 2 or 3).

The application can monitor the getReadCount() method to determine when new data has been received. In interrupt mode the read() method becomes non-blocking and returns the id of the channel whose data was the last received so that it can be read with getRaw(), getTared() and getCalibrated().

Prototyping Weigh Scales

Once the basic hardware related functions of the library were coded and broadly tested, it was time to prototype a weight scale to complete the weigh scale code.

Hardware

I was testing with a 1kg bar-type load cell, so a small scale was adequate. A 100mm diameter top and a bottom plate were modelled in Fusion360, shown below, and 3D printed in ABS.

The top plate is a solid disc. The bottom is more open to save material and give access to the screws for joining the top plate and load cell. Both plates include a small pad to lift the load cell so that it is cantilevered it between the two plates. Machine screws (M4) connect all the components together.

Additional hardware required for this prototype was:

• A 2 line by 20 character LCD module. In this instance it used an I²C interface to the processor, but any other size module and interface that works with LiquidCrystal (or clones) library will work.
• A tact switch to tare and calibrate the scale.

The final configuration is shown in the photo above, along with a few of the objects used to test the scale and my 1kg bag of rice used to for calibration.

Software

As the library does most of the heavy lifting, the application software becomes straighforward.

The software described here is the MD_HX711_WeighScale example from the library.

This example implements a weigh scale that

• Can be tared and calibrated using a tact single switch. A Single press of the switch sets the tare, double press sets the calibration to 1000g.
• Tare and calibration settings are stored in EEPROM and loaded at startup.
• Updates the LCD display with the current weight as soon as a new weight is available.
• Demonstrates receiving data from the HX711 in either polled or interrupt driven mode, set by a #define at compile time.

Configuration Parameters are loaded at startup. The EEPROM data includes two signature bytes so that the software can detect a ‘first time’ run and initialize the data to sensible defaults. All changes to configuration values are immediately and transparently saved to EEPROM.

The tact switch is managed by the MD_UISwitch library (also described in this previous post). This allows the application to test for either a press/double press in the main loop() and do the necessary for each case.

Taring is done to set the scale ‘zero’ by a simple pressing of the tact switch. This is usually when the sale is empty by could equally be when the scale has a container on it.

Calibration is carried out by putting a known 1000g weight (my not-very-accurate bag of rice) on the scale and double pressing the switch.

This application needs to be non-blocking for the user switch to work properly. In this case it turns out there is minimal difference to the application’s structure between interrupt and polled modes. In polled mode it monitors isReady() before calling read() to read the data; in interrupt mode it checks getReadCount() to know when new data is available.

One wrinkle is that when the weight is zero, ADC noise fluctuation around the zero point causes the scale to display 0.0 and -0.0. To prevent what looks like a flickering minus sign, the application calculates and displays a ‘damped’ weight calculated as

float dampedWeight(float newReading)
// Dampen the fluctuations in readings value and make any small // negative values 0.0
{
  const float PORTION = 0.80;
  static float lastReading = 0.0;

  // dampen
  lastReading += PORTION * (newReading - lastReading);

  // kill small negative values
  if (lastReading < 0.0 && lastReading > -0.1)
    lastReading = 0.0;

  return(lastReading);
}

If a weight is negative by less that the least significant figure (ie between 0.0 and -0.1) then we can display it as zero. This completely eliminates the visual distraction of the ‘flickering’ minus.

Additionally, this function also dampens the changes to the displayed weight by only adding in PORTION (80%) of the change between the current and last reading. This dampens the ADC noise but also has the side effect of a pleasing ‘converging value’ animation on the weighscale display.

If you search for ‘Arduino’ and ‘weighing’ you very quickly come across the HX711 board module and an associated world of strain gauges and load cells.

All this looked interesting with some learning along the way. The result is that I took a dive into the subject and ended up with some new knowledge and ideas for the future.

In this first part I cover the hardware requirements and in the next how to write software to implement a weighing system.

The HX711 ADC

The HX711 is a precision 24-bit Analog to Digital Converter (ADC) designed for weigh scales and industrial control applications. It readily obtainable from all the usual online marketplaces as ready-made modules implementing the standard datasheet circuit.

The IC interfaces directly with a up to two Wheatstone Bridge load cell’s differential outputs and incorporate signal amplifiers.

Channel A differential input can be programmed with a gain of 128 or 64. Channel B has a fixed gain of 32.

Large gains are needed to accommodate the small output signal from the sensor. When a 5V supply is used for the sensor, the gain corresponds to a full-scale differential input voltage of ±20mV with gain 128, ±40mV for 64 and ±80mV for 32.

Load Cells

Load cells come in various shapes and are rated from 0.1kg to over 1000kg full scale. They come in many different types of form factors but the two most common are bar and strain gauge types.

Bar-type Load Cells

Bar type load cells are straight bars with strain gauges attached to the point where it has maximum bending. A variant of straight bar is the S type cell design for tension (pulling) applications.

Each load cell has four strain gauges connected in a Wheatstone Bridge formation. The labeled colors correspond to the color-coding convention coding of load cells. Red, black, green and white wires are connected to the load cell’s strain gauge and yellow is an optional ground or shield wire to lessen EMI.

The direction of the force arrow labels on the load cells must match the direction of resultant force. If the resultant force is straight down (the usual in a weighing application) then the load cells must be installed so with the force arrow labels pointing down.

Strain Gauge Load Cells

Strain gauge load cells are commonly seen on the corners of bathroom scales and similar ‘platform’ type applications. Each load cell is a half Wheatstone bridge, as shown below.

This type of load cell must be combined into a circuit of 2 or 4 gauges to create the full Wheatstone bridge, with each side of the bridge including the strain resistors from two of the strain gauge load cells. The circuit for combining four strain gauges is illustrated below.

A simple way to combine the wiring is to create a Combinator Board. Here the wires from the individual strain gauge cells are joined in a hub arrangement, producing the required Wheatstone Bridge connections. Shown below is the hub connection for a four sensor configuration.

Module Wire Connections

The HX711 module’s A channel interfaces to the load cell through four wires labeled E+ (or RED), E- (BLK), A-(WHT), A+(GRN), and an optional shielding ground SD(YLW) on the circuit board.

The B Channel interfaces to a separate load cell through the E+, E- (common with Channel A) and B+, B- connections on the circuit board.

E+ and E- are the positive voltage and ground connections to load cell; the A+/A-, B+/B- the differential outputs from the load cell.

The module is connected to the processor’s power supply (Vcc and GND) and 2 additional processor digital input pins to the module’s DAT (or DT) and CLK (or SCK). These digital pins are used to manage the limited configuration options available and read the data from the HX711.

Hardware Control

Sampling Rate

The HX711 can sample at 10 samples per second (SPS or Hz) or 80Hz, set by the RATE pin on the IC.

Some module boards have a jumper on the reverse side of the board to set the rate, as shown below. Connecting RATE to 1 (Vcc) sets 80Hz and 0 (GND) is 10Hz.

Data Read and Gain Control

CLK is set by the processor, DAT is read by the processor. These two
digital signals make up the serial interface to the HX711.

CLK should be kept LOW by the processor unless clocking during a read cycle.

The data is read as 24 bits clocked out, one bit per clock cycle, from the HX711. Additional clock transitions (+1 to +3) are used to set the mode for the next read cycle according to the handshaking sequence below.

• When an ADC reading is not available, DAT is set HIGH by the HX711. CLK is held LOW by the processor.
• When DAT goes to LOW, the next ADC conversion can be read by the processor.
• The processor sends 25 to 27 positive (transition LOW to HIGH) CLK pulses to shift the data out through DAT one bit per clock pulse, starting with the most significant bit (MSB), until all 24 data bits are shifted out.
• The HX711 will then hold DAT HIGH for the remainder of the clock pulses.
• Channel and Gain selection for the next read is controlled by the number of additional CLK pulses (+1 to +3) send to the HX711, for a total of 25 to 27 clock pulses as shown in the table below.

Fewer than 25 and more than 27 clock pulses in one communication cycle will cause a serial communication error requiring a HX711 reset.

Reset and Power Down Sequence

When power is first applied, the power-on circuitry will reset the IC.

The CLK output from the processor is also used to reset the HX711 IC.

When CLK is

• LOW, the HX711 is in normal working mode.
• changed from LOW to HIGH and stays HIGH for longer than 60μs, the HX711 is powered down. It remains in this state while the signal remains high.
• changed from HIGH to LOW, the HX711 resets and restarts normal working mode.

Following a reset the hardware defaults to Channel A input, gain 128.

In Part 2 we’ll look at the software for this module and how to use the hardware/software to implement a weigh scale system.

If you search for ‘Arduino’ and ‘weighing’ you very quickly come across the HX711 board module and an associated world of strain gauges and load cells.

All this looked interesting with some learning along the way. The result is that I took a dive into the subject and ended up with some new knowledge and ideas for the future.

In this first part I cover the hardware requirements and in the next how to write software to implement a weighing system.

The HX711 ADC

The HX711 is a precision 24-bit Analog to Digital Converter (ADC) designed for weigh scales and industrial control applications. It readily obtainable from all the usual online marketplaces as ready-made modules implementing the standard datasheet circuit.

The IC interfaces directly with a up to two Wheatstone Bridge load cell’s differential outputs and incorporate signal amplifiers.

Channel A differential input can be programmed with a gain of 128 or 64. Channel B has a fixed gain of 32.

Large gains are needed to accommodate the small output signal from the sensor. When a 5V supply is used for the sensor, the gain corresponds to a full-scale differential input voltage of ±20mV with gain 128, ±40mV for 64 and ±80mV for 32.

Load Cells

Load cells come in various shapes and are rated from 0.1kg to over 1000kg full scale. They come in many different types of form factors but the two most common are bar and strain gauge types.

Bar-type Load Cells

Bar type load cells are straight bars with strain gauges attached to the point where it has maximum bending. A variant of straight bar is the S type cell design for tension (pulling) applications.

Each load cell has four strain gauges connected in a Wheatstone Bridge formation. The labeled colors correspond to the color-coding convention coding of load cells. Red, black, green and white wires are connected to the load cell’s strain gauge and yellow is an optional ground or shield wire to lessen EMI.

The direction of the force arrow labels on the load cells must match the direction of resultant force. If the resultant force is straight down (the usual in a weighing application) then the load cells must be installed so with the force arrow labels pointing down.

Strain Gauge Load Cells

Strain gauge load cells are commonly seen on the corners of bathroom scales and similar ‘platform’ type applications. Each load cell is a half Wheatstone bridge, as shown below.

This type of load cell must be combined into a circuit of 2 or 4 gauges to create the full Wheatstone bridge, with each side of the bridge including the strain resistors from two of the strain gauge load cells. The circuit for combining four strain gauges is illustrated below.

A simple way to combine the wiring is to create a Combinator Board. Here the wires from the individual strain gauge cells are joined in a hub arrangement, producing the required Wheatstone Bridge connections. Shown below is the hub connection for a four sensor configuration.

Module Wire Connections

The HX711 module’s A channel interfaces to the load cell through four wires labeled E+ (or RED), E- (BLK), A-(WHT), A+(GRN), and an optional shielding ground SD(YLW) on the circuit board.

The B Channel interfaces to a separate load cell through the E+, E- (common with Channel A) and B+, B- connections on the circuit board.

E+ and E- are the positive voltage and ground connections to load cell; the A+/A-, B+/B- the differential outputs from the load cell.

The module is connected to the processor’s power supply (Vcc and GND) and 2 additional processor digital input pins to the module’s DAT (or DT) and CLK (or SCK). These digital pins are used to manage the limited configuration options available and read the data from the HX711.

Hardware Control

Sampling Rate

The HX711 can sample at 10 samples per second (SPS or Hz) or 80Hz, set by the RATE pin on the IC.

Some module boards have a jumper on the reverse side of the board to set the rate, as shown below. Connecting RATE to 1 (Vcc) sets 80Hz and 0 (GND) is 10Hz.

Data Read and Gain Control

CLK is set by the processor, DAT is read by the processor. These two
digital signals make up the serial interface to the HX711.

CLK should be kept LOW by the processor unless clocking during a read cycle.

The data is read as 24 bits clocked out, one bit per clock cycle, from the HX711. Additional clock transitions (+1 to +3) are used to set the mode for the next read cycle according to the handshaking sequence below.

• When an ADC reading is not available, DAT is set HIGH by the HX711. CLK is held LOW by the processor.
• When DAT goes to LOW, the next ADC conversion can be read by the processor.
• The processor sends 25 to 27 positive (transition LOW to HIGH) CLK pulses to shift the data out through DAT one bit per clock pulse, starting with the most significant bit (MSB), until all 24 data bits are shifted out.
• The HX711 will then hold DAT HIGH for the remainder of the clock pulses.
• Channel and Gain selection for the next read is controlled by the number of additional CLK pulses (+1 to +3) send to the HX711, for a total of 25 to 27 clock pulses as shown in the table below.

Fewer than 25 and more than 27 clock pulses in one communication cycle will cause a serial communication error requiring a HX711 reset.

Reset and Power Down Sequence

When power is first applied, the power-on circuitry will reset the IC.

The CLK output from the processor is also used to reset the HX711 IC.

When CLK is

• LOW, the HX711 is in normal working mode.
• changed from LOW to HIGH and stays HIGH for longer than 60μs, the HX711 is powered down. It remains in this state while the signal remains high.
• changed from HIGH to LOW, the HX711 resets and restarts normal working mode.

Following a reset the hardware defaults to Channel A input, gain 128.

In Part 2 we’ll look at the software for this module and how to use the hardware/software to implement a weigh scale system.

[Paul] participated in a hackathon at work and created a hack to help solve what was ultimately a people problem. A soda fridge at work wasn’t getting refilled when empty. Instead of trying to make people less lazy, [Paul] went with making the fridge more needy.

The first thing [Paul] did was make a soda fridge refill sensor from a scale. As the fridge got emptier, it got lighter. The scale senses that and can decide it’s time for a refill. The only part missing was how to read the output from the scale. To do that, he took an unusual approach.

The soda fridge sits on an analog scale with a dial. [Paul] saw there was no need to measure the exact weight of the fridge, only to detect a refill threshold. He came up with a simple hack: colored paper attached to the scale’s dial and an Arduino with an OSEPP COLOR‑01 color sensor pointed at the paper. The dial moves in response to the fridge’s changing weight, and the color sensor reads the color of the paper as it moves under the sensor. With a little bit of trial-and-error calibration and some barely modified sample code for the sensor, it was possible to reliably detect when the fridge required refilling. With the sensor done, it was time to use it to solve the lazy people problem.

In a way, the root problem wasn’t that people couldn’t be bothered to check if the fridge needed a refill – it was that the right people weren’t finding out at the right times. This resulted in spotty refilling as well as soda not being ordered when needed. This hack means that the fridge can now actively announce its state, which now allows things like notifying people via email that it is their turn to refill and re-order. It turns out that a fridge that can tell people what it needs has a much better chance of being serviced, compared to a one that has to wait for people to check up on it.

We’ve seen people interface directly to the load sensors in weight scales before, but this hack took a completely different approach.

Thanks to [Paul] for sharing.

Felxiforce is a force sensor that is very similar to FSRs we just wrote about in principal. They change their resistance when you apply force to them. (The flexi part of the name is because they are flexible) Felxiforces are about twice as expensive as their FSR cousins, but these are much more stable, and are calibrated to a specific weight. You can buy them in 1, 25, or 100lb ratings. This article was written using the 100lb version.

Like the FSR I’m not sure if you can get a really precise weight reading from it, it seems a bit shaky, and the output seems to be logarithmic, not linear. But it does have a much larger range than the FSR, and in general will be better if you you need to sense a range of weights, or need to guess how much water is in a cup based on the weight.

When using the flexiforce, you need to make sure all the weight you want to sense is directed onto the small sensing area. So you may need to make a jig to direct the weight if you want to sense something you put on top of it.

Hooking it up, and why

The flexiforce sensor ranges its resistance between near infinite when not being touched, to under 25K ohms when you approach its weight limit. When barely touching it, it has a resistance of around 10M ohms.

We can measure that change using one of the Arduino’s analog inputs. But to do that, we need a fixed resistor (not changing) that we can use for that comparison (We are using a 10M (1,000,000 ohm) resistor). This is called a voltage divider and divides the 5v between the flexiforce and the resistor.

The analog read on your arduino is basically a voltage meter. At 5V (its max) it will read 1023, and at 0v it will read 0. So we can measure how much voltage is on the flexiforce using the analogRead and we will have our force reading.

The amount of that 5V that each part gets is proportional to its resistance. So if the the flexiforce and the resistor have the same resistance, the 5V is split evenly (2.5V) to each part. (analog reading of 512)

But if the flexiforce is pressed on pretty hard, reading only 25K of resistance, the 1M resistor is going to soak up 40 times as much of that 5V. So the FSR would only get .12V. (analog reading of 25)

And if something is barely pressing on it, the flexiforce may be 5M of resistance, so the flexiforce will soak up 5 times as much of that 5V as the 1M resistor. So the flexiforce would get 4.2V. (analog reading of 852)

Code

The arduino code for this just could not be easier. We are adding some serial prints and delays to it just so you can easily see the readings, but they dont need to be there if you dont need them.

//From the bildr article http://bildr.org/2012/11/flexiforce-arduino/

int flexiForcePin = A0; //analog pin 0

void setup(){
  Serial.begin(9600);
}

void loop(){
  int flexiForceReading = analogRead(flexiForcePin); 

  Serial.println(flexiForceReading);
  delay(250); //just here to slow down the output for easier reading
}