Electron data usage

General
1

Over a 24 hr period, my dashboard indicates I used just under 0.24MB to Particle.publish the following data string every 30 minutes, which would appear to mean each publish ate up about 5k (240,000 / 48) = 5k. Is this normal? Seems a big data debit for a short string.

Pasted image1619×118 15.8 KB

I used a ds3231 to yield the time string and didn’t call any other cloud functions than publish, and I uploaded the application via dfu:

void setup()
{
  Wire.begin();
  get3231Date();
  yearint = year + 2000;
  sprintf(ds3231timeStr,"%s, %d/%02u/%02u - %02u:%02u:%02u",weekDay,yearint,
    month,thedate,hours,minutes,seconds);
  get3231Temp();
  sprintf(publishStr, "%.2f° %s  %.2f", temp3231, ds3231timeStr, fuel.getSoC());
  Particle.publish("electron1", publishStr,60,PRIVATE);
  delay(1000);
  System.sleep(SLEEP_MODE_DEEP, 30 * 60); //30 mins
}//setup()

EDIT: Also the Electron stopped publishing on battery when battery SOC (builtin firmware FuelGuage) dropped to 80, which seems premature. Not positive it was due to “low” battery but it did resume publishing after giving it USB power.

2

On cellular, every bit counts. If it’s not necessary to include the time, then don’t. The time it’s published is already included in the publish itself. Adding that manually will only lead to increased data usage. If you do need a date, try to keep it as short as possible, without elaborate formatting. Literally every bit counts.

3

@Moors7. Absolutely agree, I was just using time to verify as I test this thing out. At this point I’m just trying to get a handle on what to expect. Since the docs suggested that Particle.publish was a lean user of data (sorry can’t find the reference now), I was a little taken aback that a 39 byte string would cost 5k. Is there any info available on the approximate data cost of Particle functions?
Edit: Found the reference. https://docs.particle.io/guide/getting-started/data/electron/
I’m definitely got to spend some brain cells to digest all those issues!
Edit2: The reference above in one section says "Whenever the Electron has to join the cellular network it will “handshake” and register itself " such as waking from sleep. Is it less costly to keep it awake?
Also since “Pings (once every 23 minutes if no other communications happen and device is awake. 122 bytes)” would it wind up being more data efficient to publish just under every 23 minutes?

4

The docs have a lot of great info, and I know there is a SLEEP and PUBLISH example planned, but what I see right now is:

Being "Sleepy" When your Electron is asleep you won't use pings and power consumption will be much lower! For now, hop over to the firmware reference and read about sleep. Examples coming soon!

If you use Deep Sleep, the Electron will power up again from reset and re-handshake with the server. This will consume anywhere from 3KB to 6KB more data than if you were to use a STOP mode Sleep that effectively halts the processor and keeps the cellular modem on and connected to the cellular network. See example below.

Also to note, deep mode sleep does not turn off the modem, only the processor. You have to call Cellular.off() prior to sleeping for the lowest power consumption, at the expense of more data consumed on your next boot.

Try changing your sleep line and loop like this:

void setup()
{
  Wire.begin();
  pinMode(D1, INPUT_PULLDOWN);
} //setup()

void loop() {
  get3231Date();
  yearint = year + 2000;
  sprintf(ds3231timeStr,"%s, %d/%02u/%02u - %02u:%02u:%02u",weekDay,yearint,
    month,thedate,hours,minutes,seconds);
  get3231Temp();
  sprintf(publishStr, "%.2f° %s  %.2f", temp3231, ds3231timeStr, fuel.getSoC());
  Particle.publish("electron1", publishStr,60,PRIVATE);
  delay(1000);

  System.sleep(D1, RISING, 30 * 60); // Halt processor right here for 30 mins

} //loop()

I'll report back with the official example when I have it...

2 Likes
5

