Running background services on a PocketPC

Question

I've recently bought myself a new cellphone, running Windows Mobile 6.1 Professional. And of course I am currently looking into doing some coding for it, on a hobby basis. My plan is to have a service running as a DLL, loaded by Services.exe. This needs to gather som data, and do som processing at regular intervals (every 5-10 minutes).

Since I need to run this at regular intervals, it is a bit of a problem for me, that the system typically goes to sleep (suspend) after a short period of inactivity by the user.

I have been reading all the documentation I could find on MSDN, and MSDN blogs about this subject, and it seems to me, that there are three possible solutions to this problem:

1. Keep the system in an "Always On"-state, by calling SystemIdleTimerReset periodically. This seems a bit excessive, and is therefore out of the question.

2. Have the system periodically waken up with CeRunAppAtTime, and enter the unattended state, to do my processing.

3. Use the unattended state instead of going into a full suspend. This would be transparent to the user, but the system would never go into sleep.

The second approach seems to be preferred, however, this would require an executable to be called by the system on wake up, with the only task of notifying my service that it should commence processing. This seems a bit unnecessary and I would like to avoid this extra executable. I could of course move all my processing into this extra executable, but I would like to use some of the facilities provided when running as a service, and also not have a program pop up (even if its in the background) whenever processing starts.

At first glance, the third approach seems to have the same basic problem as the first. However, I have read on some of the MSDN blogs, that it might be possible to actually conserve battery consumption with this approach, instead of going in and out of suspend mode often (The arguments for this was that the nature of the WM platform is to have a very little battery consumption, when the system is idle. And that going in and out of suspend require quite a bit of processing).

So I guess my questions are as following:

• Which approach would you recommend in my situation? With respect to keeping a minimum battery consumption, and a nice clean implementation.

• In the case of approach number two, is it possible to eliminate the need for a notifying executable? Either through alternative API functions, or existing generic applications on the platform?

• In the case of approach number three, do you know of any information/statistics relevant to the claim, that it is possible to extend the battery lifetime when using unattended mode over going into suspend. E.g. how often do you need to pull the system out of suspend, before unattended mode is to be preferred.

• Implementation specific (bonus) question: Is it necessary to regularly call SystemIdleTimerReset to stay in unattended mode?

And finally, if you think I have prematurely eliminated approach number one, please tell me why.

---

Please include in your response whether you base your response on knowledge, or are merely guessing (the latter is also very welcome!).

Please leave a comment, if you think I need to clarify any parts of this question.

Modestomodesty

What kind of regular interval are we talking here? 30 seconds? 10 minutes? every hour? what kind of information are you gathering? – Serai

Thank you for asking. We are talking every 5-10 minutes, as often as possible is to be preferred. I don't think it is that relevant to the problem, but the information i'm gathering are primarily GPS coordinates, I would like a detailed path of the route traveled. – Modestomodesty

Answer 1

CERunAppAtTime is a much-misunderstood API (largely because of the terrible name). It doesn't have to run an app. It can simply set a named system event (see the description of the pwszAppName parameter in the MSDN docs). If you care to know when it has fired (to lat your app put the device to sleep again when it's done processing) simply have a worker thread that is doing a WaitForSingleObject on that same named event.

Unattended state is often used for devices that need to keep an app running continuously (like an MP3 player) but conserve power by shutting down the backlight (probably the single most power consuming subsystem).

Obviously unattended mode uses significantly more powr than suspend, becasue in suspend the only power draw is for RAM self-refresh. In unattended mode the processor is stuill powered and running (and several peripherals may be too - depends on how the OEM defined their unattended mode).

SystemIdleTimerReset simply prevents the power manager from putting the device into low-power mode due to inactivity. This mode, whether suspended, unattended, flight or other, is defined by the OEM. Use it sparingly because when your do it impacts the power consumption of the device. Doing it in unattended mode is especially problematic from a user perspective because they might think the device is off (it looks that way) but now their battery life has gone south.

Jink

Thank you very much for your answer! I have been looking at the MSDN docs for CeRunAppAtTime which does not have the same elaboration on the pwszAppName parameter as CeRunAppAtEvent does. This is exactly what I need! – Modestomodesty

Perhaps you could answer my bonus question too (or already did?), is it correctly understood, that I need to signal SystemIdleTimerReset regularly while I do my processing (in unattended mode), to keep the system from sleep? Or will it wait till I signal PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE)? – Modestomodesty

Answer 2

I had a whole long post detailing how you shouldn't expect to be able to get acceptable battery life because WM is not designed to support what you're trying to do, but -- you could signal your service on wakeup, do your processing, then use the methods in this post to put the device back to sleep immediately. You should be able to keep the ratio of on-time-to-sleep-time very low this way -- but as you say, I'm only guessing.

See also:

Power-Efficient Apps (MSDN)

Power To The People (Developers 1, Developers 2, Devices)

Power-Efficient WM Apps (blog post)

Burgonet