Power to the People

Article
08/01/2005

In 2002 when we released our first Smartphone OS, there were quite a few fundamental differences between the Smartphone and the PocketPC. Since then, we've been working to unify the platforms. In WM5, we did a bunch of plumbing work to this end, and brought Softkeys and Persistent Storage to PocketPC. At this point, the two biggest differences in the platforms are the PocketPC touch screen and the wildly different power models the two platforms use. In this blog entry, I'm going to talk about those power models and what they mean to users. I'll follow up with a second entry that talks about what this means to ISV developers.

You are getting very sleepy...
It all comes down to this: PocketPCs sleep, and Smartphones don't. Smartphones have a model that's very easy to understand. The device can be on, or it can be off. When it's on, everything works. When it's off, nothing does. When it's off, you can't receive phone calls, you don't get meeting reminders, and nothing is burning power. You can pull out the batteries and have no detrimental effects. (Okay I'm stretching the truth a bit here. Many phones use a tiny bit of charge to keep a clock going so that you don't need to reset the time every time you pull out the batteries.)

The PocketPC model is much harder to explain. It can be on, it might be able to be off, and it can be somewhere in between. A purist will call that in between state "suspended" but I like to anthropomorphize my devices, and "sleep" is more catchy. When the device is asleep, the screen is off, and programs aren't running. In fact, by and large, programs don't even know that the system went to sleep. We never tell them, and we expect them to act as though it never happened. While the PocketPC was asleep, they just didn't run.

Still, while the system is asleep, there are a few things that keep working, and those things can wake the system back up. For instance, the power button works. And an incoming phone will wake the system up. So will a meeting reminder. Applications have the ability to say, "Run me at this time, and wake the system up to do it if you have to." If you've ever had your PocketPC turn on in your pocket, it was a result of something deciding it was time to wake up, even though you didn't want it to. (Yes, that annoys me too.)

Sleep is the main way that PocketPCs conserve power. So the PocketPC is always trying to fall asleep. He's like a bored security guard on the graveyard shift staring at a TV screen with his eyes drooping, only to jolt himself back awake every few minutes. In Settings you get to tell your PocketPC how long to stay awake. Three minutes is typical. And then you've got to actively work to keep him up. If three minutes go by without you pressing any buttons or touching the screen, he'll fall back to sleep. (You can put him right to sleep by pressing the power button.) Apps that want to keep him awake longer need to be proactive about it. There's a function apps call (SystemIdleTimerReset) every 30 seconds when they want the system to stay awake. This is how Media Player keeps the music playing for longer than three minutes. This is also how Active Sync can make sure it syncs everything. And this is how PIE can download huge files without the system falling asleep in the middle of them. Etc.

But wait, it gets even more complicated than this. What happens when the system wants to wake up briefly to do something (like keep your email up to date) but doesn't want to bother you about it? (There was a time when the PocketPC turned on at midnight and shined its backlight all over your bedroom, thus waking you up with him. Now he's smart enough to not turn the backlight on for his midnight excursions.) There's a semi-lucid state between Sleep and On called "Unattended." In Unattended, the system is running, but the screen and backlight are off. Unattended is how ActiveSync keeps your email up to date without turning the device on in your pocket.

PocketPCs generally don't have a button you can press to turn them all the way to Off. But if you pull out the batteries (because of Persistent Storage, more WM5 devices will have removable batteries), they'll turn Off completely. By and large, however, when the device seems to be "Off," he's really just asleep.

That guy must drink a lot of coffee...
As I said before, things are much simpler in the Smartphone world. Smartphones follow a model we call "Always On." These guys never sleep. You can turn them off completely, but when you do that, you don't expect to receive phone calls (at least, I hope you don't. You'll be disappointed otherwise). Sure, if you don't touch any keys for a bit, the backlight will turn off. And if you don't touch any keys for a while longer, the screen will turn off. And with the screen off, he looks asleep. But he's not. He's just resting his eyes. Programs are still running, and everything is still going.

This is simpler for everyone involved. Users don't need to understand the differences between On, Off, Sleep and Unattended. And apps don't need to frequently call SystemIdleTimerReset to keep things going. We've written all of our Smartphone apps to use the CPU as little as possible. If you're not actively using the device, then nothing runs 99.9% of the time. And our OEMs have written code that makes the CPU go into an extremely low power mode whenever there's nothing for it to do. When the phone is sitting there idle, it's using just barely more power than a sleeping PocketPC.

But there's a drawback. Badly written apps can do very bad things to your battery life. Say you've got a cute little app that has an image of a kitty that jumps around and waves to you. And, say that animation makes the CPU run just 1% of the time. You've got the device sitting on your desk overnight, with the screen off, and this darned kitty desperately trying to get you to look at it, even though you're in bed and uninterested. The animation just cut your standby time to one tenth of what it would have been without it.

