Rockbox Development > Feature Ideas
Battery management while charging
blr_p:
--- Quote ---As I said, the power consumption is lower, so the battery capacity probably has dropped quite a bit. I expect it has way less than 80% of its original capacity now, but I don't really know; I can't easily battery bench it in the Apple firmware, and I'm not motivated enough to do it the hard way, and I don't exactly know what Apple's stated life is based on, so without measurements from when the battery was newer it's hard to work anything out.
--- End quote ---
Hmm i don't see any ipod video logs posted for the battery runtime plugin.
But RB can run on the ipod video ???
It seems the runtime plugin is not available in RB for the ipod video.
Damn, so it makes it harder now to tell how your battery deterioated over time.
I found out the battery specs i quoted in my previous post were for a 0.2C discharge load that means the battery runs down in 5 hours. That's what the graphs are referring to above. 0.2C appears to be a standard battery test.
So to interpret those graphs one must consider how long the unit takes to run down first. If its 10 hours thats a 0.1C load, if longer then even less, 15 hours is a 0.067C load.
The only way i know to get anywhere close to a 0.2C load is to play FLACS in a loop on the clip+. Otherwise with mp3s it will be longer so the load is more like 0.1C or even lower.
Am assuming a 0.1C or lower load will take longer (twice as long?)to kill the battery than a 0.2C load as its more gentle.
blr_p:
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---This just doesn't make any logical sense. If 4 hours a session is good enough for you and the full capacity of the battery is 15 hours of runtime, then you don't have a problem! You can use the battery however is convenient, and it'll be many many years before it's lost enough capacity that it can't deliver 4 hours any more. You are receiving no benefit from some complex scheme. Someone who wants to use the player for 12+ hours at a time might benefit from the battery having a longer life, but *can't achieve that* by having the charging behaviour change, because if they don't charge it as fully, or discharge it as fully, they can't get their desired runtime even while it's new.
--- End quote ---
This is a good point. I was fearing that the clip+ would be dead in about two years with normal use so was looking to see what could be done.
There is a fixed time before a battery gives up the ghost. You can use that time either in small chunks or use more in a go. I guess this is your point, that either way you end up with nearly the same amount of work. So i guess the deep DoD isn't going to make a tangible difference. Shorter DoDs are better though its not so mandatory.
So i guess an operating range from a charge level of 20 - 90% should be ok, not full DoD nor 100% charged, that's over 10 hours run time for a battery that can deliver 15h or 70% run time.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---The idea that you should have a battery that's 3-4 times the capacity you actually need is insane. Some devices happen to work out this way because their physical size/weight vs their power consumption allows for it, but most consumer electronics this is basically impossible: nobody makes a high end smartphone that lasts for most of a week on a single charge with regular usage, because you *can't do it* without making the device massive and heavy beyond what people will consider buying.
--- End quote ---
The idea comes from sizing lead acid batteries for a home UPS. Sizing is cost effective in this case as those batteries do not like deep discharges and cycle time can be considerably reduced.
A smartphone is two levels more complicated than a clip+. First there is the transmitter/receiver that needs to increase power as and when the signal weakens and ontop of that you might be doing some cpu intensive computing on it. A lot of unpredictable and heavy pulsed loads in concert. Not charging to 100% might help.
People aren't going to give up their smartphones, better battery tech is required here.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---And, again, if you *have* got a battery that's 3-4 times the capacity you actually need, then caring very much about the charging behaviour is a waste of your time because it will have way more capacity than you need for a *very* long time whatever you do: it takes an extremely large number of cycles to lose 75% of capacity no matter how deep those cycles.
--- End quote ---
ok, so i still have the point about not charging to 100%. Here is another article in favour.
--- Quote from: PCT ---Always maintaining a Li-ion battery in a fully charged condition will shorten its lifetime. The chemical changes that shorten the battery lifetime begin when it is manufactured, and these changes are accelerated by high float voltage and high temperature. Permanent capacity loss is unavoidable, but it can be held to a minimum by observing good battery practices when charging, discharging or simply storing the battery. Using partial-discharge cycles can greatly increase cycle life, and charging to less than 100% capacity can increase battery life even further
--- End quote ---
--- Quote from: PCT ---A 100-mV to 300-mV drop in float voltage can increase cycle life from two to five times or more. Li-ion cobalt chemistries are more sensitive to a higher float voltage than other chemistries.
--- End quote ---
That means choose whether to charge to 90% or as low as 70%.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---So, here's the next problem: our devices don't have "gauges". The batteries in almost all cheap consumer electronic devices do not have smart charging controllers built in, or even state-of-charge monitoring. The charge controller is part of the device, not the battery; it rarely stores any data whatsoever, and usually it's so dumb that you actually have to drive it in realtime in software to make it charge at all, which is why a lot of these devices can't charge without switching on. The percentage of battery displayed in Rockbox is not the reading from some gauge, it's just a guess based on the current cell voltage read by an ADC, compared to a hypothetical discharge curve that's hardcoded into Rockbox for that player. It completely ignores internal resistance because we haven't got a good way to model it. That same cell voltage is also used to decide how to charge the battery (which phase of charging to be in, etc).
Smart batteries with real state of charge gauges are generally only found in laptops. So, yeah, all your comments about gauges and calibration and so on are completely irrelevant, because those things *do not exist* on any of the hardware we're talking about.
--- End quote ---
Interesting, did not realise there was so much control of charging in user land, thought the devices firmware would be responsible and the only option available to RB would be charge to 100% or nothing.
This means you have to individually code a charging algorithm for each device RB is ported too, that is if you allow RB to do charging on that device in the first place.
Incidentally what criteria do you use to decide the battery is full and to stop the charging ? That the 4.2V is reached along with timing ?
If its hit and miss then not charging to 100% would be preferable.
Thing is the battery benches tend to be close to what the user expects assuming the battery is in good working order, not read any comments that the RB 'gauge' is wildly off so far.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---Yes, it's an anecdote. The point was it's an example of real-world capacity loss. "Testing data by a battery company" here actually means "some graphs put up by some company that makes expensive advanced battery chargers", which if you think about it is someone with a vested interest in making you think that battery charging is complicated.. :p
--- End quote ---
Ah yes what a conspiracy :D
--- Quote from: BU ---Chargers for cellular phones, laptops, tablets and digital cameras bring the Li-ion battery to 4.20V/cell. This allows maximum capacity, because the consumer wants nothing less than optimal runtime. Industry, on the other hand, is more concerned about longevity and may choose lower voltage thresholds. Satellites and electric vehicles are examples where longevity is more important than capacity.
--- End quote ---
Cadex caters to industry, not the consumer.
The CPF forums where the LED torch geeks hang out are crazy about analysers. Theirs is an even simple task than with PMP's with a nice DC load
I've got a MAHA for AA/AAA batteries and its been very helpful with knowing which batteries to use, pair with and maintain.
Not going to 100% is the only point that really matters with a PMP and i don't think that's very complicated in comparison.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---As I mentioned above, since there are no battery gauges in these devices, this is a waste of time and is just using your battery more for no reason. The Rockbox percentage is a completely fixed calculation and the only way to get it back "in sync" is to battery-bench your device with its battery in its current state, work out approximately what the discharge curve is as a result, and modify the source code with your readings.
--- End quote ---
Ah ok. So if i run battery benches every 3 months then that is what i have to do.
--- Quote from: torne on October 23, 2012, 05:38:23 AM ---Edit: Also, yaknow, I'm not stopping you (or anyone else) from implementing this and trying it, though obviously testing it objectively is going to be rather time-consuming and require comparing two devices. All I've tried to do is warn people that it may not be worth the effort. If you do implement it, test it, and can show that I'm wrong and the effect is significant, then that's great and I'll help you get your patch landed as soon as possible.
--- End quote ---
Comparing with another device is not possible, though ideal.
Can i prove to everybody here that this is a better strategy for longer battery life ? no, all i can do is point to the sources, reputable ones that say not charging to 100% is better. So i will do that for now.
There is an IEEE paper from 2006 that talks about the same thing but i've not been able to get a copy.
Getting it to the right amount so far turns out to be a matter of timing, its ~a half hour from 40-80% or a little more. Using a longer range needs to adjust accordingly.
If this idea ever makes it into the RB build, and the mistaken notion is created that RB has less runtime, because the charge level stops at a certain point, will that create a misconceptoin, that poor saratoga will have to spend a year explaining ;D
saratoga:
--- Quote from: blr_p on October 26, 2012, 12:11:59 PM ---
--- Quote ---As I said, the power consumption is lower, so the battery capacity probably has dropped quite a bit. I expect it has way less than 80% of its original capacity now, but I don't really know; I can't easily battery bench it in the Apple firmware, and I'm not motivated enough to do it the hard way, and I don't exactly know what Apple's stated life is based on, so without measurements from when the battery was newer it's hard to work anything out.
--- End quote ---
Hmm i don't see any ipod video logs posted for the battery runtime plugin.
But RB can run on the ipod video ???
--- End quote ---
FYI, the Ipod Video is also called the "Ipod 5G".
--- Quote from: blr_p on October 26, 2012, 12:11:59 PM ---It seems the runtime plugin is not available in RB for the ipod video.
--- End quote ---
Sure it is.
--- Quote from: blr_p on October 26, 2012, 12:11:59 PM ---The only way i know to get anywhere close to a 0.2C load is to play FLACS in a loop on the clip+.
--- End quote ---
FLACs on the Clip+ last almost 20 hours with a new battery, so you're closer to .05C. You'll never get up to 0.2C on an MP3 player, they use far too little power to discharge that quickly.
--- Quote from: blr_p on October 26, 2012, 12:11:59 PM ---A smartphone is two levels more complicated than a clip+. First there is the transmitter/receiver that needs to increase power as and when the signal weakens and ontop of that you might be doing some cpu intensive computing on it. A lot of unpredictable and heavy pulsed loads in concert. Not charging to 100% might help.
--- End quote ---
Thats no different then an mp3 player.
torne:
--- Quote from: blr_p on October 26, 2012, 12:11:59 PM ---
--- Quote ---As I said, the power consumption is lower, so the battery capacity probably has dropped quite a bit. I expect it has way less than 80% of its original capacity now, but I don't really know; I can't easily battery bench it in the Apple firmware, and I'm not motivated enough to do it the hard way, and I don't exactly know what Apple's stated life is based on, so without measurements from when the battery was newer it's hard to work anything out.
--- End quote ---
But RB can run on the ipod video ???
It seems the runtime plugin is not available in RB for the ipod video.
Damn, so it makes it harder now to tell how your battery deterioated over time.
--- End quote ---
You have misinterpreted what I said again. The battery bench plugin works fine on ipodvideo, as you should've been able to figure out from me saying I battery bench it often :) But you can't run the battery benchmark *in the Apple firmware*, because obviously Rockbox isn't running, so the only way to measure battery life in the Apple firmware is to actually time it manually while listening to the device so you know when it cuts out, and I can't really be bothered (plus I don't use iTunes, so I don't have any music on the player in a form that the Apple firmware can read). This means I can't compare the battery runtime it gets now to the *quoted* runtime from the device's specs, because comparing Apple's quoted runtime to Rockbox's current runtime is not a fair comparison: Rockbox is significantly more power efficient on this device, and so it will always get more runtime than Apple's firmware for *any* given state of the battery. The device was used for years by a friend before I came into possession of it, and they never used Rockbox, so I don't have any battery bench results for it that aren't from when I got it halfway through its life.
--- Quote ---I found out the battery specs i quoted in my previous post were for a 0.2C discharge load that means the battery runs down in 5 hours. That's what the graphs are referring to above. 0.2C appears to be a standard battery test.
So to interpret those graphs one must consider how long the unit takes to run down first. If its 10 hours thats a 0.1C load, if longer then even less, 15 hours is a 0.067C load.
The only way i know to get anywhere close to a 0.2C load is to play FLACS in a loop on the clip+. Otherwise with mp3s it will be longer so the load is more like 0.1C or even lower.
Am assuming a 0.1C or lower load will take longer (twice as long?)to kill the battery than a 0.2C load as its more gentle.
--- End quote ---
As saratoga pointed out we don't come anywhere near 0.2C load. FLAC is actually a pretty efficient codec, also; we have a number of codecs that need way more power than that. :)
torne:
--- Quote from: blr_p on October 27, 2012, 07:51:15 PM ---This is a good point. I was fearing that the clip+ would be dead in about two years with normal use so was looking to see what could be done.
There is a fixed time before a battery gives up the ghost. You can use that time either in small chunks or use more in a go. I guess this is your point, that either way you end up with nearly the same amount of work. So i guess the deep DoD isn't going to make a tangible difference. Shorter DoDs are better though its not so mandatory.
--- End quote ---
Yes, this is exactly my point. Your clip+ will, in all likelihood, still have perfectly good battery runtime after 5+ years of normal use. It probably will have a little more runtime after 5+ years of careful use with 20-90% charge cycles, but going out of your way to make sure you do this seems pointless to me because the benefit is really not that great.
--- Quote ---The idea comes from sizing lead acid batteries for a home UPS. Sizing is cost effective in this case as those batteries do not like deep discharges and cycle time can be considerably reduced.
--- End quote ---
Lead acid UPS batteries don't have to fit in your pocket, or be light enough to carry, so yes, of course in that environment you can buy as big a battery as you feel like, and getting one that's several times the capacity you think you will need is perfectly reasonable. This is a meaningless comparison to bring up in this context :)
--- Quote ---A smartphone is two levels more complicated than a clip+. First there is the transmitter/receiver that needs to increase power as and when the signal weakens and ontop of that you might be doing some cpu intensive computing on it. A lot of unpredictable and heavy pulsed loads in concert. Not charging to 100% might help.
--- End quote ---
This is exactly the kind of load you have on our devices as well, though. The CPU usage varies depending on what codec you are playing right now, and varies frequently during playback as well as the clock gets scaled up and down depending on the PCM buffer fullness, and powering the flash memory/disk/screen are the occasional high-current draws that come at not-entirely-predictable times that are much like radio transmissions :)
--- Quote ---ok, so i still have the point about not charging to 100%. Here is another article in favour.
--- End quote ---
As I've pointed out *numerous* times now, I understand perfectly fine how charging to the highest possible state of charge is bad for the battery and I've not said a single thing that contradicts this. I'm just going to ignore you continuing to repeat the same points.
--- Quote ---Interesting, did not realise there was so much control of charging in user land, thought the devices firmware would be responsible and the only option available to RB would be charge to 100% or nothing.
--- End quote ---
Rockbox *is* the device's firmware (except on Android devices and the yp-r0, where it runs as a linux app). There is no "user land"; all of Rockbox runs in kernel mode and there is no other software running on the device once Rockbox boots. Some devices have a hardware charge controller that handles the entire logic of charging (like the ipodvideo, in fact, which has a LTC4066), but other than those devices, we *have* to drive it manually. Even when there is a hardware charge controller, we generally still have the ability to tell it to stop charging (the code for this is present but not used on ipodvideo) since it normally has an input for that, though it would have to be based on our ADC reading for the battery voltage since the controller doesn't usually tell you anything about state-of-charge.
--- Quote ---This means you have to individually code a charging algorithm for each device RB is ported too, that is if you allow RB to do charging on that device in the first place.
--- End quote ---
Yes, on devices where charging is not handled entirely in hardware we have to write the whole thing.
--- Quote ---Incidentally what criteria do you use to decide the battery is full and to stop the charging ? That the 4.2V is reached along with timing ?
--- End quote ---
Different on different devices. We do what the datasheet says, or what the original firmware does, or what seemed to be a good idea after experimenting with it. I didn't write any of this code, so I don't know :)
--- Quote ---Thing is the battery benches tend to be close to what the user expects assuming the battery is in good working order, not read any comments that the RB 'gauge' is wildly off so far.
--- End quote ---
People complain about the battery percentage being grossly inconsistent quite often, and it's usually because they have an old battery that's built up a high internal resistance. But, they are usually complaining about devices that are well over five years old; devices like the Clip weren't released long enough ago to have experienced significant battery degradation yet to the point where users will actually notice the percentage being a bad indicator.
--- Quote ---Ah yes what a conspiracy :D
--- End quote ---
That wasn't really a serious comment; just trying to remind you that there are multiple sources out there with different experiences :)
--- Quote ---Comparing with another device is not possible, though ideal.
--- End quote ---
Sure it is, source two batteries from the same batch and install them in two identical players. I implied it was impractical, and it is, but it's quite possible. :)
--- Quote ---Can i prove to everybody here that this is a better strategy for longer battery life ? no, all i can do is point to the sources, reputable ones that say not charging to 100% is better. So i will do that for now.
--- End quote ---
Everybody here who knows anything about batteries already knows this is a better strategy for longer battery life. I know it. That's not what I'm asking you to demonstrate. I'm asking you to demonstrate that the practical impact on a normal user using their mp3 player in a normal way, with or without this charging change behaviour in Rockbox, is actually something that the user will notice as an improvement.
My experience messing with devices, the sources I've read (including your sources, which do not disagree with my knowledge/experience at all), and the anecdotes of people using Rockbox on devices that have used the same battery for many years, suggest that the effect is not big enough to be worth the trouble, for these devices. This does not mean that it's not actually an objectively better strategy, or that it doesn't have much bigger benefits on other devices with different battery management behaviours or different load profiles, or that we'd reject a patch that implemented this strategy as an option (in a clean and well-designed way). It just means that I'm not going to implement it for you, and that I'm not going to try and convince anyone else to implement it for you either :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version