Bug 12419 - Power management support
: Power management support
Status: CLOSED FIXED
Product: SB Radio
Classification: Unclassified
Component: Power Management
: Include FW version in comment
: PC Windows XP
: P1 normal (vote)
: 7.4.0
Assigned To: Richard Titmuss
:
Depends on:
Blocks: 13280 13398
  Show dependency treegraph
 
Reported: 2009-06-17 12:08 UTC by Richard Titmuss
Modified: 2009-10-05 14:26 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Titmuss 2009-06-17 12:08:28 UTC
"Copy Jive battery management features: status reporting, turn off after paused for 2 hours, support suspend mode, turn off if battery voltage low, no DDR2 memory refresh"
Comment 1 Pat Ransil 2009-08-03 15:13:58 UTC
changing to p2 because we wont have batteries in the field until october
Comment 2 Richard Titmuss 2009-08-04 05:14:02 UTC
Changing back to a P1, as batteries will be available for reviewers, etc. We also need to QA the battery charging, etc. works and that takes time.
Comment 3 Richard Titmuss 2009-08-04 05:16:51 UTC
Battery monitoring (icon in status bar) added in r6896. This also adds lcd screen dimming after 30 seconds on AC and battery (to be reviewed).
Comment 4 Richard Titmuss 2009-08-05 08:13:57 UTC
Updated hours worked, I started on this at the beginning of the week.
Comment 5 Richard Titmuss 2009-08-14 02:50:45 UTC
Questions/answers from Richard/Caleb:


>is a battery installed?
You can tell one is installed by looking at battery_voltage, battery_vmon1_voltage, battery_vmon2 voltage.  If they are above a volt, the battery is installed.

The readings are in millivolts.


> are we using battery or AC power?

AC power any time AC is installed.
Battery power when AC is removed.
Solar power when both are removed.


>is battery charged?
That will need to be a separate flag from the MCU, since it's dependent on temperature, not voltage. (not implemented)


>is battery charging?
flag from mcu (not implemented)


>what % of battery is left (when on battery power)
battery_charge/battery_capacity.  But this is an estimate that can be way off during the first charge cycle or two.

>does the firmware need to worry about battery_disable or battery_tempreture?
You will need to disable charging when pumping out very loud music.  But, as I said, the worst that can happen is the PSU shuts down, and the system continues running from the battery.

It should be pretty seamless.




> # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/wall_voltage
> 18080
> reading in what, what range is valid?
That's in millivolts.  Looks like you have a pretty spot-on 18V.


> i see 18xxx returned when on ac power
> falls to around 10xxx when ac power is removed, reduces over time to around 98xx
Hmm, you're still reading 10V from wall voltage when AC power is removed.  Interesting.
could be.  

Any time wall_voltage is below 17 volts (17000) you can assume the AC adapter has been removed.  

You might want to use 16500 just to be safe.



> # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/battery_capacity 
> 2000
> maximum value i would expect to see in battery_charge?
> does this value change while booted?
The capacity will be a dynamic capacity estimate, based on how long it takes to charge & discharge.  It's supposed to be in mAH.  Proabably not something that the user needs to be exposed to, but I figured we needed to use *some* units, so mAH was as good as any.


> # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/battery_charge 
> 1986
> amount of charge in battery, battery %age = (battery_charge / battery_capacity) * 100
> is 0 is no battery installed

No battery instaled is when battery_voltage < 1000.  
battery_charge == 0 means there's no charge left in the battery.  But it can be off, especially on the first few charge cycles.



> does battery_charge = battery_capacity when on ac power and battery is fully charged
ideally, that's true.  But again, both of those are estimates that should improve over a few charge cycles.  (once charging & power consumption is sorted out)

> had battery in, report 1986 for charge.
> removed battery, powered off, power on, plugged in battery. then reports 1005 for charge, and > rising.
Ah, if you remove the battery, it doesn't know how much charge is in the battery when you plug in a new one, so it assumes 50%.  This should be fixed to be more accurate.

Perhaps a community member with multiple batteries can write a plugin to manage multiple batteries :-)  But for the moment, we assume 1 battery/baby.



