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.

BQ35100: Understanding calibration and remaining capacity

Part Number: BQ35100

Hello, 

I have some questions about this battery gauge module:

  1. Reading the TRM about the calibration steps I found this "Perform the following calibration sequence during battery pack manufacturing process". I have the gauge mounted on my custom board, is it useful to perform a calibration? If yes, in which stage should I perform it?  At the very FW start? Why is mentioned the battery pack manufacturing If I already use a battery pack? 
  2. About Current Calibration, I read this on TRM  "CC Gain and CC Delta are two calibration parameters of concern for current calibration. A known load, typically 1000 mA, is applied to the device during this process". Considering the custom board nature is quite impossible to apply a current of this magnitude. How can I perform this (if I should calibrate the gauge of course)? 
  3. About the Remaining Capacity process, I use a LiSOCl2 battery and want to calculate the remaining capacity percentage. Below I post my procedure, is this a proper way to evaluate the remaining percentage? Looking at TMR I also found the EOS Mode, but it is a little unclear. Where I can found the value about battery charge status? Should I read only EOS Trent Detection from the DataFlash?

My current remaining percentage procedure acts as follow:

/* Write Cell design capacity*/
data[0] = 0x4A;
data[1] = 0x38; // Tadiran mod. SL-2780 19Ah {hex 0x4A38}
sCmd = DF_CELL_DESIGN_CAPACITY_mAH_ADDR;
writetoDF(sCmd, data, DF_I2_SIZE, TIME_WRITE_DF); // write to DataFlash memory 

...

while(1){
...
 /* Read command DESIGN CAPACITY*/
cmd[0] = CMD_DESIGN_CAPACITY;
readCommand(cmd, rx, DF_I2_SIZE, TIME_READ_ONLY);
designCapacity_uAh = ((uint16_t) rx[1] << 8) | rx[0];
designCapacity_uAh *= 0x03E8; //design Capacity * 1000  

/* Read command USED CAPACITY*/
cmd[0] = CMD_ACCUMULATED_CAPACITY;
readCommand(cmd, rx1, DF_I4_SIZE, TIME_READ_ONLY);
usedCapacity_uAh = ((uint32_t) rx1[3] << 24)
                    | ((uint32_t) rx1[2] << 16)
                    | ((uint32_t) rx1[1] << 8)
                    | ((uint32_t) rx1[0] << 0);

usedCapacity_uAh = (usedCapacity_uAh > designCapacity_uAh) ? designCapacity_uAh : usedCapacity_uAh;
percentage = (float) (designCapacity_uAh - usedCapacity_uAh) / (float)(designCapacity_uAh);

bqData = (uint16_t) (percentage * 100);

...
}

It returns always 100%. Is there something wrong? 


Best Regards,

Vincenzo 

  • Vincenzo,

    1) Yes calibration is required. It needs to be done after the fw image is loaded (if you you updating the image like using a golden) 

    2) You need to apply a known load to know what to calibrate to. normally this is all done at the PCM manufacturing stage. 

    3) The gauge does not report remaining capacity. There are lots of E2E questions already answered about EOS mode you should be able to reference. High level in EOS mode you need a correct chemID and to follow an exact process to update MeasuredZ. MeasuredZ will be used to compare against the chemID and establish and SOH percentage.

    Accumulation mode will only count coulombs and it does not report an SOH at all. 

    The last most is for LiMn02 type cells. It also requires a correct chemID and is based off the voltage of the battery.

    Thanks,

    Eric Vos 

  • Hi Eric,

    I am working together with Vincenzo on the topic (we are colleagues).

    Your reply makes me change our approach to this issue. Our device is a sort of smart meter: it samples sensor data every 10 minutes, and sends it to a data collector through a wireless connection (with CC1352). Hence the battery use is strongly asymmetric: we will have approximately 10 uA for 10 minutes and 30-40 mA at maximum for a few seconds.

    We need a way to estimate the remaining battery life: a true SoC would be our best choice, of course, but we can also accept a less accurate solution. So, what is our best chance to get an acceptable (say, +/- 10%) estimate?

    I am thinking abou two possible solutions:

    1) using Accumulator Mode, we could estimate the average current consumption; this should be done only when our device is in its active state (as the extra current drawn by BQ35100 would be too big for the sleep state), and only a few times per day (say, 10-15 times), in order to save the BQ35100 internal data flash (see Technical Reference Manual, §5.1.1, Caution warning).

    2) our device's long term average current consumption should be well-known due to its nature: the repetitive tasks should help in this estimation and we could take some deviations into account by adding an extra percentage. The BQ35100 EOS mode would then help us to check (and correct, if necessary) that estimation and, at the same time, give an accurate information about the battery end of life.

    Both solutions are very approximate, and maybe they can be combined together in order to improve the final result. But what approach do you think would be our best choice? Do you think there would be a third choice? Or perhaps there is something more we can do?

    And, finally, about calibration: can we use the BQ35100 evaluation board and a load equivalent to our device active state consumption in order to generate a golden file? How can we upload the golden file into BQ35100 in our final device? I2C?

    Thanks in advance (and sorry for the long post...)

    Regards,

    Stefano

  • Stefano,

    Which mode to use should be pretty easy to establish based on the battery you plan to use. 

    ACC - No SOH information. This would be useful in capturing the "Actual" current during the broadcast. should be alseep the rest of the time and you host would need to handle the 10uA average since the gauge has no reference of time. You can always read the "passed charge" and store it locally and not commit to flash if you are worried about flash wear out. We do write different pages so wear out is unlikely. 

    SOH Mode - for LiMn02 SOH reported on voltage. Battery should be relaxed when you wake. 

    EOS Mode - For Li-thynol chloride cells. 

    Switching between modes can be done but isnt really recommended. 

    Updating the golden image is done via I2C. I recommend a bq.fs file which lists the I2C commands to send to update a device. 

    Thanks,

    Eric Vos

  • Hi Eric,

    ok, then we can choose between the two solutions. We will make a few tests and make our choice.

    Just a last question: do we need to calibrate our battery both for using ACC and EOS modes? Can we do it with the evaluation board?

    Thanks again

    Stefano

  • Stefano,

    Yes it is expected to perform calibration on the gauge for every board. 

    Thanks,

    Eric Vos