Sleep with Network Standby on Electron

Apart from the SIM carrier’s keep-alive transmission, then, was there additional data being transmitted to Particle’s cloud for reestablishing a connection, and that is what was addressed in 0.6.0?

That bit about the hash compare between last and current state to better know whether a full handshake is required or not was added/improved.
Also the behaviour how the cell module was “powered down” was polished AFAIK

The 0.6.0 firmware just only sends the keep alive message to the Particle Clould if you have not done it within 23 mins. It’s all handled automatically now even if sleeping and waking up fresh to keep your data transmissions to a minimum when using Particle Cellular service.

That’s how I understand it at least.

So if we compare the overall data usage (i.e. everything from the Particle SIM’s cellular handshake to the data necessary for reestablishing a cloud connection) between versions prior to 0.6.0 and post 0.6.0, will there still be a substantial difference between waking from deep sleep every hour compared to sleeping for 15-20 mins? Prior to changes in 0.6.0 the difference in data transmission between 1 hour of deep sleep vs 15 mins was tremendous, and I’m wondering how much of that was attributable to the cellular network as opposed to Particle fully reinitializing the device (or was it 50/50).

I think the data savings was implemented before the 0.6.0 firmware so I would say your seeing the increase in data usage because of the 4440 byte handshake every time you woke up later than 23 mins past the last time you last pinged the cellular service & Particle Cloud.

If you reconnected within 23 mins than your only needing to send like 144 bytes of data vs the 4400 which is a huge difference.

Ok I think I understand, thanks! So now that reconnecting to the cloud, even if only once per hour, consumes 135 bytes instead of 4400, most of the data usage hit has been reduced.

@LloydChristmas I’m pretty sure any reconnection past the 23 min mark since the previous ping will cost you the 4400 bytes even with the new firmware. They can’t change the 23min required cellular network ping updates with software changes.

1 Like

I am having trouble establishing what exactly happens with SLEEP_MODE_DEEP and NETWORK_STANDBY both enabled. I just upgraded to 6.0 so I may be able to make some observations in the next few days that help me figure this out but it would be nice if it was documented more clearly.

For example, my application connects hourly to the cloud to send in counts from a sensor. In void(setup) I check whether the awake time was what we expected when the sleep interval was set, or if it was shorter (awoken by trigger from the sensor). If triggered by the sensor I update the count and then go back to sleep with wakeup at next hour, otherwise I connect to the cloud and publish data, then go to sleep with wakeup at the next hour. I originally was turning off the cell modem before sleeping, but am now leaving it on to try and reduce my data usage which is very high with hourly publishes under the previous firmware. I am trying to power this unit with a small solar setup that may or may not have access to decent sunshine so I am trying to keep power usage as low as possible.

My questions are:

1a. Will my Electron wake up and maintain the cell tower connection on its own (the 23 minute I’m still here message)?
1b. Will I see any activity on the RGB LED?
1c. Does the cell modem need to be left on for this to work?

2a. If it does not - if I wake up after an hour, do I still pay a data penalty for rehandshaking with the cell towers, but not for reinitializing the cloud connection?
Any estimates for what this data penalty may be? (I am sending relatively little data each hour so this may not be a problem if I can stay in the minimum tier).
2b. If the data penalty is similar to before (6-7kB was my understanding) what is the most efficient way to maintain this connection to the cell towers but minimize power use? Will waking every 20 minutes, turn on cell modem, particle.connect(), particle.disconnect(), turn off cell modem keep the connection going without the data penalty, or does the cell modem need to stay on?
2c. Would implementing something like the above in my code be more power efficient than leaving the cell modem on and using NETWORK_STANDBY?

If anyone can provide insights I would greatly appreciate it

1 Like


1a. No
1b. No
1c. Yes - standby is not off
2a. the other way round
2b. extend sleep time, which reduces both - data usage for cell tower handshake is negligible in comparison to cloud handshake - SLEEP_NETWORK_STANDBY says it: standby is not off - with SEMI_AUTOMATIC cloud connection control is up to your code
2c. with a default sleep longer than keep the alive periode you can (have to) find your own sweet spot settings.


Hey Drew!

I have this Electron Solar setup running now.

To keep you data rates as low as possible and avoid the 4kb handshake data cost when connecting to the cell tower after being away for longer than 23 mins then you need to send data or wake up and ping the Particle Clould every 23 mins or less.

@ScruffR If he does not want to wake up and send data but only wants to wake up and send the Ping / Keep Alive message, what would that ping code look like? I’ve always just published within the 23min window.

