Hello again,

I have a small app which reads data from a serial port periodically,
and sends it over the network. I'm running it on Windows Mobile 5
with .NET 2.0, compiled with the VS2008 beta.

I'm doing the periodic polling with an OpenNetCF LongIntervalTimer.
Every 30 seconds, the device wakes up, goes into unattended mode,
reads the serial port, writes to the network, then leaves unattended
mode.

This works exactly right when I turn the device off with the power
button: it leaves the backlight off, wakes up at the appropriate times
to do processing, and uses much less power.

However, while my app is running, the device will never idle time out
into suspend mode and turn the backlight off. I'd like to get this to
work, because it's easy to forget to push the power button and end up
wasting a ton of battery power.

My questions are:

* Normal applications go to sleep just fine with no user input, so
it must be something my app is doing to keep it awake. What sorts
of things could cause this? Using the serial port? Network
activity? Entering and leaving unattended mode? Screen updates?

* Is there a way to have the OS ignore whatever's causing it to
reset the idle timer?

* Any other ideas what might be causing this, and how to fix it?

Thanks!

----Scott.

> * Normal applications go to sleep just fine with no user input, so
> it must be something my app is doing to keep it awake. What sorts
> of things could cause this? Using the serial port? Network
> activity? Entering and leaving unattended mode? Screen updates?

Could be any of them. The OEM can decide on any activity to keep the idle
timer reset. I've used serial interrupts in a platform before - it's nice
to not have the device go to sleep while serial data is being transmitted.
Network interrupts are quite common - you don't want the device to go to
sleep while you're streaming audio or video though the network. Screen
updates likely would not cause an idle reset or the device would almost
never go to sleep.

> * Is there a way to have the OS ignore whatever's causing it to
> reset the idle timer?

No.

> * Any other ideas what might be causing this, and how to fix it?

Not offhand.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com

Thanks for the help so far. I've been reading and experimenting since
I posted this message, and have a few thoughts.

"<ctacke/>" <ctacke[at]opennetcf[dot]com> writes:

>> * Normal applications go to sleep just fine with no user input, so
>> it must be something my app is doing to keep it awake. What sorts
>> of things could cause this? Using the serial port? Network
>> activity? Entering and leaving unattended mode? Screen updates?
>
> Could be any of them. The OEM can decide on any activity to keep the idle
> timer reset.

Ah, OK, that explains why it's not clearly documented.

> I've used serial interrupts in a platform before - it's nice
> to not have the device go to sleep while serial data is being transmitted.
> Network interrupts are quite common - you don't want the device to go to
> sleep while you're streaming audio or video though the network.

Right, it would be annoying to have the device go to sleep right in
the middle of a serial or network send, but in my case I'm sleeping
for a while between uses of the serial port and network, and during
that time it would be useful for the device to go to sleep to save
power. Then I could run the system in unattended mode with the
display off while I'm gathering and sending data.

One way to get the idle behavior I want would be to monitor the user's
activity while my application is asleep. If the only activity on the
system seems to be during my use of the serial port and network, I can
detect that and force the device to go to sleep. Not perfect, I know,
but better than nothing.

To implement this, I'm looking for a way to get the user's idle time,
that is the time that Windows Mobile uses to decide when to put the
device to sleep, the one that is reset by SystemIdleTimerReset(). The
OS must keep track of this somewhere, but I can't find a way to get at
it. Does anybody know a way?

Right now the closest I've been able to find is GetIdleTime(), which
seems to return the total number of ms the CPU has been idle, not the
amount of time since the user has interacted with the device.

Thanks!

----Scott.

There is no standard way that will work for all Windows Mobile devices ever.
On later devices, you might be able to find the name of the event used by
GWES to signal user activity. Take a look in the registry in
HKLM/System/GWE, the value name is ActivityEvent and see if there's an event
name there for user activity. If so, using OpenEvent with that name should
give you a handle to that event, which you could use in a call to
WaitForSingleObject() or WaitForMultipleObjects() to detect when there *is*
user activity and do something as a result. It works in CE5 for sure, so I
think that WM6 is a slam dunk. I'd guess that WM5 does it, too. Not clear
on whether WM2003 and earlier would...

Paul T.

