In the first approximation, we can present a Li-Ion battery as a jar with the following parts:
- Consumed volume
- Remaining volume
But why is this not true, and why can't we consume all the charge from the battery?
In the first approximation, we can present a Li-Ion battery as a jar with the following parts:
But why is this not true, and why can't we consume all the charge from the battery?
I needed tabular values for the dependency of Open Circuit Voltage (OCV) of a Li-Ion battery on Depth of Discharge (DOD), but I couldn't find this data anywhere.
The closest I found was an image of OCV by State of Charge (SOC) in a ResearchGate article. Although the authors provide a formula for modeling these values in the article, I only needed an array of approximate values.
Therefore, I decided to extract them directly from the image.
This is a driver for Arduino that provides functions to interface with the BQ28Z610 battery gas gauge device over I2C protocol. With this driver, you can operate the BQ28Z610 device via the serial port from your computer using Arduino.
Functions were implemented based on the documentation:
Not all functions described in the Technical Reference Manual were implemented, but most of them.
The driver also includes some additional service functions for more usability.
This program is designed to be written on Arduino or ATtiny85 and acts as a stub to respond to the speaker's requests via the I2C protocol, enabling the speaker to be used while connected to mains power without using a battery.
It can be used when you don't want to or cannot use the battery pack.
We will need:
There are standard instructions on the internet about how to perform a learning cycle, but in this article, I will explain how to practically perform a learning cycle in a real case for the used Device and why it may fail.
The data I have collected during this journey is attached via the link at the end of the article.
Disclaimer: The author of this article has no affiliation with Texas Instruments. This article is written for the purpose of personal and independent research by the author. It may contain mistakes and subjective judgments made by the author. The author disclaims any responsibility for the consequences of using the information provided in the article. The materials of the article are distributed as-is. Each person who uses the materials in practice assumes full responsibility for the consequences thereof.
Let's take the used Gas Gauging Device BQ28Z610 and connect some new batteries to it.
If you read the GaugingStatus()[REST] flag via the I2C protocol from the BQ28Z610 device and it never becomes high, then just check again which bit you read, because the documentation from TI has many typos, and this is one of them.
The information about the relationship between sealing/unsealing the device and FETControl() with ChargeFET() and DischargeFET() is not clear enough in the Technical Manual. Therefore, I decided to address this gap with this article.
|
| The relationship between the seal/unseal device and FETControl() with ChargeFET() and DischargeFET() |
I found one peculiarity that was not mentioned in the documentation. I don't know why it was designed this way, but I would like to share it with the community.
There are no issues with calling DischargeFET() it works just fine. However, this isn't the case for ChargeFET(). So let's take a closer look at the states:
So Charging works only if Discharge FET was previously enabled. This behaviour is strange, but now you are informed about the process.
![]() |
| Usage of the ChargeFET() and DischargeFET() |
Custom driver for the BQ28Z610 device was connected directly via I2C. It is possible to obtain non-zero values from functions Voltage(), Temperature() and other. Charging and Discharging are allowed, current flow can be seen on the ammeter, but functions "0x0C/0D Current()" and "0x14/15 AverageCurrent()" always return [0x00, 0x00].
You may try increase actual current up to 1 A.
You may try to call function "12.2.15 AltManufacturerAccess() 0x0021 Gauging" to turn on the gauging of the current.
If nothing else helps, you should check your hardware circuit and test the sense resistor (Rsense). To do this, pass some current through it and measure the voltage across it in millivolt fractions.
For example, Rsence = 2m0 (2 milliohms). So current 1 A will produce 2 mV on it: "1 A * 2 mO = 2 mV".
To exclude the software component of the test, you need to:
|
|
Test circuit independent |
|
|
Test schema independent |
If the voltage is 0, then check your main circuit and try to clean it a little bit and remove any stickers - perhaps during production, sense resistor connections were shorted.
If the voltage is correct then build another test circuit:
|
| Test circuit via BQ28Z610 |
![]() |
| Test schema via BQ28Z610 |
If the voltage is 0 this time then the problem is in the microchip, the possibly it's a software issue, maybe it shorts the sense resistor by some configuration - but it was not my case, so I cannot confirm or deny if such a case possible.
Was used microchip BQ28Z610 at the battery pack from "JBL Xtreme 2", with the Device Name from the Data Flash: "ID1019-A-M26-28z610".
At my parents' place, there was a Christmas lights string that I admired since childhood, even though I couldn't recall ever seeing it whole and functional. I always wanted to see its glow and charm when it was lit up. 🌟
The light was in dreadful condition: not all lamps were present, wires were cut, and only a few lights were working. I decided to "refactor and rebuild" it completely but to save as many original parts as possible.
So, my exciting journey started with the task: replace glow-lamps with LEDs, and, consequently, replace the supply voltage from 220v to 5v.