This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ27542-G1: SoC jumps 30% after coming out of hibernate.

Part Number: BQ27542-G1
Other Parts Discussed in Thread: BQSTUDIO

I'm using a 27542-G1 with a 63 mAhr L-Ion cell.  After going into and coming out of Hibernate mode following  a discharge down to something in the 20-30% SoC range, the gauge often reports a SoC (incorrectly) that is around 30% higher than the last reported (correct) SoC prior to Hibernation.  I have verified that the SoC prior to Hibernation is approximately correct given the known discharge current and time from a fully charged state to the removal of the load and entry into Hibernation.  In addition if the battery is allowed to discharge after coming out of hibernation the voltage falls rapidly into cutoff after extracting the energy available at the original SoC indication just prior to Hibernation.  Once the battery is recharged to 100% SoC the behavior during a subsequent discharge is accurate as long as the discharge isn't interrupted by going into Hibernation.

The gauges are all configured by writing the entire DF with data extracted from a gauge that was initialized via bqStudio with a Chemistry obtained through the process specified in the datasheet and has experienced at least 10 charge-discharge cycles.  In this application the current sense resistor is 200mΩ and the gauge is calibrated with a scale factor of 10 (1ma of actual current cause the gauge to indicate a 10ma current).

I can provide the DF contents but I don't see any way to include that here.

  • Hi Lance
    Why are you using the hibernte mode? That mode is only recommended to be used for shipping or storage and because the algorithm isn' functional in that low power state, the gauge isn't expected to be be accurate upon exit from hibernate mode until you charge to full or discharge to empty.
    The gauge only goes into hibernate after you sent the hibnerate command and then the current goes below the hibernate current amongst other conditions.

    If you are keen on using the hibernate mode, then you must charge the battery to full upon exit, otherwise you have to use sleep mode.
    thanks
    Onyx
  • I have to use hibernate mode because the fuel gauge will discharge my little 60 maHr battery in a matter of weeks and the users expect to be able to put them on the shelf for months at a time without losing more than half the battery capacity. In addition the user interface is only a couple of buttons which doesn't provide any simple way for someone to enable hibernate selectively.

    I didn't see anything in the datasheet that indicates that going into hibernation causes the gauge to lose track of the SoC and in fact I'm pretty sure there's a description of how the SoC at entry to hibernate will be returned initially until the gauge has had time to re-evaluate the actual SoC as determined by the Impedance Track algorithm.
  • To Clarify, I don't need the fuel gauge to be accurate immediately after powering up out of hibernation but I do need it to become accurate within a reasonably (few minutes?) period after that.
  • Unfortunately, That is not how the gauge works. In coming out of hibernate, it needs a proper reference point to return to full accuracy. Depending on where you are on the OCV profile of your battery, the error in SOC accuracy you see would be more or may be less. Upon exit from hibernate, you have to allow the gauge to take a proper OCV measurement of the relaxed battery to make SOC estimates. If you have any form of current flow during that measurement, it will cause the SOC estimated to be erroneous. That being said, charging to full upon exit from hibernate is the recommended way to get the gauge return to high accuracy. if that is not possible, then ensure you don't have any current flow upon exit from hibernate and ensure you are not in the flat zone of that chem id to reduce the error during initialization.
    thanks
    Onyx