Asset Tracker Data vs Power Consumption Discussion


This my first post, so forgive me if it contains too many questions or topics for a single post. I just wanted to start a discussion concerning data vs battery consumption on the AssetTracker.

Firstly, many thanks to all those who have added/improved/fixed the AssetTracker code libraries. It has been a journey for me to get everything working together. There was much to learn and 90% of it came from this awesome community and the contributions of code, suggestions, tools, apps and fixes. Now that I have the hardware fully working and can flash locally, I am back on my turf (software development) and I have few comments/questions.

When using the AssetTracker, it seems to boil down to data vs power consumption and I am attempting write the software that can handle both scenarios. I have been collecting info concerning power and data consumption for the MCU, FuelGuage,GPS & Cellular module. Below are my findings followed by some questions. Please feel free to correct any information I may have gotten wrong.

– Data Savings —

  1. Buffer as much data as possible within your desired publish time frame and send all the data at once.
  2. Publish less data by using short names and abbreviated data.
  3. Publish fewer messages by processing locally on the device to determine when to publish by considering times/dates to monitor, alert priorities (GPS boundaries), GPS read intervals, buffer size, etc.
  4. When using Sleep(), use the SLEEP_NETWORK_STANDBY option if you are publishing more than one event per day. Each re-connect uses 6144 bytes, which is the same amount of data as 19.32 hours of keeping the cellular module on and maintaining a connection. If you are publishing less often, you should not use that option and manually turn the to save data. (and power).

– Power Savings –

  1. Use DEEP_SLEEP_MODE and only wake up on motion or timeout (ping/battery check).
  2. Increase your sleep timeout to as long as possible.
  3. Turn on the GPS only when acquiring a fix and immediately turn it off, unless you require more updates than the time it takes for the GPS to re-acquire a fix,
  4. Wake up Fuel Gauge only when you need a battery reading.
  5. Initialize Accelerometer only when you need it such as prior to going to sleep with the wakeUpPin option in the sleep() function.
  6. I read on the Adafruit website that the GPS on the Electron can log 16 hours to it’s internal non-volatile memory even while the Electron is in sleep mode. By utilizing this functionality, you could log a GPS reading every minute while the Electron was asleep for 15 minutes and publish them all at once in a single event. This could save considerable power as the Electron is the biggest power consumer.
  7. If you are not using the SLEEP_NETWORK_STANDBY option, do not turn on the Cellular module until you have read the battery, obtained a fix and are ready to publish your message.

– Questions I can’t find answers to –

  1. What is the power consumption of the cellular module when it is active, in DEEP_SLEEP with SLEEP_NETWORK_STANDBY on and in DEEP_SLEEP with SLEEP_NETWORK_STANDBY off? Obviously, in most cases, it is bests to leave Cellular.on() for data savings,but not all.
  2. What is the power consumption of the Fuel Gauge (Awake and Asleep) ?
  3. What are the data / power implications between connect/reconnect or maintaining a constant connection to the cloud?
  4. Do you save data if you use the NO_ACK option when publishing a message?
  5. What are the pros/cons of storing configuration values in SRAM retained variables or EEPROM?
  6. Would it be worthwhile to take control of the RBG and turn brightness to zero when the AssetTracker was not sleeping ?

– Suggestion –
When the Electron is sleeping and the Cellular module is on (SLEEP_NETWORK_STANDBY mode), my understanding is that a ping is sent every 23 minutes or so ‘keepAlive()’. Would it not be possible to provide a checkbox on the dashboard that instructed you guys to include a flag in the next ping that tells the Electron to wake it up. It’s TTL would only be 30 seconds so maintenance would be minimal.

This could resolve the issue of a remote installation where you needed to change a setting, flash new code, or get an GPS reading when the Electron sleep timeout is days.

My low-power application waits 10 seconds after waking up and listens for a request to stay connected. Otherwise, it has timeouts for everything (GPS Fix, Cellular Connect, Cloud Connect, etc) and is always trying to get back to sleep in order to save power. On failure, I introduce a new sleep() timeout and retry x number of times. It usually will eventually correct itself.

Anyway, thank you for taking the time to read this and perhaps contribute to it and thanks again to the really smart guys on this forum for making the ElectronTracker possible.

Bill Freeman


Thanks for this discussion, I learned a few things as I have been dealing with similar issues with my project which collects event data and then connects hourly to the towers/cloud to upload. Unfortunately I can’t answer any of your unanswered questions.

It would be great to have a table somewhere that summarizes baseline power/data usage in all of the different sleep modes.

Mainly I would like to know how to minimize battery usage while also minimizing data usage on an hourly connect frequency. Can the cell modem be turned on every 20 mins or so to keep this connection alive and not incur the reconnection data penalty? or does turning off the modem automatically force a reconnect process on the next connection. What command would keep this connection going with the minimum amount of data sent? Particle.process()?

I’m a newbie with the Asset Tracker. Any chance you’d be willing to share (some of?) your code? Your power savings ideas are exactly what I’m hoping to do. I’d rather not re-invent the wheel!

Thanks either way! :slight_smile:

Sad to see there hasn’t been any feedback on this topic :frowning:

@ir_fuel, although the OP makes a pretty good post, you may want to check out these threads with more info about power and data savings: