Bug in reported battery charge

[_wb_]

The battery charge reported in /sys/class/power_supply/bq27500-0/charge_now is a bit buggy. The problem is that it stops getting updated at some point when you're charging. Around the time when the battery reaches its "full" level (not the design level, but the value of charge_full), the battery keeps charging ("topping off") at a slower rate. The charge_now counter doesn't get updated anymore though, but you can see a positive current_now value. Then when the charging finally stops, and the battery goes back to discharge mode, the value of charge_now does get updated again, counting down from where it stopped getting updated. Then at some later point, the error somehow gets corrected and the reported value jumps up again.


I can demonstrate this phenomenon using my Pandora System Info tool. This tool doesn't report the actual value of charge_now; instead it shows the value of charge_now + delta, where delta is computed from the current and voltage that has been observed since the last change of the value of charge_now. Usually the interpolated value and the value of charge_now are nearly the same, and each time charge_now gets updated with a new value, they are identical. But when charge_now stops being updated, the interpolated value starts to differ a lot over time.


Here's a plot of last night's battery charge (the interpolated values):

As you can see, it jumps down suddenly when the battery starts discharging again, because that's when the value of charge_now starts changing again. Then some hours later, it jumps up again, because (I guess) it somehow corrects for the error.


I think the plots shows that the interpolation during the last phase of charging (from about 22:00 to 23:00) was actually correct, and the reported charge_now values were wrong. Not shown here are the values of energy_now; those seem to be updated correctly.


I don't know who can change anything about this - I guess this is a (minor) bug in the kernel battery driver.

 

[notaz]

Unfortunately this comes directly from the bq27500 chip and is behavior of it's firmware. Unless you can dump and reverse engineer it's firmware (which would be easier then getting help from TI), there is no way to fix it.


Talking about TI help, you can seldom get help at their forums:


http://e2e.ti.com/support/power_management/battery_management/f/180.aspx

 

[_wb_]

I see. In that case, there's not much I can do, except not thrusting the values reported by the chip when they differ too much from the expected value. On the above graph, the sudden jerk down would be ignored and interpolated values would be given until the point where the chip values are "reasonable" again.

 

[thatgui]

I see. In that case, there's not much I can do, except not thrusting the values reported by the chip when they differ too much from the expected value. On the above graph, the sudden jerk down would be ignored and interpolated values would be given until the point where the chip values are "reasonable" again.

As a happy "customer" (thanks for system info) I would say: give people the choice, wether they like to see the "raw" data or the smoothed.

 

[_wb_]

That's already the case: you can see the raw data in dark green and the interpolated value in light green. I'm gonna add the raw data to the logfile too.

 

[_wb_]

Sorry about the gravedigging, but here's a plot that shows how large the difference can be between the raw reported value and the estimate: