poor battery life - is suspend broken?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Charge the freerunner fully
2. Note value in /proc/uptime
3. Leave it idle, not charging for 4 hours. The phone should receive no
phone calls or SMSes during the test.
4. Observe the /proc/uptime increase by 3 hours 22 minutes (!) and
   battery at 68% full. Have it slept for 40 minutes only out of the 4
hours it was suspended for??

What is the expected output? What do you see instead?
The /proc/uptime should remain almost the same (minus about 40 seconds for
suspend and several seconds to wake up, connect and read the /proc/uptime)
and battery should hold much more charge.

What version of the product are you using? On what operating system?

 * FreeRunner A6:
 * android-on-freerunner-cupcake-week-2009-44.tar.gz
 * Activated SIM card plugged in
 * WiFi off
 * GPS off
 * 8 GB SanDisk SD card plugged in

 provide any additional information below.

Original issue reported on code.google.com by skliarie@gmail.com on 10 Nov 2009 at 1:18

[GoogleCodeExporter]

I can confirm this issue.
I'm running android-on-freerunner-cupcake-daily-20091103.tar.bz2

Original comment by andreas.chr.osowski on 14 Nov 2009 at 12:30

[GoogleCodeExporter]

This might related to the recamping bug #1024 of the GSM hardware:
http://docs.openmoko.org/trac/ticket/1024

but that does not explain uptime increase.

Original comment by skliarie@gmail.com on 25 Nov 2009 at 6:24

[GoogleCodeExporter]

It might if if wakes up every time it re-camps and then has to time out before 
it 
sleeps again. Are you still experiencing this with a recent (after 20-Nov) 
build?

Original comment by scarhill on 25 Nov 2009 at 2:57

[GoogleCodeExporter]

No, I haven't seen any commit in the daily builds for last week or two.

Original comment by skliarie@gmail.com on 25 Nov 2009 at 3:15

[GoogleCodeExporter]

I pushed a change on 12-Nov which should restore the previous behavior wrt 
#1024. 
Please retest with a recent daily or weekly build to see if it resolves your 
issue

Original comment by scarhill on 25 Nov 2009 at 5:38

• Changed state: FeedbackPending

[GoogleCodeExporter]

I am using week 48 and have symptoms of suspend not working. The moko seems to 
doze
in and off suspend. I can hear a click from the speakers every few minutes and 
when I
wake it up, the clock is only 3 mins behind.

Original comment by roberto....@gmail.com on 30 Nov 2009 at 4:16

[GoogleCodeExporter]

Roberto, can you do the test like one I have done at the description and post 
the
results? This is to test whether the change of scarhill improved things.

Original comment by skliarie@gmail.com on 30 Nov 2009 at 4:24

[GoogleCodeExporter]

Ok, I'll do it friday. Just one question, shall I read uptime via terminal or 
usb
connection is fine?

Original comment by roberto....@gmail.com on 1 Dec 2009 at 3:24

[GoogleCodeExporter]

Via terminal (adb shell cat /proc/uptime) should be ok.
Just remember to disconnect the phone from USB after that.

Original comment by skliarie@gmail.com on 1 Dec 2009 at 3:28

[GoogleCodeExporter]

This is very strange...

At the begninning I didn't had this issue; then I installed some apks and I 
noticed 
this issue to happen again... However I don't really think this issue related 
to 
anything from third party. But today I noticed a strange behavior in fact, I 
navigated some time at the university using the wifi and disabling the 
suspension at 
all; then, before of going home, I turned on the suspension and everything 
worked 
well (the phone was suspended correctly, I couldn't hear the "resume 'clicks'" 
nor 
turning on the LCD with many AUX pressures [that works when resuming fails]; I 
also 
was able to turn wakeup and suspend it again)... Then I come home, some hours 
later, 
and I resumed the phone: since then It never goes to sleep anymore :|.

To get the point, however, I think that we should look at the rtc 
implementation, in 
fact these resumes are all caused by the rtc interrupt timer as you can see 
from:

# cat /sys/class/i2c-adapter/i2c-0/0-0073/resume_reason
4000000000

