N800 Battery Meter

[Nik1]

Anyone find the battery meter terribly inaccurate? I'm finding that it falls 2 bars after a reboot and rises one when the screen is off for a few minutes. It also maintains full 4 green for very long periods of time then suddenly drops to 1 red. It would be good if it showed a percentage including the number of hours it can run for, like on most Symbian UIQ smartphones.

[zerojay]

It does show how many hours it can run for. Click on the icon.

[gLobster]

But calculated information not true.

[TA-t3]

[Warning: This is a bit long-winded because I'm answering not just you, but also some earlier postings about the battery meter.]

It does show how long it can run (well, when you click on it), or rather, 2 numbers. One is if you just leave it on, but idling, the other if you execute something that needs CPU (e.g. surfing online and constantly paging through the browser).

The load the N800 presents on the battery varies with several orders of magnitude depending on what you do, that's why there are two figures that are so different (e.g. 10 days/6 hours). There could in principle have been any number of figures added ('3 hours if you do this, 6 if that, 14 if something else, 3 days if..'). This is what you get when you mix a highly optimized-for-power-saving CPU with a lithium battery.

The nature of a lithium battery is that voltage drops quickly if the current load goes above a certain level (you should try to watch a Palm T3 w/original battery and wi-fi card.. you could _watch_ it drop, second by second), then it comes back up again a while after the load goes away.

The net result is that it's very difficult for the battery application to come up with an accurate prediction about remaining time. It can look at the current drain of the moment and calculate remaining time from the capacity of the battery and voltage level of the moment (or some slightly different method), but a bit later the current drain may be 20 times higher or lower, and what then about the prediction? So, it gives you two values: The best case, and the worst case. Note that this is much easier to calculate on a laptop because the power saving modes are not at all as dramatic as on the N800, and even easier on a phone because most of them can be in just 2 modes only: Not using the radio (i.e. not calling), and using the radio (calling). Low drain, high drain (some ARM-based smartphones with wi-fi and PDA capacity leans more into the complicated direction, obviously).

That been said, I would like to have one or two additions to the meter: In addition to the predicted times it could have battery voltage and a simple percentage (where 100% is when it's at where the charging circuit cuts off, which is probably around 4.10 or 4.20 volts, and some sensible value down there somewhere for 0% (you would _never_ want to go that low though..). My Palm T3 starts to shut off certain applications somewhere below 15-20%, and it goes into sleep mode below that (configurable).

The 4-bar battery meter is a too crude voltage meter. The 3party app. FileZ on my T3 measures decimals to two digits. It's possible that this can be done on the N800 too, although it's not directly readable -- I dimly remember a discussion on the developer's list about a system value which just gives you a number, and someone would have to figure out how to convert that to volts.
With a specific voltage value you would eventually learn how to predict the remaining usage time based on your own usage patterns and experience. The 4-bar meter is too crude (not the same as inaccurate, which I first wrote here) for this.

[Nik1]

Thanks for your post Ta- t3. Yes, I think crude is a better way to put it, but I guess I cant complain as the n800 is the only device I have that uses radio constantly. I would still prefer a % rather than 4 bar system.

[murphy]

Thanks TA-t3 for these explanations.
I'm also a T3 owner and I wonder if it is possible (like a 3rd part app on the T3) to change the N800 minimum value where it automatically shut down.
Maybe we could gain 10-20% of autonomy ? Or maybe it shuts down when there is really not enough power ?
Anyway a % bar could be great.

[disq]

well sony has this technology called InfoLithium. so it's possible to implement.

[Texrat]

The meter can be inaccurate, especially when it gets down to 2 bars. As I've posted before, I've seen my N800 drop from 2 green bars to 1 red one in a matter of minutes... after taking many hours to go from 4 green to 2. Maybe it's inverse logarithmic? (only part kidding)

[TA-t3]

The non-linearity is (at least) partly caused by how lithium batteries work. There's a lot of capacity stuffed up there in the near-100% area..

[kb0sei]

I'd personally like a power meter that shows me the max voltage and current voltage. The time does me no good.

One thing I've noticed about my N800, which I've had 2 weeks now, is that sometimes I'll turn the unit off and put it on the charger, and when the battery is full I take it off the charger but it won't turn on.

This morning I had to pull out the battery, replace it and put it back on the charger before it would come on. 10 minutes later the battery was full again, and it's been ok since.

[dblank]

I'd personally like a power meter that shows me the max voltage and current voltage. The time does me no good.


Same here.. does anyone know how to get at this information??

It'd be neat if there was a way to get the current consumption as well, without jamming an ammeter between battery and device.

[johnkzin]

I just want to know % full. A time estimate is _nice_, but not necessary. A percentage full is necessary.

The other thing I don't like: when it's charging, it only tells you "charging". It should also tell you the % full here, as well.

[KotCzarny]

i have made a bunch of scripts to visualize misc retu-adc data, you're welcome to try: http://mrrau.dyndns.org:23280/n800/kcbatt/

kcbatt is my attempt at cmd-line battery reporter
gather_data/ contains scripts to log/plot

ps1. battery reporting algo is v0.1, so any feedback will be nice :)
ps2. it needs access to /dev/retu so you will need to run it as root or give default user access to that device
ps3. contact me on irc: #maemo on freenode
ps4. should work on 770 and 810 too

[qwerty12]

@KotCZarny

Very nice :), thanks :)

Btw, are you on #maemo with that name? Thanks for the copy help on there too.

eek, copy not cp. as was pointed out on irc. I have a lot to learn about the internet abbreviations...

[instigator]

I use battery-status. It OS2008 compatible and gives you % full.

It is found in Andrey's Maemo Repository or here : http://nitapps.com/

[KotCzarny]

from 'battery-status' page:
"Note: Because battery-status relies on DBus signaling, running it has the unfortunate side effect of activating the battery applet. I will try to find a workaround for this."

my tool bangs on raw metal (/dev/retu) and gives battery voltage as one of digits so you can finetune it for yourself. every % number is only an estimation, be it nokia's applet or battery-status.
and for compatibility you need only /dev/retu (it's not hildon app, it's meant to be run in scripts)

[PinCushionQueen]

Sorry to be so dumb - but I can't get kcbatt to work on my N810... What exactly do you need to do to install this? I copied kcbatt.bin to my /usr/bin/ directory and then in xterm ran # sudo gainroot -> followed by # kcbatt I keep getting permissions errors. What am I doing wrong? Thanks!

[qwerty12]

@PinCushionQueen

type as root, one time only:
chmod +x /usr/bin/kcbatt

:)

kcbatt works nicely on my n800.

[cyberboy]

Many Nokia Mobile Phones are so，Not just for N800.

[PinCushionQueen]

Thanks Qwerty12! That did the trick...

I must say that I quite a bit surprised at the difference in "estimations" of percent battery life left on my N810 between the 2 applications (battery-status vs. kcBatt) kcBatt reads consistanly ~20% lower than battery-status. Heck kcBatt gave me a level of 86% immediately after unplugging my NIT from the charger. Does this mean something is wrong with my battery? my charging connector? or the kcBatt algorithm?

I'm not sure what to trust. Isn't it bad to run Li ion batteries down too low on a regular basis?

[qwerty12]

I see what you mean. I think kcbatt algo needs updating?

Nokia-N800-51-3:~# kcbatt
retu-adc #8: 385 batt: 19% [= ]
battery LOW, recharge suggested
Nokia-N800-51-3:~# battery-status
[Mar 18 19:31] 8.4%
Nokia-N800-51-3:~#


I would place my bets on kcbatt being incorrect :( because my n800 runs out of batt quickly (due to my habit of using 44hz for mmc & disabled power freq scaling).

Edit look at this:
Nokia-N800-51-3:~# kcbatt
retu-adc #8: 334 batt: -2% [ ]
battery LOW, recharge suggested
Nokia-N800-51-3:~# battery-status
[Mar 18 19:40] 7.6%
Nokia-N800-51-3:~#


-2%?

[KotCzarny]

reason for kcbatt was to make a util to show retu-adc value (percentage was added as a quick and dirty estimation) have you looked at my plots? (yellow is battery, pink is strictly related to charging status) http://mrrau.dyndns.org:23280/n800/kcbatt/batt2gp.png
i could have made it to show fixed 100% above certain value, and fixed 0% below other, but i wanted to have util that can show me how really that value fluctuates over time (with and without load). i'm still doing battery rundown tests, that's why no updates to algo..
last 2 plots are without wifi and with locked screen/keys, observe how quickly #8 drops under load and after getting back to idle it goes up a little (on 16/03 i made a skype call that lasted ~1h), another observation is ending part of the curve on 7/03, i have chosen 340 as a 0% in a rough guess and 570 as 100% (during charging it goes over 600, but drops quickly to ~570), and 400 is ~20% (that's when i print 'recharge suggested') i can make an update version with max set to 560 and min to 400, but what i would really like is a log of the battery rundown from anyone else (to see how batteries of different ages compare). and remember, every % is just an estimation

[KotCzarny]

i have made a little update to kcbatt, comments are welcome (changed min/max to 390/560, added params -be,-bf to set them on cmd line) please test and report what values work best for you (here or on irc)

[KotCzarny]

yet another update (v0.2.3), this one brings oversampling and timing estimate (algo is still linear and very conservative :), v0.2.4 looping mode (-l) for continuous operation

[Sky_mac]

My battery meter icon no longer shows the up and down movement indicating it's charging. Then after awhile it (the icon) disappears from the task bar altogether. However, it still seems to be charging. When I click on the icon (while it's still showing) the text says "charging". And when the N800 is powered off all indications of charging are as normal.

Anyone else had this problem?

[sondjata]

It happened to me for a while some time ago. After a few restarts it started working as expected.

[Starcruiser1229]

Hmm, sounds interesting. I too find the battery meter to be more or less crazy. One thing I have found is that, for me, the number of days remaining for standby * 10 is generally about the same as the battery life estimated by battery-status (ie 9 days = 90%), which I use for quick and dirty estimations.


I would love a desktop applet that uses the script above or battery-status for more reliable numbers.

Also (and I am sorry for the side-track), but has anyone played around with the different cpu scalers? I was wondering if there was any real effect on battery life by changing to a more agressive scaler? I figured out how to switch them (I wrote a quick script), but their effects on the battery use are beyond my ability to determine....

Patrick

[qwerty12]

My battery meter icon no longer shows the up and down movement indicating it's charging. Then after awhile it (the icon) disappears from the task bar altogether. However, it still seems to be charging. When I click on the icon (while it's still showing) the text says "charging". And when the N800 is powered off all indications of charging are as normal.

Anyone else had this problem?

Refresh the gtk icon cache.

[Benson]

Also (and I am sorry for the side-track), but has anyone played around with the different cpu scalers? I was wondering if there was any real effect on battery life by changing to a more agressive scaler? I figured out how to switch them (I wrote a quick script), but their effects on the battery use are beyond my ability to determine....

Patrick
By more aggressive, you mean chopping frequency quicker at idle? We use ondemand by default, which is the best for that. There's also conservative, which is slower in slacking off, but doesn't seem to really help performance. Performance and powersave, of course, just peg it at maximum or minimum; and null sets it to 400000, even when the maximum drops to 333000 in order to boost the DSP.

[Sky_mac]

How do I go about refreshing the gtk icon cache?

[Quartz]

FWIW, I've been noticing that my battery meter and life is also weird (in fact I found this thread because I was about to post my own about it)

when my n800 is fully charged, I get something to the effect of "6 days when idle" in the meter, yet if I immediately soft-off it, the battery only lasts about 50 hours before it starts chirping (I've tested this several times). mind you, this is about as idle as it can get- I have no windows open and nothing running with the wifi off and screen locked.

is 2 days normal battery life when in soft-off? did installing ssh or some other background service cause me some problems?

also, I notice that if I use mozilla for a little while and have it eat up some memory, then put my n800 into soft-off *without* quitting, my battery's DEAD within 6 hours. this has happened to me a couple times now when browsing the web in bed before I go to sleep- I wake up in the morning and it's shut itself off. anyone know what's up with that? it doesn't seem to be related to the page having a looping flash animation or anything obvious like that.

[lardman]

Mozilla seems to stop dyntick from taking effect, probably has some timer running depending on what's displayed at the time (e.g. flash adverts, etc.)

[rittf800]

FWIW, I've been noticing that my battery meter and life is also weird (in fact I found this thread because I was about to post my own about it)

when my n800 is fully charged, I get something to the effect of "6 days when idle" in the meter, yet if I immediately soft-off it, the battery only lasts about 50 hours before it starts chirping (I've tested this several times). mind you, this is about as idle as it can get- I have no windows open and nothing running with the wifi off and screen locked.

is 2 days normal battery life when in soft-off? did installing ssh or some other background service cause me some problems?

also, I notice that if I use mozilla for a little while and have it eat up some memory, then put my n800 into soft-off *without* quitting, my battery's DEAD within 6 hours. this has happened to me a couple times now when browsing the web in bed before I go to sleep- I wake up in the morning and it's shut itself off. anyone know what's up with that? it doesn't seem to be related to the page having a looping flash animation or anything obvious like that.

Same thing here, with os2008 on my n800. It was one of the reasons I went back to os2007, I ended up charging it every day twice, in the morning and evening, and sometimes in the car during a commute. It's even worse if you experiment with the hostmode: if you use the commands to switch back to client mode, it randomly turns hostmode back on which can drain the battery in a few hours even with no devices attached.

I will check to see if mozilla on os2007 has the same result

[Den in USA]

As long as I have my spare batttery, it is not critical that I be able to estimate my remaining battery life. Still, my N800 beats any laptop I have ever used.

[jaiotu]

How do I go about refreshing the gtk icon cache?

Run "gtk-update-icon-cache"

I am having the same problem with my battery applet disappearing and not animating during recharge. Updating the icon cache did not help. I ran the gtk-update-icon-cache command as both user and root.

I have rebooted multiple times, and even tried removing the battery and putting it back in. No luck.

I am hoping that it will just "fix itself" after some more reboots or whatever, but until then, it is a mystery to me.

This is a fresh install of OS2008 on a n800. Installed last night and used penguinbait's install to SD, then installed penguinbait's KDE (Zelda edition.)

[Benson]

Actually, it's something like gtk-update-icon-cache -f /usr/share/icons/hicolormore or less. As root.

[jaiotu]

Actually, it's something like gtk-update-icon-cache -f /usr/share/icons/hicolormore or less. As root.

Well... I can certainly more on my Tablet, but I don't have less installed. Is there a repository? :D

Okay, joking aside, thanks! This did the job perfectly. My battery applet is now behaving itself.

[Benson]

Indeed there is; I installed less from some repo, but I don't remember which... :p Glad it worked! (I wasn't sure I remembered that quite right, as it's been so long.)

[solca]

i have made a bunch of scripts to visualize misc retu-adc data, you're welcome to try: http://mrrau.dyndns.org:23280/n800/kcbatt/

kcbatt is my attempt at cmd-line battery reporter
gather_data/ contains scripts to log/plot

ps1. battery reporting algo is v0.1, so any feedback will be nice :)
ps2. it needs access to /dev/retu so you will need to run it as root or give default user access to that device
ps3. contact me on irc: #maemo on freenode
ps4. should work on 770 and 810 too

Hi KotCzarny!

Thx for kcbatt!! I'm using it within NITdroid (http://www.internettablettalk.com/forums/showthread.php?t=25410) with some clever hacks supplanting with a script the content of /sys/class/power that it's needed by the Android to present batt info. But kcbatt raw value diverge a lot when screen on/off, wifi on/off, etc.

Can you help me get a better behavior?
And do you know where to obtain if AC is plugged or not?

[BrentDC]

Hey solca. I was working on a program to read retu data and estimate battery level (this was in Maemo/Hildon, not Android). It used a battery level history file to predict how much % was left. It was extremely volitile for the reasons you mention. I figured that some "smoothing" was needed to make it more accurate, but the only way to do this is to know the current battery draw, but was unable to retrieve this data from the system (it is possible though, because an application called "Field Test Display"* can read it).

BTW, you can catch charging/discharging events via dbus, though I couldn't quite figure out how to do it.

*=With the bme plugin.

[solca]

Hey solca. I was working on a program to read retu data and estimate battery level (this was in Maemo/Hildon, not Android). It used a battery level history file to predict how much % was left. It was extremely volitile for the reasons you mention. I figured that some "smoothing" was needed to make it more accurate, but the only way to do this is to know the current battery draw, but was unable to retrieve this data from the system (it is possible though, because an application called "Field Test Display"* can read it).

BTW, you can catch charging/discharging events via dbus, though I couldn't quite figure out how to do it.

*=With the bme plugin.

Does that "Field Test Display" read it from dbus?

No, I would like to query AC plugs/unplugs events by reading from somewhere (/dev/retu) but no luck so far...

[BrentDC]

I have no idea what it read it from; I could only find a .deb and not the source. I found out who the maintainer was (someone at Nokia), and thought about sending an email, but never did.

Here it is: http://timeless.justdave.net/repository/catalogue.tableteer.nokia.com/updates/diablo/

(you need to install both the ftd* files to get info on the battery).

[Matan]

Hi KotCzarny!
And do you know where to obtain if AC is plugged or not?

You can tell if AC is connected by reading ADC number 3. I believe it shows input voltage level (or something similar). It appears to give three levels:

0 - No power source connected

about 0x100 - power source connected, charging

about 0x170 - power source connected, not charging.

If it is indeed showing input voltage level, then the reading will depend on charger used. A well regulated source will give the same level, whether charging or not.

[solca]

You can tell if AC is connected by reading ADC number 3. I believe it shows input voltage level (or something similar). It appears to give three levels:

0 - No power source connected

about 0x100 - power source connected, charging

about 0x170 - power source connected, not charging.

If it is indeed showing input voltage level, then the reading will depend on charger used. A well regulated source will give the same level, whether charging or not.

Exactly as you describe it! :D

Now I can detect AC plug/unplug and batt full which is a huge improvement for battery metering in NITdroid. Before this I was relying on very imprecise heuristics based on register #8 which is completely erratic (or misunderstood). Thx!

I was wondering if you know what the other registers means?

@Nokia: it's time to release the RETU/TAHVO ASICs documentation! :rolleyes:

[ciroip]

Im testing various way to check the battery status for a python application. Using the dbus make the tablet 'fart' everytime I check the level if the charger is connected. I really like the idea to read directly the os values using kcbatt (and having some alternative values to compare to the usual dbus based programs) but it seem only works if the app is 'root'
Any idea how solve?
https://garage.maemo.org/frs/download.php/5359/sshot_kcbatt.jpg

[BrentDC]

I don't know of any way to read retu as user...

My Python program just used "subprocess.Popen('sudo ./retu-adc', shell=True)" to read it. It doesn't really do anything new...but at least you don't need to actually run the whole program as root (but you need the proper software installed to enable sudo to do that).

[ciroip]

I don't know of any way to read retu as user...

My Python program just used "subprocess.Popen('sudo ./retu-adc', shell=True)" ....
a thousand way to reach the same result :) .
The point is that for that clock the battery check is just an 'extra feature' and if Ill not able to figure out a decent way to read that values Ill probably decide to remove all that part. thank you for the hint anyway, Seem to remeber I tried to read the retu directly from python but probably doing something wrong (Im not a programmer at all :( )

[BrentDC]

Just get yourself Matan's retu-adc program and it is pretty easy to check... BTW, I'm not much of a programmer either :) I just know a little Python and trial and error usually results in the desired effect. :)

