Boron GPIO provides less current than Electron's GPIO?

I used in an Electron project its D0 (set to OUTPUT, HIGH) in order to power a load cell amplifier (HX711). Also, this allowed to switch off the load cell amplifier while the Electron is in deep sleep mode.

The load cell amplifier works also with the Boron (here D2), but the load cell amplifier is underpowered when adding the second load cell (in parallel) to the load cell amplifier, the D2 voltage drops from 3.3 to about 2 VDC.

Do the Boron GPIOs provide less current than the Electron GPIOs?
As an alternative power supply for the load cell amplifier, will the 3.3VDC be disabled during deep sleep?

The datasheet for the HX711 says normal current use is 1.4mA. A GPIO should be able to handle that or even double. What else do you have hooked up to the GPIO? A schematic would be helpful. Any code you can share as well?

Boron docs say GPIOs can put out 14mA max. That is a reduction when compared to the Electron which IIRC was 20mA max.

1 Like

I noticed this on the Sparkfun page:

How did you wire VCC and VDD when using the Electron (when it worked for you) ?
Did the HX711 operate with more than 1 load cell attached (when using Electron) ?

1 Like

I measure 2.7 mA (@3.3V pin) just for the HX711, without any load cell attached. Attaching both load cells, the current increases to 18.2 mA, which would be above the comfort zone of 14 mA (GPIO pin).

Putting several GPIO on HIGH and wire them in parallel improves the situation, but the voltage will get not higher than 2.7 VDC which is just the lowest level for the HX711.

For the Electron (when it worked for me): I wired the VCC and VDD to one GPIO, and this worked with two load cells attached to the HX711.

@blub, you will most likely need to add a transistor to drive enough current to power your devices.


That mostly explains why the HX711 + (2) load cells worked with the Election, and not a Boron (spec’d @ 20 vs 14 ma) .

1 Like

Yes, unfortunately, the lower current spec of the Boron seems to be the problem, i.e. the Boron is not just an improvement of the Electron, it is a different microcontroller.

I would be also happy to use the Boron’s 3v3 supply pin (which works for me), if one could switch off the 3v3 when putting the Boron in sleep mode (deep).

I hope one of the new sleep modes will allow to switch of the 3v3?

You can use a FET to power down the sensor when going to sleep.
You can also power down the 3v3 pin by pulling down the EN pin, but then your device is not sleeping, it’s deactivated till you let go of the EN pin again.

But if you want to know more about that you can look at the Boron schematics


@ScruffR Thanks for the hints!

Still, can you tell if it would be technical possible to switch off the 3v3? Or is this “hard-wired” and a potential future system.sleep() can’t switch it off?

@blub, it is not possible to turn off the 3V3 supply and still have the Boron operating since it uses 3V3. The EN pin on the 3V3 regulator is “hard wired” to be externally controlled. As @ScruffR and I said earlier, the ONLY way to control 3V3 to your peripherals is via an external transistor/FET.


@blub, I just came across your post. Are you still using the HX711 with the Boron? If so, are you getting nice stable readings? I’m getting very noisy data from my setup, but not with Electrons in a near identical setup. I’ve been struggling for months to get to the bottom of this but no luck so far (see my post here)
I power my HX711 from the 3.3v pin which should be able to handle the current without a problem. Ripple might still be an issue so I’ve added a 20uF tantalum and a 1000uF catalytic across the VCC and GND pins of the HX711. Unfortunately, this has not solved the issue for me. I’m keen to learn of your experience?

@Acrop, I actually had such spiky data already with the Electron, but not as many as with the Boron. After removing the outliers, I managed to get down to about 2 g scale reading precision.

In my case, the HX711ADC is creating many outliers which will bias an average value greatly. I can’t tell if this is due to the quality of its power supply or electrical noise in the amplifier or by bad shielded cables to the load cells. Anyway, I think it is pretty common to apply filters in digital signal processing, and I did this by using a median instead of just using an average. A median nicely gets rid of extreme values and therefore delivers pretty stable scale readings. I am actually surprised, that the HX711ADC library only provides an average and not a median function.

Therefore, I had to add myself a median function, as described in below code snippet. In this example, the median is calculated based on 100 instantaneous scale readings. Much less readings may also get already a stable result.

Below the wiring of the HX711 to the Boron (actually not really Boron, but the pins are the same) as well as a code snippet. I am using here the library HX711ADC (0.0.3).

I hope this helps.

#include  <HX711ADC.h>  //scale amplifier
#include  <Arduino.h>
#include  "math.h"

// HX711.DOUT	- pin #A1
// HX711.PD_SCK	- pin #A0
HX711ADC scale(A1, A0);		// parameter "gain" is ommited; the default value 128 is used by the library
float scale_weight = 0;
int const num_scale_readings = 100; //number of instantaneous scale readings to calculate the median
float readings[num_scale_readings];  // create arry to hold readings

void setup() {


void loop() {



  scale.set_scale(22);  //gain: this value is obtained by calibrating the scale with known weights
  scale.set_offset(100000); //offset: this value is obtained by calibrating the scale with known weights
  for (int i = 0; i < num_scale_readings; i++) {
    readings[i] = scale.get_units(1);  // fill the array with instantaneous readings from the scale
  scale_weight = median(readings,num_scale_readings);  //calculate median 

//Following functions are based on "", by David Dubins  

float median(float samples[],int m) //calculate the median
  //First bubble sort the values:
  float sorted[m];   //Define and initialize sorted array.
  float temp=0.0;      //Temporary float for swapping elements
  for(int i=0;i<m;i++){
  bubbleSort(sorted,m);  // Sort the values
  if (bitRead(m,0)==1) {  //If the last bit of a number is 1, it's odd. This is equivalent to "TRUE". Also use if m%2!=0.
    return sorted[m/2]; //If the number of data points is odd, return middle number.
  } else {    
    return (sorted[(m/2)-1]+sorted[m/2])/2; //If the number of data points is even, return avg of the middle two numbers.

void bubbleSort(float A[],int len) {
  unsigned long newn;
  unsigned long n=len;
  float temp=0.0;
  do {
    for(int p=1;p<len;p++){
        temp=A[p];           //swap places in array
      } //end if
    } //end for
  } while(n>1);

@blub Thank you for the detailed and most helpful response! The median is a nice work around for noisy data. I hadn’t thought of that! Hopefully one day we might see this incorporated in one of the HX711 libraries. I’d also like to hear from someone at Particle why there are so many more outliers with the Boron than the Electron.

@blub When next you are Down Under, I owe you a beer. Make it a large one! :upside_down_face:
For anyone trying the code above, don’t forget to include scale.begin(); in void setup(). Other than that, it works like a charm!

@Acrop I am glad this was helpful. Thanks for hinting on scale.begin(), which I added now in above code snippet. I actually didn’t test the code snippet yet with hardware, I was just extracting this from a larger code. Let’s see when I am next Down Under… :wink: