@RobMeades, the Particle servers need to be sent a keep-alive at a maximum interval of 10 seconds. Going to deep sleep will close all open Cloud-connected sockets since the processor is not running to maintain them. A new handshake is required whenever this occurs or when a keep-alive is not sent within 10 secs or you have specifically run Particle.disconnect(). There is a way (experimental and unsupported) to wake an Electron by “calling” it but this requires a data/voice SIM. I believe there was a topic on this on the forum.
1 Like
So if I call Particle.connect(), then go to sleep, I need to call Particle.connect() again?
I think you need a Particle mode that is decoupled from processor state. If all my traffic is uplink (which is the case for many sensors) I need to be able to sleep to save power (while maintaining RAM and time) and I am really not interested in handshaking again until the 23 minute timer is hit.
@peekay123: surely not 10 seconds? My cellular battery wouldn’t last a day.
Nope! Wake reestablishes the state as you went to sleep. So if you were connected you'll be reconnected automatically, if you were disconnected you won't be reconnected next wake.
Again, this is something else as the cloud ping. This is the cell ping.
1 Like
That’s sounds good! I will have a play.
Thanks for all the very swift and enlightening help guys, really appreciate it. 
2 Likes
@RobMeades – were you able to use semi-automatic mode to get the behavior you desire?
I have a similar application… I want to wake up only the CPU and poll a sensor once per minute, but leave the cellular modem in standby mode (not sending any data) all of the time unless the sensor value changes enough to warrant sending the update. (Sending a keepalive every 20ish minutes would be fine, of course, even if the sensor value hasn’t changed.)
Currently, I’m in automatic mode. I go into deep sleep with sleep_network_standby, but every minute when I wake up to poll the sensor, a small amount of data is sent. This just plain doesn’t work – I use up as much battery as just staying awake all of the time, and I use way more data than just staying awake.
Jeff
Have you tried System.sleep(WKP, RISING, timeout, SLEEP_NETWORK_STANDBY)?
I’ve noticed that this used less battery than deep sleep in my case.
1 Like
@JeffInCO: what I do is, as @ScruffR says, set SYSTEM_MODE(SEMI_AUTOMATIC); and then, if I know I’m going to send nothing for quite a long time (hours), I will do System.sleep(SLEEP_MODE_DEEP, sleepForSeconds); or, if I am in a more active state, I do System.sleep(WKP, RISING, sleepForSeconds, SLEEP_NETWORK_STANDBY);. In the former case, the system will wake-up from reset and the Electron board will re-register with the network, which costs a bit of time/power but is fine for such a low frequency. In the latter case my code will continue running from where it stopped after the wake-up. In order to treat the two cases in the same way I also use STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY)); so that I have a set of variables (prefixed with retained) that will survive a reset.
4 Likes
@ScruffR – I will try the stop-mode sleep (i.e., sleep(WKP, RISING, timeout, SLEEP_NETWORK_STANDBY). I have not tried it before, because the documentation wasn’t clear that code execution would resume from the statement immediately following the call to sleep so I didn’t see any advantage. Also, I don’t really have a pin to trigger on… I guess I can specify an unused IO. I think you’re implying that, after waking from stop-mode sleep while the modem is in SLEEP_NETWORK_STANDBY, that there will be no data transmitted unless my application publishes or a keep-alive is needed?
@RobMeades I’m already using retained memory to keep track of state while in deep sleep; just hadn’t worked out the details necessary to use semi-automatic mode. Ultimately, I’d like to get back to what I had with my earlier implementation of this project (Arduino Pro from Sparkfun with a 2G cellular modem) I could run for a month on 4 AA’s. I suspect that I will need to actively manage the cellular in semi-auto mode, taking advantage of deep sleep whenever possible, in order to achieve this.
Thanks to both of you for the ideas!
Yup, that's OK - I just used WKP as this will also wake the device from deep sleep with a rising edge and hence not pose any difference to the way you already got.
Exactly - providing you wake within the keep-alive time (23 minutes for the Particle SIM, but can be down to 30sec on some 3rd party SIMs).
I appreciate the info provided here. Can someone confirm that I’m understand this correctly?
If I’m using SLEEP_MODE_DEEP on the Electron for one hour and then waking to take sensor readings, my data usage would not be lessened if I was using SLEEP_NETWORK_STANDBY (instead of SLEEP_MODE_DEEP) since I’m outside of Particle’s 23 minute keep-alive time. Or would SLEEP_NETWORK_STANDBY still prevent my Electron from having to handshake?
System version 0.6.0 (currently pre-release 0.6.0-rc.1) should have some tweaks to cut on data usage after deep sleep, but I haven’t tested that yet.
But pre 0.6.0 you need to wake once every 23 min in order to not cause the 6K renegotiation cost.
So you’d need to find the optimum balance between power and data usage for your specific use-case.
When will the version 0.6.0 available for use?
That’s a question that has proven to be difficult to answer. Particle had to push release dates of previous versions quite regularly since testing needs time and found bugs during RC phase need to be ironed out before going public.
To help cutting the testing time people are welcome to try pre-release versions and report issues by opening GitHub issues
https://github.com/spark/firmware/issues
And keeping an eye one the milestones can give you a feeling how things are going
https://github.com/spark/firmware/milestones
The deep_sleep_data_usage looks like a nice improvement. I would have thought that the handshake/session authentication was a process more dependent on the server-side, but it seems like it’s actually more of a client-side process. I also wonder if (and how much) data is expended in relocating cell towers, determining handoffs, etc, upon each wake-up.
1 Like
Cellular signalling won’t be charged to you by the operator, though here will be some (small compared to the user data numbers mentioned here) power consumption impact.
Ah. Waking up and connecting every 15 minutes seems to use very little data compared to once an hour.
3 Likes
Are you using SLEEP_MODE_DEEP?
Since putting the electron into deep sleep doesn't turn off the cellular module (at least from what I've read), can I use SLEEP_MODE_DEEP instead of SLEEP_NETWORK_STANDBY for 15 minutes and still avoid the handshake?
SLEEP_NETWORK_STANDBY is an option that can be used with Standby (deep) or Stop mode sleep, not an alternative.
I’m using this:
System.sleep(inWake, RISING, 900, SLEEP_NETWORK_STANDBY);
…but I’m not on 0.6.0 yet.
Ah ok. I didn’t realize they could be used together. The way System.sleep is documented it doesn’t seem like the two are compatible.
1 Like