Bugzilla – Bug 11824
Improve battery life on Controller
Last modified: 2009-06-17 09:37:22 UTC
Ross' battery life measurements (please attach the chart to this bug) make me think that we need a few changes to the way we do power management. While the device is connected to the LAN (i.e. not suspended), there are only 3-4 hours of battery life in the device. This means, with an hour delay before suspend, you can only touch the device and wake it up 3-4 times before the battery dies. I suggest: 1. Make the device less sensitive to movement when waking up. The accelerometer is too easy to trigger. 2. If the device is awakened, but there's no user activity (i.e. no buttons are pressed), put it back to sleep quickly. Right now it stays awake for an hour. It should just be a couple of minutes. 3. The default time to suspend is too long, currently at an hour. That should be at least cut in half.
Created attachment 5139 [details] WARNING LARGE FILE: complete data and graphs in excel spreadsheet
Created attachment 5140 [details] PNG of the main graph, with annotations
Comment on attachment 5139 [details] WARNING LARGE FILE: complete data and graphs in excel spreadsheet complete data and set of graphs
See also bug 11619
*** Bug 11619 has been marked as a duplicate of this bug. ***
Created attachment 5157 [details] image showing bug 11619 You can see here quite a lot of energy is used in the 60 minutes the Controller is not suspended. Dean's suggestion of reducing the time to suspend to 30 minutes seems like an easy way to improve battery life. It takes about 20 seconds to come out of suspend, a reasonable wait after 30 minutes in my opinion. Also in Dean's first comment here he says sleep after 60 minutes, he means suspend.
The accelerometer can be tuned by modifying the following lines in /etc/init.d/suspend: echo "4" > /sys/bus/i2c/devices/0-001c/duration echo "20" > /sys/bus/i2c/devices/0-001c/threshold
(whoops, didn't meant to submit the last comment) The accelerometer can be tuned by modifying the following lines in /etc/init.d/suspend: echo "4" > /sys/bus/i2c/devices/0-001c/duration echo "20" > /sys/bus/i2c/devices/0-001c/threshold If you look in the datasheet, the device is configured with FS=0, ODR=100Hz. The 'threshold' range is +/- 2.0g, with 16.2 mg/digit accuracy. So to wake out of suspend a movement of 65mg is required. The 'duration' ranges from 0 to 2.55 sec in 10 msec steps. So to wake out of suspend the threshold needs to be exceeded for 40ms. An easy way to test the settings is using 'evtest /dev/input/event3 &' (over ssh is better than a serial dongle for this test). When the Controller is moved then you'll see output when the set threshold and duration are exceeded. Using 'echo' to set different parameters on the command line allows experimentation with the values.
In 7.3 r5489 a new configuration parameter is exposed FF_WU_CFG1. This controls which axis movement is required in for an interrupt. Possible values include: 106 - movement in X,Y or Z axis (existing default) 96 - movement in Z axis only (up/down) 72 - movement in Y axis only (forward/back) 66 - movement in X axis only (left/right) 232 - movement in Z AND Y axis After a little experimentation I think we should try these values (in suspend mode): # cat /sys/bus/i2c/devices/0-001c/config 96 # cat /sys/bus/i2c/devices/0-001c/threshold 10 # cat /sys/bus/i2c/devices/0-001c/duration 12 This only responds to movement in the Z axis (so knocks on a table should not wake the Controller up), means the movement has to be longer (120ms), but reduces the force of movement required. This changes has been made in 7.3 r5492. Note to test the suspend settings from the command line you can do /etc/init.d/suspend, to suspend the Controller.
Improved hueristics for power management in 7.3 r5497. 1. The default time to suspend has been reduced, to 40 minutes when the playmode is 'play' (eg when the player being controller is playing), and 20 minutes at other times. 2. Motion does not prevent the device from suspending. You actually have to use the buttons/wheel to keep the Controller awake. This prevents accidental motion from keeping the controller from suspending, and also allows the controller to suspend quickly if accidentally woken up.
Created attachment 5172 [details] first 7 hours of 5497 testing This looks really good, I'll leave it up to you guys to determine when this bug is fixed, but to me it looks like it's there. I woke all 8 Controllers 3 times in this graph, you can see the 3993 Controllers took 60 minutes to suspend, and the 5497 Controllers took 20 minutes. More importantly, they're actually going into suspend when they should. That makes me feel like 11619 is resolved as well. Well done Richard!
Created attachment 5173 [details] tif fail
So are we waiting on anything else to mark these bugs as 'Resolved?' Please follow up today. Thanks!
Created attachment 5184 [details] crappy image of all 8 controllers over 114 hours I woke the Controllers roughly every 2 hours for the first two days, then over the weekend let them die. The first 4 are 3993, second 4 are 5497. Better data tomorrow.
Created attachment 5192 [details] first 8 hours
Created attachment 5193 [details] first 53 hours
Created attachment 5194 [details] whole 114 hours
Are we there yet, Dean?
More clarification: at 3.7v the Controller won't turn on any more, as measured by the DLPIO8 that can show up as around 3.65v. So when the graph hits 3.65 the Controller is no longer usable. Also the first 4 Controllers are 3993 firmware, second 4 are 5497.
*** Bug 11945 has been marked as a duplicate of this bug. ***
Fixed in 7.3 r5918. This change reverts the wakeup settings to the existing values, as requested by Dean.
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.