Sleep with Network Standby on Electron


#41

I think that part of the docs needs some overhaul once 0.6.0 is officially ready for release :wink:


#42

I have another question regarding deep sleep. So from release 0.6.0 onward, when the Electron wakes from deep sleep it no longer needs to fully reinitialize but rather send a reconnect message (and provided that the Electron’s local state matches the one last communicated to the cloud, the 4400 byte transaction is omitted). Is there any time limit for reconnecting with the 135 byte reconnection message? Could I reconnect once every 12 hours or even 24 hours? Thanks in advance.


#43

@LloydChristmas It’s 23 mins. If you don’t send a update within 23 mins it has to do the full 4400 byte transaction handshake.


#44

I think that was prior to 0.6.0


#45

No, that’s a Particle cellular network thing that has not changed. 3rd Party cell networks require more frequent check-ins.


#46

Folks, let’s not forget that it’s 23mins for a Particle SIM only. 3rd party SIMs will be much lower.


#47

The 23min keep alive (for Particle SIMs) is not a firmware thing but a cell provider “requirement”. So that will not change with future versions either.


#48

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?


#49

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


#50

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.


#51

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


#52

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.


#53

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.


#54

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


#55

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.

I am using SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED)
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:
If I have SLEEP_MODE_DEEP and NETWORK_STANDBY enabled…

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


#56

AFAIK:

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.


#57

@drewperkins

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.

SYSTEM_MODE(_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

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

void setup() {
 //Serial.begin(115200);
 pinMode(ledPin, OUTPUT);    // sets pin as output
 pinMode(button, INPUT_PULLDOWN);    // sets pin as input
}

void loop() {

FuelGauge fuel;


if(fuel.getSoC() > 20)
  {


  Cellular.connect();
  Cellular.ready();



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

  }
  else
  {

  //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.
  Cellular.on();
  delay(10000);
  Cellular.command("AT+CPWROFF\r\n");
  delay(2000);
  //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.
  //delay(2000);
  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
  delay(150);
  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
  }

#58

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.


#59

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:

Thanks,
David


#60

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