Thread: Stop laptop battery from charging beyond certain point

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by cyberfish View Post
    I thought we had that settled long ago? Or I guess you just didn't read other people's posts... They optimize it for maximum battery life if you want to go mobile any time, at the expense of long term battery aging.
    And exactly how do you know that?
    Because some faux-authority "battery university" website said so?

    In fact the common sense goal --and the one most appear to have followed-- is to maximize per-charge usage time *without sacrificing the over all longiveity of the battery pack*.

    Once again... Having been in a position to observe battery life issues across hundreds of machines, I've not yet seen the case where running on AC power in any way degrades the longivity of the battery pack. Which is why post #1 on this topic labeled it a "non issue"...

    I seriously don't know what I can say to make you hear me. At this point I figure you're just arguing for the sake of arguing.

    That's what most people want, just not what I want, so I want to change it. This is not "second guessing". This is optimizing for another goal.
    No, that's called "making a mistake".

    Again... from experience with hundreds of notebooks... I've seen no evidence whatsoever that simply plugging them in on AC power and using them is going to have any meaninguful negative impact on the battery pack. It is not inherrently damaging to bring them to a state of charge and let them sit there, as you call it "in storage" while the machine operates dominantly from AC power. Modern charging circuits no longer continuously charge battiers... they are smart enough to shut off when the battery reaches about 95% of it's safe charge (and yes that number is taken from the service manual of the machines I worked with).

    In the scenario where the machine is used mostly on batteries, yes the battery life both overall and per-charge is going to slowly degrade with time. It is not possible to charge a battery without doing a little bit of damage, it's an expected fact of life. The "I use mine on batteries every day and after a year I only get 1/2 the specified time" problem does in fact occur and, yes, it is expected. As everyone here has cited there is a limit to how many times you can drain (under rather heavy current, btw) a battery pack then recharge it... They will eventually fail and that is an expected and ordinary part of that usage scenario.

    You are talking about one -- ONE -- charge... not hundreds.

    I am telling you this is a non-issue, just use the thing...


    What it appears you've gotten yourself hooked into --and cannot let go of-- is a bunch of BS magically transplanted from the days of NI-CAD batteries, recharged through an always-on circuit that did indeed damage the batteries. (As I tried to tell you, right up front)


    Engineering is applied science. Science is about what is the truth. Having 30 years of experience doesn't make you any more correct. So can we get over that and start talking about facts and verifiable knowledge, instead of using "I have years of experience" to counter any argument?
    Oh boy. If only I had a penny for every time some wet-behind-the-ears rookie tried to argue that experience means nothing in the face of pure science... only to call me on his *first* service call all humble asking me to come to his rescue.

    In fact one such call sticks in my mind as a perfect example: I was called to a location in another city a 1 hour drive away regarding a copy machine that simply would not come to life, the panel was lit up, the counters initialized but it would not make a copy. Our newly graduated, "I know more than all of you" genius technician had replaced every single board in that entire machine and was about to start pulling out motors and lamps... Everything in his totally theoretical knowledge base was telling him it was a controller board problem... but with his complete (embarrassing) lack of experience, he never once thought of the rather obvious: a blown motor fuse. 2 technicians, 4 hours drive time, 7+ hours of labour... and all that machine needed was a 3 amp fuse that would have been the first thing anyone with even minimal field experience would have checked.

    Like him, you are on the edge of a very eye opening experience... You are about to discover that all your fancy engineering training (and yes I've been through it all too) doesn't count for squat when you get out in the real world and start seeing how things actually behave in the customer's hands.

    Another example, this time pure engineering... The head office boys designed a new cash register, based on the Z-80 processor, marvelous machine, a real "top of the line" device for it's day with features many cash registers don't have, even now. When put into production and out into the field we started getting dozens of calls about "lock ups"... the machine would just die while the cashiers were using it. As soon as we realized this was a common occurance, happening sometimes 10 and 15 times a day, the engineers went after it full bore... They analysed the software, they did current checks on the power supply, they checked voltages and even did emulations of various failure modes. *Nobody* could explain it... In the end it was one of our techs from a branch office, 30 years in the field and near retirement who solved the problem... by placing an insufoil shield over the CPU chip. It seems nobody except this guy even considered the possibility of RFI from nearby transmitters causing lockups. Were it not for this one tech's extensive field experience, the problem would never have been fixed.

    As is the case with many beginning programmers we see on these boards... your books and statistics do not tell the whole story. The truth is that your degree in engineering has given you little more than a starting point, the first step into a very broad field where the actual experience you gather will be your best teacher.

    Only a complete fool would value textbook knowledge over the lessons of experience... and someday (hopefully) very soon, you're going to find that out the hard way.... We all do.

    I learned this lesson the hard way, as do most techs and engineers... Now, many years into this, I still learn from new experiences every day, my textbooks sit dusty on the shelf, used only rarely when I need to look up some obscure formula. Your "Science" doesn't hold a candle to the reality of what goes on in the real world, my friend.

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Argumentum ad verecundiam -- simple logical fallacy.

    I like the Latin because it sounds so...authoritative . You're a walking textbook of classical fallacies, Tater. I halfway believe you do it on purpose because you think it's funny. This is another interesting one:

    Argumentum verbosum

    Those two mostly work on kids and dimwits.

    Quote Originally Posted by CommonTater View Post
    In fact the common sense goal --and the one most appear to have followed-- is to maximize per-charge usage time *without sacrificing the over all longevity of the battery pack*.
    Never mind science, as I pointed out a long time ago, you can't even reason properly. This is an illogical point. It presumes there is a way to make the battery last forever, other than just leaving it in a freezer somewhere.

    Since that is not the case, just by using the battery you are "sacrificing the over all longevity". Like almost everything, the more you use it, the sooner it will wear out. And, how you treat it will also affect it's lifespan.

    Or maybe I can just store my batteries in a running microwave?

    It's not a water jug. Leaving it full will cause it to diminish in capacity more quickly. The manufacturers are happy to admit this, as phantamotap demonstrated, and perhaps a quick glance in your own manual might confirm.

    And exactly how do you know that?
    Because some faux-authority "battery university" website said so?
    It's not contentious. No one has refuted this information anywhere, except you, and you:

    1) Have a hard time making sense, and have failed to convince anyone that there is any value in your many years of being you.

    2) Have not cited even one single source to back up all your claims. If you are really the skilled and knowledgeable professional you claim to be, I'd think that would be easy. But apparently not.

    Maybe once you do actually get out in the real world, you'll figure it out.
    This is the real world. Someone should do a case study .

    Let me give you an example of the difference between "I own a toshiba laptop" and "I'm responsible for mantaining 250 toshiba laptops"... If you owned one of the ones we were working with you would blame yourself when you accidentally pushed the power plug into the case while trying to connect the charger... However, if you had to maintain 250 of them you would be able to identify it as a design flaw
    Really? Why would it take you that long? Why would it not seem like a design flaw the first time? It would to me. I'd say it was completely normal for normal people to spot design flaws in things they own one of. And completely normal for them to be correct.
    Of course, there could be a reason for that flaw, such as the trade-off between weight and strength. However, seeing as how you are not actually a toshiba engineer, I don't get how signing 100 or 200 or 1000 of them in and out of a closet would put you any closer to understanding why the design is the way it is unless you did some research. Which anyone else could do as well. I'm sorry if that undercuts the mystical value of all the time cards you punched.
    Last edited by MK27; 01-17-2012 at 05:26 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by MK27 View Post
    Really? Why would it take you that long? Why would it not seem like a design flaw the first time? It would to me. I'd say it was completely normal for normal people to spot design flaws in things they own one of. And completely normal for them to be correct.
    Of course, there could be a reason for that flaw, such as the trade-off between weight and strength. However, seeing as how you are not actually a toshiba engineer, I don't get how signing 100 or 200 or 1000 of them in and out of a closet would put you any closer to understanding why the design is the way it is unless you did some research. Which anyone else could do as well. I'm sorry if that undercuts the mystical value of all the time cards you punched.
    I have to say though, that one incident is insignificant statistically and would count as anecdotal evidence, it could be down to a coincidence etc. Where as having seen 250 incidents would provide some statistical credibility that the observation is not just a coincidence.
    Last edited by Subsonics; 01-17-2012 at 01:05 PM.

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Subsonics View Post
    I have to say though, that one incident is insignificant statistically and would count as anecdotal evidence, it could be down to a coincidence etc. Where as having seen 250 incidents would provide some statistical credibility that the observation is not just a coincidence.
    Are you sure that Tater's claim is not, in fact, essentially anecdotal?

    I would not expect toshiba to take action if just one person phoned this in, of course, and I totally agree that to some third party individual anecdotes are not as meaningful as statistical data. But there is statistical data, and then there is statistical data . I also doubt that toshiba would take action just because one person phoned in and said they personally had seen this 200 or 1000 times. The value of "statistical evidence" depends upon how it is gathered. Eg, if you took it to court, the fact that you had 200 busted computers would not be enough evidence unless you could provide further evidence that they busted because they were flawed.

    Evidence of that sort is about logic and empirical demonstration, not statistics. I think in mathematics there is the concept of proof, and proof is not about having 200 calculators that say 2+2=5.

    Identifying a design flaw is similar -- you need to find the flaw, not just the failures that imply a flaw. Statistical failures only imply the presence of a problem, and may help you to find it, but they do not prove that it exists.

    So my point was, if I broke a power jack on a computer in near darkness one night stumbling drunk while talking on the phone, I might regard that, as you say, as coincidence. However, if I broke it while paying full attention, being careful, in a sound state of mind, I would not have to do that more than once to recognize this mechanism is excessively delicate. Observing something 200 times does not necessarily make you a better observer.

    Statistics are also very prone to abuse and interpretation (because they are not hard evidence). Take your statistics with a grain of salt. CommonTater saying, "I've been in charge of 250 laptops" is a good reason to pay attention if he has an observation about laptops, but it is in no way proof that what he says is accurate, or to put your brain on hold while considering the possibility.

    So, in regard to the original topic,
    1) the statistical evidence online buries CT's (essentially anecdotal) sample.
    2) altho CT's statistics (if accurate) may imply a certain conclusion, a coherent theory and some logic is required to connect the two, and I have not seen that. Just the "argument to authority" stuff, and a lot of rambling. It is simply too easy to come up with any number of explanations why one person would have observed (or believe, or claim to have observed) a phenomenon in a particular context.
    Last edited by MK27; 01-17-2012 at 02:51 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Basic C help. charging battery DC RC circuit in series
    By yellowmania in forum C Programming
    Replies: 7
    Last Post: 11-28-2011, 10:29 PM
  2. Battery charging algorithm
    By bloody in forum C++ Programming
    Replies: 7
    Last Post: 10-07-2011, 12:44 AM
  3. Stop button doesnt stop a function (using PostMessage)
    By scwizzo in forum Windows Programming
    Replies: 7
    Last Post: 03-07-2008, 07:54 PM
  4. How does a battery die
    By BobMcGee123 in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 11-30-2007, 08:55 PM
  5. Do i need a new battery ?
    By Nutshell in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 04-06-2002, 04:20 AM