Current Consumption and Sleep modes Boron

That will be interesting.

I’m not testing those at the moment but when I did have it up and running it did not show any data usage numbers. I did just see I was charged for going over the 3 Mb free monthly data limit by 1 MB.

Is this also true for the affected Borons?
Especially no Particle.subscribe() calls?
Are the affected Borons set to be stanalone devices or are they set as mesh gateways?

Boron01 (No MESH) - This is the Boron that I perform the detailed Current/Power Measurements
Boron02 ( ? MESH ?, not certain) - This is the 3xAA Boron
Boron03 (No MESH)- This is the “Factory New” Boron that I used to confirm Boron01 Current/Power measurements spike every 78 seconds.

I’ve only used Particle.subscribe on one project in my life. No Subscribe calls on any Device in my account currently.

I’m planning on taking Boron02 far away from my office today to determine if this issue is due to proximity.
If it is, I can’t re-run the Setup procedure for Boron02 with IPhone to select “No-Mesh” because it’s 1-week into a Battery Trial.
I can confirm this behavior didn’t occur prior to Tuesday afternoon.

Even though Boron01 & Boron03 are not Mesh Gateways, I guess they could be checking the Cloud for Mesh credentials when they “hear” Boron02 Startup locally ?

1 Like

Boron02 was taken ~1 mile away. The current spikes on Boron01 continued. This issue is Cloud Based.
The two Borons were too far apart to communicate via RF.


@Rftop, are all Borons running rc27? A little matrix of device vs configuration (rc#, mesh or not, power mode, etc).

DEVICE Name System Firmware MESH Y/N NOTES
Boron01 0.8.0-rc.25 & .26 NO Modem reacts to Boron02 NO_ACK Publish
Boron02 0.8.0-rc.25 likely, not sure 3xAA Battery, Wakes Up every Min. Sends No_ACK Publish for Battery Trial
Boron03 0.8.0-rc.26 NO Modem reacts to Boron02 NO_ACK Publish
1 Like

@Rftop, you could reconfigure Boron02 by holding down SETUP, flicking RESET and holding setup for 10+ secs. Then redo the mobile app setup and decide on creating a mesh or not. I suggest you DO create a mesh since your other Borons are stand-alone and this would give you another data set. I would also recommend updating everything to rc27.

I cant do that. It’s over 1 week into a Battery Trial (Trial #2). It’s already accomplished the equivalent of 1 year of Life @ 1-hour publishes on AA batteries. It may prove 2+ years is possible. I really don’t want to influence that experiment. It’s my only test with Gen3 products that hasn’t been influenced by the shortcomings, since it was designed to mitigate those.

I will update Boron01 to rc27 and see if the modem still spikes.
I’m open to any suggestions (except messing with Boron02 that’s performing a simple publish) :grin:.


Updated Boron01 to 0.8.0-rc.27, no change.
It’s modem is still receiving “something” from the Cloud approximately 4 seconds after a Publish from an un-related Boron02.

Boron01 rc.27 Tests: Code Description: Results:
OTA #1 void setup() {} Void loop() {} Modem Responds to Boron02 Publish
OTA #2; inside setup() Modem Responds to Boron02 Publish
OTA #3 SYSTEM_THREAD(ENABLED) &; Wont Connect to Cloud (White Pulsing LED)

Screen Shot of OTA #3

I appoligize for High-jacking this thread.
I’ve created Support Ticket ID 72129

No need to apologize. I learned a lot by just reading through this! One of the great parts of this community.

Thank you for testing and publishing all this info! Please do let me know what you find in the end.


What exactly is the support ticker for? The constant 1 min power spikes that seem to be cloud related?

Yeah, the [comm.protocol] INFO: rcv’d message type=14 that every Boron (maybe all Gen3) devices receive when another Boron on my Particle Account sends a Publish. This started on 12/18/2018.
This makes calculating Power Budgets for battery powered projects impossible.
Not to mention the unnecessary Cellular Data for every Boron that I’ll ever own.

1 Like

Have you considered testing the LTE version of the E-Series Electron since it’s a lot more stable and sleep modes are working?

Problem is, I have a pile of Borons that I purchased for projects. I’m determined to use them :face_with_raised_eyebrow: (not for mesh).

You’re correct, the E-Series has Sleep modes working, but it’s probably almost as power hungry as the Electron.

BTW, now that the 3xAA Boron Trial is over, I don’t have any Borons publishing (and causing the phantom check-in’s by other Borons). So I was able to perform 1 hour detailed current/power measurements today.

In 1 hour, the Boron LTE consumes 70 mWh.
That’s an average current of 17.5 mA @ 4.00V.
The 70 mWh was a result of 50+ Voltage and 50+ Current measurements each second, integrated to track total energy for 3600 seconds.

@rickkas7 do you have any power consumption data on the E-Series LTE module that we could compare to the Boron LTE Data that is being shown here?

@will & @peekay123
Did you realize some progress in the System.sleep() modes for the Boron (and Xenon too)?
Without that I can not field test my project…
Could we contribute or help somehow? (e.g. testing)

check here: Gen 3 improvements update - 2/12/19
In short, next release, currently in internal testing, will provide at least 2 sleep modes on the 3rd gen devices.


Wanted to loop back to this thread to note that as of this morning, v0.9.0 for Gen 3 hardware with support for sleep modes is now available! Give it a try and let us know your feedback!


Hi all. Trying this excerpt of test code. Boron LTE on 0.9.0 goes to sleep, but never wakes up, even on pin state change. Have to reset to get it back. Is this to be expected?

void setup() {
    pinMode(D0, INPUT);

void loop() {

I did try the deep sleep instead and it wakes up appropriately on pin D8.