That may help - but, I tested in kernel-power v48, online, and when I couldn't kill the damn thing at 2:30am, I set it playing a video for the last hour or so until it died, while monitoring bq27200.sh over Wifi. It dutifully set EDV1 to 1 as it crept down below 3248mV for more than 15 seconds / 3 or 4 iterations of the script, and died about a minute afterwards. That's with video playing and wireless in active use, current drain around 300-400mA...

(As Estel says, I'll get a higher LMD discharging more slowly, and that's planned now that the SCUD is charged up again...)

I'll wait for the experts, but this suggests to me you're getting a more sudden or dramatic voltage drop than I am...

Sorry if this has been answered, but will the battery patch I see available work well with batterymeter (I have the mugen).

Magic, it's interesting to see you managed to get it below 3248 for 15 seconds on high usage, and single battery, without bme disabling phone.

I got different approach - when being close to discharge end (~3300 mV) I try to gradually lower power consumption - offline mode, screen as dim as it's possible, etc (not everything at all - first, off-line mode - voltage jump a little - when it reach 3300 mV again, I start to dim screen, etc).

This way, I'm approaching 3248 very slowly, and succeed all the time. Another approach is to use (as root)
ho ever, in my case, it always instantly switch vdq to 0, screwing whole calibration just before the end Ho ever, enabling H-E-N (no need for connecting anything, just enable application interface) also stops bme - maybe it's doing it different way and don't screw vdq, but I've not checked it.

It's quite strange, all that mess with bme - some users report that it disable device around 3180 mV, other that around 3300 mV. Using dual scud and very slow voltage drop, my phone usually shuts down 15-30 seconds, after edv=1 - so, it's literally around 3240. My guess is that bme shutting down device decision isn't based only on voltage - using higher discharge current, I'm able to get ~3150 voltage (but, phone shuts before 15 seconds required, from reaching @ 3248).

Anyway, plenty of options to try. From my experiences, slow end of discharge is most efficient (works 100% times), but using HEN to disable bme may be also an option.

BTW - if phone is under 3300 mV (approximately, hard to check exactly) and bme is started again, it will shut phone down unconditionally after ~20 seconds, no matter if voltage actually fall down or rise. I don't know why it behaves like that, trying same command (bme stop, bme start) @ higher voltage (so, higher SoC) doesn't result in shutting down. I suspect that bme got some hardcoded voltage value, and if detect that on start, turn red alert on and shuts down phone. the same voltage doesn't result in shutting phone down, if bme wasn't started at such low voltage (i.e. running for some time, from higher voltage).

Even closing HEN interface @ ~3300 mV (below, likely) result in such event of bme shutting device down.

---

So, it may be little complicated to get edv=1, and IMO it's hardest part. Ho ever, after mastering it, it's not a problem at all.

I'll check if using H-E-N to disable bme result in vdq=0 on my next discharge. If no, I'll dig to command used to stop bme there.

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?

Estel PM me the whole proceidure and ill add it to post #1, 2 or 3 and you can then when you update it PM me the update and i will add it and then you can post that an update has been made.

@magick777

Nice idea, and it *seems* to be doable via some smart scripting, even via .sh. Examining shadowjk's script reveal that "magic" can be done there ho ever, it's far beyond my skills for now. Still, it's nice idea to learn some scripting on it, so I'll try. But, don't expect working version from me in this millenia So, if anyone able is interested, do not hesitate.

@dr_frost_dk
All right, just let me first audit my own instructions (link is in the end of my signature, btw) for possible mistakes and outdated info. i'll do that after some sleep And PM it to You. Still, it's going to be quite long, if we want it to be understandable to *almost* (trisha, stay away) any TMO user...

I've checked calibrating with:
...at close to end-of-discharge, and this time it worked. So, i was piece of cake to achieve edv=1. I don't know why in the past it always turned my vdq=0, but, apparently, it's working now. After that, I've just rebooted device, to avoid hard-reboot on start bme (as I've said, it only happen on low voltage).

---

I've also prepared some scripts that You may find useful - first one, bnf.sh, display nice pop-up notification with most important data from i2cget (just as bq27200.sh - it's based on work by shadowjk, but you don't need to open terminal window), and it only show relevant data (for example, doesn't show charger type when you're not charging at all). It can be called upon from desktop shortcut, or mapped to one of hardware buttons (for example, camera key half-press, or proximity sensor outside calls), via ShortcutD.

I find it useful to get on-glance info about fuel gauge + get info about current used when working inside full-screen applications, via ShortcutD (notification pop-up goes through fullscreen, without putting you into task manager).




To install, unpack, and (as root) put files in correct places:
---

Another script is shadowjk's bq27200.sh with very little, but usable modification by me - when used in loop mode ('bq27200.sh 5'), it additionally show vdq status. So, You don't need to use 2 instances of bq27200.sh - one in loop, and one normal - to constantly monitor voltage and edv1 status, and at the same time to check if your vdq wasn't screwed meantime.

To use this one, just unpack, and replace your current bq27200.sh script (only change is that one regarding vdq status display in loopmode). If You don't have bq27200.sh, just (as root):
Both archives are downloadable from attachments.

My testing suggests that the limit per cycle is actually 1/8 (12.5%), not 1/6. My new N900 when I got it had a stored LMD of 2003mAh, and I am in the process of calibrating it to a Scud battery that previously tested on the old phone at 1471mAh.

After the first valid discharge, it set LMD to 1753mAh, a reduction of 12.5% (1/8) on the previously stored figure of 2003mAh. After the second valid discharge, it has now set LMD to 1534mAh, a reduction of 12.5% (1/8) on the previously stored figure of 1753mAh. This is too precise to be coincidence, so I think it'll need a third run before I get a true figure for the SCUD.

Nice catch magick. I'll update original post.

The "correct" place for those would be in /usr/local/sbin/ as they do not come from deb-package but are manually installed.

And I do not know if it is fixed already, but calls to i2cget should maybe not be hard coded to ./i2cget but without path so i2cget can be anywhere in $PATH.

"/usr/local/bin" and "/usr/local/sbin" can be added to the $PATH of the uid root in /root/.profile