rephone+GSM+GPS battery lifetime very short

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) … =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.

There’s more going on than I first realized. The battery level API returns 100, 66, or 33 for values. After my rephone has been running on a fully charged battery, and it shuts off because the battery level is too low after an hour (based on current consumption), and I plug it back in - the battery level reads ‘66’.

Furthermore, after only about 20 minutes of being plugged in, the API for this (rephone-supplied) 540mAh battery reports 100. I would expect the Linkit 2502 (the part which is in the rephone) to take a minimum of an hour to recharge a relatively discharged 540mAh battery, based on how much current it provides during charging.

One explanation could be that the rephone is shutting down too early (while the battery still has charge left); when plugged back into a power source, it doesn’t have very far to ‘top off’ the battery.

This link from the LinkitAssist 2502 page seems to indicate much lower power usage than I am seeing with my device (only the GSM entry is valid, the GPS part is not the same as the rephone xadow v2 gps part).

There are some additional points in this topic which refer to the charging current provided, being 0.1-0.3C in ‘pre-charging’ and ‘constant current’ being 0.5C. … page#p1538