Increasing Battery Life on Windows Mobile using GPS and Web updates

I have an app that runs on Windows Mobile and uses the GPS to update its location at various intervals. As expected, enabling the GPS chip uses more battery power. (no duh..)

So currently my technique has been to cycle the the GPS on/off at approx. every 4 minutes to acquire the location, do something if things changed, and update its location to the web only if necessary. Otherwise, shut it off again and wait.

On my one year old HTC Touch Diamond phone, with a fresh charge, leaving the screen ON (but dimmed), + WiFi, and doing nothing else but letting it sit there, I got a maximum of 6 hours from it.

This is "ok", but the usage of the GPS easily cuts an estimate of 2-4 hours of regular 'real-world' usage (YMMV).

The other option I've simply been thinking about is to have the web server instead signal the phone to update its location when needed, instead of the phone just doing it blindly.

That way, the phone only uses power to get a data connection and check the server. If the server tells it to update, only then does it turn on the GPS.

Except that the response time of that is much slower (I'm guesstimating), and if the phone is somewhere it can't readily get a stable update, then you won't even know its last location. At which point, you're stuck waiting.

I was hoping the phone could be more autonomous.

Is there possibly yet a better algorithm I could use to improve this setup?

Thanks.

From stackoverflow Sebastian Dwornik

• I think your current solution is going to perform the best and provide the best experience to the users.

  If you have your web server trigger the phone to update, you're really relying on too many outside things that could become disconnected (not sure if that affects your users, since you don't mention what the app does).

  If you can and haven't already, you could also make sure that your app doesn't turn on the GPS if the app is running in the background or while the screen is "asleep". That way you just fire it up as soon as the app becomes active and you're not wasting battery while the app isn't in use.

  Personally, I understand that if I'm using a Wifi/GPS/Data heavy application it's going to shorten my battery life considerably anyway. It doesn't seem like the decrease you're experiencing is too far out of line with other apps I've experienced. Keep it the way it is and make the user happy (even if they have to charge a little more often).

  From Justin Niessner

• Does the GPS engine that you are using have any accessible built-in low power operating modes. I have embedded a couple of different GPS chipsets from SiRF and u-blox into products and found that it was cheaper in battery power terms to leave the GPS switched on in its low power mode than to turn it off and then let it re-acquire. In my case it used less energy in a low power mode for all switch off times less than about 15 minutes.

  SiRF (SiRFStar-2 and SiRFStar-3) based GPS engines have a "tricklepower" mode where the GPS is only switched on for a couple of hundred milliseconds on each wakeup. The wakeup interval can be set to maybe 5 seconds, meaning that the power consumed is 5-10% of the continuously on state. There is some small tradeoff in accuracy, but the chipset will return to continuously powered mode if the quality of the fix is degraded.

  Sebastian Dwornik : Very interesting. I looked at the GPS Intermediate Driver API again and there doesn't seem to be any access to such lower level power configuration. :( Good suggestion though.

  Ian : I work on projects where we buy the chips directly from the manufacturer and incorporate them into our products. As a result I have direct access to all of the functionality provided by the chipset that I am using. If the chip is hidden behind an API then the supplier can limit access to functions so that they can use any GPS engine that supports the set of functionality that they have exposed. A possibility is that the low power mode selection is hidden behind an update rate selection option. A faster update rate may be more power efficientfor the reasons in my answer above.
  From Ian