View Single Post
Posts: 167 | Thanked: 204 times | Joined on Jul 2010
#984
Estel, I'm wondering if we couldn't find some way to automate (and thus to standardise) a testing and/or calibration procedure, based on your instructions. Initially, I'm thinking about a script that would
  • preemptively disable bme
  • charge battery using charge.sh until full, then stop charging and prevent recharging
  • monitor discharge of battery until EDV=1, optionally helping it on its way with a standardised (as far as possible) artificial load.
  • on EDV=1, immediately reenable charging assuming we still have a wall charger, die if not
  • re-enable bme if and when we detect it is opportune to do so

and I can see it having two or three separate use cases:
  • non-invasive calibration of bq27200 to a new battery, during normal operation of the handset
  • deliberate preconditioning of a new battery around the top and bottom of the charge range, whilst allowing a normal day's use in between, possibly with a user-initiated, end-of-day "kamikaze" discharge procedure.
  • recursive "burn-in" testing, calibration and/or pre-conditioning of a dedicated phone and battery that isn't doing anything else, for geeks, testers and people with multiple phones.

Would this be of interest to anyone? Are there any compelling reasons this doesn't work, or has not been done already? I might be happy to have a go at it, if we think it would be useful, but I don't know whether we can get it to fail gracefully if our battery dies along the way. Any thoughts?