Current Consumption and Sleep modes Boron

[Rftop]

So, I realize nobody will believe me - but I may have figured out what’s happening.

As previously mentioned, I have another Boron LTE on 3xAA batteries, that’s operated by an external timer and it’s EN Pin. It’s in my office about 6 feet away from my test rig that I’m measuring Current/Power/Energy consumption with via Li-Po Connector.

The Boron w/ 3xAA batteries Boots up, sends a NO_ACK Publish, and shut’s down. That takes 12 seconds. That entire cycle is repeated ~78 seconds. It’s performing extremely well, I’ve very excited about the possibilities.

Starting yesterday afternoon, I started seeing the Current Spikes on a different Boron (on the Current/Power test rig), every 78 seconds. Today, I opened up the box on another Boron, same results.

Any Boron in my office receives Something from the Cloud (causing the spike) approximately 4 seconds after the 3xAA Boron sends it’s NO_ACK Publish.

I confirmed by removing a battery from the 3xAA Boron. The others no longer Spike @ 78 Seconds.
Something changed with the Cloud Backend yesterday.

[Edit: additional info]: The Boron LTE powered by 3xAA batteries does not have any Particle.variables, Subscribes, Functions, etc. It makes several changes to PMIC in Setup() and sends a publish with: Particle.publish(eventName, msg, PRIVATE, NO_ACK);
It then Waits 1 second, and Shuts down. The external timer wakes it after it’s been shutdown for 1 min 5 Seconds, the Run-time is 13 seconds = 78 seconds

I guess it’s possible that the Mesh Radios are initiating a reaction between the Borons ?

[RWB]

@Rftop

I guess it’s possible that the Mesh Radios are initiating a reaction between the Borons

Interesting.

So the Mesh networks that are not linked together are causing data to be transmitted and received every min or so without you knowing about it.

I wonder how much of any data this is consuming per day?

Are the Boron LTE units showing your actual data usage in the console consistently?

[Rftop]

@RWB

So the Mesh networks that are not linked together are causing data to be transmitted and received every min or so without you knowing about it.

I'm not sure if this is an interaction because of physical proximity, or if it's being pushed down from the Cloud with Gen3 devices. I have Gen2 devices sending a publish on my Particle account every second a lot of times, with no weird results. I know that a Boron Publish is causing other Borons to perform some sort of cellular communication with the Cloud. I've tried Mesh.off(); but I can't tell for certain if that actually changes anything (it doesn't from a Power Standpoint).

I've moved the 3xAA Boron, but it's still on the same property. I'll take it for a ride in my truck tomorrow to determine if the Mesh Radio is causing the other nearby Boron's to check the Cloud.

@RWB

I wonder how much of any data this is consuming per day?

I'm concerned about the phantom power draw it's causing. The 40% increase in Energy Usage is significant for what I'm planning to do with Boron LTE's (if this is Cloud Based), no issue for me if it's Mesh Related and can be stopped.

No, my console isn't updating the Boron Data Usage. It did for a day, but stopped.
Are any of your's Updating their Data Usage ?

[RWB]

@Rftop

I’ll take it for a ride in my truck tomorrow to determine if the Mesh Radio is causing the other nearby Boron’s to check the Cloud.

That will be interesting.

@Rftop

No, my console isn’t updating the Boron Data Usage. It did for a day, but stopped.

Are any of your’s Updating their Data Usage ?

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.

[ScruffR]

@Rftop

The Boron LTE powered by 3xAA batteries does not have any Particle.variables, Subscribes, Functions, etc.

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?

[Rftop]

@ScruffR

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 ?

[Rftop]

@Rftop

I’m planning on taking Boron02 far away from my office today to determine if this issue is due to proximity.

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.

[peekay123]

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

[Rftop]

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

[peekay123]

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

[Rftop]

@peekay123

you could reconfigure Boron02

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

[Rftop]

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	Mesh.off(); inside setup()	Modem Responds to Boron02 Publish
OTA #3	SYSTEM_THREAD(ENABLED) & Mesh.off();	Wont Connect to Cloud (White Pulsing LED)

Screen Shot of OTA #3

[Rftop]

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

[fishmastaflex]

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.

[RWB]

@Rftop

I’ve created Support Ticket ID 72129

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

[Rftop]

@RWB

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.

[RWB]

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

[Rftop]

@RWB

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

[RWB]

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

[Attila]

@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)
Thanks,
Attila