Opened 7 years ago

Closed 7 years ago

#1961 closed defect (duplicate)

Battery indicator is inaccurate

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

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 (8)

comment:1 Changed 7 years ago by marco

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

comment:2 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.

comment:3 follow-up: 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. ;-)

comment:4 in reply to: ↑ 3 ; follow-up: 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?

comment:5 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 :)

comment:6 Changed 7 years ago by jg

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

Is this still happening?

Can we close this?

comment:7 Changed 7 years ago by jg

  • Cc rsmith added; krstic removed
  • Milestone changed from Untriaged to V1.1

comment:8 Changed 7 years ago by rsmith

  • Resolution set to duplicate
  • Status changed from new to closed

Part of #6092

Note: See TracTickets for help on using tickets.