- Status Assigned
- Percent Complete
- Task Type Patches
- Category Battery/Charging
- Assigned To No-one
- Operating System iPod 5G
- Severity Low
- Priority Very Low
- Reported Version Release 3.4
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by Andree Buschmann - 2010-01-03
Last edited by Andree Buschmann - 2010-11-16
FS#10890 - Dynamic runtime estimation (iPod Video, iPod nano 2G)
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.
dyn_runtime_estimation_v01.pa...
(1.4 KiB)
This is an attempt to make your patch works on nano2g. The battery life estimation seems reasonable.
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.
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.
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.
Not if all targets implement it (and most just return a constant value, or maybe 1 of 2 constant values depending on backlight), no?
If all targets have an implementation (even when returning fixed values), it will of course work without a #define.
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.
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).
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?
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.
Updated patch against r29321. Use runtime detection via “probed_ramsize” to detect the dfferent iPod Video types.
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
The bootloader doesn’t have the ramsize detection code in it. The current reading code probably shouldn’t be built for the bootloader anyway.
I tried this solution.
Could you validate it, please?