Battery graphs - was Re: Crowdfunding an Ubuntu smartphone

Wed Aug 28 00:44:47 CEST 2013

On Wed 28 August 2013 00:29:18 NeilBrown wrote:
> 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

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/ (German)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openmoko.org/pipermail/community/attachments/20130828/7d969577/attachment.sig>