| Groups | Blog | Home |
dotnet compact framework : Device won't idle time out when my app is running
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!
[quoted text, click to view]
> * 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. [quoted text, click to view] > * Is there a way to have the OS ignore whatever's causing it to > reset the idle timer? No. [quoted text, click to view] > * 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: [quoted text, click to view] >> * 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. [quoted text, click to view] > 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!
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. [quoted text, click to view] "Scott Gifford" <sgifford@suspectclass.com> wrote in message news:lywst2tu3k.fsf@gfn.org... > 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:
[quoted text, click to view] > 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!
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. [quoted text, click to view] "Scott Gifford" <sgifford@suspectclass.com> wrote in message news:lybqad17pb.fsf@gfn.org... > "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:
[quoted text, click to view] > 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. [quoted text, click to view] > "Scott Gifford" <sgifford@suspectclass.com> wrote in message
> news:lybqad17pb.fsf@gfn.org... >> "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! >>
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. [quoted text, click to view] "Scott Gifford" <sgifford@suspectclass.com> wrote in message
news:lybqa8gu49.fsf@gfn.org... > "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" <sgifford@suspectclass.com> wrote in message >> news:lybqad17pb.fsf@gfn.org... >>> "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: >>>
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. [quoted text, click to view] "Scott Gifford" <sgifford@suspectclass.com> wrote in message news:ly1wb3drtv.fsf@gfn.org... > "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]" <p space tobey no spam AT no instrument no spam DOT com> writes:
[...] [quoted text, click to view] > 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. [...] [quoted text, click to view] > 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. [quoted text, click to view] > 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!
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> writes:
[quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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!
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. [quoted text, click to view] "Scott Gifford" <sgifford@suspectclass.com> wrote in message news:lysl3h5r11.fsf@gfn.org... > "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT > com> writes: > >> 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.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |