Battery graphs - was Re: Crowdfunding an Ubuntu smartphone
On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown ne...@suse.de wrote:
On Sat, 24 Aug 2013 15:31:19 +0200 Dr. H. Nikolaus Schaller
h...@goldelico.com wrote:
Hm. That sounds quite different from the situation about 1 year ago when
you did the first releases of QtMoko and I always thought that the
3.7 kernel is working well enough, so that I started to add new features.
Has it become worse since then?
I like drawing graphs. So I did - see attachment.
For the last year or so my GTA04 has been logging the power usage during
suspend for every suspend cycle longer than a few seconds. I do this by
reading the charge_now value from the bq27000 in the battery, comparing the
before and after values, and dividing by the number of seconds.
I currently have my phone configured to wake from suspend every 5 minutes,
check that the modem is still working, and go back to suspend. This has
helped collect quite a lot of values.
To get the graphs I collected all those values, discarded negative numbers
(when the battery was charging) and a few numbers that were clearly
ridiculous (numbers more than 1 amp), and sorted the remainder.
So we get a cumulative frequency graph of different current levels.
The red line ('/tmp/uamp') is for the last couple of days since last reboot.
This is running 3.7 with offmode disabled.
The green line ('tmp/uamp2') is for the last year, running a variety of
different kernels.
Obviously there is a very different number of samples in each. 342 in uamp
10031 in uamp2. So I normalised the X values so the graphs are comparable.
They are much the same shape which suggests the pattern is fairly robust.
The Y axis is microamps.
The green values below 2 (20mA) are with offmode enabled I assume.
The red values are all greater because I have offmode turned off to improve
reliability.
The steps are a bit of a surprise. They are all about 2mA. I don't think
this is an artefact of the precision with which measurements are taken as the
charge value read from the battery has a much higher precision.
I think it must be an actual 2mA difference in (average) current usage.
This could be 2mA more for the whole time, or 4mA more with a 50% duty cycle
etc.
So if we can make off-mode really usable (which possibly means find and fix
some bug in the omap usb code) and if we can find out what is causing these
2mA steps and resolve that, then might might be a little closer to
acceptable power usage.
I might try running for a while with the modem turned off and see what result
I get.
Here are results with modem powered off.
1/ The minimum current is higher!!! without the modem at work. - 28mA rather
than 24mA.
2/ The maximum is much lower. 36mA vs 97mA.
3/ We still see a 2mA step. Most of the values are 30mA or 32mA. A few are
2mA lower, or 2,4,6 mA higher (roughly).
This is very strange. The very rare high values when modem is working are
quite believable. The steps and the high minimum are harder to explain.
Suppose some parallel bi-directional buss ended up in suspend with both ends
driving outputs. Suppose also that if they were driving the same value it
would cause minimal current drain, but if they were driving different values
it would cause 2mA drain on each line that was unbalanced.
Then if the actual output bits on one side were random as we enter suspend,
we would see a range of different multiples of 2mA in current drain.
If this parallel bus were related to the modem, then when the modem wasn't
in use we would see much less variability. But maybe higher average as some
bits might stuck on a bad value.
Now there is a bi-directional bus between the OMAP and the USB PHY. But I
would be very surprised if both (or either) side were driving outputs on
suspend, and I count at least 12 steps in the green line, so it would have to
include the 8 data line and 4 control lines ... which is getting increasingly
unlikely.
I might be able to try holding the PHY in reset during suspend. That should
force all pins to tri-state. However first I think I'll try 15 minute
suspends rather than 5 minute and see if that makes a difference.
Is there another credible explanation for the 2mA steps?
NeilBrown
attachment: current2.png
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Battery graphs - was Re: Crowdfunding an Ubuntu smartphone
On Wed 28 August 2013 00:29:18 NeilBrown wrote:
On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown ne...@suse.de wrote:
On Sat, 24 Aug 2013 15:31:19 +0200 Dr. H. Nikolaus Schaller
h...@goldelico.com wrote:
Hm. That sounds quite different from the situation about 1 year ago
when you did the first releases of QtMoko and I always thought that
the 3.7 kernel is working well enough, so that I started to add new
features.
Has it become worse since then?
I like drawing graphs. So I did - see attachment.
For the last year or so my GTA04 has been logging the power usage during
suspend for every suspend cycle longer than a few seconds. I do this by
reading the charge_now value from the bq27000 in the battery, comparing
the before and after values, and dividing by the number of seconds.
I currently have my phone configured to wake from suspend every 5
minutes, check that the modem is still working, and go back to suspend.
This has helped collect quite a lot of values.
To get the graphs I collected all those values, discarded negative
numbers (when the battery was charging) and a few numbers that were
clearly ridiculous (numbers more than 1 amp), and sorted the remainder.
So we get a cumulative frequency graph of different current levels.
The red line ('/tmp/uamp') is for the last couple of days since last
reboot. This is running 3.7 with offmode disabled.
The green line ('tmp/uamp2') is for the last year, running a variety of
different kernels.
Obviously there is a very different number of samples in each. 342 in
uamp 10031 in uamp2. So I normalised the X values so the graphs are
comparable. They are much the same shape which suggests the pattern is
fairly robust.
The Y axis is microamps.
The green values below 2 (20mA) are with offmode enabled I assume.
The red values are all greater because I have offmode turned off to
improve reliability.
The steps are a bit of a surprise. They are all about 2mA. I don't
think this is an artefact of the precision with which measurements are
taken as the charge value read from the battery has a much higher
precision.
I think it must be an actual 2mA difference in (average) current usage.
This could be 2mA more for the whole time, or 4mA more with a 50% duty
cycle etc.
So if we can make off-mode really usable (which possibly means find and
fix some bug in the omap usb code) and if we can find out what is
causing these 2mA steps and resolve that, then might might be a little
closer to acceptable power usage.
I might try running for a while with the modem turned off and see what
result I get.
Here are results with modem powered off.
1/ The minimum current is higher!!! without the modem at work. - 28mA
rather than 24mA.
2/ The maximum is much lower. 36mA vs 97mA.
3/ We still see a 2mA step. Most of the values are 30mA or 32mA. A few
are 2mA lower, or 2,4,6 mA higher (roughly).
This is very strange. The very rare high values when modem is working are
quite believable. The steps and the high minimum are harder to explain.
Suppose some parallel bi-directional buss ended up in suspend with both
ends driving outputs. Suppose also that if they were driving the same
value it would cause minimal current drain, but if they were driving
different values it would cause 2mA drain on each line that was
unbalanced.
Then if the actual output bits on one side were random as we enter suspend,
we would see a range of different multiples of 2mA in current drain.
If this parallel bus were related to the modem, then when the modem wasn't
in use we would see much less variability. But maybe higher average as
some bits might stuck on a bad value.
Now there is a bi-directional bus between the OMAP and the USB PHY. But I
would be very surprised if both (or either) side were driving outputs on
suspend, and I count at least 12 steps in the green line, so it would have
to include the 8 data line and 4 control lines ... which is getting
increasingly unlikely.
I might be able to try holding the PHY in reset during suspend. That
should force all pins to tri-state. However first I think I'll try 15
minute suspends rather than 5 minute and see if that makes a difference.
Is there another credible explanation for the 2mA steps?
NeilBrown
check ULPI. also check the bus from CPU to musb core. And why would both ends
need to be driven? In my book a 2mA is sth like 1.8V into 1kR termination, for
example
/j
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
(alas the above page got scrapped due to resignation(!!), so here some
supplementary links:)
http://www.georgedillon.com/web/html_email_is_evil.shtml
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml
http://www.gerstbach.at/2004/ascii/
Re: Battery graphs - was Re: Crowdfunding an Ubuntu smartphone
also check video bus. We know on GTA02 the display used iirc 20mA plus for a black screen. Oh and for the 1kR termination, just driving high a dataline that runs to an unpowered chip will eat quite some current via clamp diodes from input pin to 0V-VDD, often even enough to power the chip ;-D Called reverse feeding /j -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
