Device won't idle time out when my app is running

[Scott Gifford]

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.

 

[Guest]

* 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.

 

[Scott Gifford]

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

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]]

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]

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]]

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.

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

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.

 

[Scott Gifford]

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.

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

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]]

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.

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

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.

"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.

 

[Scott Gifford]

"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.

 

[Paul G. Tobey [eMVP]]

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.

"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.

 

[Scott Gifford]

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.

Right, my code is woken up from suspend mode by timer interrupts or
network interrupts. My GPRS radio appears to wake the device up when
a packet is received. I believe most GPRS radios will do this;
otherwise I don't see how push email could work. Keeping a TCP
connection open doesn't require any processing unless data is being
sent, in which case the device is awake by definition, or received, in
which case the GPRS radio just woke it up. So it seems plausible that
a network connection would stay open across a suspend, and my
application could work even if it were periodically suspended.

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.

Ah, OK, I don't use it either (I'm very old-fashioned about my email),
but I assumed most people buying a Windows Mobile phone used it for
push email, just like most people buying a Blackberry use it for push
email.

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.

I would expect so too, and if you can't count on a network connection
being reliable across a suspend, than something must be keeping the
device out of suspend mode. Either the device does it, the network
driver does it, the application does it, or else network connections
are reliable across suspends. At any rate, my only point was that if
staying in idle mode instead of suspend mode was good enough for
Pocket Outlook, it's probably good enough for my app.

If the device is configured by the OEM to wake on serial I/O or
network I/O,

It actually doesn't wake up from Idle mode, but it won't go into idle
mode while these devices are active. Once I get it into idle mode it
will stay there succesfully until the user wakes the device.

there's nothing you can do but reduce your frequency of use or
reconsider the usage model.

Well, or hack something together to work around the behavior and
perform work similar to the power manager. There are definitely
downsides to this approach, but so far it looks to me like the best of
several very poor options.

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.

Our usage model is publishing location data to the network, to enable
various applications like location-based social networking,
cooperative navigation, being notified of nearby people, places, or
events your are interested in, and so forth. So it relies on the data
being published frequently and unobtrusively while the device is in
your pocket.

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

Ideally, I would only be shifting power states at the same times the
power manager would shift states, so it's only the times when my
behavior differs from the power manager's that will be annoying.

is going to be more annoying than having the battery only last a
day, instead of two.

The problem is that without idling the device at all, it lasts about
12 hours, which is unreasonably low. It also leaves the screen on all
the time, which makes it prone to accidental button presses and I
think would be disconcerting to a user. Idling the device, it lasts
about 18 hours, which approaches reasonable. I was hoping suspending
the device could get it to 24 hours, which is probably just getting to
reasonable.

From what I've read, it sounds like the SmartPhone's "always on" power
model might work much better for our application, and I hope to have
my hands on one soon to see.

Thanks once more for your help and insight!

----Scott.

 

[Paul G. Tobey [eMVP]]

Blackberry essentially requires you to use push e-mail. Unless you have
access to a push e-mail account or are willing to set up Exchange server,
etc., I'd guess that most people running Windows Mobile are not using it.
It's just not that valuable to have the device learn about an e-mail the
moment the server receives it. You can always set up to check for new
e-mail every five minutes, so your maximum delay is 5 minutes. That seems
adequate to me...

Paul T.

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

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.

Right, my code is woken up from suspend mode by timer interrupts or
network interrupts. My GPRS radio appears to wake the device up when
a packet is received. I believe most GPRS radios will do this;
otherwise I don't see how push email could work. Keeping a TCP
connection open doesn't require any processing unless data is being
sent, in which case the device is awake by definition, or received, in
which case the GPRS radio just woke it up. So it seems plausible that
a network connection would stay open across a suspend, and my
application could work even if it were periodically suspended.

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.

Ah, OK, I don't use it either (I'm very old-fashioned about my email),
but I assumed most people buying a Windows Mobile phone used it for
push email, just like most people buying a Blackberry use it for push
email.

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.

I would expect so too, and if you can't count on a network connection
being reliable across a suspend, than something must be keeping the
device out of suspend mode. Either the device does it, the network
driver does it, the application does it, or else network connections
are reliable across suspends. At any rate, my only point was that if
staying in idle mode instead of suspend mode was good enough for
Pocket Outlook, it's probably good enough for my app.

If the device is configured by the OEM to wake on serial I/O or
network I/O,

It actually doesn't wake up from Idle mode, but it won't go into idle
mode while these devices are active. Once I get it into idle mode it
will stay there succesfully until the user wakes the device.

there's nothing you can do but reduce your frequency of use or
reconsider the usage model.

Well, or hack something together to work around the behavior and
perform work similar to the power manager. There are definitely
downsides to this approach, but so far it looks to me like the best of
several very poor options.

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.

Our usage model is publishing location data to the network, to enable
various applications like location-based social networking,
cooperative navigation, being notified of nearby people, places, or
events your are interested in, and so forth. So it relies on the data
being published frequently and unobtrusively while the device is in
your pocket.

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

Ideally, I would only be shifting power states at the same times the
power manager would shift states, so it's only the times when my
behavior differs from the power manager's that will be annoying.

is going to be more annoying than having the battery only last a
day, instead of two.

The problem is that without idling the device at all, it lasts about
12 hours, which is unreasonably low. It also leaves the screen on all
the time, which makes it prone to accidental button presses and I
think would be disconcerting to a user. Idling the device, it lasts
about 18 hours, which approaches reasonable. I was hoping suspending
the device could get it to 24 hours, which is probably just getting to
reasonable.

From what I've read, it sounds like the SmartPhone's "always on" power
model might work much better for our application, and I hope to have
my hands on one soon to see.

Thanks once more for your help and insight!

----Scott.