Support and General Use > Hardware

Battery preservation (esp for clip+)

(1/2) > >>

lorriman:
If it is possible to stop the charging process in software then I have a suggestion for avoiding the depleting of li-on battery capacity. This is particularly an issue for those of us using the clip or clip+ which will become unusable relatively quickly.

Li-on and li-poly batteries loose capacity at 25% per a year at room temp when charged at between 60%-100%. By keeping charge below 60% one can usefully preserve the capacity of the battery.

I try to pull my clip+ out when I see it is about half full but more often than not I forget or miss it. A software solution to limit the charging would be fantastic for those us who listen to our gadgets less frequently.

saratoga:

--- Quote from: lorriman on March 10, 2011, 04:52:05 PM ---If it is possible to stop the charging process in software then I have a suggestion for avoiding the depleting of li-on battery capacity. This is particularly an issue for those of us using the clip or clip+ which will become unusable relatively quickly.

Li-on and li-poly batteries loose capacity at 25% per a year at room temp when charged at between 60%-100%. By keeping charge below 60% one can usefully preserve the capacity of the battery.

--- End quote ---

I think its actually by keeping it from discharging below 40%, so you would go from 100% (or maybe a little less) then turn off at a little less then half discharged.  Usually deep discharging lipoly batteries is what kills them, not charging them.  But the basic idea you have is sound.  If you use less of the batteries capacity it will last a little longer.

And yes, this is all controlled mostly in software.    See:

(definitions)
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/powermgmt-target.h
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/export/as3514.h

(code)
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/powermgmt-ascodec.c

You should be able to set the thresholds to more conservative values if you want to experiment with giving up battery life in exchange for somewhat better lifespan on your battery.  Personally though I think our present values are fine. 

lorriman:
I had understood that while 40% is optimal (while also avoiding deep-discharge in storage/pre-sale) that up to 60% still saves significant capacity.

I might try that code.
Post Merge: March 10, 2011, 05:37:09 PMSaratoga, since my claim contradicts yours here is a reference :

http://batteryuniversity.com/print-partone-19.htm

Wikipedia summarises this as follows:

"A Standard (Cobalt) Li-Ion cell that is full most of the time at 25 °C (77 °F) irreversibly loses approximately 20% capacity per year. Poor ventilation may increase temperatures, further shortening battery life. Loss rates vary by temperature: 6% loss at 0 °C (32 °F), 20% at 25 °C (77 °F), and 35% at 40 °C (104 °F). When stored at 40%–60% charge level, the capacity loss is reduced to 2%, 4%, and 15%, respectively." http://en.wikipedia.org/wiki/Lithium-ion_battery#Cell_life

torne:
This will pretty much never make any difference unless you intend to leave the device on the shelf for *months at a time* without using it. For any remotely plausible usage pattern for a consumer device, basically nothing you can do will make any difference to the rate at which the battery capacity declines by a noticable amount.

lorriman:
I'm not too worried about the average user: for me a 50% max charge gets me roughly 7 hours of playback and a battery that will last much much longer. 7 hours is more than enough (I rarely use it for more than 3 hours a day). It also means that I can forget about my clip+ for extended periods without significant battery loss. Even if that were to mean simply every other day (of no use) that, I think, is significant battery preservation. The level of max charge could be user selectable: even a 60% max charge (15% pa preservation) I think is worthwhile and practical.

But as for the average user: which particular average user where you thinking of? ;)

Navigation

[0] Message Index

[#] Next page