With BT off, and GSM on, using the rephone (xadow v2) GPS, and posting to a MQTT server via TCP at one sample per second (with a 200ms blink of green led each send, otherwise led is off), I get about 52 minutes of runtime from the fully charged 520mAh rephone battery which came in the kit. No other xadow boards besides the GPS one are connected. Eclipse code is entirely event driven, no ‘delay’ calls, so the part should be able to go into its appropriate sleep mode.
According to my SIM provider, I used around 465k total of data per hour at that rate. MQTT posting is done with a very lightweight library and a persistent socket connection, is at QoS level 0 (with no server response), and cleartext (no ssl), so I’m not sure how to reduce the data usage much more (around 132 bytes per update, including TCP overhead; 57 bytes of that is payload).
Even if I budget 5mA for the led, it’s only on 20% of the time (200ms out of each 1s sample), so it would add another 1mA to the total load.
I haven’t measured the current draw from the battery during the run, partly because in doing so earlier I bricked my rephone at the time (using a spare one now). I’ve seen the links to what the rephone is rated to use (30mW) seeedstudio.com/forum/viewt … =71&t=6485 during radio+GSM. The GPS chip data sheet specifies a 21mA ‘acquisition’ and 18mA ‘tracking’ current usage. 52 minutes of runtime is around 3100 GPS samples and MQTT posts.
A 520mAh battery should let me draw 520mA for an hour, so for it to run at less than an hour I must be drawing 520mA, which doesn’t line up with what the parts are drawing. If I wanted a device to run like this for a day I would need a 13Ah battery, which is impractical for any kind of a wearable.
Has anybody else tested real-life battery life with a program running on the rephone doing GSM communication? Obviously, pushing more data exercises the radio more. I was hoping for much better battery life than what I’m getting - the best case scenario is that there are some changes I can make to ensure lower power usage when the device is not actively communicating. I will perform another test at a lower sampling speed (like every 5s) to see how much of the power consumption is baseline and how much of it is a result of data posting.