Low-Power Boron LTE, using the EN Pin


This is a great post - thanks !

I would like to recreate your tests with my own boron /TPL5111 setup to better understand my power consumption and properly size my battery packs.

Would you mind posting your full boron code for trial #1 and #2.

Much thanks,


I have several versions of Code for Trial #1 (Solar) where I made adjustments.
I’m not sure which one was the “Final”. I need to look at those closely.
As you know, sleep modes are available now which makes Trial #1 almost obsolete.
Sub-mA Sleep currents on the first firmware update means we’re better off using Sleep when Solar is an option IMHO.
However the PMIC adjustments and temperature monitoring for Li-Po charging are still valid with Sleep Modes + Solar.

Here’s Trial #2 Code. It’s Pretty Simple:
3xAA Boron LTE, 1-min

Trial #2 was a cold start every minute. Be aware that the Cellular Data Reporting wasn’t working in the Particle Console for several weeks around the time of this test. So I have no idea how much Data this actually used with the cold starts every minute. The SIM data usage spontaneously ramped-up after the trial was over and the Boron had moved on to other duties.

Please Note: Boron LTE’s stopped working on My local Cell Tower about 2.5 months after Trial #2.
I don’t know if these are related.

I’m glad we have the results for 3xAA without waiting a year for the batteries to deplete, but I don’t see any need for someone to repeat it with such an aggressive 1-minute interval ( no idea if that was your plan, just sharing my thoughts ) .


@Backpacker87 reported ~ 5MB/month for a Boron waking every 5 minutes using the EN pin & external timer.
It appears NOT connecting the the Particle Cloud helped significantly with data usage, per the thread below.

This is good news, as I wasn’t able to measure Data usage for Trial #2 during my battery tests last year when the Console had hiccups with Boron Cellular Data reporting.

Since the Data usage question seems to be answered now, here’s some more examples for a project that requires primary batteries:

A power budget for my location would be calculated using any publish schedule (1 mWh each publish) and the Quiescent current of 7.5 mWh per day.

The L91 is rated at 4,500 mWh for a 100 mA constant load (for the time spent connecting & publishing).
From looking at various discharge profiles, it’s safe to assume in excess of 5,500 mWh for the 76 µA shutdown current (just as a point of reference).

If you left the Boron LTE in standby mode, and never pulled the EN Pin high except for an Alarm/Emergency Condition, 3xAA batteries would last 2 years waiting until it’s needed (7.5 mWh per day to reach 5,500 mWh rating for shutdown current).

But most of us will want to send data at some scheduled interval for most projects.
For a 2-hour Schedule over 1 Year:

  • Operating: 1 mWh per Event * 12 Publish Events per day * 365 days = 4,400 mWh
  • Shutdown: 7.5 mWh per day * 365 days = 2,700 mWh
    Total = 4,400 + 2,700 = 7,100 mWh.
    7,100 mWh requires 6xAA in a 3 Series, 2 parallel configuration. (2) sets of 3xAA.
    That leaves you 30% additional capacity for a safety factor, or an increased update rate.

For 3xAA only @ 1 hour Shedule:
Works out to be ~ 5 months before the 3xAA L91 batteries need replacing.

  • Operating: 150 days * 24 publish Events * 1 mWh each = 3,600 mWh
  • Shutdown: 7.5 mWh per day * 150 days = 1,125 mWh
    Total = 3,600 + 1,125 = 4,725 mWh.

4.20V would be the Battery Alarm Threshold for 3xAA, to start sending a notification that 3 new batteries are required.

Note: The 1 mWh per Startup/Publish Event will likely be reduced if not Connecting to the Particle Cloud each cycle, by pushing data directly to your backend service (as @Backpacker87 did with Ubidots to minimize Cellular Data on each Event).

A comparison to the initial Sleep Mode in 0.9.0:
System.Sleep uses 700 - 800 µA Sleeping Current, or 10x that of Shutdown via the EN Pin.
But System.Sleep will continue to improve.

IMHO, for Projects with Solar or other recharging methods, Sleep Mode is the clear winner.
For power sensitive battery projects, the external timer wins.

Boron - One Year Battery Life Project
Boron Battery usage
Preliminary 0.9.0 Boron LTE current consumption in sleep modes measurements

Love this work you guys are reporting on using the LTE Boron in low power mode with the TPL5111 external timer.

I have a quick Newbie Question on using / powering the TPL5111.

My understanding is the when you pull the EN pin low it turns off 3V3 on the Boron.

So I assume you powering the TPL5111 (VDD) directly off your battery (LI+) pin?