In my next blog entry, I'll tell developers how not to destroy your battery life. But, users, if you've got apps that run animations forever, get rid of them. Yes, the PocketPC sleep would have protected you from these apps. (Remember that apps don't run while a PocketPC is sleeping.) But, even on a PocketPC, if you've got an app that's burning power unnecessarily, it's probably not an app you want.

Note that the problem here is apps which use the CPU when you're not using the phone. Doing animations and such while you're interacting with the app is fine. If you're playing a game, the backlight is on. The backlight is burning a ton more power than the CPU is. But when you stop playing, that game better stop too.

Mike, what are you smoking?
The PocketPC "Sleep" model has been around since the dawn of time. Okay, well, at least since the dawn of Windows CE. So why did Smartphone change it? You're going to find this hard to believe, but in a connected world, the Always On model actually burns less power than the Sleep model. Yes, you read that correctly. Staying on all the time actually burns less power than going to sleep. Here's why.

The issue is that it takes a "long" time to go to sleep and a similarly long time to wake back up. When a PocketPC goes to sleep, we have to notify every device driver so that they can each save any important information (their "state") and shut off the hardware they're controlling. Then, on wake up, we need to notify every driver again and have them turn all their hardware on. This process can take up to three seconds in each direction.

Smartphone, on the other hand, can come out of his idle in a millisecond, do what he needs to do, and go back to idle a millisecond after he's done.

Imagine that your device receives a SMS message. The sleeping PocketPC will need to run the CPU for around six seconds to handle it. The Smartphone will do the same task in a few milliseconds. Waking up is much more efficient on a device that doesn't sleep. It turns on only the devices necessary, uses them for the minimum amount of time needed, and then immediately shuts them back off.

Now, imagine a device that gets an SMS every time it moves from one cell tower to another, and imagine being in an area where you're on the boundary between two towers. Or, consider being signed in to an Instant Messenger client and having it frequently updating your friends list. Or, imagine a process that downloads data you care about every few minutes. Etc. As these things become more pervasive, we'll see the Always On power model being much more energy efficient than the sleep model.

In Windows Mobile 5, the PocketPC still uses the original Sleep power model. In some future version (maybe the next, maybe the one after that, we don't know yet) PocketPCs will move to the Smartphone Always On model. And then the touch screen will be the one big difference between them.

Mike Calligaro

Comments

Anonymous
August 01, 2005
Excellent information and a very well written. Keep it coming!
Anonymous
August 01, 2005
Interesting blog from Microsoft about the power states in the new version of Windows Mobile 2005.

But does anyone know if the more troublesome problem with the maximum number of processes have been fixed?
- or is it still only possible to run 32 processes simulataniously in Windows Mobile 2005?

Furthermore, what about the driver memory model? Is that still split up in in Windows Mobile 2005 so that there is a memory side for applications and a memory area for drivers?
- Will the "Bluetooth Manager" still raise "Not enough memory" exceptions in Windows Mobile 2005?

If anyone has sources from within Microsoft.. please let me know about the above "problems" status in Windows Mobile 2005?

Regards,
Kristian Reesen Skouboe
Computer Scientist
Anonymous
August 02, 2005
Any device that takes 3 seconds to suspend should be limited to idle and off. However, that shouldn't prohibit other (well designed) phones that can suspend in 250 mS from using suspend. A combination of persistent store could be quite useful

Many SP designs could take advantage of suspend to provide a better customer experience... like avoiding the amazingly painful 45 second boot time for a smartphone. Fix that, and we can all brag about eliminating suspend.

Doug
Anonymous
August 02, 2005
Doug, I think you're mixing apples and oranges. Adding suspend to smartphone wouldn't decrease the boot time. Suspend is the equivalent to idle, not off. In suspend, the phone can still ring. In off, it can't. If you want to be able to receive phone calls, then you'll let your phone idle. And smartphones come out of idle in milliseconds. If you're actually turning you phone off, I assume you're doing it to keep it from ringing. Even a suspending smartphone would be turned off and need to boot again for that.

Also, we did work in WM5 to decrease the boot time. The WM5 phones I've seen so far boot in about 30 seconds. You may claim that's still too long, but it's progress.

Finally, even a device that takes 250 ms to suspend is inefficient compared to a device that takes 1 ms to idle.

Mike Calligaro
Anonymous
August 02, 2005
Kristian, the max number of processes has not changed in WM5. That is fundamental to the way CE works and will take a significant amount of work to change. However, we understand your pain and want to fix it.

The driver model was also not changed, but it never worked the way you suggested. There is no division between memory for drivers and memory for applications. However, if you're talking about virtual memory constraints (that's a division between memory for DLLs and memory for applications), unfortunately, that too was not changed for WM5. It's another pain point we're very aware of, and another thing we want to fix, but that will take some fundamental rearchitecting.

I'm sorry, but I'm not familiar with the Bluetooth Manager issue you're describing, so I can't answer that question. There are two bluetooth stacks, one provided by Microsoft and one provided by a third party. The Microsoft stack doesn't have anything called a "Bluetooth Manager" so I believe you're asking about an issue with the other stack. I'm not familiar with changes they made to their code for this release.

Mike Calligaro
Anonymous
August 02, 2005
Mike,

First, I'm not interested in starting an argument. There are valid reasons for suspend and for true off. I would simply like to point out that ‘always off’ isn’t always the best way.

My point is that to the user, Suspend == off. This, along with the persistent store model has its advantages. A suspend state in a Smartphone could be quite useful for the appearance of fast 'turn on time' avoiding the long boot time in many, but not all, cases. After a few hours in battery powered suspend, the phone could quietly power off (real off) to save battery.

For example, if a suspend enabled phone were being charged overnight, the user would grab the phone in the morning, hit the power button, and the phone would immediately be on, without the need to wait 30-45 seconds to check email, send a text message, or make a call.

There are plenty of other reasons (too many to go into here) to have the CPU quickly available when the system is 'off'. I've talked to cellular phone manufacturers who also believe this.

Finally, I'm not talking about replacing Idle with Suspend. CE devices that support Suspend also support Idle. There is no power state that a Smartphone can get into that a 'suspend enabled' smartphone couldn't also get into.

Doug
Anonymous
August 02, 2005
great, article. I do have a question...you mentioned that the only 2 differences are the the touch screen and the power mode. Does this mean that smartphones can have WIFI? I haven't seen any that is support it yet.
Anonymous
August 02, 2005
The comment has been removed
Anonymous
August 02, 2005
(I'm following up with Doug offline.)

Dean, yes WiFi on Smartphone is a new feature for WM5. You will see WiFi enabled smartphones in the near future.

Riki, it sounds like you agree with me. (-: You wrote an app that DIDN'T run animations forever, so yours isn't one I'm telling people to get rid of.

And, yes, your description of how PPC Phone works is correct.

Mike Calligaro
Anonymous
August 02, 2005
I never understood why people would want to turn their phones off... I guess if you had it in a movie theater or hospital (go into airplane mode for that) but for the most part I always leave my phone on so the startup time is a non issue for me.
Anonymous
August 05, 2005
I am truly sorry to drag this off topic more, but this is the first time I've seen a definitive answer to this question.
Personally, I consider this to be the single biggest problem with CE--to the point that it makes me hesitate to use the device as it advertised.

I see now that it is too late to expect the architecture to change in WM5's first release. Instead, please let me ask:
1. Since the basic architecture and process limit has not changed, does WM5 at least boot "cleaner" than WM2003? Will I be able to run my WM5 device longer before process space runs out? Of course, some of this has to do with what he manufacturers load, but "all else being equal."
2. Is there a timeline when we can expect to see this resolved? A service pack in six months? Or a total rewrite of the OS in 2007?
3. Related to above question. Now that WM5 has been released to manufacturers, will this issue take a priority spot to be fixed--not just looked at?

Again, I apologize, but I don't think I can stress enough how disappointed I am to hear this news. The memory situation has become so bad, with the VGA devices especially, that I don't even recommend them to "casual buyers" anymore. Without fail, I end up receiving calls asking why this program or that won't run when "it worked yesterday." Please keep in mind that these are not power users that are pushing their systems to the limit, either.

Thank you for your time in answering our questions--it is appreciated.

-Tye
Anonymous
August 05, 2005
The comment has been removed
Anonymous
August 05, 2005
So, I've finished watching Westworld, again. With robots, action, and that grainy old-movie look, it's...
Anonymous
August 08, 2005
So I decided not to blog much from O’ahu – not such a bad thing, eh?&nbsp; (..and I got sick of updating...
Anonymous
August 08, 2005
So I decided not to blog much from O’ahu – not such a bad thing, eh?&nbsp; (..and I got sick of updating...
Anonymous
August 10, 2005
In Power to the People we learned some of the differences between how PocketPCs and Smartphones handle...
Anonymous
August 11, 2005
In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily.&nbsp;...
Anonymous
August 12, 2005
In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily.&nbsp;...
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
August 24, 2005
The comment has been removed
Anonymous
August 25, 2005
The comment has been removed
Anonymous
December 06, 2005
Where can I get specific information about the power management ? Programming the pocket pc is so frustrating because I really can't find any information, especially information about API's.
At the moment I'm writing a ppc application which captures gps data. Everything works fine, but the ppc's battery last only for about 4 hours. So now I've extended my app with some API's who turn off the ppc after receiving gps data in 20 secs and than after 1 minute the ppc app starts again (with CeRunAppAtTime) receiving gps data. (This way the battery lasts for about 20 hours). However, when the com port is closed and opened again periodically, the gps receiver has to do a restart so it takes some time to record the first NMEA string with good data quality. So that's the reason why I would like the gps not to go in suspend mode. If it stays on then I have good data each time my app starts itself. How can I force the COM2 (or gps) not to go in suspend mode ?
Anonymous
January 10, 2006
Nice article, Mike. However in regards with Doug's comment , i believe your the last section of your article is really comparing an orange to an apple.

".. but in a connected world, the Always On model actually burns less power than the Sleep model.."

It should be rephrased along the lines of < Smartphone HARDWARE burns less power than a PPC HARDWARE would ..>

Smartphone hardware does not have touch screen , screen size generally are smaller, less power consuming chips ( ie. WiFi chip ) .. mentioned are all power consuming hardware features you would find on PPC devices.

If i were to say if i have this PPC hardware running Always On model ( ie. SystemIdleTimerReset() often enough to make it Always On ), now your original statement wouldn't be correct if it is claiming Always On burns less power than Sleep Model in this sense.

Different platforms require different power strategy and Microsoft is applying a wise strategy to suit the nature of different hardware.
Anonymous
February 14, 2006
if smartphone & pocket pc only has those differences, can a smartphone install any application that a pocketpc phone use?
I mean, not all programs can be navigate by just buttons, right?
Anonymous
February 15, 2006
Hanson, the smartphone is a subset of the PocketPC. Almost every application I write runs on both SP and PPC, but it's entirely possible to write an application that only runs on one or the other. If the application required a touch screen or physical number keys, it would limit itself to one of the two platforms. Or, if an application assumed a screen size that was in one platform but not the other, it also wouldn't work everywhere. Finally, if an application relied on functions that exist on a PocketPC but that don't exist on a smartphone, it wouldn't run on smartphone.

Mike
Anonymous
April 02, 2006
I had a smartphone for a year. I wanted my phone off at night (to save batteries) and for the reminder to work even if the phone is off. I use my phone as alarm clock so it's very embarrassing being almost late for work when phone alarm doesn’t’ work due to phone being off. Smartphone just couldn't do this so I fell out of love with my orange spv 500 and went back to a normal phone. Another thing that turned me off the smartphone was the filing system - very scary. I want to find a file to send to someone and then I find myself navigating through the folders as if it's a desktop - very embarrassing.
Anonymous
May 24, 2006
Mike,

I am particularly interested with this statement."And an incoming phone will wake the system up. So will a meeting reminder.".

How could we intercept or disassociate any events from waking up the system?.

any system level or low level APIs which we can use?.
Anonymous
May 24, 2006
The comment has been removed
Anonymous
May 26, 2006
Mike,

Every incoming call, upon a call is offered, and after a call is disconnected (I am using TAPI 2.0), the system will definitely wake the system up.

I tried the suggested advice on disabling the notifications for ALL available options (not only call related options), just trying to identify which of the events wake the system up. I tried by unchecking ALL options found in the notifications, but it still wake the power up.

Appreciate if you could point out which particular low level events (from OEM point of view) to wake the system up. Some resource/articles would be very much appreaciated.

I am interested with the incoming call events where it will be handled by our TAPI application without waking the system up.(and without turning on to Flight Mode, which can not be handled by our TAPI apps).
Anonymous
May 30, 2006
When the system is suspended, the only thing that can wake it up is a hardware interrupt. The CPU has a single interrupt pin and a number of different interrupt sources are mixed together (through what's called a "Multixplexor" or a "MUX") and fed to that pin. Which interrupt sources are used is dependent on the hardware design, but these are the typical ones:
1) Keyboard (sometimes any key, sometimes just the power button).
2) Real Time Clock (RTC). All systems will have an alarm that generates a hardware interrupt when the RTC hits a set time. This is how meeting requests and scheduled active sync wake the system up. They set the alarm for time X, and at that time the RTC fires the hardware interrupt and wakes up the device.
3) Celluar hardware. On most devices, the cell stack is running in its own CPU and processing cell activity. If a phone call comes in, it fires a hardware interrupt that wakes the device up.

When suspended, the CPU is effectively off. No code is running, so no code you can write will change things. When a hardware interrupt is fired and the system wakes up, it goes through a longish process in which every hardware driver is notified and then the system is woken up.

The OEM wrote the code that is called just before the CPU is turned off, as well as the code that is called the instant it wakes up. So he has a lot of control over what happens there. The OEM also wrote all of the drivers that get called during the wakeup process. So they have opportunities there as well.

When the system finishes waking up, it goes into the "Resuming" state. In that state, the screen is off and the device will suspend again in 15 seconds unless something puts the system into a different state. However, because it was woken up for a phone call, the cell radio driver notifies the phone app that a phone call is coming in, and the phone app puts the device into the "On" state and plays the phone ring sound.

Because it's hardware, not software, that wakes the system up, the only way to keep it from waking up is to disable that hardware. For the phone, the only way to do that is to disable the cell stack. And the best way to do that is to put the phone into flight mode.

Mike
Anonymous
July 09, 2006
Hi!
Guys there's this GPS software, 'i-GO' and developper says it runs on Windows Mobile for Pocket PC. Can anyone tell me if Windows Mobile 5 is compatible with Pocket PC or Smartphone? Or maybe both?
Thanks in advance.
Anonymous
July 15, 2006
Interesting blog, i actually landed here because i am having a bit of a problem. I have an HTC Universal and was forced to disable the "sleep" aka "suspend" features because it takes 6+ seconds to wake up rather vital functions such as your RINGER/AUDIO and vibrating functions.

The problem with this is, 6 seconds on an incoming call = you miss all your calls [because it only starts ringing after the device wakes up] !

So the person calling me, hears the phone rings, but my little PPC is sleeping and takes ages to turn on audio/vibrating functions to let me know of the call.

In fact, this is the order of events:

1. Person calls me, this person hears ringing on his end.
2. My PPC in "sleep" mode, starts waking up to receive this incoming call.
3. First thing to wake up after 3-4 seconds is the backlight. So i can SEE i am receiving a call on my screen, but my phone ain't ringing yet.
4. After another 3+ seconds, the phone starts ringing and vibrating.

Now point 4 for me will seem like the FIRST ring, for the other person it's like the 7-8th ring! Most people don't wait that long..missed call!
Anonymous
July 17, 2006
Chris, they behavior you're describing is not normal. Did your device act this way when you first got it, or did it start waking up slowly later? If it started later, have you installed any extra software on the device after you bought it? Can you try uninstalling that software and seeing if it fixes your problem?

If you haven't installed anything extra, is there anything else different about the device compared to when you bought it?

Mike
Anonymous
July 17, 2006
The comment has been removed
Anonymous
July 17, 2006
The comment has been removed
Anonymous
July 17, 2006
The comment has been removed
Anonymous
July 17, 2006
The comment has been removed
Anonymous
August 03, 2006
Thanx for the very informative article :)

My problem: I have a regular Windows Mobile 5.0 Pocket PC. I have intergrated WiFi and have installed Skype on it.

There should be away to reduce power consumption in an Smartphone type way, to constantly receive Skype Call Notifactions or MSN Messenger Messages thur WiFi without requiring the Device to be 100% On (which eats a ton of power, on my device its about 1% a minute)

Perhaps a Service Pack or other fix to allow a 3rd power state would be useful to alot of people.
Anonymous
August 16, 2006
In my recent “Power to the Smartphone” entry, I talked about the biggest drains on Smartphone batteries.&nbsp;...
Anonymous
September 18, 2006
With regards to the 32 process limit on WM. What exactly is the behaviour when the 33rd process attempts to launch, and is this behaviour consistent across PPC 2003 and WM5 devices?
Anonymous
October 05, 2006
My Samsung i730 running Win Mobile 5.0 still wakes up at midnight and turns on the backlight. Does anyone know of any fixes?
Anonymous
October 23, 2006
I have a Qtec 9100 (WM5) with a 1 GB storage card. I keep my music/podcasts on the storage card. When I power off while playing a song and then power on again the media player is there but the song/playlist is gone so I have to go to the library and find the song again etc. VERY annoying. Is this a power thing or a problem with my Storage card? Any help would be greatly appreciated.
Anonymous
January 31, 2007
I have the same problem as J. Heyison -- I just upgraded my i730 to WM5.0, and now it keeps turning the backlight on for no reason. In fact, sometimes it turns on the backlight but not the screen, so I just see a white screen. When I flick the backlight switch on the left side, it then comes on normally, and I can turn it back off -- until the next time it decides to turn itself back on. It was so bright it woke me up in the middle of the night last night! (Okay, I'm a light sleeper...)
Anonymous
February 07, 2007
I have a similar problem to J. Heyison and Sam, except that at midnight the i730 makes a sound (which wakes us up, my wife wasn't happy...). I don't think the backlight is coming on. It may have started doing it after I accidentally turned on the alarm, and then turned it off. It appears to only do it some nights, maybe one night a week. Any ideas? (BTW, great blog!)
Anonymous
February 13, 2007
Funny that Media Player on Qtek 8310 eats the battery quite fast (4x faster) even if nothing is being played back! I need to manually close it using the Task Manager every time I do not need it :( Someone (Media Player guys or Qtek team) should check this. Mike, thanks for the great articles!
Anonymous
February 28, 2007
The comment has been removed
Anonymous
February 28, 2007
Unfortunately, we're the wrong people to report this to. The backlight driver on the i730 was written by Samsung, and no one at Microsoft has access to it. If it's misbehaving, only Samsung can fix it. Your best bet is to report this to your mobile operator so that they can report it to the OEM. Mike
Anonymous
March 26, 2007
Thanks for these information , I have a problem I did't have on the previous versions of windows ce (mobile), and it concerns the power management, and more precisely the sleeping state and the wake up event. I wrote an application where I catch when a sms is received and then processes it. When the device is turned on (and not suspended), everything works fine. My problem occurs when the device is in a sleeping state (I can still receive phone call and text messages...). But when this event occurs, instead of keeping the device awaken, it just flashes the screen (for a few milliseconds), and then go back to sleep... It doesn't process the message. Then, if I manually wake up the device (by pressing the power button), everythings goes back to the normal state and my code is correctly executed. Do you know why I have this behaviour and how to fix it? Many thanks, jb
Anonymous
March 26, 2007
JeanB, there is a discussion on this in the comments of the Power To The PocketPC thread, specifically here: http://blogs.msdn.com/windowsmobile/archive/2006/08/16/702833.aspx#744642 You might also want to read the "Power To The System" entry to get a background for this: http://blogs.msdn.com/windowsmobile/archive/2005/08/10/450186.aspx Mike
Anonymous
April 17, 2007
Hi Mike, It's almost a year, when my first attempt to force the ppc to sleep when an incoming call is detected, and I still have not found the ideal way to do this. Small ISVs like us would like to see more flexibility in terms of implementing software in the device we purchased and owned. Till this moment, am still trying various methods to force the device to sleep to conserve battery power by switching of backlight, and sending the device to sleep mode. My question would be, what other options do we have to do the above other than sending the device to flight mode, as doing so is equivalent to disconnecting the PPC phone from the outside world. Some implementation, voice answering machine, mini implementation of call centres etc from the phone would simply means impossible. We as the user/developer would like to see more and take advantage more from the capability of the phone in terms of its portability, processing power and phone capabilities. If the above is simply not possible, what other options do we have?.any way to send the reverse interrupt to send the power/backlight to off?. what are the ways to do so? (by studying the interrupts provided by the BSP vendor?. This may even kept confidential only to OEM partners) Any suggestions?

<snip> When the system finishes waking up, it goes into the "Resuming" state. In that state, the screen is off and the device will suspend again in 15 seconds unless something puts the system into a different state. However, because it was woken up for a phone call, the cell radio driver notifies the phone app that a phone call is coming in, and the phone app puts the device into the "On" state and plays the phone ring sound. Because it's hardware, not software, that wakes the system up, the only way to keep it from waking up is to disable that hardware. For the phone, the only way to do that is to disable the cell stack. And the best way to do that is to put the phone into flight mode. Mike

Anonymous
April 17, 2007
I don't understand what you're trying to do. You want the phone to ring and the immediately go back to sleep? Won't the user be frustrated that he can't answer the phone? Mike
Anonymous
April 18, 2007
Hi Mike, PPC phone can be implemented in various ways.Applications can be developed in various scenarios and situations, such as PPC phone-based Call Centre Manager, such as a sales hotline, where the main PPC is installed with an application which handle calls, and route it to a specific phone number of sales agent/account manager which handle that customer account. To the customers, it would seems that they have a single point of contact number (PPC phone with the installed application). In this scenario, the ppc phone can also be used for other purpose, such as document management, etc. It is impossible to have the phone backlight lit up whenever a phone call is placed to the PPC phone. This will quickly drain the battery. The way we did it was to handle the call and power off the handset soon after the device wakes up. However, we still lost a few milliseconds and drain up some battery life when the device wakes up, few milliseconds (within a seconds) of lighting up the backlight and the application's effort in switching off the power. It would be better to have a design which could provide some flexibility to the developer whether to wake the system up (and/or lit the backlight) when there is an incoming call. Thanks and Regards, Andrew
Anonymous
April 18, 2007
Okay, I think I understand what you're doing now. There's no way for an ISV to guarantee that the backlight won't come on for a few milliseconds. The OEM has that ability, since it's his driver, but there's not enough hardware standardization to make it possible for ISVs to rewrite the backlight driver. That said, many devices have a control panel that lets you completely disable the backlight. If the one you're using does, you can turn it off there, and not burn the milliseconds you're concerned with. I believe the fastest way to get the screen to turn off is this. As soon as your app detects the phone ring, first call: PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE); Then call PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0); Now handle the call. You need to be calling SystemIdleTimerReset(); every 30 seconds to keep the system from falling asleep while you're processing the call. When the call is over, do: PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE); The first PPN puts the system into a state where, if the power button is pressed, it will turn the screen off but not suspend. The second PPN simulates the press of the power button. Assuming the screen was on at the time, this will tell the system to suspend, but will instead go to the Unattended (screen off) state because of the first call. (If the screen was off when you did the PowerButtonPressed, it would turn the screen on.) When you're done with the call, the last PPN tells the system to suspend immediately (as long as there isn't another app in Unattended). If you couple that with the control panel setting that completely disables the backlight, I think this will be your most power efficient way to do what you're trying to do. Mike
Anonymous
April 18, 2007
I have tried the PPN before and backlight control panel settings in registry. However, due to the nature that the settings will only started kick in only if I emulate power off, on and then off the device again. Hence, this may not be fruitful, since the effort of the above far exceed the conservation of the power, unless, there could be some other way which I am not aware of. However, I am quite interested in venturing on rebuilding my own device drivers for cell stack, backlight, etc. Is there any information out there which I can refer to?. any pre-requisites on how to build my own device drivers? (such as getting to know the kind of hardware used, from which manufacturer, understanding the "MUX" which you have mentioned from the datasheet,etc). And also, is there anyway that two device drivers co-exist together for a particular piece of device?. Frankly,I have never developed any kind of drivers especially for Mobile devices, any online source which I can refer to?. (My guesses would be to study the sample from the platform builders, or others.) or perhaps these information are only limited to OEMs?. Another idea that came across my mind was,tapping into low level hardware interrupts and listen to whatever events occured, and report them back fast to the higher level application. Can I achieve something with this idea?.what are the pitfalls I may encounter?. and how can I achieve this from the Windows CE world?. Nevertheless, it is a very detail and fruitful explanation. I'm sure it will definitely benefit others.Thanks Mike! Sincerely, Andrew
Anonymous
April 18, 2007
There's no sanctioned way to write your own drivers for other people's hardware. But there are some amazing people over on http://xda-developers.com/ that manage to do it anyway. I'd say that's your best place to start. Mike
Anonymous
April 20, 2007
Hello eveyone, Is it possible to configure WM5 registry keys so as to enable an application run in suspended mode. In other words when the PPC goes to stand-by-mode I would like my application to keep on running. I have developed a Java application (runs with IBM J9) but when the PPC enters the suspend mode, threads pause and the application does not behave as it should do. My intention is not to completely disable suspend mode for the PPC, but just for an application (as it is possible to prevent e.g. the 'sound device' ('wav1:') from going to suspend mode, when the PPC goes to stand-by). The point is if you can achieve this by altering registry keys (setting a specific .exe for instance not to enter the suspended mode), not by having to write a C application to perform this ! Thank you in advaced.
Anonymous
April 23, 2007
christos, when the system is suspendend, the CPU is completely shut down. There's no way to shut the CPU off and keep your app running. The only way to keep your app running is to keep the system running. Doing that, though, would be bad for battery life. What does your app need to do that requires that it keep running all the time? Mike
Anonymous
April 28, 2007
It is a Java application that checks for name-days. When a nameday comes it informs the user. The user can define what time the reminder should check for namedays during the day. So if he choose 9.00am, the application will check for namedays at 9.00. Then there is a time-thread that counds x milliseconds so as to check for namedays next day (same time). In usuall phones the application works fine, without waisting too much battery. If I have to write a C application that wakes up the system every how often, then I presume that I should just forget Java...(what's the point of writting 2 programs for the job of 1!)
Anonymous
April 30, 2007
christos, does Java have any mechanism for calling native APIs (in C# this is called PInvoke)? There is an API call "CeRunAppAtTime" that does exactly what you're trying to do. You tell it, "Run my app at 9am tomorrow" and then exit your app. At 9 am, the system will wake up and your app will run. CeRunAppAtTime uses the system's Real Time Clock, which is the one clock that keeps running when the system suspends. So, if you use it, you won't have trouble with suspend. It will also protect you against the user running too many programs and the system closing your app because it needs more RAM. Mike
Anonymous
May 02, 2007
I think that you can call C from Java (99% sure) but since the Java application will be in suspend mode it won't be able to call anything...I think that the solution to the problem unfortunatelly is

create a C application that calls the Java (whenever the user specifies) or
disable suspendmode (bad for battery though). Anyhow, thank you veru much for your concern ;-) all the best, Christos <a href="http://www.geolos.com">http://www.geolos.com</a>

Anonymous
May 02, 2007
Again, using CeRunAppAtTime is the right solution. You run your app once, it calls CeRunAppAtTime and tells the system to run the app again at 9am. Your app then exits. At 9am, the system wakes up from suspend and runs your app. Your app does what it's supposed to do, then calls CeRunAppAtTime for the next day and exits. The next day, the system wakes up again and runs your app. The kind of app you're writing is precisely what CeRunAppAtTime was designed for. And we have a number of apps in the system that use it to do what you're trying to do. Mike
Anonymous
May 05, 2007
Thanks once again MikeCal, you've been more than helpfull. when you are saying that "...we have a number of ..." do you mean that you have open-source example files that use CeRunAppAtTime or documentation from where I can find out more information ? Thank you in advanced.
Anonymous
May 10, 2007
Hello Mike, You efforts are appreciated.

How can one set an application to run on 'wake-up'? 2.The application has been written and compiled, and works OK irrespective. Rgds

Anonymous
May 10, 2007
christos, sorry, I'm not aware of any open source code that uses CeRunAppAtTime, but here's a link to the documentation. http://msdn2.microsoft.com/en-us/library/ms908103.aspx I got there by going to msdn.com and typing "CeRunAppAtTime" into the search field. You can also get at this documentation from Visual Studio if you type the function name into the documentation index. Olu, I'm not sure about the best way to write an app that runs whenever the system wakes up. When I was looking up the MSDN article for christos I noticed a similar API called CeRunAppAtEvent which seems to allow for a wakeup event. I've never tried it though. If you use it and it does what you need, please report back.
Anonymous
May 11, 2007
Hi, MikeCal. I saw the comments between you and christos, i just want to know when my smartphone device has turned off by using the ExitWindowsEx(EWX_POWEROFF, 0) API, how could i boot my smartphone then. You said"when smartphone is off, nothing does.", so is there any API i can use for booting my sp, or there must have a hardware support. Thanks in advanced.
Anonymous
May 14, 2007
tbmvp, if you do a full shutdown of the phone, the only possible way to turn it back on is to press the power button. At full shutdown, the CPU is completely powered off and no code can be running. It would be possible for an OEM to design hardware to act differently, but I'm not aware of any that has. Any solution to what you're trying to do would either have to be a hardware one or one in which full shut down doesn't actually shut the phone down. Mike
Anonymous
May 17, 2007
Thank you for your answer, MikeCal
Anonymous
May 22, 2007
Dear Mike, I am the new owner of a pocket pc using Windows Mobile. When entering all day events, such as birthdays, anniversaries, etc. my pocket pc wakes me up at midnight to remind me of this all day event. This is true when entering events in the calendar mode and also when using the outlook option for entering birthdays. Can I change the default reminder time? My only solution until now has been to turn off the sound for notifications every night. Not the ideal solution. I would like to be reminded of these events, but not at midnight. If you can help, thanks.
Anonymous
May 23, 2007
Hi Celesta, I spoke with the calendar people about your problem (I've seen it too). The difficulty we have is that the alarm times are coming from the Exchange server. We're just staying in sync with them. We've had discussions with the Exchange team about this issue in the past and will continue to in the future. There's no simple workaround for you that we're aware of (no way to set the default). But, if you have a small number of these sorts of alarms, you can individually change the alarm times on them. Sorry I don't have a better answer for you. Mike
Anonymous
June 05, 2007
Hi Mike, I see it has been one year since you created this blog and you still answer questions. So, it would be great if you could answer mine too. Is there any way to prevent the Pocket PC from suspending without calling the SystemIdleTimerReset() function? If I perform an action which I do not want to be interrupted (like network communications) I need to call the PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) function and periodically call SystemIdleTimerReset() function. But calling the SystemIdleTimerReset() prevents the system from switching into one of the OFF modes (the screen remains on or dimmed but still on). If I start calling the SystemIdleTimerReset() function after I receive the notification that the system is in the OFF state (bit POWER_STATE_ON cleared / I'm using the RequestPowerNotifications() function) it's too late. Id does not prevent the system from going into suspended mode because the suspended mode comes right after the ON mode. Calling the SystemIdleTimerReset() in the ON state on the other hand is a waste of energy. How can I make the system switching into unattended mode when the system idle timer is timed out? BTW: Your blog and your comments have been a great help to my programming so far. Thanks.
Anonymous
June 05, 2007
Hi Radek, I'm glad the blog has been useful for you. The problem you're describing is one of the many reasons we like the Smartphone power model better than the PocketPC one. There is unfortunately no good way to do what you're trying to do. Time out to unattended and time out to suspend are on the same timer. For your users, the half-solution is that after your app does the PowerPolicyNotify they can hit the power button. So even though they can't rely on the phone to time out after so long, at least they can make sure it does turn off. The half-solution for you isn't much better. You can simulate a power button press with PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0); If you first enter unattended and then do that, the screen should go off. But there are significant troubles with this.

If the user is doing something ELSE with the device when your app does this, you'll suspend it out from under him. That would be annoying to say the least.
If, for whatever reason, the screen is already off, simulating the power button press will turn it back on, which it the opposite of what you want. Not that I have a better solution for you. If you DO go down this route, I suggest you only do it when your app has focus and you've noticed that the user hasn't interacted with it for some amount of time. That will lessen the chances of you turning the device off when the user doesn't want you to. Yes, you're redoing work we should be doing for you, but that's the way the cookie crumbles in this case. Mike

Anonymous
June 05, 2007
The comment has been removed
Anonymous
July 10, 2007
Mike, MY application wakes up my PPC every once a while from the suspended mode to check some signals, I only need the wi/fi and CPU for the checking. And if the signal is detected, then I will fully wake the PPC. Otherwise, I will put the PPC back to sleep. I use CeRunAppAtTime to wake up the PPC. However, it wakes up the PPC fully. I know how to turn off the display, but I don't know how to turn off others like audio. And BthSetMode does not work properly for my device. Thanks for your help. Kim
Anonymous
July 11, 2007
Kim, you want Unattended Mode. At the start of your application do: PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE); And when you're done, do: PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE); This is how ActiveSync does it's "wake up, sync, and go back to sleep without the user knowing it" trick. It will allow you to go straight to Unattended mode without turning on the screen. However, your app will need to stop doing whatever it's currently doing to turn the screen on (CeRunAppAtTime alone doesn't turn the screen on). Note that the user timeout is still in effect while in Unattended. So, if you need to run for any significant amount of time, you still need to call SystemIdleTimerReset. Mike
Anonymous
August 28, 2007
Mike, Great series of Power articles. They have really helped me out! I have a problem with PPN_UNATTENDEDMODE and SystemIdleTimerReset(): I have a thread that periodically makes wininet calls to fetch data from a URL. The fetch cycle takes about one second to complete. My thread does the following: PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE); SystemIdleTimerReset() fetch the data... PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE); This all works fine as long as the data is fetched at a rate of once a minute, or more. Many of my users, however, need the data fetched every 30 seconds while their devices are ON, but at 30 second between fetch cycles the above causes their devices to never suspend. If I remove SystemIdleTimerReset(), the device could (and does) suspend in the middle of the fetch cycle, which cause the connection to crash following the resume. Then we have to deal with messy time-outs and re-connections. I can solve this mess if I had access to the user idle timer. Then I would simply skip the fetch if I see that the device is about to suspend soon. Any and all advise will be highly appreciated! Thanks! Mike Lewis
Anonymous
August 29, 2007
Mike, you've hit one of the worst aspects of the PocketPC power model. There's no good way to solve your problem. Unattended protects your app from the user hitting the power button. If the system is on, though, you're right that any sort of frequent call SystemIdleTimerReset will keep it from suspending. I'd expect both the 1 minute and the 30 second calls to keep the system awake (the default user timeout is 3 minutes). Unfortunately, I don't know of any way for you to get access to the user timer (other than to reset it). If your users press the power button, things will work correctly (you'll suspend as soon as you leave unattended, even though you reset the idle timer). But your app is going to make it hard for their device to time out on its own. Mike
Anonymous
September 04, 2007
Thanks Mike for you response. I'm not very happy to run into "one of the worst aspects of the PocketPC power model". At the very least give us access to the user idle timer... hint, hint... How about working around this problem by tracking the backlight off timer. I assume we can figure out when the backlight goes off (say using a timer to poll GetSystemPowerState) and mark that time. Now if we can get the backlight off setting from the registry, we can calculate approximately when the device will suspend. Knowing approximately when the device will suspend, we can skip our refresh cycle if we're within a few seconds of suspending. Will this approach work? Two questions:

For WM5/WM6, can I detect when the backlight goes off with GetSystemPowerState? If so, how?
What is the registry key for the backlight timeout? Thanks again, Mike

Anonymous
October 12, 2007
The comment has been removed
Anonymous
October 15, 2007
Larry, the only solution I've ever found for the "it turns on in my pocket and changes things as the screen gets rubbed" is to activate the keylock. Of course, that means you need to unlock it every time you turn it on. There is no event log that explains why its turning on. On a previous Sprint device, that happened whenever you moved from an area of no signal strength back to an area where you could get a connection. The OEM did this on purpose for reasons I disagreed with, but I was unable to convince them it was the wrong decision. I'm not sure if they made the same choice on this new device as well. Mike
Anonymous
November 18, 2007
Hi, Is there a way to programmatically power off my PocketPC? I mean i want to completlety power off my PPC (in order to really save my battery for some days). Previously, i had a HTC TyTN that provided me this functionnality by pressing 2 seconds the power button. Can i do this by API on other PPC? Thanks for your response. Fabien
Anonymous
November 20, 2007
Unfortunately, no there's not. PocketPC's don't have an official mechanism for completely powering off. Some OEMs have provided their own mechanisms, but it has always been OEM specific. Smartphones, on the other hand, do have a full power off option and a programattic way to do it. For a smartphone, you call ExitWindowsEx with the EWX_POWEROFF flag set.
Anonymous
November 21, 2007
I have to develop simple use case by which i can have my Windows Mobile functionality working while display is off.e.g.Running of Songs on Windows Media Player while the Display is off.How i can get its value from regitry.What is the value for say DisplayOn DisplyOff Salil
Anonymous
November 21, 2007
I have to develop simple use case by which i can have my Windows Mobile functionality working while display is off.e.g.Running of Songs on Windows Media Player while the Display is off.How i can get its value from regitry.What is the value for say DisplayOn DisplyOff Salil
Anonymous
November 27, 2007
Salil, which of these questions are you asking?

