Notices

At the moment i am discussing this with some people but we have no knowledge to make such a thing so i ask this to you.

We want to have a battery indicator that tells how many minutes, hours the n900 will last. now we only have the battery status wich tells us how many % we have left or how many mAh there still is available.

THis could be done like this:

First we need a program or script that logs the mAh available every 10 seconds the difference in value between an interval indicates how many mAh was used in that amount of time. when you devide the total amount of mAh left by the used amount of mAh you can calculate the time the battery has left.

I wonder if this can somehow be implemented in the desktop command execution widget. that would be awsome!

You can go through this as inspiration and a few thoughts on the pitfalls of such an endeavor.

thanks for sending me to a thread that doesn't answer my question!

with lshal | grep batt you can get all values out of the battery. also there seems to be allready a built in function for remaining battery time. but its sending a false value.

Is there anyone who could give me a reply with valuable information regarding this?

There must be some code that can be put in the desktop command execution widget that will atleast give the remaining time from that grep batt script.

The point is, that getting out a single value that would somehow be "not false", is probably not possible.

Within a single 10 second interval, the device might consume very little or very much power, depending on what is happening right now. So with a short interval you would just get an estimate that alternates between 2 hours and 2 days every 10 seconds (in the most extreme case). With a longer sample interval to average over, the measurement will get a bit less erratic, but will still suffer from the fact that the difference in rate of consumption between idle and in use is like the difference between flushing the toilet and a waterfall.

A more feasible scheme might be one that was in N810. It gave two different estimates, "active time" and "idle time".

Code for what you are requesting should be quite simple to do, for example with a small Python script, but would provide a number that is not much better that throwing a pair of dice, or the current "false" estimate you get with lshal.

Edit: Ok, based on your another comment here, it seems that "active time" estimate is what you're looking for...

strange thing is that a sony psp can do it perfectly. showing the exact remaining time of the battery changing on the flow when starting op stuff or running programs.

Maybe there could be made a more complex calculations that includes more or less averages from earlier values in combination with the CPU load.

When i open up battery graph i can pretty much predict when the battery will be emty.

If you make a kind of prediction with a global full charge avarage but is being influenced by the current average of lets say the last 50 mAh.

You cant tell me its not possible. we just need to find the most accurate calculation.

How do laptops and other portable devices do it?

That's a good point, maybe someone should have a look.

One thing is, that devices that have less aggressive power saving functionality, are easier to predict. Your example, PSP, is a special purpose equipment that likely has no more power saving functionality in it, than turning some components completely on and off. Estimating is then easy, you can have factory calculated values of how much each component eats battery per time unit, and just do the math.

