Does Optimizing cellular data usage Electron since 0.6.0 actually work?

Dear all

I’ve been testing data usage on the Electron after implementing the instructions found on the documents and following a lot of the advice on the various threads on this topic.

My latest test was using the recommendations on: https://docs.particle.io/reference/firmware/electron/#optimizing-cellular-data-use-with-cloud-connectivity-on-the-electron

i.e system semi automatic and the line “particle.connect” after 3 particle functions.

Is this actually working?
Any difference between Electron 2G and 3G on this feature?

I am putting an Electron (2G) running on v0.6.4 to sleep and waking up after various periods of time using: System.sleep(pin, FALLING, XXX, SLEEP_NETWORK_STANDBY). In theory, the wake ups should use less data (135B in the document above), but each wake up still consumes over 5K. I tried waking up after periods longer than 1hr.
If wake up occurs in short time (before 23min), then it actually only consumes the 122B use in one ping.

Thanks for the comments.

SLEEP_NETWORK_STANDBY only works for sleep periodes shorter than the Particle.keepAlive() periode (default 23 minutes for Particle SIM). That’s known behaviour and by design.

Yes, why should it not?

What feature exactly?

Hi… Thanks for the comments. Maybe I was not clear in what I meant. The doc says:

“Since 0.6.0
When the device first connects to the cloud, it establishes a secure channel and informs the cloud of the registered functions, variables and subscriptions. This uses 4400 bytes of data, plus additional data for each function, variable and subscription.Subsequent reconnections to the cloud while the device is still powered does not resend this data. Instead, a small reconnection message is sent to the cloud, which uses 135 bytes.
Prior to 0.6.0, when the device was reset or woken from deep sleep, the cloud connection would be fully reinitialized, which meant resending the 4400 bytes of data. From 0.6.0, the device determines that a full reinitialization isn’t needed and reuses the existing session, after validating that the local state matches what was last communicated to the cloud. Connecting to the cloud after reset or wake-up sends just a reconnect message, using 135 bytes of data”

The feature that I refer to is the one quoted in the document above, which states that in order to enjoy such data usage reductions, one must declare the device in SEMI_AUTOMATIC mode and then insert the Particle.connect command after declaring the particle.functions in the set up section.

the document does not say (or at least, it’s not clear) that the wake up time to keep such cloud connection has to be lower than 23min, hence, I was hoping to get quick and low data usage reconnections by using such recommendations.

Hmm, that hard tie with SEMI_AUTOMATIC mode is something new for me and I really doubt SEMI_AUTOMATIC is a must for that to work.
Having the connect after registration of functions, variables and subscriptions is just one way to prevent some “issues” users had, when registration happened too late (e.g. due to delays or blocking calls in setup() before getting to the registration block). And using SEMI_AUTOMATIC and connect later is just one way to make sure, the registration window hasn’t closed already by that time.

And this part of the docs is rather meant as some sort of primer to know what’s going on during handshake but doesn’t claim to paint a full picture of the ins and outs of the whole cloud topic. For the full picture the complete Particle chapter of the docs has to be taken into account.
https://docs.particle.io/reference/firmware/electron/#particle-keepalive-

When the introductory paragraph mentiones the device “reuses the existing session” the session has still be reusable which won’t be the case when the connection path got lost (due to the way how cellular connecctions work).

But I agree, placeing the data optimization paragraph there without any reference to keepAlive() is confusing and I’m going to add a sentence or two about that (Update: Change done)

1 Like