Preliminary 0.9.0 Boron LTE current consumption in sleep modes measurements


Tested device: Boron LTE + I2C OLED (SSD1306)
Measurement device: Xenon + INA219 featherwing + OLED featherwing

Preliminary results for different modes:

  1. Active mode, cloud connected, not actively communicating:
    ~13 to 16 mA
    ~10.5 mA most of the time, spikes of at least 56mA every 20 sec or so.
  3. System.sleep(BTN, FALLING, 60)
    ~10 mA
  4. System.sleep(SLEEP_MODE_DEEP);
    ~9.7 mA

I also tried to add before the sleep command and the current slightly decreased to ~10mA for mode 2. which makes sense since it becomes equivalent to mode 3.

Now what doesn’t make sense is why power usage is that high in sleep modes, especially compared to xenon? Apart from mode 2. when cellular module is still on, the 2 others should be similar to what is found for Xenon c.f. this thread.
By the way, I replaced the Boron with a Xenon and run the same code. The power usage figures are the same ones found in aforementioned thread.
Can someone else conduct a similar test to rule out any mistake in my setup and/or code?

The code I’m using is shared here.
It can be compiled for either Boron or Xenon and the display is not required for the tests.


Probably need to power via the battery input pin for lowest sleep currents.

I assume you were using the USB port to power everything.

Was the OLED screen connect also? That will probably add some current while sleeping also.

I was seeing the Boron LTE pull 30ma on average and spike to 50ma when connected along with 7 Xenon nodes connected when powered via USB.


I’m powering the tested device with the battery only. The measuring device has its own battery and USB is disconnected when running the test. In active mode the OLED display adds 1 or 2 mA and in sleep mode I don’t see a difference when it’s connected vs. disconnected. I send the ‘display off’ command to the OLED before going to sleep mode, which puts it in sleep mode too.
And like I mentioned, replacing the Boron with the Xenon, keeping everything else the same gives me sleep mode current usage in the 0.1 mA range.


13 < > 16mA when running on a battery for LTE is really good in my book.

Im seeing double that when powering via 5v USB so nice to see the battery at half the power consumption.


It’s possible to get down to around 694 µA to 750 µA on the Boron in SLEEP_MODE_DEEP. powered by the LiPo connector (3.6V). You need to Cellular.on() before doing This is the case on the Electron/E Series as well. Since the modem is put into sleep mode using AT commands, if the modem is off, it won’t go into lowest power mode.

This code will get into low-power mode.

#include "Particle.h"


void setup() {

void loop() {"Turning cellular on");
    delay(15000);"Turning cellular off");;
    delay(10000);"about to SLEEP_MODE_DEEP");
    System.sleep(SLEEP_MODE_DEEP, 0);

However, that is still much higher than it should be, and engineers will be looking into this soon.


I’m consistently seeing 801-805 µA in SLEEP_MODE_DEEP for Boron LTE on 0.9.0, Manual Mode & :

  • 3.61 VDC measured at the Li-Po Connector
  • Current measured w/ µCurrent GOLD inline on negative conductor.
  • µCurrent GOLD powered by 3xAA, using 1mV/µA switch setting once Sleeping Begins.
  • Li-Po connector is the only physical connection to the Boron LTE (other than Cellular Antenna).
  • Code:; Cellular.on(); delay(15000);; delay(10000); System.sleep(SLEEP_MODE_DEEP, 0);

Amps obviously decrease when the supply voltage is increased to something more typical of a Li-Po, but the mW tracks pretty close on a slow voltage sweep over the Li-Po operating range. I guess 3.60V is just as good as any for comparing current results.

Good job folks. …Sub-mA Sleep isn’t bad for the first Sleep implementation on the Boron LTE.
I look forward to seeing how this progresses in the near future :smiley:


I repeated the measurements with your code @rickkas7 and @Rftop and I got the same figures as yours.

What I have trouble with is how to use System.sleep(uint16_t wakeUpPin, uint16_t edgeTriggerMode); and System.sleep(SLEEP_MODE_DEEP); these don’t get me anywhere lower than 9mA…

but taking cues from your sample code, I then tried this:

        // cellular module off,  stop mode;
        System.sleep(BTN, FALLING, 300);

==> power usage down to 1.2 mA

and this:

        // cellular module off, system off mode;
        System.sleep(SLEEP_MODE_DEEP, 0);

==> power usage down to 0.7 mA

It looks like is required before System.sleep() and it also needs few seconds (> 3 sec) to effectively turn off the cellular module. This is different than how it works on the Electron and I hope next firmware updates will address this difference.


This snippet on the Boron running 0.9.0 via battery appears in my tests to bring power consumption down below 1mA:


