verify charger current and battery temperature reading correctness

[sean_mosko@…]

Shanghai doesn't have much hardware support here. I'm going to assign this to
Taipei.

[Sean Chiang] If you don't have time please assign this bug to another engineer.

[mickey@…]

I observe a couple of problems:
1.) charger current always seems to report 0 here, no matter whether mode is
fast_cccv , pre, or idle.
2.) even if I leave the charger on for very long, apm reports no more than 89%

[laforge@…]

This should be mostly fixed in svn rev. 1518, but it would not hurt to actually
do the measurements and compare the readings given by the pmu driver with what
your lab equiment determines.

[alphaone@…]

The voltage reading seems to be pretty consistent (I only have cheap measuring
hardware), but the output of /sys/bus/i2c/devices/0-0008/chgcur has too much
fluctuation to be correct.
Generally this doesn't seem to represent the charging current in mA.

Here are some values taken over a short period of time (10 sec)
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
533
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
560
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
346
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
746
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
853
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
1093
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
533

Kernel is uImage-2.6-moko8-r0_0_1584_0-fic-gta01.bin from buildhost
root@fic-gta01:~$ uname -a
Linux fic-gta01 2.6.20.4-moko8 #1 PREEMPT Fri Mar 30 22:10:44 UTC 2007 armv4tl
unknown

[mickey@…]

* Bug 287 has been marked as a duplicate of this bug. *

[laforge@…]

the level fluctuation can actually be quite normal, given the amount of
non-constant-current consumers. There are a number of DC/DC converters clocked
at high rate, lots of digital consumers that have very dynamic power
requirements, etc.

The ADC value for charger current reading is an instantaneous single sample
reading. I guess it would need some kind of low-pass filtering to get rid of
the transients.

As for the actual value: I have verified the calculations a number of times.
Somebody with a usb current probe (Werner?) should probablt do measurements to
determine if those readings are correct (and we draw too muhc power), or
incorrect (we have some hardware or software problem)

[elrond+bugzilla.openmoko.org@…]

Model: GTA01Bv03
Kernel: 2.6.21.3-moko10 (I think, r2118)
(if needed, I can test with the latest kernel from buildhost)

for i in seq 200
do

cat chgcur >>/tmp/cur.dat
sleep 1

done

Mean: 1789.915
standard deviation: 169.807
Minimum: 1440.0
Maximum: 2373.0

If these are really mA, we have a problem, at least on Bv03.

If this thing really is kind to my desktop and only gets max 500 mA, I'd guess,
that one has to divide the number from /sys/../chgcur by 5 to get mA.

Is this issue really "minor"?

[oe@…]

I've compared the displayed current intake w/ an actual measurement of the same.

There is no factor, the displayed values are

• all way off
• are bouncing up and down

[alphaone@…]

Has anyone verified the readings yet?
At least the temperature readings are bogus on my device:
12
9
12
12
12
12
12
12
6
6
12

[alphaone@…]

Kernel 2.6.22.1-moko10 on a GTA01bv4

[alex@…]

Patch submitted for #193 can also apply to this one. It allows to read
negative values for chgcur, meaning the drawn current from the battery (if the
measurement is located directly at the battery.)

[anonymous]

Milestone Phase 0 deleted

[andy]

We are no longer working on GTA01, I do not believe anyone will address this issue.