Bug 8163 – Battery charge level reported by HAL increases over time

Bug 8163 - Battery charge level reported by HAL increases over time


Summary:	Battery charge level reported by HAL increases over time

Status:	RESOLVED WONTFIX

Product:	Core
Component:	Kernel
Version:	5.0/(2.2009.51-1)
Platform:	N900 Maemo

Importance:	Unspecified normal (vote)
Target Milestone:	---
Assigned To:	unassigned
QA Contact:	linux-kernel-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-01-17 22:59 UTC by Serge Matveev
Modified:	2010-10-25 23:40 UTC (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Serge Matveev (reporter) 2010-01-17 22:59:55 UTC

SOFTWARE VERSION:
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
After some wifi works I got the charge_level.percentage is 19
After reboot (turn N900 off / on) I suddently got 31. 
After some idle time (10-20 minutes) again 20 and after this I logged the next:

Sun Jan 17 23:17:12 MSK 2010
  battery.charge_level.percentage = 20  (0x14)  (int)
~ $ date && lshal |grep erc
Sun Jan 17 23:25:40 MSK 2010
  battery.charge_level.percentage = 26  (0x1a)  (int)
~ $ date && lshal |grep erc
Sun Jan 17 23:30:18 MSK 2010
  battery.charge_level.percentage = 27  (0x1b)  (int)
~ $ date && lshal |grep erc
Sun Jan 17 23:38:01 MSK 2010
  battery.charge_level.percentage = 28  (0x1c)  (int)
~ $ date && lshal |grep erc
Sun Jan 17 23:49:42 MSK 2010
  battery.charge_level.percentage = 30  (0x1e)  (int)
~ $ date && lshal |grep erc

All this time the N900 was not connected to the charger or usb.

EXPECTED OUTCOME:

ACTUAL OUTCOME:

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

I think, the charde level can't growing up without any charging. I don't
understand, what is shown bu charge level indicator in this case :-(

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.8
(KHTML, like Gecko) Chrome/4.0.295.0 Safari/532.8

Comment 1 Andre Klapper maemo.org

2010-01-18 20:07:01 UTC

Thanks for reporting this.
This could be a duplicate of bug 7636 - can you check please?

Comment 2 Serge Matveev (reporter) 2010-01-18 21:10:41 UTC

(In reply to comment #1)
> Thanks for reporting this.
> This could be a duplicate of bug 7636 - can you check please?

I don't think so. Without knowing of inner organisation of this subsystem I
can't be shure that these effect have the same reason, because 10% for 30
minutes is obviously not 'slightly rise'.

P.S. Apropos, I'm not even shure this is dbus specific bug - I start checking
lshal only after notice these starnge changes by the 'naked eye' on the status
bar indicator. If the this indicator also uses HAL, the discription of this bug
is correct. If not - there is another problem. The lshal was used only as 'log'
or 'proof' of this.

Comment 3 Ndi 2010-02-03 21:49:41 UTC

Could this be due to:

* Reset: percentage is re-calculated

* Temperature: Warming up might increase voltage

Mine sometimes goes up too, after plugging the charger for a short while or
VERY heavy usage for a short while. Heavy usage causes a voltage drop and
percentage falls. Setting it to idle actually makes it increase (averaged over
a few minutes).

I don't think it's a bug in my case, i mean, I never saw it as such. Wish N900
had a temp sensor. (hint, hint)

Comment 4 Jan Knutar 2010-02-07 01:18:04 UTC

On N8x0 the battery counter seems to reset on device reset/reboot too.

On N900, I've observed the charge level increasing for a few minutes after
disconnecting the charger before the device reported battery full.
On N8x0 I have not seen this behaviour.

The N900 behaviour is consistent with a battery gauge system that monitors
voltage to make educated guesses. If N900 has such a battery gauge system, then
it's more or less expected that the reported value is inaccurate after big
"upsets" like charging. 

N8x0 behaves more like it has a colomb counter with slightly buggy software. If
N900 also has a colomb counter based battery gauge system, then the observed
behaviour is difficult to explain.

On both systems, the value reported by lshal|grep battery is only lazily
updated. It helps to bring the battery status icon into view.

Comment 5 Eero Tamminen nokia

2010-02-15 17:48:14 UTC

> I think, the charge level can't growing up without any charging.

It's normal for the charge level to vary a bit when the system load changes
(which affects the device & battery temperature etc).  I don't know how large
the variations can be though.

You could try doing also "cat /proc/loadavg" to see how the charge variance
correlates to the changes in recent device load. (I don't think you can get
accurate temperature values for different components within the device.)

Comment 6 Ndi 2010-02-15 18:01:04 UTC

The app called battery-eye has a log of both voltage and percentage. Dips in
voltage by heavy use are visible via graph. An eye-opener app so to speak,
during high load the mV is dropped significantly, in the 10-percent (if not
more) area. the 10% refers to the active voltage range (3600-4200), not the
whole 4200.

It is not surprising that the estimate gets odd at times. I have times where mV
have been logged as low as 3680, and when load is lifted it gets as high as
3730-3750, no charging. Rebound spikes are worse, in the 200 mV range, from
moderate load, going to very high and then to near-zero. One can clearly see
the percentage estimate going up for a short while.

Also, warning, battery-eye is (was) in -devel.

Comment 7 Andre Klapper maemo.org

2010-10-11 17:04:38 UTC

Serge: Did you try "cat /proc/loadavg"?

I assume this still happens in 10.2010.19-1?

I guess this is a WONTFIX for Maemo5 anyway though...

Comment 8 Andre Klapper maemo.org

2010-10-25 23:40:16 UTC

I have tried to reproduce this in an internal development version of Harmattan
(the software version after Maemo5) but the lshal output is "stable" over the
time so this either does not happen or it's not easily reproducable.
Haven't found an internal ticket about this problem either.

For Maemo5 it is a WONTFIX as the Maemo 5 platform components are considered
stable by Nokia. Only major issues have a chance of being addressed by Nokia.
MeeGo Handset is where the unstable development is taking place. If you are a
developer (not a "normal" end-user) feedback about MeeGo Handset issues is
specially welcome, e.g. via the MeeGo bugtracker at https://bugs.meego.com.
Please note that MeeGo for the Nokia N900 is unstable.