Rockbox Development > Feature Ideas

Offical Battery Life

<< < (2/3) > >>

Llorean:
Or the 5 hour one comes from a much older build than the 20 hour one, and the code has changed significantly since then.

Taking an average of just a few skews perception even worse unless you have an extremely large set of players because it suggests to people that the numbers are "good" when the sample set is too small to really determine that.. Or did you have an idea where we could get about a dozen players of varied use amounts for each type of player we support, where the average amount of wear for each set of a dozen is very close to that of each other set and is a describable amount of wear so that we can say to people "For people who've used their player X amount of time, this level of battery life is typical."

Taking an average reduces the outliers, but you need a large enough sample set for it to matter. If we average a dozen heavily used players (as is likely the case if we average people using Rockbox) it doesn't adequately represent runtime.

The *only* useful piece of information on that page is the comparison, on the same player, of the original firmware's runtime vs Rockbox's runtime with the same playlist. Even that is only useful if there is the possibility to match volumes (which there really isn't, at best you can only approximate).

Follow that by the fact that runtime changes over time as Rockbox changes, we'd have to be updating the page monthly, which would mean tracking down another set of players (hopefully with similar averages to the original sets) and perform the series of tests every month. And then come up with a way to adjust for the fact that the batteries are aging unless we wanted to also do runtime tests in the original firmware each time, which is difficult at best to get accurately since there's no logging apparatus so you cant just check the voltages over time like you can with Rockbox.

Now, mind you, if you feel like volunteering to coordinate such an effort monthly, nobody's going to stop you. But getting numbers that are "accurate" is really impossible. The most meaningful you can get is "under similar conditions, Rockbox tends to match or surpass the original firmware's runtime." We can already comfortably say this.

If you'd like a number that *is* meaningful, come up with a way to hook some hardware up and measure the average wattage across several hours, so you can tell people how much power Rockbox draws compared to the original firmware. This would only require one player of each type, does not require running through a full charge (or several, to average out for each individual player and avoid a bad measurement) and should not be affected by device/battery age.

saratoga:

--- Quote from: Eli Gundry on April 12, 2009, 10:12:31 PM ---The ones with 5 hours to 20 hours are outliers, as they either have old batteries or are using unrealistic settings for their benches. All I want is an average battery life for all players with unified test settings. By taking an average, you can avoid the problems of accounting for old or new batteries.

--- End quote ---

This really makes no sense at all.  Aging isn't a zero mean process.  You can't average it out.  All an average would do is weight points along a capacity vs. age curve by the number of users at each point.  The result would be more or less meaningless.

If you just want a power consumption measurement independent of the battery, get a DMM and measure current.

Eli Gundry:
Alright, I guess that makes sense. Oh well, seemed like a good idea.

psycho_maniac:
this makes me want to do another battery bench but i been using my player a lot lately and this is a different player (same one just newer) and this one seems to last a lot longer then my old one.

soap:
I think the point is being missed that a battery bench at any point during the battery's lifetime can be quite meaningful IF said battery bench is "calibrated" by performing a baseline test on the Original Firmware.

As to the idea of using "Dark Side of the Moon"... There are plenty of free albums on archive.org which would be available to all.  Not to mention a common source and common encode removes yet more variables from the equation.

This is something which could totally be done as a distributed project.  All that needs done in preparation is documenting a standard testing procedure - the specifics don't matter as long as you're consistent, and a standard set of encodes.  Said standard should include specifics for each and every target's OF (where possible) and a standard .config file for each Rockbox target.

Then, and only then, could a statement such as "Using 'X' testing procedurem Rockbox achieves N% of Original Firmware runtime on target Y."
Such a statement would be true regardless of battery condition or hardware modifications (HDD size, CF card, mega battery, etc.)
Such a statement would also be quite useful, and easy to track over time.

 

Navigation

[0] Message Index

[#] Next page

[*] Previous page