How do I write an app that is notified when the screen turns off?
How do I write an app that keeps running whether the screen is on or off?
How do I write an app that turns the screen off and keeps running?
How do I write an application that keeps the screen from turning off? Thanks, Mike

Anonymous
November 29, 2007
Mike, Thanks for your blogs. All of the info you've provided in these "Power" articles is great and very helpful. I do have one question about something that seems to be incorrect. In one of your comments you said "you'll suspend as soon as you leave unattended". Are you sure? From what I have seen this is not the case. What happens seems to be that the system goes into suspend at some later time (possibly the time configured as the idle time). I believe what I'm seeing is correct and it would be designed this way, because suspending the system immediately would cause other inherent problems, which I can explain if needed. Anyway, please let me know if what I'm seeing is really how it's supposed to work (I think it is), or if it SHOULD really be suspending as soon as unattended is left, as you indicated. Thanks, Andy
Anonymous
November 29, 2007
When the system wakes up, it is guaranteed to run for the length of the Resuming timeout (15 seconds unless the OEM changed it). So, if you wake up, go into the Unattended, and leave in less than 15 seconds, you're right that the system won't suspend immediately (it'll wait until the 15 seconds complete). On the other hand, if the system has been on longer than the resuming timeout, then it will suspend immediately when you leave unattended. Is that what you're seeing? Mike
Anonymous
November 29, 2007
This resuming timeout may be what I'm seeing. I'll have to look at it a little closer to be sure. If this is the case, I'd like to ask about the use of unattended mode. Please look at the following description of a background thread that needs to wake up to do something every once in a while and tell me if this seems like normal use of unattended mode. Thread { Turn on unattended mode and start some thread to reset idle timer every 30 seconds ... while (true) { Stop the thread that is resetting idle timer and turn off unattended mode Wait for some event (keyboard, RTC, radio) that can cause the system to wake up Turn on unattended mode and start some thread to reset idle timer every 30 seconds ... do processing ... } ... Stop the thread that is resetting idle timer and turn off unattended mode } Is this a normal use of unattended mode? Thanks, Andy
Anonymous
November 30, 2007
The comment has been removed
Anonymous
November 30, 2007
Mike Thanks again for your help and the background information on the resuming timeout. That makes perfect sense. Yes, the wait is a "wait for some event" and not a busy loop. Given the thread example above, and the fact that the device can (and will) suspend as soon as unattended mode is released, there seems to be a potential problem with the use of unattended mode. As soon as the thread turns off unattended mode, the device can suspend BEFORE the call to wait for the event that can pull it back out of suspended mode. This would mean that the system is suspended indefinitely until something else pulls it out of suspend, as the thread did not reach the place where it would be waiting for it's event. Is there something that prevents this from occurring? Thanks, Andy
Anonymous
January 13, 2008
Hi Mike, As with many others on this thread, I am frustrated by my WM6 phone that is frequently activated due to inadvertent 'touches' of the screen that occur subsequent to the screen waking up due to a calendar reminder. There should be an option under Power Options, Sounds and Notifications:Reminders, or Calendar that would provide an option to not force the screen to activate for the meeting reminder. If you know of a work-around or have an application that would disable wake up of onscreen meeting reminders and calendar events, I would be most interested. Thanks!
Anonymous
January 13, 2008
Hi Mike, yup very good article, and am also impressed at the responses that have been provided. Below is a comment from your blog I would like to discuss. "There was a time when the PocketPC turned on at midnight and shined its backlight all over your bedroom, thus waking you up with him. Now he's smart enough to not turn the backlight on for his midnight excursions." At midnight my device wakes up and the backlight comes on with my WM6 device. I have been told that under Programs > System Configuration I can disable the "Wakeup Enabled" option to prevent this from occurring, but was wondering if you knew of a way that I could achieve this programatically - Ie registry key or API function - so that I can avoid doing this manually on 90 of my clients devices! Much Appcreciated Jeremy
Anonymous
January 25, 2008
Indeed power to the people.. It seams all devices wm2003 and wm2005 have wakeup problems with alarms / clocks / reminders Now without having to hardboot my PDA (then will loose some registred car-driving software) Has it ever been solved this iseu Or are thos problems simply ignored. (it's hard to ignore dough, just check google how many problems there are out there in the "real" world, in this subject) I gues al such events are eventualy somewhere stored in a DB where to clear them all
Anonymous
January 29, 2008
Hi Mike, Excellent thread here. Question (WM5): I have an application that needs to check on some RIL event every 3 or 10 seconds (implemented through timer control). I'd like to keep the application running all the time, though I don;t care the screen shall turn off. When some criteria is met, the application shall turn the backlight ON. My question- In such case where the timers are pretty short (3/10 seconds) would you still suggest entering the UNATTENDED mode make sense? Or is it better to leave the Power ON all the time (with force) and just turn off the screen? How would you approach those requirements?
Anonymous
January 30, 2008
Mike, After going (succesfully) to UNATTENDED mode, I am applying the next two lines in the code. However, the backlight does not come ON and stay dimmed. What am I missing here? (I tried to turn the backlight ON also without going out of the UNATTENDED mode, but with no good). PowerPolicyNotify((int)PPN_Message.PPN_UNATTENDEDMODE, 0); DevicePowerNotify("BKL1:", CEDEVICE_POWER_STATE.D0, POWER_NAME); Thanks
Anonymous
February 26, 2008
The comment has been removed
Anonymous
April 18, 2008
Hello, i think that you can helpe me. My device is a Ubiquio 401. This thevice have a bug that when is in suspend mode( turn power button off), it have GSM issues(phone stay off). How to solution it??? arovaris@hotmail.com
Anonymous
May 11, 2008
Mike seems to have left this discussion after I pointed out a bug with the use of unattended mode in late November. Sorry for ruining it for everyone else. Andy
Anonymous
July 22, 2008
Over the years, I’ve delivered several “Top 10” sessions and called them different things. Top Snafus,
Anonymous
August 22, 2008
On a device running Windows Mobile 5 Professional I ran a simple program that sent the key press messages for the power button a few times with delays between the messages. Upon running it I see the device turn on and off every few seconds until the program completes. This suggest that my Windows Mobile 5 phone is using an Always On model. Can you confirm this? for(int i=0;i<4;++i) { keybd_event(VK_OFF,0,KEYEVENTF_SILENT,0); keybd_event(VK_OFF,0,KEYEVENTF_SILENT|KEYEVENTF_KEYUP,0); Sleep(5000); }
Anonymous
September 04, 2008
Joel,i got the same result.after Sleep(5000) timeout,the ppc will auto resuming from suspend.i have no way to keep ppc always suspending while in Sleep API.
Anonymous
May 06, 2009
hello to everybody, I have this issue that i'm sure is related to the power module: Hi, I have a problem with the suspend wake-up procedure. I'm using the sam9263 with wince 6.0R2. I'm using a key button to wake-up the system. I put in suspend mode the system using the menu start->suspend,

if I wake-up the system within about 20-30 seconds everything works fine
if I wake-up the system after 30 seconds the system hangs: KeyPadPowerOff customclass KeyPadPowerOff resetting RTT to delay rollover BSPPowerOff +SOCSaveAndDisableAllIntrBeforeSuspend() SOCPioSaveAndDisableAllIntrBeforeSuspend() +SOCPioControllerIntrEnable() OALPowerWakeSource enable 17 SUSPEND CPU +SOCRestoreAllIntrAfterSuspend() +SOCPioRestoreAllIntrAfterSuspend() BSPPowerOn -----system hangs ----- any ideas?

Anonymous
May 06, 2009
hello to everybody, I have this issue that i'm sure is related to the power module: Hi, I have a problem with the suspend wake-up procedure. I'm using the sam9263 with wince 6.0R2. I'm using a key button to wake-up the system. I put in suspend mode the system using the menu start->suspend,

if I wake-up the system within about 20-30 seconds everything works fine
if I wake-up the system after 30 seconds the system hangs: KeyPadPowerOff customclass KeyPadPowerOff resetting RTT to delay rollover BSPPowerOff +SOCSaveAndDisableAllIntrBeforeSuspend() SOCPioSaveAndDisableAllIntrBeforeSuspend() +SOCPioControllerIntrEnable() OALPowerWakeSource enable 17 SUSPEND CPU +SOCRestoreAllIntrAfterSuspend() +SOCPioRestoreAllIntrAfterSuspend() BSPPowerOn -----system hangs ----- any ideas?

Partager via

Power to the People

Comments

Ressources supplémentaires