The Sleep Network Standby just keeps the Modem in standby mode so when you wake up the connection to the cellular network is already live and ready to send data. If you didn’t use Sleep Network Standby it would take longer to establish a connection to the cellular network and the Particle Cloud which may or may not be an issue for your particular application.

Here is a template for how I’m running my Electron off a Solar Panel and only connecting to Cellular and the cloud if the battery SOC is above 20%. If it’s below 20% SOC I do not attempt to connect to Cellular Network or even turn on the Cellular Modem to keep power consumption to a minimum.


int ledPin = D7;              // LED connected to D1
int sleepInterval = 60;
int button = D0;

void setup() {
 pinMode(ledPin, OUTPUT);    // sets pin as output
 pinMode(button, INPUT_PULLDOWN);    // sets pin as input

void loop() {

FuelGauge fuel;

if(fuel.getSoC() > 20)


  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(250);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(250);                  // waits for a second
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(250);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off

  System.sleep(D0, RISING,sleepInterval * 2, SLEEP_NETWORK_STANDBY);


  //This Code Puts the Electron into Deep Sleep for 1 hour and we shut down the Cellular Modem Completley to drop sleep power super low.
  //This code is requried right now to get the Cellular Modem to Sleep when using System-Thread(Enabled);  mode.
  //FuelGauge().sleep();   // Not putting the Fuel Gauge to Sleep provides better SOC readings but does cost us 200uA in current consumption. 300uA current consumption in this sleep mode.
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(150);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(150);                  // waits for a second
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(150);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(150);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(150);                  // waits for a second
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(150);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off

  System.sleep(SLEEP_MODE_DEEP, 3600); //Sleeping Deep for 1 Hour

I’m not 100% sure, but if you wake before the 23min end (e.g. every 20) and have a Particle cloud connection active, the “ping” should be done implicitly without further coding, but @Dave might have more accurate info about that.

1 Like

So, you can fully deep sleep the device and wake back up, establishing a new cellular connection. Often the cloud handshake is optimized to use your last secure session, and will save you bandwidth, so you don’t need to stay alive to save those bytes ( and you may burn more through pings ). The ping is meant to keep the UDP ‘socket’ alive, but that’s separate from how long lived the secure session can be.

I hope that helps! :slight_smile:


1 Like

@Dave thanks. For firmware 0.8.0 rc4 do we still need to include Cellular.command("AT+CPWROFF\r\n");
in our code for deep sleep? Or has turning off the modem - to reduce power - been resolved?

I’m pretty sure it’s been automated in the latest firmware versions but, I’m not 100% certain.

I think this is the most updated info on how to best use the current sleep modes if you have not seen it already.

Thanks @RWB! Particle team, please feel free to comment. Maybe @Dave, @suda, @jeiden or @Bdub would have an idea?

@rickkas7 may also Understand 0.8.0 rc4 updates too.

It is not necessary or desirable to turn the modem off like that. The sleep calls will take care of turning the modem off if necessary now.

Hi @rickkas7. So, what should @RWB code look like now? Please provide example code for @RWB above case.

I have a similar project to the of @RWB. For my project, I need to measure an analogue voltage every minute and report to the Particle cloud. I’ve tried idle and deep sleep… Plan to try stop mode with Sleep Network Standby next. Whatever the solution is, I need to find something that has low power usage and low cellular data.

Thanks for your help.

In that code, if the SoC is low, just call:

System.sleep(SLEEP_MODE_DEEP, 3600); 

Turning the cellular on, then off, is only necessary when the Electron is powered up for the first time, otherwise the modem won’t go fully into deep sleep. When you wake up from sleep, you can go back to sleep without turning the modem on and off, saving even more power.

You could use the reset reason or a retained variable to make the logic more robust and do the modem on/off technique, so there would be three possible cases. However, in practice you’d only ever exercise that case when you first turn on an Electron with a discharged battery, which doesn’t seem very common.

1 Like

Thanks again @rickkas7.

I got my stop mode (pin + time) with Sleep Network Standby working tonight. I’ll take my Electron hardware into work and measure the mA and mAh.

Aside question: for E-Series LTE (and yet to be released Boron LTE) what power saving should users anticipate?

I am setting up an electron to transmit sensor data to ubidots every 10 minutes and sleep in between transmissions. I am using network standby.
I am battling to get the units to update firmware.
I have set the device to particle.publish every 30 min so there is some connection to the particle cloud.
Should I use system mode automatic , semi automatic, or manual?
Should I use particle.connect after waking ?
Do I need to introduce a delay after particle connect to give the cloud time to send the firmware update ?