[BrentDC]

Ok, I dug up my python code and here it is. I couldn't find my newest version of it, though :confused: I have no idea where it went...


#!/bin/env python

# Copyright (C) 2009, Brent Chiodo

import commands
import time
import dbus, dbus.service

def average(list):
total = 0
count = 0

for each in list:
count = count + 1
total = total + float(each)
return total / count

date_stamp = commands.getoutput('date +"%-m-%-d-%-Y"' + '.csv')
cycle = 0
battery_log = []

commands.getoutput("mkdir pybattery_logs/")

while(cycle < 480):

add_time = commands.getoutput('date +"%l:%M %p"')
battery_level = commands.getoutput('sudo ./check_retu 8 9')
battery_log.append(battery_level)

if len(battery_log) > 120:
del battery_log[0]

logfile = open('pybattery_logs/' + date_stamp, 'a')
logfile.write('"%s","%s"\n' % (add_time, battery_level))
logfile.close()

if len(battery_log) < 11:
battery_average = average(battery_log)

else:
battery_average = average(battery_log[-10:-1])

if ((battery_average - 300) / 200 > 1):
print "Battery: 100%"

else:
print "Battery: %.1f%s" % ((((battery_average - 300) / 200) * 100), '%')

cycle + 1

print battery_log[-1]