Laptops, on the other hand, are so bad in power saving (with most current OS's) that you can pretty much keep assuming the worst case all the time, and that's your estimate.

Is there a smartphone that can give good battery time remaining estimates?

Possibly try compiling ibam?

I wish you'd read posts rather than skim through them.

I pointed you to the thread because it discusses in detail, the pitfalls of such an endeavor. Should you have read the thread, (and used the search feature) you'd have seen what the problem is with such and interpolation.

You would have also seen that battery drops are quite sudden, and interpolation doesn't work on the timeframe you proposed.

I have little desire to re-write all those posts. Search for references to GSM module battery usage, differences in interpolation techniques.

PSP doesn't have CPU throttling while in use, advanced sleep techniques, a GSM chip, hundreds of daemons, media trackers, schedulers, a touch screen that needs to filter events and deduce gestures, several peripherals to watch, etc.

The PSP basically has 2 operating modes: gaming and not gaming. Not gaming probably doesn't count. While in a game, the average can guess remaining battery pretty nice.

Finally, with no power management, a PSP has an estimated game life of 3-6 hours. This means that you are confined to 3 hours out of a max 6, you already have 50% reduction there. Guess 4.5 hours, then adjust. After this, you could check average CPU load, get a drain, and even a 10% error means that you are within 5%. Out of 4 hours, 5% means you get a first estimate within 12 minutes (+/- 6), which is pretty darned good.

Let us look at N900. Standby time well over 48 hours. Loaded-like-nuts battery life: 2 hours, tops. Especially if battery not new or not fully charged. 10% accuracy is a wet dream IMO, but even so, that's 10% out of 46 hours, that's 4.6 hours error when exiting standby.

This doesn't take into account the fact that on an N900, CPU load isn't a good estimate. Wifi radio (on/off, linked) isn't the biggest drain on wifi; access, encryption of traffic and sleep times are.

Laptops have batteries that are different. A typical laptop has a 10.8V, 3500mAh, that's 30 Wh battery. A laptop drains a battery between 2 hours to 4 hours, assuming average user.

First, we see the PSP issue immediately. A relatively idle laptop drains battery in 4 hours, while a relatively loaded one in 2. So it's a lot easier to get an estimate. Guess 3 hours and adjust +/- over time. If it seems like it's hurrying with the percentage, adjust down. You don't have an on-screen counter, so you don't see it jump around.

Secondly, from 30 Wh, that means 15 Wh an hour, or ~1.5A draw on average for load per assembly. This is a lot easier to estimate than what N900 has. We have a 4 Wh battery over 48 hours, that's 83 mA draw (0.083). Precision suffers.

Thirdly, most laptops that have a good guess of battery life have supplementary electronics inside, that do integral math on instant drain. The difference between interpolation from level and integrated instant drain is crucial when you have drain spikes. Notoriously spiky components? GSM.

Also, laptops have multi-cell batteries, and their behavior is quite different when loaded.

Finally, and please, if you skipped the rest of the post(s), read this:

You mistake mV, mA, and mAh in lshal's reports.

The ONLY way to determine the mAh (capacity) left in a battery is to discharge it in a controlled manner. The report is a guess and a courtesy to you. The only thing N900 measure is battery voltage.

You can stop here.

This voltage varies somewhat with battery capacity. When phone is idle and left idle for a while, the capacity left kinda follows voltage, so an estimate is done.

How estimate? Well, look at lshal. It shows 40%. Now set the battery to charge for 5 minutes. Use lshal again. It shows 60-80%. After 15 minutes, the battery indicator in status shows full.

Unplug. After a few minutes, the estimate will plummet back to 43%, or whatever you can push in a battery in 5 minutes.

Furthermore, voltage droops with load, which is even worse, because it gives you a false, less than real, indication of charge.

This voltage is what you get, not capacity, and not drain. (if we had integrated drain we could predict battery failure to the minute). It is unreliable enough that there have been bug reports that battery charge is going up, instead of down, during normal use. An indicator that has 6 steps has been reported as "acting weird". This is the data you have to work with.

I have attached a snap from battery-eye, magnified. Look at the purple line, it is the battery voltage.

The whole image encompasses 3 hours' use (horizontal). Also, the vertical division is 100 mV.

The green line is N900's guess as of what percent is like. Notice the gap.

Also notice the sharp drop when phone is opened, and CPU is on, display, etc. It's even sharper when gaming. Your estimate will either go from 30 hours to 5 minutes in under 10 seconds (rendering it useless) or average over at least a minute or so, in which case the slope is >10% in the last minute, so you'll guess ~7 minutes are left every time the phone rings.

If it were a simple matter, Nokia would have had it since 1990.

I understand that you want it and that it might be of limited use. However, it would be as useful (or less so) than writing down percentage when you start playing, look at the percentage when playing and try to guess.


Edit:
I could have saved a lot of typing if I would have noticed juise-'s post. You are correct.

There's actually a chip in N900 that constantly monitors current going in and out of the battery, maintaining a counter.

However, the parameters in that chip's eeprom are a bit poorly chosen, causing the chip to never (or rarely) reach its calibration threshold, leaving the default programmed 2000mAh as the maximum capacity, to which it resets the counter on full-charge. You could probably listen for the low battery warning that goes out over DBUS though, and adjust the empty threshold yourself.

Search for bq27200. I think the power-kernel has a driver for it.

nice geek words ndi trying to throw so much terms that no one will understand you anymore and hoping that i will say sorry your right, but your obviously are not.

You are right about the prediction on the battery graph, sometimes dropping in a straight line down. following this line would mean a battery die out within a few minutes. but fact is that when you keep using the n900 like this it in fact will die in a few minutes so the prediction is quite good! This does not mean that the battery is indeed emty. when you again fire up the n900 it will show a line up, because the battery will restore part of its power after th fast drain.

This does not mean that monitoring this behaviour cant be used to predict a remaining battery use time. And offcourse it wil flip from one hour to a few minutes. but using 100 % of the CPU power it will consume allot of power and it will die out very soon.

If you guys werent so stuburn and just write the code like i said you would see that it is quite good in predicting the remaining battery time.

You guys are really thinking to hard.

I could make this prediction myself if i knew how to write code for maemo.

You are talking about saving modes and processes and god knows what. The only thing you need to know is the use of current and prediction of mAh in a specific time frame. combined with avarages.

you use allot the battery time is very low. you stop using allot of battery the battery time will rise. whats wrong with it to show ups and downs in the battery time? thats exactly what I want..

When I fire up dosbox and i use it for an hour im sure the battery wil drain very fast. the remaining battery time program will show me this and will predict that the battery will be soon emty. when you stop dosbox. the time will rise extremely but its not far from realistic is it?

Its not that i dont understand what you are saying. when you put the n900 on the charger for 15 minutes it will show that the battery is full and it indeed will drain 5 times as fast until it reaches the real value. in this time the program i mention is not accurate. but HELL!!! the battery indicator isnt also! but after its on its normal value again you can see a pretty good prediction of when the battery will be emty.

One more example and then i stop this discussion because you guys are to geek to see this reality of the simpleness of this program.

Imagine, your n900 is in standby, the remaining battery program has calmed down and ahs a pretty nice prediction of whats going on. You need to make a trip for approx 10 hours. you wont be using your n900 allot but you wanna be sure you will manage through this time without the n900 dieing out. you look at the widget and see that it predicts a 15 hour time. so you know. that when you are not going to use dosbox or any other insane program the n900 will easily get through this trip.

Offcourse you cant charge up you n900 and then let the program say it has 48 hours left and it lets it keep that way. its an on the fly process of the time being usage that calculates a direct prediction of the usage at that moment. so playing a game and it with this drain it will last for 2 hours....

You are really missing my point on this guys! please be more open minded! and atleast give me a chance and try to write a code!

You could make the program even more complex by letting it have different modes like battery saving mode, full load mode and stuff. this way when in battery saving mode it can take earlier avarage data and use these. when in full load it wil give an on the fly prediction of that exact moment of usage.

Think with me guys, this would be something big if we could all contribute to this!