Battery graphs - was Re: Crowdfunding an Ubuntu smartphone

[NeilBrown]

On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown <neilb at suse.de> wrote:

> On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller"
> <hns at 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 20000 (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: current2.png
Type: image/png
Size: 4412 bytes
Desc: not available
URL: <http://lists.openmoko.org/pipermail/community/attachments/20130828/0df2c653/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.openmoko.org/pipermail/community/attachments/20130828/0df2c653/attachment.sig>