"Scott Gifford" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for the help so far. I've been reading and experimenting since
> I posted this message, and have a few thoughts.
>
> "<ctacke/>" <ctacke[at]opennetcf[dot]com> writes:
>
>>> * Normal applications go to sleep just fine with no user input, so
>>> it must be something my app is doing to keep it awake. What sorts
>>> of things could cause this? Using the serial port? Network
>>> activity? Entering and leaving unattended mode? Screen updates?
>>
>> Could be any of them. The OEM can decide on any activity to keep the
>> idle
>> timer reset.
>
> Ah, OK, that explains why it's not clearly documented.
>
>> I've used serial interrupts in a platform before - it's nice
>> to not have the device go to sleep while serial data is being
>> transmitted.
>> Network interrupts are quite common - you don't want the device to go to
>> sleep while you're streaming audio or video though the network.
>
> Right, it would be annoying to have the device go to sleep right in
> the middle of a serial or network send, but in my case I'm sleeping
> for a while between uses of the serial port and network, and during
> that time it would be useful for the device to go to sleep to save
> power. Then I could run the system in unattended mode with the
> display off while I'm gathering and sending data.
>
> One way to get the idle behavior I want would be to monitor the user's
> activity while my application is asleep. If the only activity on the
> system seems to be during my use of the serial port and network, I can
> detect that and force the device to go to sleep. Not perfect, I know,
> but better than nothing.
>
> To implement this, I'm looking for a way to get the user's idle time,
> that is the time that Windows Mobile uses to decide when to put the
> device to sleep, the one that is reset by SystemIdleTimerReset(). The
> OS must keep track of this somewhere, but I can't find a way to get at
> it. Does anybody know a way?
>
> Right now the closest I've been able to find is GetIdleTime(), which
> seems to return the total number of ms the CPU has been idle, not the
> amount of time since the user has interacted with the device.
>
> Thanks!
>
> ----Scott.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> writes:

> There is no standard way that will work for all Windows Mobile devices ever.
> On later devices, you might be able to find the name of the event used by
> GWES to signal user activity. Take a look in the registry in
> HKLM/System/GWE, the value name is ActivityEvent and see if there's an event
> name there for user activity. If so, using OpenEvent with that name should
> give you a handle to that event, which you could use in a call to
> WaitForSingleObject() or WaitForMultipleObjects() to detect when there *is*
> user activity and do something as a result. It works in CE5 for sure, so I
> think that WM6 is a slam dunk. I'd guess that WM5 does it, too. Not clear
> on whether WM2003 and earlier would...

Thanks, that seems to work great! I can see the event firing whenever
I interact with the device, and no otherwise. It seems not to fire
when I poll the GPS or send network traffic (though it does go off
when I first connect to the Internet), so I can just monitor this
activity and use a timer to put the device to sleep.

In the handler for the activity event, is there any way to get more
information about the event, for example if it was triggered by the
user or by the Internet coming up?

Also, does anybody have experience with the registry settings:

HKEY_LOCAL_MACHINE\Comm\Cxport\NoIdleTimerReset
HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\NoIdleIfAdapter

They seem like they prevent the idle timer from being reset with
network traffic, but they don't seem to do anything on my device. Are
they NDIS-specific? Are there comparable settings for a GPRS radio?

Thanks!

---Scott.

The connection to the Internet doesn't cause it. It's strictly when GWES
thinks that there is "user activity". I suppose that someone else might
fire it when something else happens, but you can't tell the difference
between that and any other time it fires. It's just an OS event. Treat
every such event the same...

Paul T.

"Scott Gifford" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> com> writes:
>
>> There is no standard way that will work for all Windows Mobile devices
>> ever.
>> On later devices, you might be able to find the name of the event used by
>> GWES to signal user activity. Take a look in the registry in
>> HKLM/System/GWE, the value name is ActivityEvent and see if there's an
>> event
>> name there for user activity. If so, using OpenEvent with that name
>> should
>> give you a handle to that event, which you could use in a call to
>> WaitForSingleObject() or WaitForMultipleObjects() to detect when there
>> *is*
>> user activity and do something as a result. It works in CE5 for sure, so
>> I
>> think that WM6 is a slam dunk. I'd guess that WM5 does it, too. Not
>> clear
>> on whether WM2003 and earlier would...
>
> Thanks, that seems to work great! I can see the event firing whenever
> I interact with the device, and no otherwise. It seems not to fire
> when I poll the GPS or send network traffic (though it does go off
> when I first connect to the Internet), so I can just monitor this
> activity and use a timer to put the device to sleep.
>
> In the handler for the activity event, is there any way to get more
> information about the event, for example if it was triggered by the
> user or by the Internet coming up?
>
> Also, does anybody have experience with the registry settings:
>
> HKEY_LOCAL_MACHINE\Comm\Cxport\NoIdleTimerReset
> HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\NoIdleIfAdapter
>
> They seem like they prevent the idle timer from being reset with
> network traffic, but they don't seem to do anything on my device. Are
> they NDIS-specific? Are there comparable settings for a GPRS radio?
>
> Thanks!
>
> ---Scott.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> writes:

