Battery Runtime Test
|| Quit Plugin
| Any other
|| Trigger reload (causes some more power drain at this moment)
I wrote up a plugin that simulates (or so I thought) normal power drain by spinning up the disk and reading a big file once ever 90 seconds (or thereabout). Each spinup also wrote the battery level to a log file. The test stopped when battery level reached 4%.
The result of this test astonished me: 19 hours of runtime on a set of 2200 mAh batteries! (The batteries had been charged in an external GP quickcharger.)
(PeterFavrholdt comments: after changing to 2100mAh batteries my JBR20 had more than 15hours continous playing time.)
Something tells me my test was using far less power than normal playback does, which in itself is interesting because I had the impression that there was not a lot we could do to affect power consumption.
Here is a (bad) graph showing battery level during the test:
One of my goals was to test the voltage-to-percent algorithm we use to provide a linear decline in battery level. According to this graph, it is working rather well.
Other interesting tests to try:
MarkBright - 20 Jun 2004
- Measure time until batteries really run flat (i.e. when open() fails or something like that). This would expose any offset error we may have (such as running at 1% for two hours).
- Measure time during real looped playback of a playlist, using a TSR plugin.
- Write a plugin that switches on/off usage of various things like MAS, backlight, disk, cpu etc and then measure power drain.
Taking up from this point, I decided to do a little experimentation with the Battery Test plug-in on my FMR looking for the answer two questions.
1) Just what is the battery life of this box in continuous play
The WPS value for a fully charged box indicates about 12 hours, but the values this estimate is based on the power drain of the old style Recorder
2) Does enabling the optimised ATA code make any difference?
The theory is that as the code is 50% more efficient, it should give an increase in battery life, however due to an unfortunate side effect of corrupting a (very small) percentage of drives, it is commented out in the general release.
The results were a little surprising.
With the normal ATA code - 9 hours 31 minutes
With the optimised ATA code - 9 hours 23 minutes
Both sets of figures give a very good approximation to a straight line when plotted, so that's good, but
A) The battery life is well short of the estimate
- with just about the lowest power usage scenario you could imagine... No pausing, volume changes, complex WPS updating, no backlight on and off, no browsing file structure in the background.
The initial conclusion is that the FMR (and V2?) has a higher power drain than the old Recorder. This needs to be confirmed by either multiple users doing the same test, or better still - a techie with an FMR to measure the actual
figures from an FRM/V2
B) The Assembler code seemed to make no difference - in fact showed a small reduction.
As Björn pointed out, this is within the margin of error, and I would need to run this test several times to be sure... so a total of four runs with the same firmware (With the optimised ATA code) showed a great similarity. Worst case was 09:23, best case was 09:55
- Four battery life run's with Trend lines :
It can be seen from the graph that my FMR uses between 8.3% and 9.6% per hour, this would appear to be a signifficant reduction on the figures quoted for the "Old Style" recorders.
: Battery power-drain simulator [Player
, iPod 4G
, iPod Color
, iPod Mini
, iPod Nano
, iPod Video
, iAudio X5
Copyright © by the contributing authors.