# cat /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-resume.0/resume_reason
  EINT00_ACCEL1
  EINT01_GSM
  EINT02_BLUETOOTH
  EINT03_DEBUGBRD
  EINT04_JACK
  EINT05_WLAN
  EINT06_AUXKEY
  EINT07_HOLDKEY
  EINT08_ACCEL2
* EINT09_PMU
  EINT10_NULL
  EINT11_NULL
  EINT12_GLAMO
  EINT13_NULL
  EINT14_NULL
  EINT15_NULL

So, basically it seems that the phone enables - every second - the rtc timer to 
make 
it send an interrupt to the CPU. This is not acceptable, of course...

Original comment by trevi55 on 3 Dec 2009 at 12:01

[GoogleCodeExporter]

trevi55 is that a kernel bug ? 

Original comment by Black.D....@gmail.com on 3 Dec 2009 at 3:01

[GoogleCodeExporter]

Mh, no I don't think so... I just think that android sets a rtc timer also if 
it is 
not needed (it should set them just for alerts), at every given seconds (it 
seems).
The kernel does what is designed for.

Original comment by trevi55 on 3 Dec 2009 at 3:35

[GoogleCodeExporter]

There are definitely buggy apps out there that keep the Freerunner from 
suspending. I 
have also seen it fail to suspend after making a phone call. I think the RIL 
doesn't 
release a wake lock in all circumstances. I definitely don't see it waking 
every 
minute, and can leave it suspended overnight (8 or 9 hours) while only losing 
~10% on 
battery level.

Original comment by scarhill on 4 Dec 2009 at 2:57

[GoogleCodeExporter]

I reset to the week 48 image. I had it at 90% battery before i went to sleep 8 
hours
later it was on around 83% i think ish. There are probably buggy applications. 
Is it
possible to block these ? (or should we just kill any that are still running 
before
suspending?).

Original comment by Black.D....@gmail.com on 4 Dec 2009 at 3:10

[GoogleCodeExporter]

Actually, thinking back at the pattern of the last days, it occurred to me it 
could
actually be an application. One among navit, mapdroid, ygps and gpsstatus.
I'll first try the test as detailed above after rebooting the moko.

Original comment by roberto....@gmail.com on 4 Dec 2009 at 2:28

[GoogleCodeExporter]

I've no one of these apps, and the issue rests. Plus, as I pointed out before, 
the 
suspension is broken by an alarm, so we have to check who interacts with it.

Myabe some apps could affcet this behavior, but there's a deeper bug.

Original comment by trevi55 on 4 Dec 2009 at 2:45

[GoogleCodeExporter]

A configured mail app will cause problems with suspending.

Just yesterday, I got a mail notification over gprs. I ignored it and attempted 
to
put the phone to sleep with the 2-second power button push. The screen turned 
off
then immediately back on locked. I tried again with the same result. After 
several
tries, i unlocked the phone, opened the email app to clear the notification, and
tried one last time. The phone correctly suspended after that.

Network applications will wake the phone up to check their respective data 
sources,
but should otherwise not affect anything.

The calender and alarm apps should wake the phone up until they enter sleep 
states,
but should not hurt anything else.

I can account for all these wakeups in daily usage, but i still get random 
wakeups at
times.

Maybe it comes from applications attempting to determine location? (which 
doesn't
seem to work for me anyway)

Original comment by rooly4@gmail.com on 8 Dec 2009 at 3:02

[GoogleCodeExporter]

Can we try to bufferize with timestamp the resume_reason and when they happen? 
The
attribute can contains 4k of data so a lot of it. We can try to have 1 hour of 
data
and check how many time the mobile wake up for suspend

Original comment by michaelt...@gmail.com on 27 Dec 2009 at 8:18

[GoogleCodeExporter]

having random wakeups in rc1 0.2.0.

Original comment by b.ruh...@web.de on 3 Feb 2010 at 8:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Me too, with the RC1 0.2.0, I have random wakeups. sorry, no informations at 
the moment 
PS: My phone is #1024 bug Fixed