> The connection to the Internet doesn't cause it. It's strictly when GWES
> thinks that there is "user activity". I suppose that someone else might
> fire it when something else happens, but you can't tell the difference
> between that and any other time it fires. It's just an OS event. Treat
> every such event the same...

When I was testing this earlier and having network problems, it looked
like every time it tried to connect to the network I saw a user
activity event fired, even if I wasn't touching the device. Now that
my network is working properly, I can't reproduce. Maybe it was
weirdness in my program or my network driver.

At any rate, thanks to your help I now have a simple system working to
receive UserActivity events and put the device into idle mode if it
doesn't receive one after the timeout specified in the registry. I'm
calling:

OpenNETCF.WindowsCE.PowerManagement.SetIdleState()

to put the system into an idle state. I see that there's also:

OpenNETCF.WindowsCE.PowerManagement.Suspend()

but when I call that my application doesn't work reliably (the drivers
will sometimes hang). Would it be reasonable to Suspend the system
after it was idle for awhile, and would it save power? I don't
entirely understand how the system normally goes from Idle mode to
Suspend mode.

Also, I'm trying to figure out how to make my application-specific
idle timer play well with other applications that may want to keep the
system from going idle (for example Media Player). It occurred to me
that if the GPS driver and network driver are resetting the idle
timer, and other applications are also resetting the idle timer, I
could figure out if the system was idle except for my application by
counting idle timer resets, and subtracting the ones that were
probabaly caused by my application.

To do that, I would need to be notified when the idle timer was reset.
I found an event name that looked promising under:

HKLM\System\CurrentControlSet\Control\Power\SystemIdleTimerResetEvent

I tried creating an event with that name then waiting for events on
it, but never saw any. The MSDN docs gave the impression that that
event is "write-only". Does that sound right? Is there any other way
to find out when applications have reset the idle timer?

Otherwise, I will probably try to use a rough heuristic to guess
whether other applications are active, such as estimating CPU usage
while my application is idle. This isn't ideal, but it's probably
better than draining a user's battery by never going to sleep while my
app is running. Does anybody have suggestions for other useful
information I could use to determine whether the device should stay
awake?

Thanks again!

---Scott.


> "Scott Gifford" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
>> com> writes:
>>
>>> There is no standard way that will work for all Windows Mobile devices
>>> ever.
>>> On later devices, you might be able to find the name of the event used by
>>> GWES to signal user activity. Take a look in the registry in
>>> HKLM/System/GWE, the value name is ActivityEvent and see if there's an
>>> event
>>> name there for user activity. If so, using OpenEvent with that name
>>> should
>>> give you a handle to that event, which you could use in a call to
>>> WaitForSingleObject() or WaitForMultipleObjects() to detect when there
>>> *is*
>>> user activity and do something as a result. It works in CE5 for sure, so
>>> I
>>> think that WM6 is a slam dunk. I'd guess that WM5 does it, too. Not
>>> clear
>>> on whether WM2003 and earlier would...
>>
>> Thanks, that seems to work great! I can see the event firing whenever
>> I interact with the device, and no otherwise. It seems not to fire
>> when I poll the GPS or send network traffic (though it does go off
>> when I first connect to the Internet), so I can just monitor this
>> activity and use a timer to put the device to sleep.
>>
>> In the handler for the activity event, is there any way to get more
>> information about the event, for example if it was triggered by the
>> user or by the Internet coming up?
>>
>> Also, does anybody have experience with the registry settings:
>>
>> HKEY_LOCAL_MACHINE\Comm\Cxport\NoIdleTimerReset
>> HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\NoIdleIfAdapter
>>
>> They seem like they prevent the idle timer from being reset with
>> network traffic, but they don't seem to do anything on my device. Are
>> they NDIS-specific? Are there comparable settings for a GPRS radio?
>>
>> Thanks!
>>
>> ---Scott.

I can't guarantee that the network user interface driver doesn't want the
screen on to show some sort of error. I wouldn't have done it that way (you
can search the source code and, if it's there, you'll probably find it;
check \public\common\oak\drivers\netui in CE5/Platform Builder first,
maybe).

Yes, suspend is a lower-power mode than idle. In idle, your code is
executing, but everything is in low-power mode. In suspend, *your code is
not executing*. If the device doesn't recover from suspend, you may have
problems in the OS configuration or the board support package code that's
supposed to bring the device out of suspend, or in the drivers, which have
to do the right thing to turn the devices back on. In particular, you can't
assume that any network connections that your application had are still
valid. Recovering from suspend is a much bigger job for the system than
just becoming non-idle and the same is true for your application. There's a
page in the Platform Builder help (and it's probably on MSDN online, too),
called something like System Power State Setting which talks a little about
the states.

You'd probably have to read the code to figure out how that event is used.
I'm not familiar with it. I'm not sure if you can still download Windows CE
5.0 evaluation edition with Platform Builder or not, but you can check at
www.microsoft.com/downloads. It's not the Windows Mobile code, of course,
but you can probably assume that most of the internals work similarly.

Ideally, your application should *stay out of the way* and let the power
manager decide when to go to sleep, only *preventing* that from happening,
never forcing it. Your application code should not need or want to know
anything about keyboard or touch or mouse events, etc. Those should be used
by the power manager to decide whether it's OK to sleep or not. That's the
usage mode that Microsoft expects. While you might be able to do what
you're doing and hack something in there, there will almost certainly be
things that you can't do because you're operating outside the box. No doubt
the next version of Windows Mobile will break what you're doing now, too.

Paul T.

"Scott Gifford" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> com> writes:
>
>> The connection to the Internet doesn't cause it. It's strictly when GWES
>> thinks that there is "user activity". I suppose that someone else might
>> fire it when something else happens, but you can't tell the difference
>> between that and any other time it fires. It's just an OS event. Treat
>> every such event the same...
>
> When I was testing this earlier and having network problems, it looked
> like every time it tried to connect to the network I saw a user
> activity event fired, even if I wasn't touching the device. Now that
> my network is working properly, I can't reproduce. Maybe it was
> weirdness in my program or my network driver.
>
> At any rate, thanks to your help I now have a simple system working to
> receive UserActivity events and put the device into idle mode if it
> doesn't receive one after the timeout specified in the registry. I'm
> calling:
>
> OpenNETCF.WindowsCE.PowerManagement.SetIdleState()
>
> to put the system into an idle state. I see that there's also:
>
> OpenNETCF.WindowsCE.PowerManagement.Suspend()
>
> but when I call that my application doesn't work reliably (the drivers
> will sometimes hang). Would it be reasonable to Suspend the system
> after it was idle for awhile, and would it save power? I don't
> entirely understand how the system normally goes from Idle mode to
> Suspend mode.
>
> Also, I'm trying to figure out how to make my application-specific
> idle timer play well with other applications that may want to keep the
> system from going idle (for example Media Player). It occurred to me
> that if the GPS driver and network driver are resetting the idle
> timer, and other applications are also resetting the idle timer, I
> could figure out if the system was idle except for my application by
> counting idle timer resets, and subtracting the ones that were
> probabaly caused by my application.
>
> To do that, I would need to be notified when the idle timer was reset.
> I found an event name that looked promising under:
>
> HKLM\System\CurrentControlSet\Control\Power\SystemIdleTimerResetEvent
>
> I tried creating an event with that name then waiting for events on
> it, but never saw any. The MSDN docs gave the impression that that
> event is "write-only". Does that sound right? Is there any other way
> to find out when applications have reset the idle timer?
>
> Otherwise, I will probably try to use a rough heuristic to guess
> whether other applications are active, such as estimating CPU usage
> while my application is idle. This isn't ideal, but it's probably
> better than draining a user's battery by never going to sleep while my
> app is running. Does anybody have suggestions for other useful
> information I could use to determine whether the device should stay
> awake?
>
> Thanks again!
>
> ---Scott.
>
>
>> "Scott Gifford" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
>>> DOT
>>> com> writes:
>>>
>>>> There is no standard way that will work for all Windows Mobile devices
>>>> ever.
>>>> On later devices, you might be able to find the name of the event used
>>>> by
>>>> GWES to signal user activity. Take a look in the registry in
>>>> HKLM/System/GWE, the value name is ActivityEvent and see if there's an
>>>> event
>>>> name there for user activity. If so, using OpenEvent with that name
>>>> should
>>>> give you a handle to that event, which you could use in a call to
>>>> WaitForSingleObject() or WaitForMultipleObjects() to detect when there
>>>> *is*
>>>> user activity and do something as a result. It works in CE5 for sure,
>>>> so
>>>> I
>>>> think that WM6 is a slam dunk. I'd guess that WM5 does it, too. Not
>>>> clear
>>>> on whether WM2003 and earlier would...
>>>
>>> Thanks, that seems to work great! I can see the event firing whenever
>>> I interact with the device, and no otherwise. It seems not to fire
>>> when I poll the GPS or send network traffic (though it does go off
>>> when I first connect to the Internet), so I can just monitor this
>>> activity and use a timer to put the device to sleep.
>>>
>>> In the handler for the activity event, is there any way to get more
>>> information about the event, for example if it was triggered by the
>>> user or by the Internet coming up?
>>>
>>> Also, does anybody have experience with the registry settings:
>>>
>>> HKEY_LOCAL_MACHINE\Comm\Cxport\NoIdleTimerReset
>>> HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\NoIdleIfAdapter
>>>
>>> They seem like they prevent the idle timer from being reset with
>>> network traffic, but they don't seem to do anything on my device. Are
>>> they NDIS-specific? Are there comparable settings for a GPRS radio?
>>>
>>> Thanks!
>>>
>>> ---Scott.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> writes:

[...]

> Yes, suspend is a lower-power mode than idle. In idle, your code is
> executing, but everything is in low-power mode. In suspend, *your code is
> not executing*. If the device doesn't recover from suspend, you may have
> problems in the OS configuration or the board support package code that's
> supposed to bring the device out of suspend, or in the drivers, which have
> to do the right thing to turn the devices back on. In particular, you can't
> assume that any network connections that your application had are still
> valid. Recovering from suspend is a much bigger job for the system than
> just becoming non-idle and the same is true for your application. There's a
> page in the Platform Builder help (and it's probably on MSDN online, too),
> called something like System Power State Setting which talks a little about
> the states.

I did manage to get it to work by using timeouts and retries in cases
where the drivers weren't available, and setting a power requirement
on the COM port used for the GPS. It didn't seem to save much power
though, probably because it uses more power to wake the device up and
put it back to sleep every 30 seconds than it saves. It's also
possible something my application did took it out of Suspend mode, I
don't know how to tell.

While it was suspended, though, my application was able to wake up on
a timer and also quickly wake up on an incoming GPRS packet.

If the network is not guaranteed to be available in suspend mode,
would you expect that Microsoft's always-up-to-date email puts the
device in idle mode, rather than suspend? If devices running AUTD
mail are already staying out of suspend mode, then probably it won't
do much good for my application to try to go into a lower-power mode,
since I imagine most people with a Windows Mobile phone are using AUTD
mail.

[...]

> Ideally, your application should *stay out of the way* and let the
> power manager decide when to go to sleep, only *preventing* that
> from happening, never forcing it.

Indeed, that would be ideal, but unfortunately while my application is
running and periodically accessing the GPS and the network, my device
will never go to sleep. I'm stuck with a choice between drastically
reducing my update times, from 30 seconds to over 2 minutes (or longer
depending on the user's timeout settings); having the device never go
idle, which drastically reduces battery lifetime; or trying to
re-implement part of the power manager in my own application.

> Your application code should not need or want to know anything about
> keyboard or touch or mouse events, etc. Those should be used by the
> power manager to decide whether it's OK to sleep or not. That's the
> usage mode that Microsoft expects. While you might be able to do
> what you're doing and hack something in there, there will almost
> certainly be things that you can't do because you're operating
> outside the box. No doubt the next version of Windows Mobile will
> break what you're doing now, too.

I agree completely, if you are aware of any better options I would be
delighted to stop wasting my time re-implementing the power manager.
:-)

What I'd really like to do is just have the power manager ignore my
application's use of the network and GPS, or indeed ignore my
application altogether, but if that's possible I haven't come across
it yet.

Thanks again for all of your help on this!

----Scott.

No code is running while the device is suspended. None. No idle code, no
driver code, nothing. Device vendors may set their devices up such that
certain interrupts bring them out of suspend and therefore allow network
connections to be kept alive (or phone calls answered), but you can't
control their hardware design.

I wouldn't know what the characteristics of the AUTOD mail are, but *I*
don't use it and I doubt that 'most' people are using it. I'm sure that the
mail code does *nothing* with the power state. That's up to the power
manager, as I mentioned before, and applications should generally stay the
heck out of the way, unless they need to keep the device awake.

If the device is configured by the OEM to wake on serial I/O or network I/O,
there's nothing you can do but reduce your frequency of use or reconsider
the usage model. If you're doing navigation with your GPS, it seems to me
that the user would expect the device to be on all the time. If the battery
life is too low, plug it in to some power supply. That might not be the
case for network, but I don't know enough about what you're doing to make an
educated case as to what makes the most sense. It seems to me that
constantly shifting power states is going to be more annoying than having
the battery only last a day, instead of two.

Paul T.

"Scott Gifford" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> com> writes:
>
> [...]
>
>> Yes, suspend is a lower-power mode than idle. In idle, your code is
>> executing, but everything is in low-power mode. In suspend, *your code
>> is
>> not executing*. If the device doesn't recover from suspend, you may have
>> problems in the OS configuration or the board support package code that's
>> supposed to bring the device out of suspend, or in the drivers, which
>> have
>> to do the right thing to turn the devices back on. In particular, you
>> can't
>> assume that any network connections that your application had are still
>> valid. Recovering from suspend is a much bigger job for the system than
>> just becoming non-idle and the same is true for your application.
>> There's a
>> page in the Platform Builder help (and it's probably on MSDN online,
>> too),
>> called something like System Power State Setting which talks a little
>> about
>> the states.
>
> I did manage to get it to work by using timeouts and retries in cases
> where the drivers weren't available, and setting a power requirement
> on the COM port used for the GPS. It didn't seem to save much power
> though, probably because it uses more power to wake the device up and
> put it back to sleep every 30 seconds than it saves. It's also
> possible something my application did took it out of Suspend mode, I
> don't know how to tell.
>
> While it was suspended, though, my application was able to wake up on
> a timer and also quickly wake up on an incoming GPRS packet.
>
> If the network is not guaranteed to be available in suspend mode,
> would you expect that Microsoft's always-up-to-date email puts the
> device in idle mode, rather than suspend? If devices running AUTD
> mail are already staying out of suspend mode, then probably it won't
> do much good for my application to try to go into a lower-power mode,
> since I imagine most people with a Windows Mobile phone are using AUTD
> mail.
>
> [...]
>
>> Ideally, your application should *stay out of the way* and let the
>> power manager decide when to go to sleep, only *preventing* that
>> from happening, never forcing it.
>
> Indeed, that would be ideal, but unfortunately while my application is
> running and periodically accessing the GPS and the network, my device
> will never go to sleep. I'm stuck with a choice between drastically
> reducing my update times, from 30 seconds to over 2 minutes (or longer
> depending on the user's timeout settings); having the device never go
> idle, which drastically reduces battery lifetime; or trying to
> re-implement part of the power manager in my own application.
>
>> Your application code should not need or want to know anything about
>> keyboard or touch or mouse events, etc. Those should be used by the
>> power manager to decide whether it's OK to sleep or not. That's the
>> usage mode that Microsoft expects. While you might be able to do
>> what you're doing and hack something in there, there will almost
>> certainly be things that you can't do because you're operating
>> outside the box. No doubt the next version of Windows Mobile will
>> break what you're doing now, too.
>
> I agree completely, if you are aware of any better options I would be
> delighted to stop wasting my time re-implementing the power manager.
> :-)
>
> What I'd really like to do is just have the power manager ignore my
> application's use of the network and GPS, or indeed ignore my
> application altogether, but if that's possible I haven't come across
> it yet.
>
> Thanks again for all of your help on this!
>
> ----Scott.