Low-Power Boron LTE, using the EN Pin

Connectivity BLE // NFC
1

After testing various small Solar Panels for the Boron LTE in this post, I decided to figure out how to operate a Low Powered Boron while we are awaiting Sleep Modes for Gen3. (Special Thanks to @Rwb for your help!)
The answer is the EN (Enable Pin), which works for all Gen3 Mesh Devices.

I’m now running 2 more field Trials:

  1. Boron LTE, 0.5-watt Solar Panel, 2,000 mAH Li-Po, external Timer for EN Pin to Shutdown Boron between scheduled Publishes @ 5 minutes, TMP36 to monitor temperatures inside enclosure (to disable Li-Po charging when temps are too cold/hot). RC-25 Firmware, mesh NOT enabled during initial setup w/ IPhone.

  2. Boron LTE, 3xAA, external Timer for EN Pin to Shutdown Boron between scheduled Publishes, for an Indoor Project since Solar isn’t an option. RC-26 Firmware, mesh WAS enabled during initial setup w/ IPhone.

Boron LTE Power Consumption:
I wrote code for a Photon that uses a 16-Bit ADS1115 and the µCurrent GOLD to measure the Power consumption of the Boron when powered via it’s Li-Po Connector. It averages 100+ differential 16-bit readings each second to calculate average current, totals the power over time, and prints a results line to serial every second.

A sample result for a 4.10V powered Boron LTE on the Li-Po connector includes: Startup, Cloud Connection, Publish, plus 1 sec before Shutdown is :

Power:   1.053 (mWh)    0.0011 (watt-hour)   0.925 (amp-seconds)
Total running time: 14.07 (seconds)-  this will change depending on location / cellular reception.

The Boron LTE’s average current when the EN pin is pulled LOW is 76 µA (Argon & Xenon are half that).

It’s easy to see that a tiny 0.5-watt Solar Panel & Li-Po can meet the power requirements for a Boron LTE that’s shutdown via an external Timer, on a reasonable schedule. I don’t expect any surprises for Trial #1 listed above. The enclosure is roughly 4"x2".
image

Trial #2’s Boron is operating on 3xAA batteries (Energizer L91) via the Li-Po connector and the same external timer to Shutdown via EN Pin between Publishes. The L91’s provide 4.5 watt-hours @ 100 mA load. Quick math says the 3xAA Boron should be capable of 4,000+ publishes. In my testing, Successive Cloud Connections have not taken any longer on the Boron LTE than it does after being without power for 12 hours.

Trial #2 is publishing every minute to speed up the 3xAA test. It’s Awake time is averaging 12 seconds before it shut’s itself down after the publish. It publishes the 3xAA battery voltage, the processor time for each wake cycle, and the total number of publishes since the trial began. The # of publishes are read/stored to EEPROM each cycle. I should know in a few days how close the 4,000 publish estimate is to reality. I’m using a 6xAA battery enclosure for the 3xAA batteries and Boron.
image

This is the external timer I’m using to Ground the EN Pin for Gen3 Shutdown:

It’s a great option for Gen3 projects that can operate on a schedule.

4 Likes
2

Trial #1 (Boron LTE, 0.5-watt Solar Panel, 2,000 mAH Li-Po, external Timer for EN Pin) required a modification to the Code during the experiment. Originally, the PMIC would not resume recharging the Li-Po if the input (solar) voltage dropped out completely. This means that charging would not resume after severe cloudy conditions, or night time. My solution was to add pmic.enableBuck(); inside the Setup() routine which runs each time the Boron Starts-up from the external Timer. The following PMIC settings were eventually used:

// Li-Po Power Management:
  pmic.begin();
  pmic.setInputVoltageLimit(5080);  //  for 6V Solar Panels   
  pmic.setChargeVoltage(4208);      //  Set Li-Po charge termination voltage to 4.21V,
  pmic.enableDPDM();  
  pmic.enableBuck();                //  enableBuck required when using EN Pin Shutdown.
  pmic.enableCharging();

I’m guessing that pmic.enableDPDM(); & pmic.enableCharging(); could be removed, but I haven’t confirmed that.

Once pmic.enableBuck(); was added, the daily Battery Profile became pretty boring, with no major unexpected results. The 0.5-watt Solar Panel can easily recharge the Li-Po when running a 5 minute Wake/Publish schedule. The Boron doesn’t terminate the Li-Po charge at 4.2V (SoC 100%) anymore, as with my previous tests using pmic.setChargeVoltage(4208). This isn’t necessarily a negative result, and I’m sure there is a explanation.
A typical 24 hour Graph looks like this:

image
image718×643 69.4 KB

SoC ranges from 93% (daytime) to 85% (night)
A typical Startup/Connection/Publish uses 1 mWh.
Quiescent current (while Shutdown via EN Pin) uses 7.5 mWh per day.

Notes for Trial #1:

  • The 2,000 mAh Li-Po battery that ships with the Electron is rated at 7.4 Wh, however those tests are conducted from 4.2V to 3.0V which is not a realistic range for actual operating conditions when calculating your Power Budget.
    image

  • The Tiny enclosure used for this Solar Trial doesn’t leave any room for insulation to minimize the Heating due to the Sun. Obviously, the Black color isn’t optimal either :sunglasses:

  • The Results show it’s EASY to operate a Boron LTE with Solar Recharge, even with a Tiny Panel.
    Your Panel size will depend on the average daily power for your application.
    Your Battery size will depend on the maximum days that you want to operate without any sunshine.

.

Trial #2 (Boron LTE, 3xAA, external Timer for EN Pin) is finally complete.
Energizer L91 AA batteries are used in this test. Fresh L91’s have an OCV of ~1.8V each, and 1.65V under load from Boron LTE. The AA L91’s are rated at 4.5 Wh at a constant 100 mA load.
image

As you can see the below, the Battery Voltage has started a steep decline indicating the end-of-life is approaching soon. The Boron performed 9,869 Publishes with the 3xAA Batteries in Series.

image
image708×565 48.2 KB

[Edit: Test Complete, final 12 hours shown below, 4.20V would be the Battery Alarm Threshold for 3xAA]

image
image757×567 55.6 KB

The average MCU time for Startup/Cloud Connection/Publish was 12 seconds. This does not include the 2 Seconds of “wait-after-publish” before Shutdown.

image
image714×566 51.8 KB

Notes for Trial #2:

  • The Boron LTE is truly a Cellular Module that’s capable of operating on AA batteries. This test far out-performed the calculations. I assume this is due to the cyclic nature using the EN pin (14 seconds on, 1 minute off) of this test. The 4.5 Wh published Rating of L91’s was under a constant 100 mA load.

  • Using AA batteries with a Boron LTE and the EN Pin opens up many possibilities.
    Specifically, for projects that may experience higher temps than we are comfortable with for Li-Po’s, or when the self-discharge of Li-Po’s prevent their use. 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 + a significant Safety Factor.

  • The Boron LTE datasheet list the suggested Max Voltage on the Battery Connector at 6.5V.
    Increasing the batteries to (4)xAA Energizer L91= 6.6V, which is technically out-of-spec for the Boron, but well within the PMIC specifications.

  • 4S (4xAA in series) and 3S2P (2 parallel sets of 3xAA in Series) configurations will be tested in the near future for projects that would require more than 10,000 Publish events before changing batteries, or many years in Shutdown mode. Using the EN Pin, A Boron LTE publishing Every Hour for 1 year before changing AA batteries is feasible.

Any comments, suggestions, or questions are welcomed.

4 Likes
3

[reserved for spreadsheet results]

4

Hello @Rftop,

Can you help me with a similar question?

My problem is a bit different than yours. I need the mesh device to recycle power to “itself”. I have looked at the TPL5110/1, but these two devices are designed to recycle power every (maximum) duration of two hours.

Is there a similar device that can extend this to 24 hours? I realize one can always use an external timer/relay like this:

but was hoping to miniaturize the circuit …

Thanks in advance for your input.

5

@Jimmie, there are folks on here a lot more qualified to answer that than I am.
You might solder your own resistor to the TPL to increase the cycle time above 2 hours, instead of the POT. Nope: 7,200 seconds is the Max according to TI’s datasheet also.

Or use any low-powered MCU (ATTiny) instead of the TPL to create your own.
I believe there is a programmable version of the classic 555 timer also.
Or you can wait for the Sleep modes to become available, but at a higher Quiescent current I presume.

1 Like
6

Thank you @Rftop.

You are right, the maximum is 2 hours.

I was hoping the TPL would do it as I have a board for it. BTW, I am not worried about power consumption because the system had to work 24/7. I need the timer because I want to recycle power to the Boron. System.reset does not solve the problem because the radio apparently is not reset.

7

@Jimmie, You could use a Pin to drive the EN Pin low for a Shutdown.
This will cause a Restart of the Boron:

SYSTEM_THREAD(ENABLED)

int donePIN = D6;   // Connect D6 to EN pin, probably should use a resistor ?
unsigned long resetTime = 1 * 60000 ; // min x 60,000(ms)

void setup() {
pinMode(donePIN, OUTPUT);
digitalWrite(donePIN, HIGH);
}

void loop() {
    
  if (millis() >=resetTime) {
    digitalWrite(donePIN, LOW);  // Drive EN Pin low causing a Restart. 
  }  
}

I’d expect the standard answer would be to eventually find yourself some form of external watchdog.

8

Thank you @Rftop, definitely worth checking out especially since the need to recycle power in my case in not related to a hangup issue, hence no need for a watchdog.

BTW, what size resistor do you recommend?

9

IDK, do you have any idea what size the internal Pull-up used for the EN Pin is ?
The code above works without using a current limiting resistor. I'm just guessing that it would be a good idea.
Hopefully someone else can chime in and confirm.

1 Like
10

The EN pin is connected to SYS_PWR_EN which is pulled high via a 100k resistor

image
image628×665 30.3 KB

https://github.com/particle-iot/boron/blob/master/pdfs/boron-v1.00-schematic.pdf

1 Like
11

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,

12

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

2 Likes
13

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

6 Likes
14

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.

15

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.

2 Likes
16

@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)
17

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?

Thanks,

18

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

1 Like
19

Thanks

20

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…