Wondering about iPod Battery

[DanManners]

A few questions. One, has anyone actually been working on optimizing the iPod's battery life? Second, if no one has does anyone know what would be involved in scripting the battery optimizations? I've made a lot of themes and such for the iPod 5g and a few for the Nano, and I'm going to have a lot of time this summer for scripting and such. Anyway, just throwing the idea out that I'd be willing to learn how to script if I could help rockbox in that sense. I think that if it hasn't been implicated into version 3 or the Google summer program, I'd be a candidate for scripting.

Anyways, I'm done with being redundant.

-Dan

[Llorean]

"Optimizing the iPods battery life" requires coding, not scripting.

But really, one common assumption (that may or may not be valid) is that the problem is similar to that suffered by the H300 and X5: Improperly shut down hardware. Basically, the USB hardware, or some other chip, may not be being shut down properly, and is still drawing power when it shouldn't be.

But whether or not that's the big problem, any optimizations will help battery life to an extent. This basically boils down to reading the code, and finding faster ways to get the same thing done. The best places to look for this sort of thing is things that happen often (screen updates, drawing text, etc) since that costs time everywhere.

You'd basically need to learn C, and familiarize yourself with the Rockbox source. Optimization isn't necessarily something you can just step up and do without some time spent familiarizing yourself with things, because you generally have to understand what's being done before you can come up with a way to do it faster (though a fresh view on some things can certainly help).

But as I said, the biggest problem is, possibly, simply the fact that the hardware is undocumented.

[gummbah]

The issue of battery life seems to come back quit often as well as the answers by Llorean (good work and lots of patience there  ).
 
I was wondering if in some way we could monitor and visualise progress on battery life by, for example, testing once a month battery life using exact same settings, songs and ipod. If we could see that there is significant improvement during a certain month, we might be able to track it back to certain changes in the code, which could then be used to further improve code for the purpose of battery life improvement.

Just a suggestion.

Cheers.

[Llorean]

Considering the rate at which Lithium-based batteries decay, unless you're storing that iPod in a freezer and not using it, testing monthly on the same iPod is not likely to be a good means of testing unless every time you test it, you compare it to the original firmware with a test at the same time, and somehow manage to get perfect readings on the original firmware's life.

[gummbah]

I didnt know the battery life decays that fast.

[Llorean]

A lithium-ion battery that's stored full, at room temperature, can lose up to 20% of its capacity per year. That's 1.7% per month. Even dropping that down to 1% per month (assuming cooler temperatures, and storing at an better level than full) you're talking about losing 4 minutes of battery time in Rockbox per month, just from self discharge. Which means if Rockbox were to be gaining 4 minutes per month from optimizations, you wouldn't be able to see it.

And of course, depending on how much heat you exposed your iPod too, how many charge/discharge cycles over the month, etc, the numbers could vary.

It just makes it very hard to compare your own iPod over time with itself (and it's impossible to compare with another iPod). You have to compare your own iPod to its retail software, and of course they don't provide a good benchmarking tool. This is why measuring small battery life changes is ridiculously difficult.

In theory, you could run a bench with a month old version, then immediately run the same bench with the current version, so that you're comparing the older one to the newer one on the same day, and use that method to sort of chain the benches along, in pairs. That would give you somewhat useful results from month to month.

[soap]

Measuring battery-runtime, regardless of repeatability of conditions is really an indirect way to measure what you really want to know.
You want to know how many amps (or fractions thereof   ) the player it drawing under a variety of conditions, and compare those numbers to the stock firmware.
Note that according to the tests in this thread:  http://forums.rockbox.org/index.php?topic=8867.msg68613#msg68613
Rockbox at idle is consuming 165% of Apple Firmware at idle.
All the code optimizations in the world won't solve (what appears to be) a large chunk of the problem.