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
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 wrote:
> > On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller"
> >
> > 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://ww
Battery graphs - was Re: Crowdfunding an Ubuntu smartphone
On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown wrote:
> On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller"
> 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
<>
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04-N900 vel. Neo900
Am 26.08.2013 um 14:35 schrieb Sebastian Krzyszkowiak: > Hello! > > Short introduction, as I was rather inactive in this community > recently: I'm dos, long time Openmoko supporter, owner of GTA02 and > (now broken) Nokia N900. Few years ago I was quite an active developer > of FSO (opimd) and SHR. Few days ago I've created website draft for > GTA04. > > As we all know, GTA04 project has few non-technical problems. Poor > demand is one of them, poor availability of parts is the second one. > Those two problems together are pretty much show stoppers, cause if we > fix one, the second one becomes harder. > > But Joerg Reisenweber came up with brilliant idea of adapting GTA04 > board into N900 case. Why? > - second source N900 housings are very cheap and available on eBay in > big quantities -> problem with very small amount of Openmoko cases > solved > - there are still new spare parts floating around on free market > > But using N900 gives us more: > - GTA04 with physical keyboard! > - screen that doesn't appear to be off in full sunlight > - it seems that while some people like Openmoko case (I do), most > rather think "it's nice idea, but I wouldn't show up anywhere with > such a brick" :( N900 case seems to be more commonly accepted by > public ;) > > Wait, there's even more! > - if done right, we can engage Maemo community and increase the demand a lot! > > There are LOTS of broken N900s in possession of Maemo community > members due to problems with faulty USB connector and GSM modem. Many > of them (owners ;)) are waiting for proper N900 successor that never > came (N9 is not, and Nokia is not interested in platform anymore at > all). > > This might be great time to merge efforts from Openmoko/OpenPhoenux > and Maemo communities. Neo900 project can benefit from both of them - > there will be QtMoko/SHR/Replicant on the one side (it's just modified > GTA04, so running all of them should be very easy), and there will be > Maemo, Meego and maybe more porting initiatives on the other side. > Joerg's idea includes full port of Maemo 5 (Fremantle) to allow N900 > users to have drop-in upgrade - just like now GTA04 is for GTA01/02 > owners. I think that can increase interest a lot! > > For now we named it "Neo900" - making nods to both N900 and Openmoko roots :) > > I'm super excited about this idea, and it seems that I'm not the only one: > Look at http://talk.maemo.org/showthread.php?t=91142 > > You can also read logs from #maemo from yesterday and today: > https://mg.pov.lt/maemo-irclog/%23maemo.2013-08-25.log.html > https://mg.pov.lt/maemo-irclog/%23maemo.2013-08-26.log.html > > It seems there is some interest, and that's just on Maemo side :) > > What do you think? Very good idea. If we can use the same basic design both, the GTA04 and the Neo900 could have many common components. And adding the number of chips bought of one type will help to reduce the purchase price of both. So trying to merg this is to the benefit of both. BR, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04-N900 vel. Neo900
Am 26.08.2013 um 16:24 schrieb Tomas Nackaerts: > Hi all! > > I actually think this is a great idea! I always liked the N900 formfactor. > But > is it technically possible? I remember somebody mention that the option modem > is quite big? Yes, but it is the flattest one we could get. And from the photos of the N900 board I have seen they even need more space for the separate modem chips. > And if there will be a redesign the fit the gta04 to the n900 > will it possible to update the specs a bit? faster cpu and stuff like that? Faster CPU: yes - the idea is to use the 1GHz DM3730 which is 25-30% faster (at least at peak performance - if clock is reduced to 200MHz it is also slow). > But to be honest, i will probably not buy this device if it has the same > problems the current gta04 has. (power usage and modem enumeration) Well, we can't say if it will have the same problems - and even if the problems if the GTA04 are really problems or just lack of a solution. And, I must warn a little - a Neo900 design may have other problems we will only see if it has been built and tested by hundredts of users. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
