Iaudio X5l/M5L battery life estimates.

[GSV3MiaC]

I'm enjoying my Rockbox'd Cowon/iAudio M5L, but the battery life estimation is way off. I mean WAY WAY off .. factor of 2-3 pessimistic. The software won't let me opt for any battery larger than 2250mAHr (which is what I actually have), so I can't fake it out that way - is there any other user adjustment(s) to tell it that it needs to multiply by a bigger number? Or does it calibrate itself over time and get better?
 
I guess I could put a battery_bench.txt file in for analysis, but the current error is rather more gross than 'fine tuning' IMO. Also I tend to actually use it rather than leave it playing one album in a loop. fwiw I'm playing .ogg at Q=1, into Sennheiser PX100s, no effects, no equalizers, volume = -30 (why '-' ??).
 

[nls]

The reason it is off is that no one has calibrated it (yet), simple as that, this is tru for most rockbox targets currently. (All except archoses and iriver h100)
It does not calibrate itself over time.
Why negative volume?
Because the volume in rockbox is a reference to the recording volume, 0dB means it should be at the same level as it was recorded/mastered, a negative volume is lower and a positive (where possible) is louder. We had an arbitary scale of 0-100 (iirc) long ago but since it doesn't really mean anything and a volume of say 50 would not be the same on different models it was dropped for the dB scale

[GSV3MiaC]

Ok, Guess I better turn in a battery_bench log after all then, even if it means deliberately leaving the M5l to sit and run down. So far I observe (from a  limited run):-
 
a) The battery starts at 4.2v. Rockbox seems to be hardwired to believe the max is 4.1v, so we stay at 100% for the first 3-4 hours until it gets down to 4.1v.
 
b) from there the voltage and %age track down together (as you'd expect), however the hours left (gradient) is off by somewhere between 2x and 3x. 8 hours in, my battery life estimate has dropped from 15+ to 13+, although, as I said, it didn't move at all for the first 3 hours.

Looks to me as if I should eventually get 25-30 hours, which is pretty good .. original firmware quotes 35, which is normally a bit optimistic.

Thanks for the explanation of volume. Makes sense, but it is sort of counter-intuitive to have smaller numbers equate to larger volume (the '-' is easy to overlook in some fonts). I can't imagine getting into positive number territory without massive distortion and aural destruction.

[nls]

Then it seems like the voltage<->percent conversion isn't entirely correct either...
IIRC amiconn (who made the m5 port) got something like 50 hours in a mp3 runtime test on an m5l.

[pixelma]

IIRC amiconn (who made the m5 port) got something like 50 hours in a mp3 runtime test on an m5l.

Yes, but that was a battery_bench test with backlight turned off... plus it was a brand new device and as usual for a bench: no browsing etc. He also did a "backlight always on" test under the same - otherwise perfect - conditions which lasted for 36h 14 min.

Anyways - the battery level percentage was calibrated using these test results and it seems to be quite good on mine (well that's the one used for calibrating ). If your result is way off and maybe others' as well I think that gathering a few benches in the wiki, like it's been done for other targets, could possibly help to find an average that suits better. It would be best to agree on a certain bitrate and codec and/or other average settings so that the results are comparable - the "standard" that was used is 192kbps mp3s which worked out well for calibrating battery percentage on other targets in the past.

The runtime estimates on the other hand weren't calibrated at all which would have meant additional work in the powermanagement code - a part that needs a severe cleanup as some developers (including amiconn) say. At least I believe that was the reason given (not a 100% sure though).

[GSV3MiaC]

So a freshly charged battery on your comes in at only 4.1v?? Mine (M3L, 20GB, probably one of the last few made) comes in at 4.2v, and stays above 4.1v for s significant time (3 hours).

I can live with the (just slightly) whacky %age, but the whacky runtime estimate is far enough off to be annoying. I know that the batteries do not decay in a nice straight line, but even that would be a much better estimate than the current one. Possible the simplest quick fix would be to stick in a user provided scaling factor (or else, much harder but neater, calculate and store one on the fly).

I ONLY play .ogg, Q=1, and I have my own particular .wps, and I mess with the controls yea-often (hardly ever - they are in my pocket locked 90% of the time), with no remote, so the only really useful battery life measure for me is mine. I'd cheerfully tell it the answer (roughly (volts-3.6)*45 hours, as far as I can see), but there is noplace to feed this in.

[GSV3MiaC]

OK, I finally managed to wear down my M5L battery - took a heck of a long time. This was playing .ogg at Q=1, with very little user interaction (but some!). However it looks like I can't submit the results to the wiki page without registering, which seems like overkill for one battery log entry, so I'm paasting it here and hopefully someone can get it to where it is needed?

As you can see, some modification of the estimates is required - the battery was at >100% for 3+ hours, and the run time estimate was off by 3x for most of the duration of the test.

[attachment deleted by admin for age]

[Rincewind]

If you don't mind doing a custom build, you can try a patch I wrote recently.
I can't access Flyspray at the moment, Search for "runtime scaling", then you should find it.
If I can access Flyspray again, I'll edit this post for the link.

The Patch adds a new new menu option, where you can set the maximum runtime you get on average. This value is then used to scale the runtime display.
Should be exactly what you need.

I think that this patch is useful even after a rewrite of the powermanagement, because runtimes between players always differ due to wear of the battery.
I haven't got much feedback on the patch, yet.

[GSV3MiaC]

Thanks for the offer, but I don't have the time to mess with custom builds right now. I can apply my own scaling factor .. my runtime is ~88*(volts-3.6) hours, and I don't plan to ever get back down into the <3.7v area where it all goes pear-shaped (well, inverted bathtub shaped, really!).
 
This is with a (newish) 2250mAHr battery, so I guess a more general estimate would be 40*mAHr*(volts-3.6), which is close enough fo government work. I did poke the units a few times on the way though, including some changes to the playlist, and I didn't notice exactly when it died, so 2 days (48 hours) looks eminently possible. Well done Rockbox!!

You should be able to accomodate 'wear on the battery' by feeding in a lower mAHr number (there are lots of options, but nothing GREATER than 2250).