Rockbox

Tasklist

FS#10890 - Dynamic runtime estimation (iPod Video, iPod nano 2G)

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Sunday, 03 January 2010, 14:41 GMT
Last edited by Andree Buschmann (Buschel) - Tuesday, 16 November 2010, 07:06 GMT
Task Type Patches
Category Battery/Charging
Status Assigned
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This patch is a proof-of-concept for an adaptive runtime estimation.

Reason to implement such behaviour is that different user settings and user behaviour have large impact to the power consumption and -- as a result -- to the runtime. E.g. disabling LCD will save lots of power, but some users do not want to disable the LCD to keep readability in daylight.
This patch therefor adapts the estimation of runcurrent() based upon real measurements of the current consumption. The algorithm starts with a default (CURRENT_NORMAL which is defined in the config-file of each player) and uses a weighting scheme with a large time constant to adapt the estimation of the current consumption. The time constant is 1024, which should equal ~20 minutes as the runcurrent()-function is called once per second. With a smaller time constant the runtime estimation is "pumping" too much when the HDD is active.

This first version is just a hard coded experimental solution. Nevertheless something like an actual_current()-function can be implemented for each player in its own powermgmt-file. Players with capability to read the current will return this measured real current, all others still return the fixed default CURRENT_NORMAL.
This task depends upon

Comment by Laurent Papier (papier) - Monday, 18 January 2010, 21:55 GMT
This is an attempt to make your patch works on nano2g. The battery life estimation seems reasonable.
Comment by Andree Buschmann (Buschel) - Thursday, 25 March 2010, 20:05 GMT
Updated the patch with the following changes:

- introduce a new define "HAVE_DYNAMIC_RUNTIME_ESTIMATION"
- introduce a new interface function "read_battery_current()" to powermgmt.h
- implement read_battery_current() for iPod nano 2G, iPod Video and for PCSim
- use read_battery_current() for current estimation (low pass filtered with time constant = 1024 sec)
- use read_battery_current() in debug_menu.c

This implementation easily allows to add this functionality to other targets.
Comment by Thomas Martitz (kugel.) - Tuesday, 26 October 2010, 12:16 GMT
What's the reason for HAVE_DYNAMIC_RUNTIME_ESTIMATION? In your first post you said targets that can't have would just return a constant value in read_battery_current(). I think that's a good idea and doesn't need the define.
Comment by Andree Buschmann (Buschel) - Tuesday, 26 October 2010, 19:56 GMT
We need at least a #define that tells us whether there the target has an implementation to read the battery current. This #define would best be located in the config.h, at least from my point of view.
Comment by Thomas Martitz (kugel.) - Tuesday, 26 October 2010, 20:10 GMT
Not if all targets implement it (and most just return a constant value, or maybe 1 of 2 constant values depending on backlight), no?
Comment by Andree Buschmann (Buschel) - Wednesday, 27 October 2010, 05:56 GMT
If all targets have an implementation (even when returning fixed values), it will of course work without a #define.
Comment by Thomas Martitz (kugel.) - Wednesday, 27 October 2010, 07:45 GMT
I'm thinking this patch could also be useful on targets which don't report exact values. I don't know how it currently works but your patch seems to filter out short backlight ons (e.g. when changing tracks) when the target would report a higher current when the backlight is on.
Comment by Andree Buschmann (Buschel) - Wednesday, 27 October 2010, 18:58 GMT
Yes, it filters with a large time constant to allow usage on HDD targets as well. The current patch does of course not allow to use recording or backlight gain for targets without an implemented current measurement. Of course it could be implemented as well, but most of those currents are more or less useless (those were either taken over from other targets or roughly estimated).
Comment by Rosso Maltese (asettico) - Wednesday, 16 February 2011, 12:31 GMT
The patch applies but I got the following error:

firmware/target/arm/ipod/powermgmt-ipod-pcf.c:140:32: warning: "MEM" is not defined
firmware/target/arm/ipod/powermgmt-ipod-pcf.c:142:32: warning: "MEM" is not defined
firmware/target/arm/ipod/powermgmt-ipod-pcf.c:145:6: error: #error HAVE_DYNAMIC_RUNTIME_ESTIMATION defined without adc routine known.

I know that now there is no differences in code for the 32 and 64 MB ipodvideo, but the code in that point differs for the two models.
What is the right one?
Comment by Andree Buschmann (Buschel) - Wednesday, 16 February 2011, 14:18 GMT
The patch is outdated as it still makes use of different iPod Video builds. There have been changes to recognize both iPod Video variants at runtime which need to be backported to this patch.
Comment by Andree Buschmann (Buschel) - Wednesday, 16 February 2011, 19:53 GMT
Updated patch against r29321. Use runtime detection via "probed_ramsize" to detect the dfferent iPod Video types.
Comment by Rosso Maltese (asettico) - Wednesday, 23 February 2011, 07:35 GMT
Building the bootloader, I got this error:

firmware/target/arm/ipod/powermgmt-ipod-pcf.c: In function ‘read_battery_current’:
firmware/target/arm/ipod/powermgmt-ipod-pcf.c:141: error: ‘probed_ramsize’ undeclared (first use in this function)
firmware/target/arm/ipod/powermgmt-ipod-pcf.c:141: error: (Each undeclared identifier is reported only once
firmware/target/arm/ipod/powermgmt-ipod-pcf.c:141: error: for each function it appears in.)
make: *** [build_bootloader/firmware/target/arm/ipod/powermgmt-ipod-pcf.o] Errore 1
Comment by Torne Wuff (torne) - Wednesday, 23 February 2011, 10:43 GMT
The bootloader doesn't have the ramsize detection code in it. The current reading code probably shouldn't be built for the bootloader anyway.
Comment by Rosso Maltese (asettico) - Monday, 07 March 2011, 17:01 GMT
I tried this solution.
Could you validate it, please?

Loading...