Der große Akku-Drain-Thread

[payce]

Wartet mal noch ein paar Tage ab: Laut nadlabak ist im neuen Kernel der deep sleep bug endlich erledigt. Nadla hat dies im neuesten CM6-Kernel auch schon verbastelt. Seitdem scheint die Geschichte gegessen zu sein. Es ist nur eine Frage der Zeit bis andere Kernels nadla's Arbeit wieder übernehmen (MIUI, Cronos etc... basiert ja alles zum Großteil aud nadla's Arbeit).

Moto wird wohl hoffentlich auch bald mal mit dem offiziellen Update rausrücken.

PS. Zur Info (erster Changelog Eintrag unter "Update")

 

[eybee1970]

Wartet mal noch ein paar Tage ab: Laut nadlabak ist im neuen Kernel der deep sleep bug endlich erledigt. Nadla hat dies im neuesten CM6-Kernel auch schon verbastelt. Seitdem scheint die Geschichte gegessen zu sein. Es ist nur eine Frage der Zeit bis andere Kernels nadla's Arbeit wieder übernehmen (MIUI, Cronos etc... basiert ja alles zum Großteil aud nadla's Arbeit).

Moto wird wohl hoffentlich auch bald mal mit dem offiziellen Update rausrücken.

Cronos ist seit 1.8.0 auch schon mit dem brazil kernel unterwegs, ebenfalls HoNo, FroyoMOD und seit heute MIUI mit den jeweils aktuellen Versionen

 

[relaxo]

Wartet mal noch ein paar Tage ab: Laut nadlabak ist im neuen Kernel der deep sleep bug endlich erledigt. Nadla hat dies im neuesten CM6-Kernel auch schon verbastelt. Seitdem scheint die Geschichte gegessen zu sein. Es ist nur eine Frage der Zeit bis andere Kernels nadla's Arbeit wieder übernehmen (MIUI, Cronos etc... basiert ja alles zum Großteil aud nadla's Arbeit).

Moto wird wohl hoffentlich auch bald mal mit dem offiziellen Update rausrücken.

PS. Zur Info (erster Changelog Eintrag unter "Update")

es ist zwar erst einmal vorgekommen, deshalb juckts mich nicht weiter, aber ich hatte mit dem aktuellen CM6 einmal den sleep-bug. knapp 8h ohne grössere benutzung + 100% "running".

allerdings hatte ich das problem auch mit dem 2.1 stock (was die foristen hier tw. als lösung anbieten), insofern...

 

[payce]

@eybee: Jupp, MIUI habe ich auch grad gelesen! Ach fein. Das wärs ja, wenn das Thema nach einem gefühlten Jahr endlich vom Tisch wäre.

 

[JanR86]

Ich habe komischerweise seit dem letzten Update immer 100% unter "wird ausgeführt" stehen, was sich auch nach einem Reboot nicht ändert; allerdings habe ich dennoch eine Akkulaufzeit von ~24h, was bei meinem Nutzverhalten eher dafür spricht, dass mein Milestone dennoch in den Deepsleep geht...

Kann es sein, dass das Akkuprotokoll einfach nicht immer korrekt ist?

 

[payce]

ARGHLLL!! Leute, bitte schlagt mich ned, aber ich habe bei den Messungen weiter vorne einen recht peinlichen Fehler gemacht. Wie vorne schon geschrieben: Ich wiederhole die Messung eh und mache dann mal ein paar Auswertungen. Sorry! Kommt aber alles noch und dann in einem eigenen Thread dazu.

(peinlich, peinlich...)

 

[pogobi]

Ich habe komischerweise seit dem letzten Update immer 100% unter "wird ausgeführt" stehen, was sich auch nach einem Reboot nicht ändert; allerdings habe ich dennoch eine Akkulaufzeit von ~24h, was bei meinem Nutzverhalten eher dafür spricht, dass mein Milestone dennoch in den Deepsleep geht...

Kann es sein, dass das Akkuprotokoll einfach nicht immer korrekt ist?

Taktest du z.B. per SetCPU bei deaktiviertem Bildschirm herunter? Hast du undervoltet bei niedrigen Takten? Der Akkudrain ist dann auch nicht mehr das was er mal war

 

[JanR86]

Taktest du z.B. per SetCPU bei deaktiviertem Bildschirm herunter? Hast du undervoltet bei niedrigen Takten? Der Akkudrain ist dann auch nicht mehr das was er mal war

Ich habe inzwischen gemerkt, dass der Fehler nicht am Akkuprotokoll lag, sondern daran, dass das Protokoll, was ich immer über das BatteryLeft-Widget aufgerufen hatte, sich bei mir anscheinend nicht aktualisiert hat. Die absoluten Werte betrugen nur wenige Sekunden und veränderten sich auch nicht.

Wenn ich das Protokoll dagegen über die Spare-Parts oder die Telefoninfo aufrufe habe ich auch bei "wird ausgeführt" keine 100% mehr stehen. War also falscher Alarm meinerseits (was auch die nichtvorhandenen Auswirkungen des Akkudrains erklärt ).

 

[payce]

Uiuiuiii. Ich habe heute schon ein paar Messungen gemacht. Ey, Leute, froit Euch auf die Auswertung. Da kommen ein paar lustige & überraschende Geschichten zusammen. Ein kleiner Auszug:

- StandBy Flugmodus/2G/3G/APN völlig wurschd: Alles unter 20 mW *IM DEEP SLEEP*
- HSDPA Upload so bis zu 4 W (!!!!!)
- Der Akkuverbrauch ist von schwarzem zu weißem Display um ~40 mW höher (wiederholbar) - nix zum Akku sparen, aber lustig & interessant zu wissen
- Die Akkuanzeige geht beim Laden auf 100% *und die weiße LED geht aus* (!!!) OBWOHL der Akku nachweislich erst 70% Kapazität erreicht hat. Obwohl die weiße LED aus ist, wird munterst (~ 600 mA) weiter geladen.

Das mal nur die Highlights. Der Thread kommt bald!

 

[eybee1970]

danke, payce! Immer toll Deine posts zu lesen, da sie oft neue Erkenntnisse und wenn nicht zumindestens immer wissenswertes bringen!!!

Wenn Du den thread dann erstellst, dann doch gleich mit Empfehlungen zum Akkusparen - wäre klasse

 

[Christoffer]

- Die Akkuanzeige geht beim Laden auf 100% *und die weiße LED geht aus* (!!!) OBWOHL der Akku nachweislich erst 70% Kapazität erreicht hat. Obwohl die weiße LED aus ist, wird munterst (~ 600 mA) weiter geladen.

Das mal nur die Highlights. Der Thread kommt bald!

da freu ich mich doch auch schon auf die Enthüllungen um den Stein

das mit der LED wusste ich schon da ich immer bei Spareparts gucke ob de Akku voll ist - jedenfalls bild ichs mir ein das da zu sehen

 

[relaxo]

- Der Akkuverbrauch ist von schwarzem zu weißem Display um ~40 mW höher (wiederholbar) - nix zum Akku sparen, aber lustig & interessant zu wissen

krass. woran kann das technisch denn liegen?! bei nem lcd ist die hintergrundbeleuchtung doch immer an. und klar ist es zum akku-sparen gut. schwarze themes/backgrounds etc. bevorzugen, mag nicht viel bringen, aber besser als nichts (wobei ich sowieso schwarz bevorzuge)

 

[petersteier]

Der Thread entwickelt sich auseinander: manche feilen an den settings um noch ein paar Tage länger durchzuhalten, manche (so wie ich) haben ein Schlafstörung, die nach wenigen Stunden kommt und nur mit booten weggeht; da sind dann alle Sparmassnahmen aussichtslos.
Anscheinend gibt es keine Möglichkeit (logcat etc.) rauszufinden ob der deep sleep momentan noch geht. Nur mit *#*#4636#*#* dauert das ja Stunden! So werde ich nie den Verursacher finden.
Daher: meine Brachiallösung: jede Stunde automatisch mit Tasker wenn Display aus und nicht am Ladegerät booten. Ich berichte, ob das hilft.

Vielleicht weiss doch wer, wie ich ohne Amperemeter feststellen kann, ob der Stein schläft?

 

[petersteier]

Ich hab' mit Hilfe der Android-Referenz doch einen Weg gefunden, den Deep Sleep festzustellen. Folgendes shell-script (root and busybox notwendig) ggespeichert als /sdcard/milesleep mit TextEdit:

####################################
# detect deep sleep on android
# Peter Steier, 22.1.2011

