Ticket #1961 (closed defect: duplicate)

Opened 7 years ago

Last modified 7 years ago

Battery indicator is inaccurate

Reported by: jfuhrer Owned by: David.Lin
Priority: normal Milestone: Future Release
Component: embedded controller Version:
Keywords: Cc: rsmith
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

OFW: Q2C18 Build: 488

I've observed strange behavior with the battery charge indicator in the past couple builds. Sometimes, it does not decrease when unplugged or will not increase when charging. Occasionally, the charge will leap up by a large amount all at once. It generally corrects itself after a while.

Change History

  Changed 7 years ago by marco

It's broken right now, we need to get an HAL snapshot in the builds.

in reply to: ↑ description   Changed 7 years ago by rsmith

Replying to jfuhrer:

I've observed strange behavior with the battery charge indicator in the past couple builds. Sometimes, it does not decrease when unplugged or will not increase when charging. Occasionally, the charge will leap up by a large amount all at once. It generally corrects itself after a while.

I've seen cases where the EC code is failing to reset the capacity,voltage, current, etc values to zero when the battery is removed. I'm also beginning to get some reports back from the users that the battery capacity report from the EC can be erratic. The equations that govern the calculations for battery capacity on a NiMH battery are pretty complex. So I can't really say I'm that surprised.

It would be really helpful to me if you could set up some sort of userspace logging facility that can track the battery management system parameters. There is a lot of info in the battery EEPROM beyond the voltage and current.

With a newer kernel and EC code you can: - Read a unique 64-bit ID for the battery pack - Read all the values in the gas guage EEPROM using the OLPC battery driver.

With these features we can track BMS parameters on a per battery basis. This will be crucial to diagnose some of the more bizarre battery problems. One the HAL stuff settles down please contact me (richard at laptop dot org) and I'll help you get a list of EEPROM values that are important to track.

Having all that data logged across multiple charge/discharge cycles will be _really_ useful for solving the battery corner cases that I think are beginning to surface.

follow-up: ↓ 4   Changed 7 years ago by cjb

  • cc krstic added

With a newer kernel and EC code you can: - Read a unique 64-bit ID for the battery pack"

CC'ing Ivan so he knows we have one more accessible unique identifier than he thought we did. ;-)

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 7 years ago by rsmith

Replying to cjb:

With a newer kernel and EC code you can: - Read a unique 64-bit ID for the battery pack"

CC'ing Ivan so he knows we have one more accessible unique identifier than he thought we did. ;-)

Sort of. Its per battery. You can remove batteries and put them into other laptops. Is that really useful for Laptop IDs?

in reply to: ↑ 4   Changed 7 years ago by krstic

Replying to rsmith:

Sort of. Its per battery. You can remove batteries and put them into other laptops. Is that really useful for Laptop IDs?

No, it's pretty useless :)

  Changed 7 years ago by jg

  • owner changed from hughsient@… to David.Lin
  • component changed from power manager (OHM) to embedded controller

Is this still happening?

Can we close this?

  Changed 7 years ago by jg

  • cc rsmith added; krstic removed
  • milestone changed from Untriaged to V1.1

  Changed 7 years ago by rsmith

  • status changed from new to closed
  • resolution set to duplicate

Part of #6092

Note: See TracTickets for help on using tickets.