Any concern about hitting the EN pin on the Boron with with 4.2 volts from the DRV Pin on the TPL5111 on wake.

Thanks for any input on wiring the TPL5111 on the Boron.

Again, thanks for your nice work this topic - super useful.


Since the EN pin is not a GPIO pin of the main controler but the enable pin of the switch/regulator (which is meant to deal with higher voltages than its output voltages) there is no risk in that (as long you stay within the specs of the switch/regulator.


@micromet, The TPL5111 doesn’t Power the Boron.
It only pulls/holds the EN Pin to Ground during a Shutdown.

I never checked, but I assume that the TPL5111 wont influence the EN pin state during normal operations, and the EN pin would remain ~3.8v from the Boron’s Pullup.

You may be thinking about The TPL5110, which is a different animal.

My TPL5111 Connections

TPL      Boron LTE
VDD   >   LI+
GND   >   GND
ENout >   EN
Done  >   D6 (your choice)


Thanks @Rftop for sharing your example.

Quick question, when the TPL chip pulls EN low to disable the Boron, where does the program resume when the EN returns High via the timer? Doe the program pick up where it left off in the main loop ? or does it reset and run the setup again?



The device would start fresh at startup. No variables will be retained unless using retained or eeprom.




This might be obvious, but can the Boron even charge while the EN pin is low? I would imagine that this disables power to the PMIC too…


Yes, the Boron can still recharge the Li-Po while it’s disabled (Shutdown) with the EN Pin.


What if the charging current is initially applied while the Boron is disabled? I can only seem to get the charge indicator light to common if I plug in the usb BEFORE the device gets disabled…


That wont work, as you discovered.

Here’s my understanding:
While operating, the PMIC decides if all the requirements are met for a Charge Cycle.
Once started, that Charge Cycle will continue even after a EN pin Shutdown, until the Cycle is completed or interrupted. The Boron will need to Boot before another Charge Cycle is started.

For instance: A Solar Boron will continue to recharge after EN pin Shutdown until the Panel Voltage collapses (significant Cloud Cover).

[Edit] But if your project has a Power Source Available for recharging, why not just use Sleep Mode instead of EN Pin ? The Boron can Sleep @ < 1 mA.


What’s interesting is that I can get the charge light to come on after the device is disabled when I plug in a usb powered by a wall charger… but when I plug in the usb from my Mac the light doesn’t come on…

Yes I’ve been looking at stop mode sleep vs this enable pin… hitting the enable pin just seems to be more efficient.

My devices are solar powered and go out in some remote places. They read a lot of sensors that can draw decent current. Also in some locations like northern Canada, there may be a number of days where I can’t charge the batteries because it won’t get above freezing. Using the enable pin will virtually ensure that I will never have a power failure.

I saw your thread about the sleep current in stop mode, and it looked like you could get down to 1.2mA… have you found out how to get any lower since?

Thanks for all this info!


I’ve never noticed that, but I just tried and confirmed.

My Guess is that during EN pin Shutdown, the PMIC reverts to it’s default/basic configuration.
The results would suggest that the Minimum Voltage or Current isn’t being met with a Computer USB port, but can be met with AC/DC charger, which makes sense.

But I seem to recall confirming that the user defined PMIC settings were obeyed after EN Pin shutdown… at least back in 0.9.0 firmware days. I could be remembering incorrectly.

System Power Manager can now change all your PMIC settings behind the scenes now, which significantly hurts Solar Powered Borons. I’ve paused my work with Solar Boron’s for now until that’s addressed. Most of my long term testing is invalid now.

Of course, a 12V Panel charging a SLA is still a good option if you have the space.


I thought if we called this:

(credit to @avtolstoy)

void setup() {
    // Delay for up to two system power manager loop invocations
    // Change PMIC settings
    PMIC pmic;

That would make the system retain user defined PMIC info?


Correct, but I don’t have any idea what other implications that has.
That Interrupt might be used for Li-Po safety, such as the safe trickle after an accidental over-discharge, etc.

It’s fine for testing, but not something I’m comfortable with for deploying to an actual Client location.


Good point. I wish we could get some clarity on the PMIC issue. I don’t really want to switch back to the electron form factor. Even though it’s a great device.


I’ve done some digging today, and apparently detaching the Interrupt shouldn’t cause any unforeseen problems. I’m going to ask a few questions in the previous Thread dealing with detachInterrupt(LOW_BAT_UC) and Solar Charging a Boron later today.
[Edit] Link to Post, for clarity.


Awesome, I’ll keep an eye on that thread.