void loop() {;

However my loop never wakes up. I’m researching that now and will post back.


On mesh devices you need to pull D8 high to wake the device. There is no timed wake from deep sleep with Gen3 but Stop Mode sleep will only draw very little extra current over deep sleep.


By stop mode sleep do you mean SLEEP_NETWORK_STANDBY? And it would still need a wake pin, if I understand correctly?


No Stop Mode sleep is what you get when you execute System.sleep(pin, edge, timeout)


Have any of you been able to use the System.Sleep for a longer duration than 5 minutes? I use this in my code to initiate a stop mode sleep for 5 minutes.;
    digitalWrite(statusLED, LOW);
    System.sleep(BTN, FALLING, 300);

I am currently using Automatic mode, waking up every 5 minutes, taking readings, publish an event and then fall back asleep. There is very little power consumption while it is sleeping which is fantastic however if i program this to be longer than 5 minutes, let’s say 30 minutes using this:;
    digitalWrite(statusLED, LOW);
    System.sleep(BTN, FALLING, 1800);

It never seems to wake up again. I am theorizing it doesn’t wake up like it should after some duration OR maybe it’s waking up but not re-connecting properly before falling back asleep.

Next steps:

  1. Determine exact breaking point (works at 5 minutes, doesn’t work at 30 minutes) Where does it break.
  2. Investigate behavior using manual mode. Confirm it is connected before publishing and then falling back asleep.

On the plus side, the Boron can take a lot of sleep, wake up, take readings, publish, sleep… cycles with consuming very little battery. I’ve at 80 cycles since yesterday. Started at 96% and is only at 95% LiPo 6600 mAH battery. Pretty sure If i can get it to sleep properly for 30 minutes it’ll easily last the 3 months that I need it to.

Have you seen this behavior before? is there a good workaround? Do I need to use Manual mode and control the Cellular separately?


After seeing your post, I tried 30 minutes on a Boron LTE and it worked fine.
I use Manual Mode though.


How do you determine this? If you are publishing to the cloud, you most likely need to wait for Particle.connected() before proceeding after sleep. You may want to blink the D7 LED when you wake to see if it is waking or not as well.


Peekay123: Nothing more than it just never publishes anything to the cloud with the only line of code that changes was the 300 --> 1800. I originally had 300, confirmed it worked, changed it to 1800, it never posted anything, changed it back to 300 it published things, changed it to 1800 and it didn’t publish anything. I need to set it to 30 minutes and use a stop watch to look at it 30 minutes later to see if it ever does the breathing cyan. Since that was the only line of code that changed I figured I wouldn’t have to use manual mode but I’ll give that a try tonight.


Rftop… fantastic. I was hoping it was something stupid I was doing or just having to use Manual mode. My application requires longer sleep duration and I didn’t want to hassle with using the EN pin. Would you mind posting your exact code for doing this in manual mode. Maybe i missed something obvious. I’ll give manual mode a try tonight.


I didn’t mean to imply that Manual Mode would be required… I only mentioned it because that’s what I tried first.

I’d also bet this is the problem:


Sleeping 30 minutes is probably close to the worst possible time duration given that the keep-alive is 23 minutes. That tells me that at 30 minutes the device most likely has to re-establish a connection from scratch. You may end up using less battery and less data if you wake up every 20 minutes… Of course, would need to be tested…


So I must of goofed two days ago somehow. When I tested it last night, I was able to sleep and wake up every 10 minutes, 20 minutes and 30 minutes without any problem while still in the default automatic mode. It’s been publishing every 30 minutes ever since. Not really sure what I did wrong two days ago that it wasn’t publishing. Sorry for the confusion everyone. I’ll be better on testing more before asking this community to keep the content relevant. In any case, I still will add the Particle.Connected() as a precautionary measure and best practice but doesn’t look like it’s required.

Great suggestion. I will update it to be 20 minutes and see how it does. With the new LTE being significantly less power, I think even waking up every 20 minutes, the 6600mAH battery will last the duration I need to.

For my application, I’d like the Boron to last 10 weeks total on a 6600mAH lipo battery and publish as often as possible without having to do a solar charger or take it down to recharge at all. If needed, I could do a even larger battery pack. Next improvement I need to make is cut the power to the sensors when sleeping using GPIO pins. The 3 sensors I have draw about 1 mA as measure using my Fluke meter.


Interesting you should say that. I’m also finding that my Boron 2/3G’s are not publishing reliably to the cloud after 10-min sleeps. I’ve also been using AUTOMATIC mode until now and these sleep lines:;
System.sleep(A4, RISING, 300);

Even more intriguing is that there are quite a few cloud connect events where the battery voltage is sent, but the Webhook JSON is NOT sent. See below:

Can anyone shed some light on this behaviour?
I’ve just changed to SEMI_AUTOMATIC mode and the intermittent JSON sends continue.