Discharge Rate

[Zyxmon]

Firstly thank you for the nice program. I have tried it in 30 day evaluation period for a couple of hours. I have a good impression.

Now a question and probably a suggestion.

I have a new Lenovo U450 laptop (CULV Intel processor SU7300, switchable graphics, etc...). I have charged my battery only 3 times after the purchase.
I wanted to check how screen brightness, cpu load, power scheme, graphics (integrated Intel/discrete ATI) influence the discharge rate. But all programs (Everest, Passmark BatteryMon, Battery Bar) report constant discharge rate - 14208mW. Only on heavy load (CPU + ATI GPU) the reported discharge rate was somewhere 16000+ mW. I do not think the discharge rate reported by BIOS/Battery controller is correct.
The Full LifeTime/Remaining Time reported by Battery Bar is change (decrease) when I load my laptop (watching video) and increase after I stop watching video. I do not know how BatteryBar calculate these values (averaging over some undefined time?), but the values seem reasonable and different from the standard Win7 power applet.

I think the most simple way to report Discharge Rate is to multiply the voltage by the current. This how it is probably implemented in controllers/bios. The more correct way would be to divide the capacity change by the time of change. I think a good idea would be to add such a value (Calculated Discharge Rate) to the Battery Bar. The user can set the time interval to check capacity change for such calculations.

[Chris]

You're right that the discharge rate is as reported by the battery itself. Some batteries don't even report the value and some are not accurate.

BatteryBar displays that for your information, but it doesn't use it in its calculations. As you noticed, the time remaining in BatteryBar is calculated by timing how long it takes to discharge 1% and keeps track of that for each percent remaining value.

While the computer is running it also runs a method to verify the accuracy of the estimate by comparing the estimated time remaining for the last 10 percentage points against the ACTUAL time that it has taken to discharge over the same 10 percentage points. It then generates a ratio and adjust the time remaining estimate accordingly.

I think it would be possible to calculate the discharge rate based on the change in capacity over time. Please post your suggestion to http://feedback.osirisdevelopment.com

[Guest]

Thank you for the answer and the detailed description on calculating the remaining time. I have found the voting page yesterday and added my votes to "estimate discharge rate for batteries not supporting it".
No 1 in the suggestion page is "Graphs..." - that was my second suggestion. As I've written it can be started by making log files with time and other (user selectable) values in text files. One can use these files to draw graphs in the third party software.

[Chris]

I do want to add a graphing capability to the system, but it's going to take me a little time to get it done. I hope to include it in the 3.4 release.

[Guest]

I have investigated xml profile file and made manual discharge rate calculations. The results are reasonable.
I've reseted profile several times to be sure that previous records do not interfere with full lifetime when I change brightness and cpu load.
Does the program takes into account sleep mode and hibernation?
Some entries are missing in the profile file.
I have one entry with zero seconds.

[Chris]

BatteryBar does take into sleep. In other words, sleeping doesn't generate bad data. When a sleep event is received, BatteryBar turns off it's internal timer and doesn't restart it again until after the computer resumes.

Entries that are missing are due to the program not running during those percentages. If you boot up the computer on battery and it's at 88.5%, BatteryBar won't start the timer until it reaches 88.0% to make sure it doesn't skew the data by timing partial percentages.

A "0" seconds entry means that your battery actually skipped that value. For example, if you disconnect from 100% and your battery makes a sudden drop to 96% (common when your battery wear is about to increase), then BatteryBar inserts 0 values for 99, 98, and 97 percents because in reality those percents only lasted 0 seconds (skipped).

[Guest]

Thanks for the explanation. BTW my battery controller seems not to give accuracy more then 1% (at least BatteryBar does not show decimals after the point with appropriate settings).
Capacity granularity shown under linux is rather high.

[Zyxmon]

Just for your information (zero values). May be it is a small bug in BatteryBar, but most likely it is the battery controller behavior near 50% of charge. The charge rate -

Code:

<PercentTime Percent="47" Time="75" Samples="1" />
      <PercentTime Percent="48" Time="75" Samples="1" />
      <PercentTime Percent="49" Time="75" Samples="1" />
      <PercentTime Percent="50" Time="0" Samples="1" />
      <PercentTime Percent="51" Time="150" Samples="1" />
      <PercentTime Percent="52" Time="70" Samples="1" />
      <PercentTime Percent="53" Time="75" Samples="1" />
      <PercentTime Percent="54" Time="75" Samples="1" />

The discharge rate

Code:

<PercentTime Percent="44" Time="315" Samples="1" />
      <PercentTime Percent="45" Time="355" Samples="1" />
      <PercentTime Percent="46" Time="315" Samples="1" />
      <PercentTime Percent="47" Time="305" Samples="1" />
      <PercentTime Percent="48" Time="515" Samples="1" />
      <PercentTime Percent="49" Time="0" Samples="1" />
      <PercentTime Percent="50" Time="365" Samples="1" />
      <PercentTime Percent="51" Time="365" Samples="1" />
      <PercentTime Percent="52" Time="310" Samples="1" />

[Zyxmon]

This evening my battery passed 50% mark (discharging). I'm sure 50% and 49% did not last zero seconds according to the BatteryBar. But the record in the profile is <PercentTime Percent="49" Time="0" Samples="2" />. Strange (I have some programming skills) - but it looks like a bug in the BatteryBar.

[Chris]

If it always seems to happen at the same spot, it will be easy to track with a debug log.

Follow the instructions at http://osirisdevelopment.com/wiki/Submit_a_bug_report to generate a debug log to send to me. Make a note in the comments regarding the jump at 50%.