time.sleep(60)



check_retu is a hacked version of Matan's retu-adc. It is attached.

This program basically just polls the retu every minute and writes it to a log file. It then uses that data to calculate (albeit completely unrefined) the battery level. Feel free to use this code :)

Edit: The forum messed up th indenting. You'll need to fix it.

[Matan]

If you want to access retu as a user, just run

chmod a+rw /dev/retu

(You need to run this every time you boot).


About using the info from python scripts - you can use ioctls directly from python, there is no need to use retu-adc program or variant.

Something like:

import fcntl
f = open("/dev/retu")
adc8 = fcntl.ioctl(f, 0x6003, 8)

[Matan]

@Nokia: it's time to release the RETU/TAHVO ASICs documentation! :rolleyes:


Extremely unlikely - those chips are used in many Nokia phones, not only in the tablets. Furthermore - those are probably generic GPIO/ADC/RTC/etc. devices. The real question is what is connected to which GPIOs, ADC ports, and how.

[ciroip]

If you want to access retu as a user, just run

chmod a+rw /dev/retu

(You need to run this every time you boot).


About using the info from python scripts - you can use ioctls directly from python, there is no need to use retu-adc program or variant.

Something like:

import fcntl
f = open("/dev/retu")
adc8 = fcntl.ioctl(f, 0x6003, 8)

Ill reserve to 'thankyou' for when (and if) I will understand what you are actually saying :)

[Lord Raiden]

I for one would like to toss my hat into the ring and say that a battery meter with colored text denoting battery remaining would be best. It's "sorta" done that way already in regular Linux, but I'd like to see it that way in the NITS too. IE, it's green text until it hits 25%, yellow until it hits 10%, and red the rest of the way down. Then when you click on the text, it can say "estimated" run time and idle time.

[zanne]

sorry if this can be considered cross-posting (http://talk.maemo.org/showthread.php?p=293378#post293378), but i don't know which is the more appropriate thread for my questions...

bye bye

[zanne]

solution (http://talk.maemo.org/showthread.php?p=293378#post293386) found :-)

but the meter seems to be not very accurate:

Nokia-N810-23-14:/home/user# ./kcbatt -q
98
Nokia-N810-23-14:/home/user# ./kcbatt -q
99
Nokia-N810-23-14:/home/user# ./kcbatt -q
99
Nokia-N810-23-14:/home/user# ./kcbatt -q
98

is it normal?

(btw, for who doesn't know, "-q" option shows the % value of the battery)

tia.

bye bye

[zanne]

after a lot of frustration, i found out that one guy in my department wrote a program that (in the middle of other operations) checks the battery level of the nokia N810 devices; is written in C++ and uses dbus library that asks to hal, so i think that is also valid for N770 and N800.

after a few modifications i'm now able to check correctly the status of the battery! :D

in attached you can find the source code, with the hope that it will be helpful to someone.

bye bye