If ur wondering about Battery power in C600

[Guest moosery]

if it does work and your getting results the way it works the guestimated time out is the average of a fast percent (when your using the phone) a slow percent (standby time) the time the last percent was used (current usage) and the average of the 3  divided by 4 times the remaining dipercentage of battery left

in code view its

$timeleft = ($slow + $fast + $current + ($slow+$fast+$current/3))/4 * $batterylevelpercentage

2 days with usage is good (if you think it sucks, you can use my e100 that lasts 8 hours if you dont look at it and then tell me 2 days sucks)

any questions let me know

later

Owen

<{POST_SNAPBACK}>

Owen -

Agree with the fact that 2 days normal usage is good, just a little annoyed that the 600 seems about half as good as the c500 - but nothing good can last forever I guess.

With regs to your battery prog. I cant understand why the formula isnt:

timeremaining = (timerunning/(start%-current%)) * current

where timerunning is time from starting the app

start% is the battery% when starting the app

current% is the battery% right now.

then if you had run the phone for say 10hrs, and gone from 100% to 50%,

timeremaining = (10/50) * 50 gives 10hrs remaining. An accurate percent based on linear degradation of the battery.

or 10hrs dropping 20% from 80% :

timeremaining = (10/(80-60)) * 60) = 30 hrs remaining.

your method would not be consistent as you're not really knowing how many shorts, mediums or longs. For example I might be surfing heavily for 5 mins, then not touch the phone for the next few hours. Then you have a short of 1min, and long of 60min, but only one short, yet many longs. Unless you count the number of shorts, mediums and longs as well as the duration, and ratio them out...which I dont fancy thinking about the maths for!!

Not that I'm trying to challenge your hard work - just a sucker for punishment and spend too much time thinking about things like this, and it's been bugging me 'cos I am sad....

Cheers

Tim

[Guest beersoft]

Tim

you raise a good point.

the old old old version of the app used to do it like that, but there where alsorts of problems with it,

the quick summary of them:

when you charge the phone, you have to reset the start time and percentages, which then skewes the numbers, the crazy powermanagement also doesnt give a steady power usage (mostly seen on the mpx200) which for no apparent reason the power would go up 3% for 10 mins then drop 4%

going with (timerunning/(start%-current%)) * current does give an estimated time from current use, but the fast +slow+average+current/4 does give a better estimate from usage patterns

please excuse the old numbers (this is from the E200 which i used for development)

over 28 days of testing, the times are

slow 2mins

fast 50mins

last was 50mins

average of 26mins

and say a current of 40mins

thats 3% in 2.6 hours and at your current usage 33.6 mins% with a full to flat time of 54hours (not bad for the E200)

33.6 * 97 = 54hours

using the same figures

(156 / 3) * 97 = 84 hours as long as nothing happens

the main problem, is that power usage isn't constant and there isnt a way to get accurate results as there are too many variables to account for (signal strength, backlight/screen timeouts, battery condition, colour of pants worn, is GPRS enabled, you know the type of thing).

there proberbly isn't a right way to work out time remaining just using the api call and some very basic maths, storing every time for every % and using that as a guide would possibly give truer numbers, but then when you have spent 7 hours getting lots of slow times, then get called into the server room and have to make 2 hours of calls at 2% signal kinda screws up the numbers.

if enough people ask, and supply me with programming juice (thats beer) i might fix the bug in the logging code so you can get a hard copy if how the battery behaves ( i think there is a version 1.5ish somewhere on modaco that logs, but it does reboot the phone every 9 days/leak memory like a big leaky thing) as its not enabled in the current release

later

Owen

[Guest moosery]

Owen

Thanks for that - I appreciate the explanation and I see your point.

I am itching to see an application that's accurate, and I'm a developer of sorts, but never done anything on windows mobile, wouldnt know where to start.

I'm thinking I could figure out an "equation" that would be 'hot poop'. The only thing you'd need is a counter for each of slow, medium and fast (how many times each has occurred). I'm thinking just three variables, short_times, medium_times, long_times.

Are you in any way interested in a slight modification if I can solve it? I dont want to hurt my head thinking of the logic if I cant use it. I haven't recovered from last time I used it!

Cheers

Tim

[Guest kam_]

I think another thing to consider is the extra pixels the C600 has. Thats:

220x176 = 38720

verses:

320x240 = 76800

Thats almost 50% more pixels = 50% more transistors which need to be switched and powered.

My personal feeling is that the various processes that are running doing housekeeping tasks and the sometimes nonsensical power saving methods make the biggest difference in normal use.

If you were to make a continuous call on both phones from full charge i'm sure the difference would be alot less pronounced and weighted by the particular GSM module in use.