bogus battery voltage?

[tve]

I have an rPi4 with UPS HAT and Cellular LTE HAT stacked. I have a LI-Ion battery in the UPS hat. When I query all the available info I get:

{ 'firmware': {'ver': 'v0.3.22'},
  'input': {'temp': '38.25', 'voltage': '4.544', 'current': '1.15', 'power': '5.225'},
  'system': {'temp': '51.6', 'voltage': '5.152', 'current': '0.764', 'power': '3.728'},
  'battery': {'temp': '30.62', 'voltage': '2.151', 'current': '-0.064', 'power': '-0.138', 'level': 100, 'health': 100, 'max_charge_level': 95, 'design_capacity': 2500},
  'fan': {'speed': 0, 'health': 1}}

The battery is fully charged and reads 4.19V with my meter. Yet the API returns 2.151V?

[tve]

It looks like some of the other battery stats are not working either. Here is what I get after running for ~20 minutes on battery

{ "firmware": {"ver": "v0.3.22"},
  "input": {"temp": 35.62, "voltage": 0.0, "current": 0.0, "power": 0.0},
  "system": {"temp": 51.6, "voltage": 5.152, "current": 0.798, "power": 4.372},
  "battery": {"temp": 32.12, "voltage": 2.151, "current": -0.064, "power": -0.138, "level": 100, "health": 100, "max_charge_level": 95, "design_capacity": 2500},
  "fan": {"speed": 0, "health": 1}}

The actual battery voltage is 4.00V now, that's not "level:100" for sure. Also, the current of -0.064A doesn't make sense.
I'm running the latest master (b1b048a).

[tve]

It turns out that a full power cycle fixes the battery readout issue. This does leave the problem that the UPS HAT can get into a bad state where it reports garbage values. This should be fixed...

[ciszkiewicz]

We have the same issue. Are there any updates on the fix?

[ciszkiewicz]

It looks like some of the other battery stats are not working either. Here is what I get after running for ~20 minutes on battery

{ "firmware": {"ver": "v0.3.22"},
  "input": {"temp": 35.62, "voltage": 0.0, "current": 0.0, "power": 0.0},
  "system": {"temp": 51.6, "voltage": 5.152, "current": 0.798, "power": 4.372},
  "battery": {"temp": 32.12, "voltage": 2.151, "current": -0.064, "power": -0.138, "level": 100, "health": 100, "max_charge_level": 95, "design_capacity": 2500},
  "fan": {"speed": 0, "health": 1}}

The actual battery voltage is 4.00V now, that's not "level:100" for sure. Also, the current of -0.064A doesn't make sense. I'm running the latest master (b1b048a).

What firmware are you running?

[tve]

Is there any chance to get this fixed? I'm picking my project up again and see that there has been no new release...
I power up my rPi and the power manager API reports a battery voltage of 1.95V while my multimeter shows 3.85V.

I now unplugged USB power, so the Pi is powered by the battery. Here's what I get from the power manager API:

{"firmware": {"ver": "v0.3.22"},
 "input": {"temp": 36.37, "voltage": 0.0, "current": 0.0, "power": 0.0},
 "system": {"temp": 51.1, "voltage": 5.152, "current": 0.538, "power": 3.092},
 "battery": {"temp": 33.25, "voltage": 2.477, "current": -0.074, "power": -0.183, "level": 1, "health": 91, 
           "max_charge_level": 95, "design_capacity": 5000},
 "fan": {"speed": 0, "health": 1}}

So according to the power API a 183mW draw on the battery powers the 3.092W Pi???
A UPS is about reliability, this thing is anything but reliable!

[ensarkarabudak]

Hi @tve ,

Please make sure you set your battery design capacity correctly. It seems like two different battery capacities are set in the HAT data you shared. 2500 and 5000 mAh.

'battery': {'temp': '30.62', 'voltage': '2.151', 'current': '-0.064', 'power': '-0.138', 'level': 100, 'health': 100, 'max_charge_level': 95, 'design_capacity': 2500},

"battery": {"temp": 33.25, "voltage": 2.477, "current": -0.074, "power": -0.183, "level": 1, "health": 91,
"max_charge_level": 95, "design_capacity": 5000},

You can set the capacity of the battery with the set_battery_design_capacity() function. Please see for details: https://sixfab.github.io/sixfab-power-python-api/#SixfabPower.set_battery_design_capacity

Battery data is provided by the fuel gauge integrated into HAT. It is usual for such ICs to return the correct data after a full power cycle after inserting the battery. It was designed this way. So we do not recommend that you insert and remove the battery frequently, this will cause deviations. It gives more reliable information after several charge-discharges of the battery. After inserting the battery into the HAT in your project, set the battery capacity and then charge-discharge the battery several times. Check the battery values, if the data is still wrong, there may be a problem with your IC, we can change the HAT for you.
The fuel gauge integrated used is bq27441-G1. Product datasheet: https://www.ti.com/lit/ds/symlink/bq27441-g1.pdf?ts=1654514226211&ref_url=https%3A%2F%2Fwww.google.com%2F

Apologies for delaying.

[tve]

It seems like two different battery capacities are set in the HAT data you shared. 2500 and 5000 mAh

Yes, these tests were 4 months apart!

Look at the voltage and current measurements, these are completely off and they are independent of the fuel tracking algorithm. If the chip indeed thinks that these are V and A then there's a hardware failure. I guess I'll have to attach a logic analyzer to find out.

Looking at the schematics, you have Bin tied to ground, so the chip cannot detect when the battery has been inserted/removed. I'm not seeing any API functions for this either. So there's no way to tell the chip when the battery has been changed?

[ensarkarabudak]

As mentioned earlier, it will return the correct values after a few power cycles.
The current and voltage values you compare in the API are provided by the fuel gauge, if they do not match the data you measured with the multimeter after a power cycle, there may be a problem with the IC. Do not forget to set your battery capacity correctly.
We did not encounter such a situation in the tests of my teammates on the HAT. What is your usage scenario, Would you please provide more details about your situation?

I'm not seeing any API functions for this either. So there's no way to tell the chip when the battery has been changed?

There is no such function in the API.

[tve]

I hooked up a logic analyzer to see what the BQ27441 actually outputs and it matched what the API returns, but the i2C transactions looked a bit odd, specifically, the second byte of a read command didn't have an ACK...

I then desoldered the BQ27441, cleaned the pads, and soldered it back. Now everything looks reasonable. I don't know whether there indeed was a soldering issue or whether all this properly reset the chip...

************* Input Sensors **************
Input Temp: 25.62
Input Voltage: 0.0
Input Current: 0.0
Input Power: 0.0
************* System Sensors **************
System Temp: 32.1
System Voltage: 5.172
System Current: 0.35
System Power: 1.776
************* Battery **************
Battery Temp: 26.62
Battery Voltage: 3.407
Battery Current: -0.617
Battery Power: -2.102
Battery Level: 4
Battery Health: 91
************* Fan **************
Fan Health: 1
Fan Speed: 6420

The rPi4 is running from the LiPO battery and the numbers line up and also match what my multimeter says.

[ensarkarabudak]

Great!
We truly value your feedback and the time you took on the issue. Thank you for your valuable feedback.
We will take care to ensure that such an incident does not happen again.