Decrease in battery life after installing 3.11

[jjbjammin]

I was curious if other Rockbox users have noticed a decrease in battery life with 3.11? I have Rockbox installed on a Sansa Fuze (v1) and I use to get around 12-13 hours battery life with 3.10. Since upgrading to 3.11 I now get about 10 hours. None of the settings on the player have changed since the upgrade. Any ideas or suggestions? I guess I could always revert back to 3.10 to get those couple hours back.

[bertrik]

Have you actually measured a difference, using battery bench mark for example?
It could be that the battery has just lost a bit of capacity, or that you're unconsciously misjudging the runtime.
Try doing a couple of back-to-back battery benchmark (e.g. 3.10 first, then 3.11, then 3.10, then 3.11) with the same audio material, same volume and same other settings.

Only if that still gives a significant difference, then we can look into it seriously.

[jjbjammin]

I was able to run benchmarks for both 3.10 (build 2dc891b-120213) and 3.11. For both tests I used identical settings and had the same mp3 file play on repeat. The benchmark for 3.11 shows that it depleted 50% of the battery in a little over 6 hours while the 3.10 benchmark shows that it had depleted the same amount after 8 hours and 45 minutes. Attached are the benchmark results and my Rockbox configuration settings. Thanks for your help!

[tpijag]

With all due respect, you really need to use the benchmark test as designed. Run it to completion.

As you have tested, you have a major confounding variable. You do not know whether you have confirmed a change in battery life or a change in the accuracy of the battery meter.

[jjbjammin]

True. These battery benchmarks can be time consuming so I wanted to run a partial on both versions just to see if it was me or the player and it does confirm something has changed with Rockbox since the Feb 13th build. When I have the opportunity I will try to run complete benchmarks on both. Thanks.

[saratoga]

I did a battery bench, comparing 3.11 to an older bench I did 18 months ago:

3.11: 09:41:52
r28624-101120:  14:22:20

So battery life is about 5 hours worse.  Figuring out which commit did it is left up as an exercise to the reader.

[bertrik]

hm, that's quite a bit indeed ... :|
About 16 mA assuming a 550 mAh battery.

Just an idea, perhaps the fm tuner somehow stays enabled.
Something was recently changed in tuner power control.

Do you see a difference in the fm radio debug menu right after boot without explicitly disabling the fm tuner, and when the fm radio is explicitly enabled/disabled?

[saratoga]

Do you see a difference in the fm radio debug menu right after boot without explicitly disabling the fm tuner, and when the fm radio is explicitly enabled/disabled?

By "disable" do you mean long press the play button the FM screen to leave it?  If I do that, the registers do not reset back to the original state:

Original: https://plus.google.com/u/0/112705301073457671666/posts
Quit FM playback:  https://plus.google.com/u/0/112705301073457671666/posts

Is it worth trying a battery bench with the FM radio disabled (undef  CONFIG_TUNER SI4700)?

[saratoga]

I'll try bisecting a little tonight.  First I'll confirm that the Feb 13 build works, then I guess binary search from there.  If anyone else feels like helping, it'll speed this up if they could test 3.10. 

[saratoga]

2dc891b-120213:  14:41

[bertrik]

My analysis so far, is that the si4700 tuner chip stays in some kind neither-on-or-off state, because it doesn't receive a clock signal. The part of the code that enabled the clock was moved from the radio init sequence to the si4700_sleep sequence, so the clock is never enabled unless the tuner is explicitly woken up.

The tuner has two power-related bits in register 2 (ENABLE at bit 0, and DISABLE at bit 6). Normally, setting one of these would bring some kind of internal state machine in motion to either start a powerup or powerdown sequence and these bits would auto-clear.

What I see in these bits on my clip v1 (with an si4702) instead:
* just after startup (radio has not played yet): 0x0041 - > ENABLE=1, DISABLE=1
* after starting the radio: 0x4001 - > ENABLE=1, DISABLE=0
* after muting the radio : 0x0001 - > ENABLE=1, DISABLE=0
* after turning the radio off: 0x0000 - > ENABLE=0, DISABLE=0

I think the neither-on-or-off state just after startup is consuming the extra power.

One quick and simple solution would be to move the internal clock signal initialisation back to the radio init code.

[saratoga]

If you post a patch, I'll do the battery bench.

[bertrik]

Can you try this:

diff --git a/firmware/drivers/tuner/si4700.c b/firmware/drivers/tuner/si4700.c
index 16ec136..c41129b 100644
--- a/firmware/drivers/tuner/si4700.c
+++ b/firmware/drivers/tuner/si4700.c
@@ -371,6 +371,8 @@ void si4700_init(void)
 #ifdef HAVE_RDS_CAP
         si4700_rds_init();
 #endif
+        si4700_sleep(0);
+        si4700_sleep(1);
     }
 }
 
This explicitly turns on the radio to get the internal oscillator to work (so it doesn't get stuck in a neither-on-or-off state), then powers it down again.

[saratoga]

Sure, running it now.

[saratoga]

Patch:  14:08

Push it when you're ready.