Two more ways to save battery (if solutions can be found)

[sfaure03]

Only if those programs == too stupid to go to sleep.

[mswlogo]

Originally Posted by Yay 4 Juggs

ram actually relates to power...the less available ram the more draw on the processor the more draw on the battery

I don't think it works that way. It's all "AVAILABLE" all the time.

But I did kill OperaPreL.exe by renaming it to OperaPreL.exe_
And RSS Hub.exe RSS Hub.exe_

Apps do use CPU, poke the network etc. which does use power.

I also shutoff the auto dim and set it fairly low brightness and it still looks very good.

I shut direct push off to keep data connection off and just run Active Sync manually.

[mswlogo]

Originally Posted by sfaure03

Only if those programs == too stupid to go to sleep.

Agreed.

Just killing apps and freeing RAM won't save battery unless those apps are doing something like triggering notifcations, polling the network etc.

[snovvman]

I set HKEY_LOCAL_MACHINE\Software\HTC\HTCSensor\GSensor\ DeviceAvailability to "0". Upon soft reset, the value reverted to "1". I made many registry changes, and this is the only one that auto-reverts. Any ideas?

Thanks.

[Certs]

Yeah I also noticed after making the change the settings reverted back to normal upon reset. Not bothering with it anymore for now, the amount of battery saved I doubt is worth the trouble anyway

[snovvman]

For background, read the first post of this thread.

Taking this thread back from hibernation. I found this key:

HKLM/Drivers/BuiltIn/GSensor/Dll=Gsensor.dll, by changing the name of the file to, say, 1Gsensor.dll, the driver won't load and therefore no accelerometer. Not sure if this will save battery, but I will give it a try. I don't use apps that require the sensor, and would actually prefer to manually rotate the screen anyway.

Another item: I came across HKLM/Drivers/BuiltIn/ErrorReporting/PollInterval. While I have error reporting turned off, but I wonder if it still "polls", so I changed the default value from 180000 (presuming 3 minutes) to 1800000 (30 minutes).

Please report here if these help battery life.


BTW, I am still looking for a way to adjust the light sensor's response to a given light condition. Niki's Light does not work. If you know of a way, please post.

[cappy]

Snovvman, I admire your persistence. But if any battery life is saved, it will be minimal and at the margin. Windows is an event driven operating system. Imagine the CPU as a gerbal inside one of those ferris wheels, running and running. Each poll adds a miniscule amount of weight to the ferris wheel, like a snowflake. The heavier the snowfall, the more weight. But you would need a blizzard to really burden the gerbal. The gerbal keeps running at the same pace, using the same amount of energy.

Well behaved programs running in Windows do not measurably increase CPU usage, except when they are actually doing something. Take a look the Task Manager on your computer. There is a function that measures CPU usage. Except for programs that are actually processing something, running programs do not burden the CPU. If you have FcdSoft's Task Manager installed on your device, you can view the CPU usage of the various processes and you will see the same thing. You can be running 10 applications. If they are well behaved and at idle, the CPU usage will hover around 1%.

Running programs consume memory, but they do not burden the CPU or drain the battery, unless they are actually doing something. Start several applications, leave them running, and observe their effect upon the CPU. Unless constantly running a procedure, like calculating PI, they will not add to CPU usage. There are good reasons to close applications when done with, but increasing battery life is not among them, unless the apps are not well behaved and are constantly running a process in the background other than polling.

I think big benefits will be gained by finding those applications that are not well behaved. For example, I have been running Gyrator 2 for a few days. It does not effect CPU usage. However, once during that time it did not release properly and caused CPU usage to remain at 50 x normal. Had I not killed the process, it would have drained my battery completely. I did not write the application and have no desire to debug it. But it has to be watched. In the end, it may not be Gyrator 2 at all, but a bug in the Rotate function within Windows. Also, something either in Windows or an application that is running can cause the Data Connection to stay active. It does not happen often, but when it does the battery will drain completely within a few hours. So until someone finds the cause, the Data Connection has to be watched. Once, I observed that something did not release the CPU, when the Data Connection was dormant. Again, finding what caused this will save big on the battery. Until then, I watch the CPU usage regularly. It is displayed right below my battery icon in the Status Bar. If it stays above 1% for more than a few seconds, I know that there is a problem.

Keep up the good work Snovvman.

[snovvman]

Thanks cappy. I don't disagree. I was hoping that, by not loading the driver, the sensor itself would actually not be "activated" or powered up. Sort of like keeping WiFi off, if the sensor can be kept powerered off, I'd imagine there would be some savings. Although the polling "event" only blips the CPU a small amount, the sensor device would be draining power all the time (since, I assume, it is always "on" in order to report the change in state?).

Thanks again for taking the time to write. You made very good points.

[cappy]

Originally Posted by snovvman

Thanks cappy. I don't disagree. I was hoping that, by not loading the driver, the sensor itself would actually not be "activated" or powered up. Sort of like keeping WiFi off, if the sensor can be kept powerered off, I'd imagine there would be some savings. Although the polling "event" only blips the CPU a small amount, the sensor device would be draining power all the time (since, I assume, it is always "on" in order to report the change in state?).

Thanks again for taking the time to write. You made very good points.

Thank you. I appreciate the methodical way that you approach an issue.

For myself, I have concluded that the Diamond is a big advance over previous Win Mobile devices. This is a super piece of hardware and I will take full advantage of the features that the Diamond offers. If I monitor the device for mis-behaved applications, the device will not drain the battery prematurely. I have the GPS locator turned on, I use the light sensor, and I have added Gyrator 2 to rotate my screens. Weather is set to update automatically. I am not afraid to leave well behaved applications open in the background.

This is why I responded to the subject of your thread. I am convinced that turning off all of the extended Diamond features might prolong battery life by a few percent. Compare this to a 5 minute phone conversation. But if a mis-behaved application can be isolated, it may prolong battery life by 50% to 100%. Compare this to 2.5 to 3 hours of talk/data time.