> how safe is battery charging? ok for kids, no exploding babies (having just read an article on 
> exploding ipods!)
No, NiMH batteries don't explode.  That's one of the main reasons we went with NiMH.  And now there's even a timer in place so that chargin will terminate after a while.  

I'll implement temperature based charging soon, so it won't get too hot either.


> when does msp430 shut the system down on a low battery? when battery_charge = 0?
No, when any battery cell shows 1V/cell or less.  So, this is (when battery_voltage-battery_vmon2_voltage) <= 4000, battery_vmon1_voltage < 3000, (battery_vmon2_voltage - battery_vmon1_voltage) < 3000


> is battery_charge linear?
It should be, yes.


> can IR be used as a wake up source?
Good question... I forget what we decided on that one :-)
Yes, we should be able to maintain IR on for a month on a pretty discharged battery.  (83 days for a fully charged battery), so, wake on IR shouldn't be a big deal.


> if they don't make sense i can tidy them up, otherwise i've let you know :-D
Yep, makes sense.
Comment 6 SVN Bot 2009-08-28 06:55:39 UTC
 == Auto-comment from SVN commit #7302 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7302 ==

Bug #12419
Fixed bug #1320
Fixed battery icon state. This code will work with the next revision of the msp430 code (after Caleb's made 
some changes).
Comment 7 SVN Bot 2009-08-28 06:57:13 UTC
 == Auto-comment from SVN commit #7303 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7303 ==

Bug #12419
Capture an error condition.
Comment 8 SVN Bot 2009-08-28 08:26:05 UTC
 == Auto-comment from SVN commit #7306 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7306 ==

Bug #12419
More power management updates.
Comment 9 SVN Bot 2009-09-02 01:48:09 UTC
 == Auto-comment from SVN commit #7365 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7365 ==

Bug #12419
Toggle POWER2 key on msp430 power events. This is a hacky, but convinent, way to signal these events to the application.
Comment 10 SVN Bot 2009-09-02 01:49:05 UTC
 == Auto-comment from SVN commit #7366 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7366 ==

Bug #12419
Pass POWER2 keys (signalling power event) to the lua application.
Comment 11 SVN Bot 2009-09-02 04:14:17 UTC
 == Auto-comment from SVN commit #7368 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7368 ==

Fixed Bug #13757
Fixed Bug #13280
Bug #12419 +4
Battery updates, improved battery status and low battery behaviour.
Comment 12 SVN Bot 2009-09-02 04:20:39 UTC
 == Auto-comment from SVN commit #7369 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7369 ==

Bug #12419
Turn off testing code.
Comment 13 SVN Bot 2009-09-02 09:34:39 UTC
 == Auto-comment from SVN commit #7377 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7377 ==

Bug #12419
Refactor the battery check for firmware updates. This allows different checks for jive/baby.
Comment 14 SVN Bot 2009-09-02 10:03:36 UTC
 == Auto-comment from SVN commit #7379 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7379 ==

Bug #12419
Fixes for battery low firmware update check.
Comment 15 SVN Bot 2009-09-02 11:07:42 UTC
 == Auto-comment from SVN commit #7382 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7382 ==

Bug #12419
Fix jive firmware upgrades.
Comment 16 Richard Titmuss 2009-09-03 04:16:18 UTC
The following power states are supported:

ACTIVE
  The user is interacting with the system, everything is on.

IDLE
  The user has stopped interating with the system, the lcd is dimmed.

SLEEP
  A low power mode, the power amp is off.

HIBERNATE
  Suspend to ram. Not currently supported on baby.


State transitions (with default times):

* -> ACTIVE
  Any user activity changes to the active state.

ACTIVE -> IDLE
  After 30 seconds of inactivity, player power is on

ACTIVE -> SLEEP
  After 30 seconds of inactivity, player power is off

IDLE -> SLEEP
  After 10 minutes of inactivity, when not playing

SLEEP -> HIBERNATE
  After 1 hour of inactivity
Comment 17 SVN Bot 2009-09-03 04:18:45 UTC
 == Auto-comment from SVN commit #7398 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7398 ==

Fixed bug #12419
Fixed bug #13398

Extended baby's power management states. Turn off the PA after 30 minutes of inactivity, or when then player 
is in the off state.
Comment 18 James Richardson 2009-10-05 14:26:40 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.