Original comment by Florent....@gmail.com on 9 Feb 2010 at 1:20

[GoogleCodeExporter]

Me too, i can hear the speaker's click every few minutes. the battery 
discharges at a 
rate of about 4%/h, but my FR is not #1024 bug fixed. i'll update the firmware 
soon and 
post again.

Original comment by dopp...@gmail.com on 2 Mar 2010 at 7:27

[GoogleCodeExporter]

android-on-freerunner-cupcake-0.2.0-RC1.tar.gz: all network services 
GPS,WiFi,GSM are
off (no SIM inside) and no alarms went off during the test.
Result: while sleeping - it is awake for 3239 seconds per hour.

How can I see applications that prevent the phone from sleeping?

Original comment by skliarie@gmail.com on 20 May 2010 at 9:36

[GoogleCodeExporter]

I did the same test after removing the "WiFi toggle" and "GPS toggle" widgets 
and
rebooting and voila: The phone used just 60 seconds of for the hour!

I am now trying to find out which application spoil the battery.

BTW, I don't know whether I have Openmoko http://wiki.openmoko.org/wiki/1024 
bug on
my phone.

Original comment by skliarie@gmail.com on 20 May 2010 at 11:59

[GoogleCodeExporter]

Please, in detail, how you have done this:
> removing the "WiFi toggle" and "GPS toggle" widgets

Original comment by Alexandr...@gmail.com on 20 May 2010 at 3:51

[GoogleCodeExporter]

I saw that these two widgets - "WiFi toggle" and "GPS toggle" use CPU even when 
the
FreeRunner is not in use, so decided to switch them off.

I have not finished my tests yet, but looks like the way to get long-life is to 
not
use WiFi,GPS and GSM after reboot. You should switch on "Airplane mode" and 
reboot
the phone, so it would not attempt to use any of the radios.

I will post my observations once I get better picture.

Original comment by skliarie@gmail.com on 20 May 2010 at 8:35

[GoogleCodeExporter]

With this radio-free configuration after 10 hours of standby time the battery 
was 80%
full. This gives us about 43 hours. On average it spent 17 seconds per hour 
awake
while sleeping.
Tomorrow I will make similar test with GSM enabled, so we can compare results 
with
SHR-based ones from here: http://neil.brown.name/blog/20090224195326

Original comment by skliarie@gmail.com on 23 May 2010 at 4:41

[GoogleCodeExporter]

Using the default email app, I get low battery life and need to reboot often. 
Switching mail apps seems to help this problem. I've switched to maildroid and 
seen 
a significant increase in battery life. I don't have any numbers just yet, will 
post 
soon.

Original comment by rooly4@gmail.com on 23 May 2010 at 10:07

[GoogleCodeExporter]

All-

Reading through your talk here, and it's gr8 stuff.  Low power mode and battery 
drain
is a challenge to all vendors, linux, embedded, and otherwise.  Here's an 
insider's
bit of info though.

I don't feel "uptime" is a valid metric for dealing with the topic you're going
after.  Instead, you should be measuring the current consumption of each 
component on
your board, and figuring out its contribution to your total current 
consumption. 
Specifically, you need to know how much your uP consumes at it's highest 
frequency
rate, it's lowest (e.g. off) and everything in between.  You need to know how 
much
your modem consumes.  And your RF front end, and everything else.  

You need to break it down, and add everything back up again, to compare against 
your
actual current drain out of your battery terminals.

anyways, back on topic.

uptime doesn't appear to me to be a valid metric for this topic.

http://linux.die.net/man/5/proc

/proc/uptime
    This file contains two numbers: the uptime of the system (seconds), and the
amount of time spent in idle process (seconds). 

As for measuring current, you create a "loop" for the power supply to each 
device on
your board.  And you get a current probe, and hook it up to an o-scope, to 
watch,
over the duration of a period of time (e.g. a slot) and fight each and every 
little
peak that comes up.

THEN you can work your way down to the ~3mA range that is acceptable for an 
embedded
hand-held device.

Good Luck!

Original comment by TheDixt...@gmail.com on 3 Jun 2010 at 9:53