@BDub
I tested various even simpler versions of your example (stop mode rather than deep sleep) and could not obtain a reliable publishing result. (I did correct your order of sleep parameters). At best, I got a 40-60% publish rate with stop mode sleep, often much lower. Earlier I obtained essentially 100% when using deep sleep. But as @BDub says, deep sleep causes much high data use so I really want to figure out how to use stop mode with the electron. Publish always seems to return true regardless of whether it actually does publish or not (due to using UDP?). All the apparently correct led flashes occurred yet publish would occur seemingly randomly. Anyway, I went on to try various hard and soft delays before and after publish and that did not improve the reliability, not that I had any reason to believe it would. While deep sleep seems compatible with the electron, something about stop mode appears to muck up either the cellular or cloud connection. Has anyone had better luck?
BTW, I’m getting rssi of -85 and qual of between 19 and 25

6

@BDub
When I switch the build firmware from 0.4.9 to the develop branch on local build (and use LTO=n with gcc version 5.2.1 20151202), the electron code below works pretty near flawlessly at least for 15 minutes :smile: . Be nice to know why, but I have no idea, so I’m not sure which of the changes made the difference. Will run it overnight at much longer intervals and see if the improvement holds up. Curiously though, if I disconnect the battery and run entirely on usb, I still get plausible values for VCell and SoC and they diminish over time. :confused: Huh?

#include "application.h"

FuelGauge fuel;

char publishStr[20];

void setup() {
  pinMode(WKP, INPUT_PULLUP);
}//setup()

void loop() {
//  CellularSignal sig = Cellular.RSSI();// this also works
//  sprintf(publishStr, "%i %i", sig.rssi, sig.qual);//this also works
  sprintf(publishStr, "%.2f %.2f", fuel.getVCell(), fuel.getSoC());
  Particle.publish("e1", publishStr,60,PRIVATE);
  System.sleep(WKP, FALLING, 60); //1 min
}//loop
7

@bpr thanks for reporting back on what you are seeing. I’m remembering now that there are a few pull requests that needed to be merged for Stop mode to work and session move to also work. These won’t be present in v0.4.8-rc.6 or v0.4.9, but will be in the next Electron firmware release so keep an eye out for that (coming soon).

SoC will update very slowly over time, so any immediate changes to the battery state won’t be noticed. You can call .quickStart(); to rebase the SoC value but there is currently no automated way to do this (detecting that you are running on USB power only). I’m not sure there will ever be a system event type of way to detect this (removal of the battery) either since an open battery looks very much like a high resistance battery (charges up instantly). I won’t go into ways you could do this in your application code right now, but I think it should be possible if that’s something you need.

1 Like
8

@BDub Update: Electron code shown above (just changed to publish every 30 min rather than every min) continues to publish very well over 12 hr period (one missing publish out of the 24 expected). :grinning: But again, I don’t know whether this success is due to turning off LTO or moving from 0.4.9 to develop or both. Unfortunately, I forgot to unplug the usb cable so didn’t get a sense of battery usage yet. :sob:
Needless to say, I’m very happy with the increased reliability!

9

That’s good to hear, and we do recommend compiling with COMPILE_LTO=n. System parts are compiled that way.

Because you don’t have some of the latest changes, when you wake up from sleep, since the modem is being turned off, it will have to go back through a longer blinking green cycle connecting back to the cell network and cloud before it can publish. Is that what you are seeing?

10

@BDub
3 seconds white then
20 seconds green blinking then
3 seconds cyan breathing

11

Cool, makes sense. When you try again with 0.5.0, you should be able to wake right up from Stop mode sleep and publish immediately.

1 Like
12

@BDub Over the past 2.5 hrs, instead of the VCell and SoC data, all I’m getting now is spark/device/app-hash notifications, which occur at times I should otherwise be getting the battery info publish message. The app-hash is the same every time. Without any intervention from me, it went from reliable publish events to just the app-hash messages. The docs say app-hash is sent after flashing, which doesn’t apply here. Any idea what’s happening?
I should mention that the rgb led behavior is exactly the same as when I was getting the coded publish event.

Pasted image1361×306 50.1 KB

13

Further update. Remained stuck in spark/device/app-hash land past 4 hrs so I woke it up by momentarily grounding WKP. This produced spark/device/app-hash notices only. I plugged in the usb cable and tried the wakeup. Another spark/device/app-hash. I removed the battery and woke it up. Another spark/device/app-hash. Only when I removed both the battery AND usb and then reconnected both usb and battery did I manage to get it publishing upon momentarily grounding the WKP pin - though not reliably at first (6 successful out of 9 awakenings) despite the electron displaying the apparently correct rgb led sequence.
The publish message reports VCell and SoC and is reporting “4.07 97.18” now that it’s publishing again ( also the red led if off so it’s not sensing a need to charge) so it doesn’t appear that it ran out of power…
Any thoughts, anyone?

14

To rule out other issues, can you try leaving your Electron on instead of going to sleep. Just create a if (millis() - lastTime > 30*60) { } block to publish your data from and see how that does.

15

Will do. But we need to keep in mind it started to fail after about 16-17 hrs.....

Here's what I'll run:

#include "application.h"

FuelGauge fuel;

char publishStr[20];
uint32_t lastTime = 0;

void setup() {
//  pinMode(WKP, INPUT_PULLUP);
}//setup()

void loop() {
  sprintf(publishStr, "%.2f %.2f", fuel.getVCell(), fuel.getSoC());
//  Particle.publish("e1", publishStr,60,PRIVATE);
//  System.sleep(WKP, FALLING, 1800); //30 min
if ((lastTime + 1800000) <= millis()){
  lastTime = millis();
  Particle.publish("e1", publishStr,60,PRIVATE);
 }
}//loop
16

Sounds good, and I’d like to propose a change that will help avoid wrapping errors, and also publishes on boot.

#include "application.h"

FuelGauge fuel;

char publishStr[20];
uint32_t lastTime = millis()-(1800*1000UL);

void setup() {
}

void loop() {
  sprintf(publishStr, "%.2f %.2f", fuel.getVCell(), fuel.getSoC());
  if (millis() - lastTime > 1800*1000UL) {
    lastTime = millis();
    Particle.publish("e1", publishStr, 60, PRIVATE);
  }
}
17

OK, I just flashed your change.

18

@Bdub , @bpr Hey guys I have a Electron just sitting here and little time to play with it so I figured I would flash this code and see if I saw the same issues.

I just flashed Bdub’s code above and here is the first publish event I received after the first flashing the Electron over 3G cellular which worked perfectly.

Should the App Hash be showing up with every publish along with the Battery Voltage and SOC Readings? I don’t see that when publishing from the Photon.

Pasted image1349×113 12.4 KB

Never mind the 2nd update only shows the battery status info as desired.

Pasted image1346×58 4.71 KB

So it looks like that Hash info is only sent when the device first connects to the cellular network. And this is the extra data that occurs when you wake the cellular module from Deep Sleep instead of sleep it looks like.

19

@BDub, the always on (No stop mode sleep) electron test produced very good results every 30 minutes, usually exactly to the second, from 4:09pm Calif time through the night until 11:09a
m today, then my the dashboard stopped recording events, until I restarted in on returning home from work this evening and found it still publishing. I’m assuming the reported dashboard problem, rather than the electron, was the cause of the stoppage. I had also setup a particle subscribe e1 mine log window but that shutdown at the same time. I think we can assume it’s a stop mode sleep interaction as @RWB also found enter link description here

20

That’s good to hear! Also I’ll update you with my test :smile: I’ve been running my posted code above since yesterday on battery alone on my U260 (3G) and just saw another publish come through. "name":"e1","data":"3.44 1.28" At 1.28% charge, I decided now would be a good time to plug it back in to charge it up again :wink: