Jaa


Power to the System

In Power to the People we learned some of the differences between how PocketPCs and Smartphones handle power.  In Power to the Developers part 1 we learned about some of the things a developer can do to manage his app's use of power.  In preparing a part 2 of the developer entry, I've realized that we need a prequel that describes the System's "Power Manager" and how it behaves. 

Half the story
Remember that what I'm about to describe here is really only half the story when it comes to power.  On CE, one millisecond after there's nothing for the CPU to do, it goes idle.  In idle the CPU is moved into an extremely low power mode and doesn't power back up again until either some piece of hardware wakes it up, or a scheduled task happens.  Also, most drivers aggressively self-manage their power.  If nothing is plugged into the USB port, for instance, the USB port isn't powered, etc.  This is moderately interesting in that it's an indication that we're doing things correctly, but to a developer or a user, all you really need to know is that apps which use the CPU unnecessarily waste power.  Hopefully you've gotten that message in my previous two entries.

The other half of the story
That brings us to Power Manager (PM).  PM manages many of the hardware drivers in the system.  It can manage all of them, but a driver must be written to take advantage of PM's control, and we haven't required that they all do so.  PM is relatively new.  It was first introduced to Windows Mobile in the 2003 edition.  And, over time, we've been migrating more and more power functionality to it.

The main job PM handles is managing drivers that can't manage themselves.  As I said above, the USB port knows when nothing is plugged into it, and can shut itself down.  But the LCD screen doesn't know if a user is looking at it, so it doesn't know when to turn itself off.  That's where PM comes in.  PM might also control USB ports, but, even if it tells them to turn on, they won't if there's no reason to. 

You should think of PM as doing stuff on a granularity that's relevant to users and developers.  You set control panel entries which say to turn off the backlight after 15 seconds and to turn the screen off after 3 minutes, etc.  Those control panels feed that information to the Power Manager.  On the other hand, you don't have much control over what happens in the millisecond granularity of idle.

State of Confusion
Power Manager uses a concept called "System Power States" to do exert its control.  The concept is pretty simple.  PM has a list of drivers it controls, and, for each state, it has list of settings for those drivers.  In one state, it turns everything on.  In another, it turns off the screen and backlight, but leaves everything else on.  In yet another, it turns off the screen, backlight, and audio, etc.  Remember that many drivers know better than PM and will stay powered off even when it says to turn on (i.e. the USB port that has nothing plugged into it).

There are a lot of these states.  Some are relevant to PocketPC, and some are relevant to Smartphone.  I'm going to list them here and give a brief description of what they do.

  • On:   The user is interacting with the device.  Everything is on.
  • BacklightOff:   There has been a brief period of user inactivity (no one has pressed any buttons or touched a touchscreen).  The backlight has been turned off, but everything else is on.  When you set the backlight timeout values in the control panel, you're setting how long the system should wait before going into this state.  (Note that this state is new for WM 5.) 
  • UserIdle:   There has been a longer period of user inactivity.  Both the backlight and LCD have been turned off.  When you set the screen timeout value on a Smartphone control panel, you're setting how long the system should wait before going into this state.  This state is generally not used on PocketPC.  There's no reason to turn the screen off when the device is about to go to sleep (sleeping turns the screen off).  However, if/when PocketPCs go to the "Always On" model, they'll start using this state.
  • ScreenOff:   You go into this state when someone specifically says to turn the screen (and backlight) off.  For instance, in Media Player you can assign a button to turn the screen off.  When you press it, we go into this state.  This state is different than UserIdle, though.  This state says, "The user wants the screen off and doesn't want it to turn back on."  UserIdle says, "The user hasn't touched any buttons in a while, so we might as well turn the screen off to save power."  In ScreenOff, pressing a button (other than the power button) doesn't turn the screen back on.  In UserIdle, pressing a button does turn the screen back on.  Both PocketPC and Smartphone use this state.
  • Unattended:   This is a confusing state in which the screen, the backlight, and the audio are off.  I won't go into too many details, other than to say that this is a PocketPC-only state that is used by applications which need to do things without alerting the user.  While the PocketPC is in this state, the user thinks the device is asleep.  For instance, ActiveSync when it syncs every 5 minutes.  It's waking up, syncing, and going back to sleep, but the user can't tell.
  • Resuming:   This is the state the PocketPC goes into when it wakes up from sleep.  In this state, the screen is off, and there is a very short (15 second) timer before it goes back to sleep.  The only way to keep the device from going back to sleep is to have something put it into one of the other states.  This is really for dealing with spurious wakeups and for giving the system a way to get into Unattended without letting the user know about it. 
  • Suspended:   This is the PocketPC "Sleep" state.  Everything is off, and the system isn't going to wake back up until some piece of hardware wakes it up.  It's not actually an official Power Manager state, the way the other six are, but I'm including it for completeness.

As you can see, things are much simpler in an "Always On" device like Smartphone (the three most complicated states don't get used). 

Next up: how to have Power Manager tell your app whenever these state transitions happen.

Mike Calligaro

Comments

  • Anonymous
    August 11, 2005
    In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily. ...

  • Anonymous
    August 12, 2005
    In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily. ...

  • Anonymous
    August 17, 2005
    Can you teach me how get into Unattended mode when wake up, like ativesync doing the sync .
    I mean that every 5 minutes , my app wake up in the unattended mode,do some task ,into supsend mode. and repeat again after 5 minutes later.are ther any api can achieve that?
    i have used the CeRnAppAtTime.But my app was run in On state...
    please mail me the answer
    my address is wjr87u@yahoo.com.tw
    thank you so much.
    best regards

  • Anonymous
    August 18, 2005
    A good read for CPT 355 about power for Windows Mobile devices http://blogs.msdn.com/windowsmobile/archive/2005/08/01/446240.aspx This is part of series on power, but one of the more interesting parts is the list of power states for smartphones and Pocket PCs from this post http://blogs.msdn.com/windowsmobile/archive/2005/08/10/450186.aspx * On: The user is interacting with the device. Everything is on. * BacklightOff: There has been a brief period of user inactivity (no one has pressed any buttons or touched a touchscreen). The backlight has been turned off, but everything else is on. When you set the backlight timeout values in the control panel, you're setting how long the system should wait before going into this state. (Note that this state is new for WM 5.) * UserIdle: There has been a longer period of user inactivity. Both the backlight and LCD have been turned off. When you set the screen timeout value on a Smartphone control panel, you're setting how long the system should wait before going into this state. This state is generally not used on PocketPC. There's no reason to turn the screen off when the device is about to go to sleep (sleeping turns the screen off). However, if/when PocketPCs go to the "Always On" model, they'll start using this state. * ScreenOff: You go into this state when someone specifically says to turn the screen (and backlight) off. For instance, in Media Player you can assign a button to turn the screen off. When you press it, we go into this state. This state is different than UserIdle, though. This state says, "The user wants the screen off and doesn't want it to turn back on." UserIdle says, "The user hasn't touched any buttons in a while, so we might as well turn the screen off to save power." In ScreenOff, pressing a button (other than the power button) doesn't turn the screen back on. In UserIdle, pressing a button does turn the screen back on. Both PocketPC and Smartphone use this state. * Unattended: This is a confusing state in which the screen, the backlight, and the audio are off. I won't go into too many details, other than to say that this is a PocketPC-only state that is used by applications which need to do things without alerting the user. While the PocketPC is in this state, the user thinks the device is asleep. For instance, ActiveSync when it syncs every 5 minutes. It's waking up, syncing, and going back to sleep, but the user can't tell. * Resuming: This is the state the PocketPC goes into when it wakes up from sleep. In this state, the screen is off, and there is a very short (15 second) timer before it goes back to sleep. The only way to keep the device from going back to sleep is to have something put it into one of the other states. This is really for dealing with spurious wakeups and for giving the system a way to get into Unattended without letting the user know about it. * Suspended: This is the PocketPC "Sleep" state. Everything is off, and the system isn't going to wake back up until some piece of hardware wakes it up. It's not actually an official Power Manager state, the way the other six are, but I'm including it for completeness....

  • Anonymous
    September 19, 2005
    John, I'm sorry, I missed your comment back when. I was just checking through comments now and saw it.

    Here's how to enter and leave unattended mode.

    If you call:
    PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);
    at the start of your app, it will enter unattended.

    Then, when you're ready to exit, call
    PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE);
    That will tell the system that you're done.

    This is what ActiveSync does.

    Mike Calligaro

  • Anonymous
    April 18, 2006
    Is there anyway to automatically run application unattended on WM5?

    In otherwods, is there some consumer utility that will run an applicatin in WM5, unattended?

  • Anonymous
    April 21, 2006
    MadDog, are you asking if it's possible to say, "I'd like this application that's already on the device to run in unattended"?  

    If you can't change the application's code, you can't make the application itself run in unattended.  

    One thing you could do is have an application that puts the system into unattended and keeps it there.  I'm not sure if that's what you're looking for, though.  

    Can you tell me more about what you're trying to do?  What application would you like to be unattended and when?

    Mike

  • Anonymous
    May 02, 2006
    Here's one for you -

    In several HTC WM phone devices, setting the option to vibrate on new mail doesn't work when the device is in standby.  Is this by design, or a bug?  An example device is the HTC Wizard.

    If it's by design, please do something so that we can enable it, even if it's a reg entry.  If it's a bug, well...

    If the device would do a short vibe when new Direct Push mail is delivered, this would truly be close to a blackberry killer.  As it is, it's 70% there.

  • Anonymous
    July 02, 2006
    Hi there,

    As with John Wei, I'm also developing an application that requires the use of unattended mode. I've writtin a small test program based on your suggestion above, though I'm having a few issues.

    The test program wakes itself up using CeRunAppAtTime every minute, sets unattended mode, sleeps for 10 seconds, sets the next wake up event, then unsets unattended mode.

    1. When the device has woken up and entered unattended mode, the keyboard and touchscreen are active. An accidental press on a button or touch of the screen wakes the device up. Is there any way to fix this?

    2. Sometimes, like once an hour, the device will wake up completely. Its as if the call to request unattended mode didn't work.

    3. After a long time, say 3 hours, of waking up and sleeping, if I turn the device on I've lost the use of the touchscreen and have to soft reset before I can use it again.

    I'm using a Symbol MC70 running WM5

    Any help would be much appreciated.

    Tom

  • Anonymous
    July 02, 2006
    In addition to my previous post,

    I forgot to mention another anomaly I've been experiencing.

    The first time my application wakes the device up and enters unattended mode, the call to PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) does not suspend the device again. After the user idle timer expires, it suspends the device for me, then all following calls to PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) work. I've tried a variety of ways of suspending the device, including the user idle timeout. All seem to exhibit the same behavior.

    Cheers

    Tom

  • Anonymous
    July 06, 2006
    (Assume everywhere below when I say "LCD off" I mean the touch screen is off too.)

    John, the device is not behaving the way I expect it to.  If the device is suspended, then CeRunAppAtTime will cause it to go into the Resuming state, which has the LCD off.  When you put it into Unattended, it should leave the screen off.

    It sounds like that device turns the screen on during Resuming.  That is not our design.  However, Symbol makes vertical devices intended for specific uses, and we sometimes allow verticals to act differently than our designs if the changes are needed by their specialized customers.  It's possible that Symbol changed this behavior intentionally.  You'll need to work with them to see.

    For your second question, if the request to enter unattended mode failed, the device would suspend.  It will only wake up completely if something tells it to.  Maybe some other process is waking the device up?

    For your third question, the touch driver is OEM specific.  That's definitely something you'll need to work with Symbol on.

    And, as for the question in the second comment, it sounds like something else is running on the device that has requested unattended.  Unattended mode has a ref count that goes up every time someone requests unattended and goes back down every time someone releases it.  The system won't suspend immediately if the ref count isn't 0.  So, if something else is running that has requested unattended, then your requesting and releasing it won't suspend the system.  

    The ref count is cleared whenever the system wakes up from suspend, though.  So if something has bumped it, either it ran right when your app did, or the system wasn't actually suspended when you started your app the first time.

    Mike

  • Anonymous
    November 07, 2006
    The comment has been removed

  • Anonymous
    January 19, 2007
    The comment has been removed

  • Anonymous
    January 23, 2007
    Hi all, I am using PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) & PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) around opening the serial driver. This works. If I turn the device off in the middle of opening the serial driver, the device goes into unattended mode and things progress nicely. The problem we are having is the power button acts strangely after we put the device in the unattended state, and requires 5 or so presses to turn the device on or off. From a user experience this is a big issue. Any ideas?

  • Anonymous
    January 23, 2007
    The comment has been removed

  • Anonymous
    January 23, 2007
    The comment has been removed

  • Anonymous
    January 23, 2007
    Unfortunately, any way to hook the power button would be OEM driver specific.  The keyboard driver needs to tell us that the power button was pressed before we can tell your app that it happened.  My guess at the current problem is that the driver isn't doing that in the first place. One thing you can do to narrow the problem down is to have your app watch for one of the keys you CAN hook, and, when it's pressed, do: PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0); If that turns the screen on as normal, we will have a pretty good indication that if the keyboard driver were to do that things would work.  If that also takes 5 presses, I'll have to ponder more what's happening. Mike

  • Anonymous
    January 24, 2007
    The comment has been removed

  • Anonymous
    January 24, 2007
    Mike, Sorry about the spelling errors. It was early this morning. The device we are using is the TDS Recon X running Windows Mobile 5. Joel

  • Anonymous
    January 24, 2007
    Hi Joel, I don't work with TDS, so if you're already in contact with them and they're receptive to your issues, that's a good path.  In general, all they really need to do for the Hibernate issue is to replace whatever they're currently doing when the power button is pressed (I suspect they're sending a VK_OFF) with the PowerPolicyNotify.   The CF drivers issue is more complicated.  The OEM has a number of places in the suspend and resume processes where they can control what's happening and how long things take.  They should be making sure that their drivers fully unload/load.  So, while the PowerPolicyNotify is certainly the EASIER fix, fixing the CF driver is the correct one. I don't think I understand your idle time question.  The default is 3 minutes, but the UI allows users to set it as low as 1 minute.  For that reason, we suggest that apps call SystemIdleTimerReset  every 30 seconds.  That's guaranteed to be more often than the minimum idle time and has a good amount of room for slop.  You could get away 45 seconds, and could probably get away with 59 seconds, but 30 seconds is definitely safe. But I don't think that's what you're asking.  Are you asking to programatically change the timeout value itself?  If so, I'd need to know more about what you're trying to do.  Are you worried about resetting the idle timer a few seconds before you finish what you're doing, leaving unattended, and then having the system stay awake for almost 3 minutes?  That won't happen.  The system suspends immediately after leaving unattended mode. Mike

  • Anonymous
    January 29, 2007
    hi mike, thank you for your response ! i don't think that it only deals with the filesystem.. i changed the directory of the executable, but the OS still looks after it in the previous directory.. i also cleanbooted (factory settings) the device (it is a symbol mc9094 wm5) and got the same message by the OS !!! odo

  • Anonymous
    January 29, 2007
    hi, where does the OS "save" the setting with the notification ? in the registry or somewhere else ? odo

  • Anonymous
    February 12, 2007
    Hi Mike, Thanks for the great blog. We are using PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0) in our WM6 keyboard driver whenever the user presses the power button, and we're running into a problem when the power button is pressed twice quickly, the second time occurring before the device is suspended. It appears that the PowerPolicyNotify call is an asynchronous notification to the Power Manager, and the second notification we're issuing appears to be processed after the device is resumed, resulting in unexpected behavior. My question is, how should this situation be correctly handled? Thanks, Sean

  • Anonymous
    February 13, 2007
    Sean, what kind of time are we talking about between the two presses?  Is it a case of hardware debouncing being needed, or is it a user physically pressing the button twice quickly?   Is this an accurate description of what you're seeing?

  1. Device is awake and the user presses the button twice quickly
  2. Device goes to sleep
  3. User presses the power button again
  4. Device wakes up and then goes back to sleep Mike
  • Anonymous
    February 13, 2007
    Hi Mike, This is a case of the user physically pressing the button twice quickly (hardware debouncing has been disabled for the purpose of this test), and the situation is exactly as you describe. I should also mention that the keyboard driver calls PowerPolicyNotify once during the resume. We're also able to reproduce the behavior with an application calling PowerPolicyNotify twice before suspend, with a small wait between calls. I'm considering addressing this issue by flushing the PM policy notification queue during the keyboard power off handling. What are your thoughts on this approach? Also, what's the recommended way for an application to suspend the device? PowerPolicyNotify, GwesPowerOffSystem, SetSystemPowerState, or something else entirely? Thanks, Sean

  • Anonymous
    February 14, 2007
    Sean, flushing the PM queue is a dangerous action.  It's possible that you'd throw out other things in the queue, like an application request to go to unattended, and break user scenarios like always up to date email.   I've talked with the Power Manager owner, and unfortunately, we don't have a good solution for you.  We believe that if you send a PPN_POWERBUTTONPRESSED while the system is suspending then it will be queued up and run again when the system wakes up (as you're seeing).   I'd first verify with your customer that they find the "user presses the power button rapidly" feature to be compelling.  There are probably a hundred different WM devices on the market that don't guard against this that are doing fine. If your customer believes that this scenario is important, I guess my suggestion would be some sort of advanced debouncing on the power button.  You could grab the tick count when you send the PPN and store it in a variable.  When you go to send the next one, check to make sure sufficient time has passed.  Have some guard value like 0xFFFFFFFF that means to allow the PPN no matter what, and set the variable to that value in the keyboard power handler.  That way you can put a fairly large debounce time in and not have to worry about scenarios where the device does suspend and the user wants to turn it back on immediately. Regarding applications suspending the device, please give me the scenario you're trying to implement there.  There are few, if any, reasons for an application to suspend the device.  The application will almost never know what the user really wants to do and will likely do the wrong thing.  For instance, how will the application know that the user isn't watching a movie, or that always up to date email isn't syncing, etc? The one valid place I've ever seen for apps wanting to shut the system down is unattended ones.  For instance, if you have a app that needs to wake the system up every 5 minutes but only needs to run for a few seconds, you don't want the system to spend 3 minutes timing out only to start back up in 2 minutes.  Unattended mode was designed for that situation and handles it for you.  When the app leaves unattended mode, if nothing else is going on with the system, it will suspend immediately.   Mike

  • Anonymous
    February 17, 2007
    The comment has been removed

  • Anonymous
    February 19, 2007
    Greg, my VB is really rusty, so forgive me if I'm missing something.  But aren't you only incrementing intCntr to 30001 if the system is Unattended?  If the system goes from Resuming directly to On without doing Unattended, wouldn't that result in intCntr still being 0? Mike

  • Anonymous
    February 19, 2007
    The comment has been removed

  • Anonymous
    February 21, 2007
    Greg, your device isn't behaving the way I suspect.  I believe there is an unattended app that is running more frequently than normal. On a typical suspended device, if you press the power button it will go from suspended to Resuming, and then from Resuming directly to On.  There's no reason for it to go to Unattended in that case. If the system wakes up due to an unattended app running, you'll typically see it go from suspended to Resuming, and then go to Unattended from there.  If, while the unattended app is running, you hit the power button, it will go to On. It's pretty unusual for the system to go from suspended to resuming to unattended to on all in one press of the power button.  Usually it's either already in unattended when you press the power button or it doesn't do unattended at all. On the suspend case, there's no guarantee that your app will run before the system suspends.  The system doesn't notify apps before suspending because it doesn't want apps to have the power to slow down the suspend.  So you're more likely to see the wake up than the suspend.   I'm pretty confident in the message queues.  They're used in a bunch of places throughout the system and work there.  I believe what they're telling you is happening is really happening.  I just don't understand why your system is working the way it is.  What unattended mode apps do you have on the system?  The two main ones that come with it are active sync when doing "always up to date" email and calnot/clocknot which run briefly at midnight.  There are some OEMs that do other things with unattended as well.  For instance, the Palm Treo uses unattended pretty significantly and frequently uses it if their hardware detects certain situations at resume.  Maybe you have something similar?   Mike

  • Anonymous
    April 13, 2007
    From what I know, the PowerPolicyNotify API manages an internal counter. Can this value be obtained from somewhere? (API, registry) I have trouble maintaining the Palm Treo 700w in the unattended state. It behaves like another process is reverting the effect of the PowerPolicyNotify and my application enters the suspended state.

  • Anonymous
    April 16, 2007
    Jozsef, are you calling SystemIdleTimerReset() every 30 seconds?  Unattended protects you against the user hitting the power button, and it allows you to wake the system up and do work without turning the screen on, but you still have to keep the system from timing out due to inactivity.   We didn't want an app to call the PowerPolicyNotify, then crash, and lock the system on forever. Mike

  • Anonymous
    May 13, 2007
    Greg, How do you make to get aware of any power change with RequestPowerNotifications in VB .NET? I want to create a queue to know when the power off button of my PDA is pressed, but I don't know how. Could you pass me the code (with as more details as possible, because all information I've find is in C and I can't understand it). Thanks

  • Anonymous
    June 27, 2007
    Hey buddy how to make my app not to go blackscreen? on both wince 4,5,6? I mean I use keybrd_event(..) every 10 seconds, but it doesnt work on wince 4. Also I dont know the name of the driver (BKL1, BKL2, BKLN...) so is there an easy way to tourn off for the time my app is runing this powersaving mode?

  • Anonymous
    July 02, 2007
    In Windows Mobile, we require that the backlight driver be named BKL1:, so you should be able to SetPowerRequirement on that.  Sorry, but I can't remember if the power infrastructure that relies on was available version 4.   Mike

  • Anonymous
    July 13, 2007
    I'm particularly interested in the ScreenOff state.  I think a stand alone utility that toggled the ScreenOff state would be an excellent power saver for my Samsung sgh-i607 smartphone, or any smartphone for tht matter. I realize that Media Player offers this functionality, but Media Player has to be running in order for it to work.  And, that workaround becomes ineffective when I connect to the smartphone with Active Sync and use an application called Pocket Controller, which allows me to fully control my smartphone from my PC.  Once I connect through Pocket Controller and want to navigate away from Media Player into something else, all the lights come back on, and that becomes annoying as well as a battery drain.  Particulary if I am connected to the device via Bluetooth. I'm not a programmer. Could you be so kind as to point me in the right direction, or even post the code C# needed to toggle ScreenOff state?  It would be great to have this utilty that could be assignable to a hardware key, so that it could be easily toggled on/off. Thanks!

  • Anonymous
    July 17, 2007
    I can't yet use the WM5 APIs, and have an application that requires the system to stay on, in order to receive wireless notifications.  I do turn the screen off, but have to periodically call SystemIdleTimerReset(). Which of these is the best way to delay, so that the CPU can go idle:

  1. Create a thread & Sleep.
  2. Create a system event to call my app.
  3. Create a timer.
  4. Something else?
  • Anonymous
    July 18, 2007
    The comment has been removed

  • Anonymous
    July 18, 2007
    Trevor, the methods you suggested are pretty equivalent.  However, how long do you plan to keep the system awake?  Keeping a PocketPC from suspending can have a pretty significant effect on battery life.  If you're going to do it for a few minutes, it's probably not an issue.  But if you're planning to keep the system on all the time, you're likely to cause trouble for your users.  What kind of notifications do you need to get?  Would it be possible to have the notification itself wake the system up so that your app can let it sleep? Mike

  • Anonymous
    July 19, 2007
    hi , In Palm Treo  , the power key is mapped to call end key , when the call end/Power key is pressed the screen freezes up . how it could be handled . Is it in an unattended state

  • Anonymous
    August 06, 2007
    MikeCal wrote: >What kind of notifications do you need to get?  Would it be possible to have the notification itself wake the system up so that your app can let it sleep? The notifications are coming through a WiFi alert.  The user of the device is receiving an important message, whose time can't be predicted.  Is there a way to have a PocketPC wake up on this sort of event?

  • Anonymous
    August 06, 2007
    Unfortunately, no.  The WiFi stack runs on the main CPU, and that CPU is off when the system is suspended.  So you can't wake the CPU with a WiFi notification. Apps that need to get asyncronous WiFi communications (ie VOIP) either need to keep the system on all the time, or be run on a Smartphone instead of a PocketPC.  Smartphones already keep the system on all the time, but are tuned to do it well. Mike

  • Anonymous
    August 08, 2007
    Mike, I'm developing a .NET CF 2.0 app to run on a WM 5.0 PDA.  I want to do some processing in the middle of the night, and my idea was to use the transition from "suspend" to "unattended" to do this. By logging the power events that the RequestPowerNotifications gives me, I see that at midnight the device always wakes up for at least 15 seconds and sits in "unattended" mode. I would like to piggy back on this wakeup and simply perform my processing at that time.  Do all WM 5.0 devices wake up in this manner?  Or are there situations the device does not go into unattended mode in the night? Thanks, Ryan

  • Anonymous
    August 13, 2007
    Hi Ryan, Windows Mobile wakes up at midnight for two special processes: CalNot and ClockNot.  One updates Calender Notifications and one does Clock Notifications.  One runs every night at midnight and one runs every Sunday at midnight.  I can't remember which is which.  (-: These processes are on every Windows Mobile device, but it's not guaranteed that they will always be.  In some future version we could concievably change when they run, or get rid of them completely. There is a much safer way to do what you want.  If you call CeRunAppAtTime you can set the system to wake up and run your application at whatever time you'd like, including Midnight.  If you do that, you can run at the same time Cal/ClockNot runs, but continue to work even if we change them in the future. Mike

  • Anonymous
    August 21, 2007
    Hi Mike, Thanks for all your posts.  They're great.  Here's my question: Does the CPU clock speed mode that you can set under Settings->System->Processor (WM5) have anything to do with these power states? We're using a PPC (FSC PocketLoox) as a dedicated device and want to tweak the CPU clock speed mode setting programmatically, but can't figure out how.  Can't seem to find any documentation on what this corresponds to.  Clearly this is processor dependent.  Is this an OEM-specific thing? Thanks! Tim

  • Anonymous
    September 13, 2007
    Hi Mike, I have a program that shows a notification when an sms is recieved.butafter some seonds-i guess you said 6 seconds-it turns off device again. My program load a dll which loading it take around 6-7 seconds-becouse on loading it does some other things too-. So how can i prevent system from getting back into sleep mode. I think the calling SystemIdleTimerReset on another thread solve might the problem.but how much the interval should be? and also i read somewhere that keylock programs interfere with this and when keylock is on,calling this wont keep system alive.. so is there any solution?

  • Anonymous
    September 13, 2007
    Hi Mike, I have a program that shows a notification when an sms is recieved.butafter some seonds-i guess you said 6 seconds-it turns off device again. My program load a dll which loading it take around 6-7 seconds-becouse on loading it does some other things too-. So how can i prevent system from getting back into sleep mode. I think the calling SystemIdleTimerReset on another thread solve might the problem.but how much the interval should be? and also i read somewhere that keylock programs interfere with this and when keylock is on,calling this wont keep system alive.. so is there any solution?

  • Anonymous
    October 02, 2007
    Anyone out there familiar with CommonTime mNotes?! I have a question relating to our corporate PDA solution - M3100s (aka HTC Hermes) ROM version 2.11.61.1 running Windows Mobile 5 with CommonTime Msuite v.4.3.966 hooking into our Lotus Notes email for push etc Now...regarding Push. My understanding is as follows: The device registers with mnotes notification server "hello, I'm here"...if any new mail is waiting then mnotes will push it out to the commontime client on the device.  So far so good. I'm also under the impression that if the PDA is 'asleep', then it is no longer bothering to regsiter its self with the mnotes notification server, and therefore receives no push mail. To combat this, in the mnotes client there is a 'Device wakeup Period' slider which specifies a how often the device wakes up from its slumber to go regsiter with notification server. By default, this is set on the slider to happen every hour. So what power state constitutes 'asleep'in this instance? At what point does the PDA switch from receiving a new mail pretty much instantly...to being asleep and the device having to drag itself out of bed to go and handshake with the notification server to pick up new mail?! Bob

  • Anonymous
    October 15, 2007
    Sorry for such a late response.  It appears that I missed these questions. Tim: Processor speed is entirely an OEM thing.  There's nothing inherent in the OS that sets processor speeds, and anything regarding these speeds would be separate from the device states.  It's possible that the OEM choose to change rates at various states, but I wouldn't expect that.  It's more likely that they do it based on CPU idle than user inactivity.   roozbeh: It sounds like you're being hit by the Resuming state.  SystemIdleTimerReset doesn't affect the resuming state.  If you search this page for "PPN_UNATTENDED" you'll find a comment where I explain what you need to do. Bob: I'm sorry, but I'm not familiar with mNotes.  I'm guessing, however, that the "asleep" you're talking about is whenever the system is suspended.  If you go into the Power control panel, you'll see words to the effect of "on battery power, suspend if the device is unused for 3 minutes."  You can change the number of minutes there.  Whatever you set, if you don't interact with the device for that long it will suspend.  It will also suspend if you press the power button. Mike

  • Anonymous
    November 02, 2007
    Is it possible to wake the device from sleep by pressing the screen not by button? So, when the device is standby (or screen off), user could press the screen to make the screen on again? Thank you.

  • Anonymous
    November 05, 2007
    Ian, it is possible for an OEM to make hardware that acts that way, but I haven't seen any do so in a very long time.  The general problem with that concept is that the device will be touched while the device is in your pocket and that will drain your batteries. The last device to enable this had a clear plate that went over the screen to keep it from being touched when you didn't want it to be.  Needing to move the plate aside was worse than needing to press a power button. Mike

  • Anonymous
    November 06, 2007
    The comment has been removed

  • Anonymous
    November 07, 2007
    The comment has been removed

  • Anonymous
    November 15, 2007
    Thanks for the article! But what a mess those power-related problems! I never heard of anything designed so bad, sorry M$ guys, you do not have any idea how the good software is made. I see different hard-coding in OEM drivers every day. They do it not because they are stupid, but because they have no other way to get behavior they need... And we are not speaking about rocket science here. And now we need that special behavior in my application, but we cannot hard-code it into driver! IWe need it to work on hundreds different (but essentially the same) pieces of hardware... No way. You can censor my comment off, but Windows Mobile applications do not get any better from this. :(

  • Anonymous
    November 20, 2007
    Jason, we certainly didn't expect OEMs to hardcode app names into their driver.  )-:   Can you tell me more about what your app is trying to do?  What is the scenario where you want the user to send your app keypresses without him seeing the screen?  In general, if I'm interacting with the device I expect the screen to be on.  If I'm not interacting with the device, I lock the keypad. Mike

  • Anonymous
    November 20, 2007
    The app in question is our media player product named Pocket Player, www.conduits.com/products/player, and users often want to keep the screen off when they are controlling the device. Media players would want this functionality; I'm not sure off-hand for other use case scenarios. It's the "ScreenOff" power mode above, and works on all devices except those that hardcode WMP in their driver. "Interacting with the device" could be limited to just pressing Action to pause playback but unfortunately the screen turns on after any keypress, unless we fake our window class name.

  • Anonymous
    November 21, 2007
    The comment has been removed

  • Anonymous
    November 22, 2007
    The comment has been removed

  • Anonymous
    November 26, 2007
    Mike, I have a piece of code that uses CeSetUserNotificationEx to run applications at a given time. The code works fine on Smartphone, but on PocketPC it does not wake up the device, but rather queues up all notifications and runs them when the device is manually woken up. What would be the correct way to get this working this on the PocketPC. I have seen samples that suggest that CeSetUserNotificationEx is the way to do it on PocketPC but for some reason it does not work(The Pocket PC device is AT&T Tilt or HTC TyTn II if that matters).

  • Anonymous
    November 27, 2007
    Stefan, the correct way to do what you're describing is to use CeRunAppAtTime.  That will launch your app at the given time, and will wake up the PocketPC to do it (if necessary). Mike

  • Anonymous
    December 02, 2007
    Thanks Mike, Unfortunately, CeRunAppAtTime does the same thing -  if the device is awake both CeSetUserNotificationEx and CeRunAppAtTIme work correctly. Once device is asleep they "queue" the notification(s) and run them once you wake up the device. I know that they are scheduled correctly and they run because the moment you press the power button everything executes as planned. Do you have any idea why would that happen? Can it be device specific (again the device is HTC Kaiser, TyTn II, AT&T Tilt).  

  • Anonymous
    December 02, 2007
    Stefan, It might be that the device is in Unattended mode, but is indeed running the application. This gets around the longstanding "device wakes up at midnight" problem. Try calling SetSystemPowerState(NULL, POWER_STATE_ON, 0) in your WinMain and see what happens.

  • Anonymous
    December 04, 2007
    The comment has been removed

  • Anonymous
    December 17, 2007
    The comment has been removed

  • Anonymous
    January 26, 2008
    I have a WM5 application that needs to periodically check information from the RIL interface (say every 3 or 10 seconds). Currently, if no user input is entered the PPC would fall into the idle state (not suprisingly), thus stopping the application. I can use a few minutes timer and invoke the CeRunAppAtTime (for the same application) but am not sure this is the best way to revive the application. What would you suggest? BTW- I use C#

  • Anonymous
    January 29, 2008
    Hey Mike, I'm glad that I found sucha great blog and I've got a several questions for you :)

  1. Could you tell me, please, what WM's thread scheduler do when it has nothing to do? For example, all threads are in an awaiting state. I'm almost completely sure that it is not using "while( no_new_external_events ) {}" to spend that "vacation" time. As I remember my university course the x86 has HLT command to make CPU freeze until an interrupt occur. Does WM use the same feature of CPU's it running on? Maybe it is not a responsibility of your team, but maybe you know how it done by OEMs in certain commercial devices.
  2. What is the best way to get current CPU's utilization? There's no GetSystemTimes on CE platform. I found idea to use CreateToolhelp32Snapshot + Thread32First/Next + GetThreadTimes. But that enumeration could be interrupted by thread switch, so we could get a mistake. Isn't it? Thank you, Denis Stanishevskiy
  • Anonymous
    February 04, 2008
    I am shutting down a Psion Device (Win CE 5.0) using the following calls - FileSystemPowerFunction(1); PowerOffSystem(); What api should I call to turn off the Keyboard backlight? Thanks

  • Anonymous
    February 10, 2008
    I have nearly the same situation as "Hezi". I have a WM5/6 PPC application that needs to periodically check information from the WM registry. Currently, if no user input is entered the PPC would fall into the sleep mode, thus stopping the application. I can use a few seconds/minutes timer and invoke the CeRunAppAtTime (for the same application) but am not sure this is the best way to revive the application. What would you suggest? Please answer.

  • Anonymous
    March 14, 2008
    What exactly is the difference between idle and useridle? SetSystemPowerState(NULL, POWER_STATE_IDLE, 0); SetSystemPowerState(NULL, POWER_STATE_USERIDLE, 0);

  • Anonymous
    May 16, 2008
    well, i think taht  u can help me. When I turn off button of my device (G-smart), GSM signal down, and I dont receive callas and sms. This device dont have rom upgrade anymore (out of production). Any idea for solution?? arovaris@hotmail.com

  • Anonymous
    June 03, 2008
    I have target system (WinCE 5.0) in which Suspend/Wakeup works if the  WinCE GUI Shell is included on PB OSDesign. Without the WinCE GUI shell, the system always does a Cold Boot start. Any thing I should look for.?

  • Anonymous
    June 18, 2008
    Hi, How can I turn the screen off in c#? Thanks.

  • Anonymous
    June 18, 2008
    Hi, Firts I must say that I suppose POWER_STATE_IDLE  mode is not valid for my sbc:arm9 based qq2440.Because when i use POWER_STATE_SUSPEND, the system replies,but using POWER_STATE_IDLE i don't get result as screen off. Now, my question is how the system gets through the POWER_STATE_ON state when a user touches the screen again. Namely i should ask how the system gets events when it is on suspend mode? Thanks in advance.

  • Anonymous
    June 19, 2008
    Hi, In fact i want to set all the things from platform builder, namely the time for getting through the screen off mode and then when user touches the screen again on mode. Is it possible? I suppose it can be if i set somethings in the source code of the pm driver or the PWRBTN_PCF driver(the pm driver in the sbc's bsp)? Thanks in advance.

  • Anonymous
    June 27, 2008
    I'm working with a USB device connected to a WM 5.0 terminal.  I've found that the terminal does not consider USB traffic when determining if the terminal is idle.  So what happens is, I'm sending data in thru the USB port and the terminal goes to sleep.  I've not found the PowerPolicyNotify to work for this case.  I also can't seem to get the PPN(false) call to work.  It seems to hang up. [DllImport("coredll.dll", CharSet = CharSet.Unicode)]        public static extern bool PowerPolicyNotify(int dwMessage, int dwData); bool bStatus = PowerPolicyNotify((int)PPN_Message.PPN_UNATTENDEDMODE, 0);

  • Anonymous
    November 06, 2008
    I'm developing a WM 6.1 device and my power button device driver calls PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0);, so the device normally goes to suspend and when the device is in the ScreenOff state its lcd/backlight turns on. I'd like to add an optional behavior to my device through a dedicated configuration in the user interface. That is I'd like that optionally pressing the power button it puts the device into the ScreenOff state instead of the Suspend state. Do I have to change my power button device driver or does it exist an alternative way? does a registry key exist to get this type of behavior? How can I associate the power state transitions (i.e. from On to ScreenOff) and the power events (i.e. like power button pressure) ? thank you!! Marco