Forced shutdown occurred at 7:40AM under idle conditions, minimum brightness, wifi on and screen allowed to blank between checks.
This is less than an hour off where the calculator pinned it, and as mentioned, this is easily accounted for by the lack of "understanding" it had because of consumption shift.
It was never meant as a rock solid accuracy piece, just a WYSIWYG to estimate its rough charge.
There is a known fatal flaw in the accuracy of the code anyway - when it is plugged in to charge, the power has to be on for it to estimate both SoC and time remaining to charge completion, which is actually rather accurate, probably because the current is more or less steady throughout the charge process. Even though its still using the discharge calibration profile to calculate, it is remarkably accurate (I believe) because the calibration run was pretty much level, with a few spikes from progress checks.
If it is plugged in to charge without power on, the code obviously can't track the charging (since the battery firmware isn't involved), and so the calculator gets confused and displays BS information when it is brought up.
The code does however "self-align" when the charge current drops below about 10mA, which triggers the SoC counter to be cloned from the calibration value, setting it at 100%. So if the battery is allowed to fill up before boot, or when the current drops low enough while on, the counter resets and can once again be roughly trusted.
This isn't a really big deal, because I can tell within about 10% where it sits just by pulling up the voltage graph (both tables get filename date/time stamps and saved, then reset at boot time to provide clean graphs for that session). As you can see above, the discharge curve is relatively linear, at least for now. This might of course change as the pack ages. Time will tell, and that's what this thread is about.
BEGIN "BRUTAL" EDIT
One other note about this entire concept... For anyone who wishes to attempt this, there are some caveats that may not be immediately obvious.
First, I can't say for certain, but in theory, this works on any laptop. In the past, I have even monkey rigged a dummy pack or two to run 11.1V nominal systems directly from FLA. Clumsy, but it worked.
There is a big problem tho (at least with the Asus, I'm assuming any other modern-ish laptop would play roughly the same game) - Battery management by OEM designs involves a chip in the battery that tracks charge and discharge, and is polled by the operating system to get metrics for SoC and the like. This chip however (at least in this particular pack) does not understand what has happened here, and therefore has no clue how to predict the battery's state. In the case of Asus specifically, there was an additional bug in the firmware that was eventually uncovered that caused premature failure of the battery because the charge process would terminate before the battery actually reached full charge. The result is that the OS displays premature failure warnings (this one started out when I got it at 40%, its currently 32 something). I have no idea what will happen when it reaches 0, but there does at least appear to be a single provision for miscalculated SoC.
During discharge, the firmware tracks the battery down much quicker than it should inherently, but then on top of that, because of the bug, this makes the calculated slope that much more slipperier.
But a peculiar thing happens at about "15%" remaining (according to the firmware) - The code seemingly all of a sudden realizes that the voltage and the calculated charge don't agree enough, and so it must be a little out of whack. The result of this is that it "sticks" at right around the 15% mark, and appears at first to be trying to self correct. After a while (it varies, haven't pinned it down), it gives up and soon goes critical, with the firmware's final warning to the OS that (under Linux) displays a "who knows, its threatening death, but I can't tell you when, so don't say I didn't tell you so" and then is never to be heard from again. The firmware quits reporting metrics to the OS, and the only other sign that the firmware IS still in there somewhere comes if the machine is cycled after this point.
If a power down/up or reboot is attempted, the machine either refuses to power on (BIOS "ignores" the power switch, or in the case of a reboot, it hang right at the very last moment, presumably when the kernel lets go of the hardware.
This is very annoying, because there will still be 90+% of actual power available, but BIOS won't let you touch it because the firmware is playing dead.
I figured out a portable workaround for this that involves two 9V NiMH batteries in a small box, with a 7812 and a momentary switch running to a coax power plug that, when activated, can sustain the load of the machine for the first few seconds of POST, at which time BIOS thinks the battery is charging, and allows the machine to come up. The button on the hack box can then be released, and the machine falls back onto the the LiIon, and boots normally. There aren't any special requirements for the hack, in fact even though it supplies about 1.2A @ 12V, the 7812 doesn't need a heatsink because the window is so short. NiMH doesn't have any issue with supplying the juice either. I've charged it once since I built it, and have started the box with it several times and it hasn't failed yet.
Another problem, I brought on myself... I flipped the polarity one night because I misread the stripe in the wire (isn't that "standardly" positive and tip? WTF?). Anyway, the only consequence of this (luckily) was that I took out the charging circuit. Charging is now performed with one safety net removed, and is done by a current limited buck converter that floats the pack up to 8.4V, the highest "safe" voltage.
I don't know how the original charge circuit would have handled the mega battery - its construction followed close in line with the "removal" of the circuit. BIOS still gets a signal that charge is taking place, but without the buck converter attached, no actual charging takes place. Unfortunately, I don't have any data from the FLA jobbies, because that was before full battery management techniques, and I charged the FLAs independent of the laptops.
Third, I had to write all of the battery reporting code myself, since the firmware is clueless. This wasn't a big deal (for me); there's nothing really extravagant about any of it other than a brief tangle with permissions over root being able to cron out speech synth and cycle the box. The default config of Ubuntu 10.04 doesn't allow either of these due to security concerns (although I didn't fully understand the sound thing, other than maybe sound drivers aren't included in the trusted group for root for fear of exploits). Other than that, its pretty straight forward, basically a bunch of sed/awk/grep calls made from bash scripts, and cron to trigger them.
The last of the big issues is probably the most important. Lithium Ion is a very temperamental chemistry, with a propensity for violence. It demands respect, and has little tolerance for error, lest ye be a glutton for punishment, aye!
There are safety mechanisms that are there for a reason, and need to be translated as closely as possible to the "new" battery. There are thermisters that monitor cell temperatures throughout the packs, and LVD/HVD that must not be bypassed. The original battery control needs to remain in place as much as possible, and in my case, even though I had to make an external charge circuit, I still ran the connections into the laptop, and connected them at the main pole connections in the box. This is to ensure that the disconnects remain in effect. I cannot stress this enough. Failure of a safety component can potentially result in catastrophic failure of the entire pack, involving magic smoke and fire on epic levels that unless you have seen up close and personal, cannot appreciate fully. Lithium Ion is a very energetic chemistry, and can release it violently if it gets pissed off. I'm going to say this again, DO NOT BYPASS THESE MECHANISMS.
The one physical translation that probably won't fully work for any pack of this magnitude is the thermister placements. In my case especially, I had to make the best guess compromise and place the only thermister that is present in the original pack right smack in the middle of it as best I could - I figured this is the most likely location to be prone to pent up heat.
Normally, there would be SEVERAL thermisters in a pack this size, but this is one aspect of doing something like this that you can't "trick out". If the firmware doesn't see what it wants to see from these seemingly innocuous little devices, charge and/or discharge will not be allowed, as the firmware would be seeing this as a dangerous situation. The original thermister(s) need to be used, and simply extended off the board (usually). Don't go around this. The only way to get power in and out of a pack in this state would be to bypass the disconnect MOSFETs. DON'T DO IT!
Those are the major considerations, and there are other smaller ones, but they are more about things like physical location of the battery in relation to the laptop, etc. If you use a decent gauge wire for the main terminals, voltage drop will not be too much of a problem. There are also connections at each cell connection where they tie together in series. These can be thinner, but are important. They provide balancing and monitoring functions for the cells, and if omitted, the pack is likely to lock out.
Steve
