Sansа Clip Zip - Improve battery life

[Mihail Zenkov]

I measure current between player and battery and try tweak power consumption.

Current in mA (less is better):


You can convert current to hours:
battery capacity (mAh) / mA = hours

For example rockbox with patch consume 10.9 mA when play flac, battery capacity in Zip - 300mAh.
300 / 10.9 = 27.5 hours

In reality it would be less - battery capacity degraded over time.

Some interesting results:
1. Original firmware have problem with flac (double power consumption).
2. Themes can significantly differ in power consumption when screen on.
3. Radio consumes too much (but I didn't try to optimize it).
4. We have room to improve battery life


rockbox-improve_battery_life.patch:  set master clock to 48 MHz, undervolting CVDD1, CVDD2, PVDD1. WARNING: this patch may cause instability, freeze or sound quality degradation.

rockbox-backlight.patch: disable DCDC15 when screen off (save 1mA), like we already do in Clip Plus. Good for inclusion in main branch.

rockbox-usb.patch: prevent USB power consumption (additional 5 mA in all modes) after it disconnected. Also good for inclusion in main branch.


I try many other clocks/voltages without any significant difference.


Link for binary build: http://forums.rockbox.org/index.php/topic,48368.0.htm

[saratoga]

I measure current between player and battery and try tweak power consumption.

Current in mA (less is better):

Awesome thanks, no one has looked at power on the sandisk players in years.  I knew more improvements were possible but haven't looked into them.

1. Original firmware have problem with flac (double power consumption).
2. Themes can significantly differ in power consumption when screen on.
3. Radio consumes too much (but I didn't try to optimize it).
4. We have room to improve battery life

Yes, the sandisk firmware uses the official flac decoder, which is VERY slow.  We used it too for a bit, but quickly switched to ffmpeg's much faster one, which was then heavily optimized.  It can decode a file using less than 10 MHz of CPU.

rockbox-improve_battery_life.patch:  set master clock to 48 MHz, undervolting CVDD1, CVDD2, PVDD1. WARNING: this patch may cause instability, freeze or sound quality degradation.

We did tests years ago of lower clock speeds (and also lower memory bus speeds), and found that they made relatively little difference.  This is actually why no one has bothered to get CPU frequency scaling running, it was believed to only have a very small impact on battery life.  These results are therefore very interesting. 

Do you know how much of the change is from the voltage settings and how much is from the CPU frequency?  Or is it that lower clock means you can more safely use a lower voltage?  Perhaps this will motivate enabling CPU frequency scaling.

rockbox-backlight.patch: disable DCDC15 when screen off (save 1mA), like we already do in Clip Plus. Good for inclusion in main branch.

I'll try this out and commit if it works ok for me.

rockbox-usb.patch: prevent USB power consumption (additional 5 mA in all modes) after it disconnected. Also good for inclusion in main branch.

These needs to be tested, but looks like a big oversight on our part.  I suppose this may help with other AMS devices too.

I try many other clocks/voltages without any significant difference.

We did a lot of testing years ago, I will try to find the results and forward them to you.  I found that increasing PCLK (the memory bus is on this) greatly increased performance but also power draw.  At lower speeds, the player was slower, but more efficient.  Running the memory faster massively improved how fast some of the decoders were (far fewer MHz needed for realtime playback) but decreased battery anyway. 

[saratoga]

http://gerrit.rockbox.org/r/#/c/988/
http://gerrit.rockbox.org/r/#/c/989/

Will commit in a day or two if no one sees any problems.  Note that I changed the backlight current sink on value to be 91 (its previous value) rather than 90.  Probably doesn't matter but I was unclear on why it was changed.

[saratoga]

Some comments about the voltage patch:

1)  Reducing the main CPU frequency is fine for FLAC and for people who don't use much DSP effects, but probably even mp3 + EQ would skip that low.
2)  If you change any of the registers related to supply voltages, make sure that you don't reduce the device's maximum volume.  0dB should be the max without distortion if the audio hardware has the correct voltages.

[saratoga]

Patch with work in progress frequency scaling:  http://www.rockbox.org/tracker/task/11297

As you can see we never figured out why dynamically scaling the frequency reduced battery life.  Possibly this was a mistake or oversight if you found that lowering the clock improved battery life.

[Mihail Zenkov]

Do you know how much of the change is from the voltage settings and how much is from the CPU frequency?

I check on playing flac:
mod PLLA save 3.5 mA
mod CVDD1 save 2.2 mA
mod CVDD2 save 1 mA
mod PVDD1 save 1 mA

Or is it that lower clock means you can more safely use a lower voltage?

Yes, it also allows use lower voltage.

We did a lot of testing years ago, I will try to find the results and forward them to you.  I found that increasing PCLK (the memory bus is on this) greatly increased performance but also power draw.  At lower speeds, the player was slower, but more efficient.  Running the memory faster massively improved how fast some of the decoders were (far fewer MHz needed for realtime playback) but decreased battery anyway. 

I try check PCLK. Any idea what also I should check?

