Bugzilla – Bug 11619
Controller doesn't suspend consistently after r3993.
Last modified: 2009-09-08 09:11:54 UTC
I put two Controllers side by side and Caleb's script is measuring their voltage and recording every two seconds using the DLPIO8. I will upload the results when the 3993 Controller finally dies; right now the 4824 Controller is dead, the 3993 one looks to have about half its life left according to on screen meter. The plan is recharge and switch batteries then repeat the same test, once this one is complete.
Created attachment 5084 [details] Caleb's script log file Switched batteries between Controllers, now the 4824 lasts longer than 3993. Note that fully charged the batteries differ 4.06 to 3.91. Richard / Dean, what voltage should I expect to see from a fully charged brand new battery? Also, at what voltage should I expect the Controller to shut off? From what I see it looks like around 3.6V they shut down. Sadly this test may have not been complete, we experienced a power outage when the 3993 Controller was totally dead but the 4824 still had life left.
Sorry, I'm confused. Did the battery life move with the battery?
Yes Dean, I'll get a hold of some brand new batteries and try this again today.
Created attachment 5107 [details] 2nd test, new batteries 2nd run of this test. I got some new batteries from Diane and they both reported similar voltage with the meter at full charge. r3993 Controller started at 4.06v, r4824 started at 4.09. Unfortunately my PC suspended sometime during the test. Now the r3993 Controller is dead and reporting 3.48v (3.42 from DLPIO8), the r4824 Controller reports 3.71 (3.66 from DLPIO8) and shows about 1/4 left on the screen. I'll start this test once more tonight.
Created attachment 5132 [details] Ross's 2nd test data made all pretty with graphs and stuff
Ross, what is the goal with this bug now? What were we really trying to learn with this experiment? What action is left?
I can chime in here: - First we want to see the impact the fixes that richard put in to improve responsiveness (at the expense of some battery life) - Second we want to take this opportunity to understand the battery discharge profile over time and user activity and make sure we're making the right trade offs. Based on the last set of measurements, it looks like the first part is that the changes don't appear to have a significant impact, though we should probably measure the device with more use. I suggest a motion table to keep the device awake. And looking at the same charts, it seems that we can probably improve our overall battery life significantly by reducing the time-to-suspend in some cases. For this, I propose that we suspend after 5 minutes if woken from suspend without the user interacting with the device.
See also bug 11824
Created attachment 5150 [details] full battery test
Created attachment 5151 [details] first 3 hours
Created attachment 5152 [details] last 30 hours
Excel file is 40mb. A little more information. I started this test at 6pm on 4/17, I measured each battery (and labeled them) with the fluke meter: controller A battery 3 (4.093 fluke) controller B battery 5 (4.190 fluke) controller C battery 6 (4.098 fluke) controller D battery 7 (4.165 fluke) controller E battery 8 (4.129 fluke) controller F battery 9 (4.126 fluke) controller G battery 10 (4.174 fluke) controller H battery 11 (4.034 fluke) 1pm today here is the status of each Controller: A turns on, displays charge me! B turns on, 50% C turns on, 50% D turns on, 25% E won't turn on F won't turn on G turns on, 10-25% H won't turn on Controllers A through D are r3993, Controllers E through H are r4824.
Have confirmed findings on these versions of firmware. Suggestions for improving overall battery life now in bug 11824. Closing this one to point to 11824. *** This bug has been marked as a duplicate of bug 11824 ***
Turns out this is actually not a duplicate. There are two open battery issues currently. First this bug, 11619. Battery life is worse in r4824 than it is in r3993. It appears from the charts, particularly comment #10, that 4824 Controllers don't suspend after 60 minutes. The other bug 11824 is a more general bug about Deans changes we should make to default timers to improve battery life.
Would a log file of a unit that is not suspending on time be helpful, Richard?
Ross should we change the summary of this bug to 'Controller doesn't go into sleep on time' or something more specific?
Created attachment 5195 [details] first 50 hours of 3993 vs 5497 At 3.65-3.7 volts the Controller will no longer turn on. During this test I would wake the Controllers every 2 hours or so. 3993 Controllers wait 60 minutes to suspend, 5497 Controllers wait 20 minutes (while not playing). This chart shows the 3993 Controllers reaching non-waking voltage levels somewhere around 28 hours while the 5497 Controllers continue to wake up at the 50 hour point.
Created attachment 5196 [details] resized Sorry this is a more reasonable sized image.
Fixed in r5497, Controller now consistently suspends when it should with new timers. Bug 11824 to remain open for other general power consumption changes, namely how much and which direction movements to wake on. Also bug 11980 for newly discovered potential battery life shortening bug.
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.