Electron Data Usage Investigation

No, I don’t see that at all!
With “up to 2/3+” and the subsequent condition, I was just refering to the possible worst case, but didn’t imply I was ever seeing that and definetly not on a regular basis.

Ok cool… to be fair the retry can happen 5 times before it resets the network connection which will then also force a full handshake… so it goes from data savings up to half down to like zilch if you have connectivity problems, but that won’t be any fault of the NO_ACK option :wink: Perhaps the benefit can be seen the opposite way, your data didn’t get through with your connectivity issue, but you also are not retrying over and over and re-handshaking … so give or take 6000% data conservation with NO_ACK in poor connectivity situations?

2 Likes

@Bdub @ScruffR I used MDMA’s code for testing the data transfer rates on the Electron using the NO_ACK vs. not using it and I came up with the following results.

I was just checking the data usage updates on the SIM Card Billing page, but its resolution was too small to see what was going on.

Here is the data usage for my Publish Event not using the NO_ACK feature:

Reset counter of sent/received PSD data!

Read counters of sent or received PSD data!
CID: 31 SESSION TX: 0 RX: 0 TOTAL TX: 0 RX: 0

Publish some data!

Read counters of sent or received PSD data!
CID: 31 SESSION TX: 200 RX: 61 TOTAL TX: 200 RX: 61

And here is the data transfer rates after adding the NO_ACK to the Particle Publish event:

Reset counter of sent/received PSD data!

Read counters of sent or received PSD data!
CID: 31 SESSION TX: 0 RX: 0 TOTAL TX: 0 RX: 0

Publish some data!

Read counters of sent or received PSD data!
CID: 31 SESSION TX: 200 RX: 0 TOTAL TX: 200 RX: 0

As you already stated were saving 61 bytes of data on every Publish when using NO_ACK.

If I updated every five mins over 24 hours, that’s 288 publish events.

288 Publish events x 200 bytes = 57,600 bytes per day using the NO_ACK

288 Publish Events x 200 + 61 Bytes = 75,168 bytes when not using the NO_ACK.

So for my testing the NO_ACK is saving me 75,168 - 57,600 = 17,568 bytes.

17,568 bytes of savings / 200 bytes per publish event gives me an extra 87 publish events that otherwise would have been eaten up by the ACK sent from the server. That’s pretty good data savings :smile:

As discussed the savings get to be much more if there is a situation where the Electron begins to retry sending the message up to 5 times.

2 Likes

@BDub @mdma

Quick question about:

Does this work with any Deep Sleep time frame? Like does it work the same if I sleep for 5 five mins vs. 5 hours? How about a 24-hour deep sleep?

I’m asking because in the past I remember we had to ping the server every like 24 mins or something to avoid the handshake data penalty. Is that a thing of the past now with this new feature?

@RWB, as PR #953:

Reduces data consumption when the device is reset or wakes up from deep sleep.

1 Like

@Bdub @MDMA @peekay123

Do you guys know if the PR #953 also works when using a 3rd party SIM? Or does this only work when using a Particle SIM?

I ask this because I found this discussion somewhere and wanted to ask if it’s still true or not.

The **** SIM, working on the Particle Electron, will log on to a cell tower and connect to Particle’s Dashboard. You will see your data on Particle, and you pay **** for the data. So far, so good.

Here’s where it gets complicated: The Particle board uses UDP communication, and sets a 23 minute keep-alive ping to keep that connection alive, in line with what their own SIM is set to use with the various telco’s. The **** SIM times out much quicker (maybe around 3 minutes or so), and drops the UDP connection.

To keep the UDP connection alive, you can set a more frequent keep-alive ping on a Particle Electron (they have an IDE-level function for that), but that will quickly use your data. The figure is something like 1MB / 3 days. So the **** SIM, on Particle, works – but to get the same functionality it’s actually more expensive than Particle’s own SIM.

There’s a lot of discussion over on Particle.io about this topic; search for UDP and/or Timeout and/or APN in their Community. Note: You also need to set the Particle Electron to the APN value when using the **** SIM.

Hope that helps. Summary: Each company’s SIM seems well-suited to their own hardware, but some cross-pollination may occur!

It should work if deep sleeping up to 23 minutes with the modem remaining on. It may work up to 1 hour. It should not work after 1 hour. You should use: System.sleep(SLEEP_MODE_DEEP, 120, SLEEP_NETWORK_STANDBY);

It will, but the data savings really only applies if you are communicating with the Particle Cloud. As mentioned above in your quote, 3rd Party SIMs typically require a 30 second Particle.keepAlive(30) rate.

1 Like

That is very good to know!

The Ping consumes 122 bytes.

Does the initial cellular & Particle cloud handshake still consume 3KB to 6KB of data? And why would the handshake consume 3KB one time and up to 6KB the next? I have not tested the handshake data rates personally.

Man that is a big reason to not use 3rd Part SIM cards :smiley:

1 Like

@BDub Is there a way to be flagged if the first publish was unsuccessful when using NO_ACK?

Hmm? How would that work?
If it wasn’t successful the cloud wouldn’t know about the attempt and the device can’t know what happens with the event once it let go of it.
So the only way would be to ACK a successful event, but this is obviously undesired when using NO_ACK :wink:

The only thing you can check is the return value of Particle.publish() to know if the event was at least queued.

1 Like

I am trying to reduce Electron data usage, in this regard I have reduced my publish to the one shown below:

Particle.publish("f", levelString, PRIVATE, NO_ACK);

Does replacing “f” with “1” in the above function reduce my data usage ?

No it doesn’t - one byte is just as big as any other

Not sure how many characters “levelString” is, but, for example, if that string was reduced from 5 characters to 2 characters, then yes, that would reduce the total amount of bytes sent.

As @ScruffR said, replacing “f” to “1” won’t provide any data savings.

Is there a way to track or get a concrete number of how much data we are using per send. At the moment we have exceeded our data limit yet we do not send that much data. We are just trying to see how much data we are sending. Thank you

  • Shane_Mats

This may help you: