Battery life with different publish frequencies

Has anyone done studies on typical run time for different publish frequencies? Before I do some myself, I figured I would ask.

Great question!

I have been using the trackers for a few weeks now and just recently looked at some stats from the database. The trackers are running a slighly customized firmware that sends the default message every 15 minutes and can switch to 1Hz reporting after receiving a special command.

Here is a screenshot of the battery life of 5 trackers sending one event every 15 minutes (my STANDBY mode):

  • Unplug at 12pm from charger - 30% at midnight. Roughly 6%/hour.
  • Battery life is very uniform across the 5 trackers
  • Battery life stretches a lot below 10% and eventually we get to about 36 hours in this mode.

Now streaming at 1hz between 11:30am and 3pm:

  • Start at 11:30am with 95% battery - stop at 3pm with 65% battery. Roughly 8.5% / hour.

Surprise - surprise - the difference is much smaller than what I expected. The default tracker firmware does nothing to save battery: the GPS stays on all the time and the MCU as well. This seems to be the majority of the power consumption and the cellular usage, even every 1s does not weigh much compared to them.

The good news is that this is not too bad (at least in my opinion) for a first shot and there is obviously a lot of room for improvement in standby mode. It would be really nice if Particle shared more ideas and code to save power (which they discussed in a webinar but I am not seeing in the firmware). For my usecase, I do not need the GPS on all the time, but I would like to keep the cellular modem on. Would love to see an example showing this.

thomas

1 Like

And just as I go and check the status of the mysteriously named “sleep” branch on github, I see:

So I will guess I will be doing more tests soon! Thanks @eberseth.

I had a suspicion this was not the best for the battery …

I see that there is a new commit (which I do not have in my firmware tested above) to go into shipping mode when a low battery detection is detected:

So with this commit and the cutoff at 8% per default, I expect the battery life will be closer to 15hours (92% / 6%/h).

I decreased the 8% cutoff to 2% based on similar testing as yours in the sleep update. We are also looking into fuel gauge calibration/correction so that the charge state is a bit more accurate. Some of the challenges of coming up with this lower limit includes the uncertainty of remaining charge.

Thanks! I do appreciate your efforts.