Supports SBS v1. The bq uses the System Management Bus v1. The bq also supports the SBData charge control functions. Battery state-of-charge, remaining capacity, remaining time, and chemistry are av ai l a b l e o v e r th e s e ri a l l i n k. The bq estimates battery selfdischarge based on an internal timer and temperature sensor and user-programmable rate information stored in external EEPROM.
|Published (Last):||2 November 2015|
|PDF File Size:||14.71 Mb|
|ePub File Size:||13.61 Mb|
|Price:||Free* [*Free Regsitration Required]|
Last but not least, we need to talk to the battery. My preferred way to write a simple proggie in C. Bare C was easier to tame. Here are the code snippets I could come up with. For obscure reasons, you have to compile them with some optimization turned on - e. The battery BQ provides a heap of data: instantaneous voltage and current, temperature, what the IC thinks is the remaining effective capacity, current charge level per cent , voltage tresholds for full charge and full discharge, including an early warning treshold, reporting that the battery is running our of gas.
Most values are coded as a 16bit word, expressing the value measuder in "milli"units - i. Some values are slightly more cryptic: e. The BQ also contains many adressable registers that positively contain some data but are not mentioned in the documentation.
For a full reference of the meanings of the individual register contents, check out the data sheet. The documentation is also quite brief regarding the reset of the IC - which you can only find out once you actually attempt to reset it. Only after a brief power-cycle unsolder and reconnect one of the wires going to the cells does the reset operation finish.
The BQ counts up and down how many mAh have entered and left the battery between the upper and lower voltage treshold. Further observations, side notes and rants Besides the linux I2C, I know of a Slovak freeware util for Windows, available from somewhere at the Czech "hardware server" , that can reportedly do a number of interesting generic things over I2C: write and read operations, including macros consisting of multiple atomic actions etc.
A battery data listing and reset might as well be a piece of cake. During our battery experiments, occasionally we need to completely discharge the battery. Unless we have a stand-alone discharger device available even an improvised quick hack , we need to leave the complete discharge up to the notebook.
And this is where we have a problem with the more intelligent operating systems such as Windows or Linux, that set the notebook asleep well before the battery is completely empty - probably when the gas gauge reports zero per cent, or perhaps when it signals the "early warning", which is usually somewhat later.
We need to discharge the battery to the very bottom - to the point where the BQ detects the "hard" low treshold and invokes via I2C a complete shutdown of the notebook, to protect the battery from damage caused by over-discharge. The charge level percentage and the actual battery capacity in mAh are derived from the milliAmps flowing through, being integrated over the time it takes between full charge and full discharge - more or less there are some magical corrections in the formula.
In particular, the BQ signals this "incomplete charge cycles" condition with a particular alarm bit in a certain status register - for a complete interpretation, see the data sheet.
With respect to proper functioning of the "gas gauge", utilization of the battery and the memory effect however disputable it is , the charging and discharging should only stop when the BQ itself finds that the voltage has reached the respective treshold - of which it informs by the status bits in the respective registers, as well as by sending "broadcasts" via the I2C link to a well-known smart charger I2C address assuming the role of an I2C bus master for the moment, even though normally the smart battery gas gauge is a slave.
Which has been observed with a rather expensive notebook model we had in my job, with many different pieces used throughout the company, with Li-Ion batteries. The BQ also mentions that, in order to achieve maximum precision, it is possible to fine-tune callibrate the initial values stored in the serial flash. The BQ features a separate I2C port just for the serial flash, that is not connected to the outer connector.
Why do we have to connect the battery via a parallel port? Just like the BQ, the BQ also has a documented but different reset procedure, again dependent on a write-protect lock. Not even after the write-protect lock is properly removed, which already requires you to wiretap the external 24c There seems to be a workable workaround, consisting in rewriting the "actual capacity" value in the external 24c01 Flash EEPROM - a single word value 16 bits holding the last learned capacity in mAh.
Please note that the BQ chips use a "private" i2c bus to talk to the 24c To save power, the BQ chips only power up the external 24c01 for a second when they need to talk to it read it or write it.
Which means that we definitely need to provide power to the 24c01 externally. To sum up, the whole reset workaround procedure should look like this: Start Linux with i2c-pport and the other modules. Disconnect the gas gauge PCB from the cells in the pack perhaps replacing the cells at the same time.
Attach the parallel port I2c probe to the 24c Attach the probe to your parallel port. Disconnect the probe from the PC and unsolder it from the 24c Reconnect the battery cells to the gas gauge PCB. You should see a change. Run the battery through two or three full charge cycles in the notebook.
Rhett Chronograph Stainless Steel Watch
Talk to your battery