I try change PVDD2 and have worst result, even if I try disable it (write 0x80 to it).

Note that I changed the backlight current sink on value to be 91 (its previous value) rather than 90.  Probably doesn't matter but I was unclear on why it was changed.

As datasheet say it shouldn't change any thing. Clip Plus and Clip v2 set it to 0x90. I set it to 0x90 and don't see any changes. I think 0x91 just mistake.

1)  Reducing the main CPU frequency is fine for FLAC and for people who don't use much DSP effects, but probably even mp3 + EQ would skip that low.

Right, we need dynamically scaling. But it more complicated to test and tune.

2)  If you change any of the registers related to supply voltages, make sure that you don't reduce the device's maximum volume.  0dB should be the max without distortion if the audio hardware has the correct voltages.

Ok. You already have this problem with a patch?

Patch with work in progress frequency scaling:  http://www.rockbox.org/tracker/task/11297

As you can see we never figured out why dynamically scaling the frequency reduced battery life.  Possibly this was a mistake or oversight if you found that lowering the clock improved battery life.

I try check it.

My first patch have problem - it change core voltage in bootloader, fixed in new version.

I also think we should set CPUFREQ_DEFAULTA and CPUFREQ_NORMAL to FCLK, as we don't have dynamically frequency scaling. With current value we have wrong udelay.

[Mihail Zenkov]

I check PCLK - try 12MHz and 6Mhz - no significant difference.

[saratoga]

I think that is too low.  The maximum is 60MHz, and we found acceptable performance down to about 20MHz (lowering it too much means the CPU wastes a lot of power waiting for memory loadds).

By the way, can you join use in #rockbox?  We are discussing these patches. 

Edit:  Testing the USB and backlight changes increased my Zip runtime by 32%. 

[saratoga]

To help with testing, I've added new debug menus that show the current SOC voltage regulator outputs (using an on board A/D to read the voltages).  You can see then under System -> debug -> view io ports and then hit the down button to scroll through all the voltages.

[Mihail Zenkov]

I think that is too low.  The maximum is 60MHz, and we found acceptable performance down to about 20MHz (lowering it too much means the CPU wastes a lot of power waiting for memory loadds).

I just test it. In patch I don't change it (24Mhz).

By the way, can you join use in #rockbox?  We are discussing these patches. 

I don't use IRC, sorry.

Edit:  Testing the USB and backlight changes increased my Zip runtime by 32%. 

Good.

To help with testing, I've added new debug menus that show the current SOC voltage regulator outputs (using an on board A/D to read the voltages).  You can see then under System -> debug -> view io ports and then hit the down button to scroll through all the voltages.

Great! What I want add today

[saratoga]

I think the current build now shows all (about 20) voltage channels on the device.

Regarding pclk I don't mind to tell you what to use, but somewhere between 20-40 is likely optimal.

By the way one user testing the lower CPU clocks found that they break most formats other then flac.  So if we want to lower them much frequency scaling will be needed.

[saratoga]

Have you taken any measurements of AVDD17 or AVDD27?  Looking at the voltages, we run AVDD17 a little higher because it determines the maximum headphone output.  I was thinking raising it might be useful, but I won't do that if it uses a lot of power.

Edit:  If I understand correctly, AVDD17 is the analog voltage used for almost everything but headphone amplifiers (line out, mixers, etc) while AVDD27 is the headphone output.  I wonder if AVDD17 could be lowered since we do not use the line out. 

[Mihail Zenkov]

By the way one user testing the lower CPU clocks found that they break most formats other then flac.  So if we want to lower them much frequency scaling will be needed.

I also use it with mp3, but without any postprocessing. Frequency scaling should by next step.

Have you taken any measurements of AVDD17 or AVDD27?  Looking at the voltages, we run AVDD17 a little higher because it determines the maximum headphone output.  I was thinking raising it might be useful, but I won't do that if it uses a lot of power.

I measure it at first - no significant difference at low volume. I don't test it at high volume. I try check it again.

Edit:  If I understand correctly, AVDD17 is the analog voltage used for almost everything but headphone amplifiers (line out, mixers, etc) while AVDD27 is the headphone output.  I wonder if AVDD17 could be lowered since we do not use the line out. 

When I try disable AVDD17 I don't hear any sound And save 1 mA  - we can use this on pause, but not sure if it have sense.

[Mihail Zenkov]

Checked -  no significant difference at pause, low volume (-35dB) and high (0dB).

[saratoga]

The volume mixers are still needed for playback, so AVDD17 can't be disabled.  It might be possible to lower it (although that might require adjusting the volume mixer gains too to avoid clipping), but if it only uses 1 mA its probably not worth it.

AVDD27 is at 2.7v right now according to the A/D, so even if we raised it to its maximum of 3.3, that only gains ~ 1dB in maximum output.  Maybe not worthwhile.

Testing CVDD2, it seems that PVDD1 is derived from it, and furthermore that the SD cards run off it, as 1.8v gives an ATA error trying to read storage