LASTSECS=$(date +%s)
while test 1 -eq 1 ; do
sleep 10 ;
SECS=$(date +%s)
LOSS=$(($SECS-$LASTSECS-10))
if test $LOSS -gt 5 ; then
echo -e "\n$(date) Deep sleep $LOSS seconds detected."
else
echo -n .
fi
LASTSECS=$SECS
done ;
##############################

In ConnectBot (Hintergrundverbindung aufrechterhalten):

su
. /sdcard/milesleep

schreibt ein Protokoll der DeepSleep-Zeiten raus. So kann ich jetzt auf die Jagd gehen, was den DeepSleep stört.

 

[petersteier]

Erste Erkenntnis: der Stein geht bei mir am Ladekabel gar nicht in den DeepSleep. @payce: vielleicht ist das relevant für die Strommessung?

 

[petersteier]

So. Bei mir (G.O.T. 2.2) funktioniert der Deep Sleep mode nach dem Ausstecken des Ladekabels weiter, ob das Display an oder aus ist. Ich habe noch nicht viel Statistik, aber da scheint es sich doch um einen Mythos gehandelt zu haben.
Ein Schlafstörer ist das GPS. Wenn es mal eingeschalten war, ist der Deep Sleep bis zum nächsten Booten weg. Das trat sowohl be Google Maps als auch bei "Tricorder" auf. Bei deaktiviertem GPS stört Google Maps nicht. Ich werde mal GPS und meinen stündlichen Tasker-Boot deaktivieren, und weiter berichten.

Danke übrigens dem, der auf GPS weiter oben im Blog hinwies (leider schon zu viele Seiten um ihn wiederzufinden).

Anmerkung 24.1.2011: Man muss nicht neu booten. GPS kurz deaktivieren reicht. Siehe unten.

 

[Smoki]

Ein Schlafstörer ist das GPS. Wenn es mal eingeschalten war, ist der Deep Sleep bis zum nächsten Booten weg. Das trat sowohl be Google Maps als auch bei "Tricorder" auf. Bei deaktiviertem GPS stört Google Maps nicht.

Auch meine gefühlte erfahrung mit dem Deepsleep-Bug bei CM6. Sobald man mal seine Position mit Maps und GPS bestimmt hat wars das mit Deepsleep.
Ich habs immer so gemacht:
Hab mit *#*#4636*#*# mir die Zeit bei "Wird ausgeführt" gemerkt. Display aus und nach 10Min wieder draufgeschaut. Wenn der Stein nicht in den Deepsleep ging kamen 10Min dazu, wenn der DeepSleep funktioniert hat kam höchstens ne Minute dazu.
Dann dauerts wenigsten keine Stunden um rauszufinden ob der Stein in der DeepSleep geht.
Mit CM6 hab ich aber auch schonmal 20% über Nacht verloren mit ausgeschaltetem Handy! Genauso ist die Akkuanzeige immer direkt von 40% auf 20% gesprungen. Also was bei CM6 in der Statusleiste angezeigt wurde, war auch irgendwas nur keine vernünftige Akkuanzeige.
Edit: Wenn der Stein am Ladekabel hängt geht er AFAIK nie in den DeepSleep. Das gehört sich wohl so.

 

[petersteier]

Leider ging über Nacht der DeepSleep wieder verloren. Um 01:13:40 wurde das Ende des letzten pprotokolliert. logcat -v time *:S schaut für diesen Zeitraum so aus:

01-23 00:59:06.577 W/BatteryStatsImpl( 1301): Couldn't get kernel wake lock stats
01-23 00:59:06.640 D/WifiService( 1301): ACTION_BATTERY_CHANGED pluggedType: 0
01-23 01:11:05.639 D/WifiService( 1301): acquireWifiLockLocked: WifiLock{NetworkLocationProvider type=2 b
inder=android.os.Binder@452d4398}
01-23 01:11:07.335 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: DISCONNECTED/SCANN
ING
01-23 01:11:08.803 D/ConnectivityService( 1301): ConnectivityChange for WIFI: CONNECTING/CONNECTING
01-23 01:11:08.952 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: CONNECTING/AUTHENT
ICATING
01-23 01:11:09.210 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: CONNECTING/OBTAINI
NG_IPADDR
01-23 01:11:10.678 D/WifiService( 1301): releaseWifiLockLocked: WifiLock{NetworkLocationProvider type=2 b
inder=android.os.Binder@452d4398}
01-23 01:11:11.741 D/ConnectivityService( 1301): ConnectivityChange for WIFI: DISCONNECTED/IDLE
01-23 01:11:11.741 D/ConnectivityService( 1301): getMobileDataEnabled returning true
01-23 01:11:11.741 V/ConnectivityService( 1301): Switching to already connected mobile
01-23 01:11:11.749 D/ConnectivityService( 1301): adding dns 194.48.139.254 for mobile
01-23 01:11:11.749 D/ConnectivityService( 1301): adding dns 194.48.124.200 for mobile
01-23 01:26:05.679 D/WifiService( 1301): acquireWifiLockLocked: WifiLock{NetworkLocationProvider type=2 b
inder=android.os.Binder@452d4398}
01-23 01:26:07.374 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: DISCONNECTED/SCANN
ING
01-23 01:26:08.843 D/ConnectivityService( 1301): ConnectivityChange for WIFI: CONNECTING/CONNECTING
01-23 01:26:08.937 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: CONNECTING/AUTHENT
ICATING
01-23 01:26:09.179 D/ConnectivityService( 1301): Dropping ConnectivityChange for WIFI: CONNECTING/OBTAINI
NG_IPADDR

Das erste, was nach dem DeepSleep geloggt wurde, war ein Wifi-lock (allerdings erst nach 13 Min!). Der Wifi empfang ist bei mir am Nachtkastel ziemlich schlecht. Ascheinend war er abgebrochen.

Ich deaktiviere Wifi: der Deep Sleep geht wieder! (ohne reboot). Da sind anscheinend doch ein paar Bugs in der von G.O.T. 2.2 verwendeten Froyo-Testversion!

 

[petersteier]

Nach einem Aufladen kam der Deep Sleep nicht wieder; war aber nicht das Ausstecken, sondern das Wifi: kurz disable/enable brachte den Deep Sleep zurück. Ebenso ist es beim GPS: kurz disablen in den Einstellungen, und der Deep Sleep geht wieder (oben hatte ich fälschlicherweise behauptet, dass nur ein reboot hilft).

@Smokey: das ist eine gute Methode! Braucht kein Root und Shellscript. Hier nochmal genau beschrieben, wenn es wer nachmachen will:
1) in der Phone App: *#*#4636#*#* tippen. Menü erscheint.
2) Menüpunkt "Akkuprotokoll" auswählen
3) "Seit dem letzten Ausstecken", "Andere Verwendung"
4) Mit Zurück-Softkey zurück zum Menü
5) Warten, bis die Armbanduhr genau eine ganze Minute anzeigt, dann nochmal "Akkuprotokoll".
6) auf "wird ausgeführt" tippen, die angezeigte "Zeit ohne Schlafmodus" abschreiben.
7) 2x Zurück-Softkey zum Menü
8) Screen ausschalten mit on/off
9) kurz vor voller Minute Screen wieder an
9) Warten, bis 2 Minuten voll, dann wieder "Akkuprotokoll"
10) Wieder "wird ausgeführt" anklicken, die neue Zeit abschreiben
11) Ist die Zeitdifferenz 2 min, dann funktioniert der Deep Sleep ***NICHT***, und man wir keine lange Standbyzeit erreichen.

Bei mir war die Zeitdifferenz ca. 30 sec, das Gerät war also 1 min 30 sec im Schlafmodus. Wer geschickt ist, kann die Wartezeit auch auf 1 min verkürzen. 10 min ist sehr gemütlich. Das wiederholte zurückgehen zum Menü ist notwendig, da die Werte nur beim Antippen von "Akkuprotokoll" aktualisiert werden.

Mein nullter Vorschlag zur Lösung des Akku-Drain: Zuerst prüfen, ob der Stein unter Tiefschlafstörungen leidet. Wenn ja, Wifi und GPS nur aktivieren, wenn man sie wirklich braucht (mein erster Vorschlag wird ein Tasker-Profil sein das das automatisch macht).

Wenn keine Tiefschlafstörung vorliegt, auf payces Messungen warten, was "regulär" viel Strom braucht.

 

[nodh]

Ich kann bestätigen, dass einmalige Verwendung von GPS den Tiefschlaf verhindert.
Mein Fall: Neue Installation von CM6 0.06, nach dem Booten schöner Schlafzyklus. Dann das erste Mal Google Maps gestartet, das hat natürlich über GPS meinen Standort bestimmt, und das wars dann mit der Akkulaufzeit. Abhilfe hat das deaktivieren des GPS gebracht.