BQ35100: Scaled R and Impedance return always 0

Hello Victor,

Can you provide a log file of the your testing. When you apply 100mA load, does this cause a drop of atleast 100mV in the open circuit voltage of the battery? Can you send me the gg file from the gauge?

Regards,

Adrian

Hello adrian, yes there is a drop that is more than 100 mV. Open Voltage is 3.45V and voltage drop is 3.11V (read with data command Voltage 0x08).

bq35100_2025_Jan_09.gg.csv

Hello Victor,

Did you send the NEW_BATTERY command when the testing initially started?

This is pretty hard to debug after the fact, so I think the best course of action would be to go through the whole process and setup again from the start. If you have a fresh battery, lets start fresh with that battery and start over the process. 

Also, can you go into detail the whole test procedure. What type of load is happening between the learning pulses?

Regards,

Adrian

Yes, I start my experiment by sending the NEW_BATTERY command. I did not have a fresh battery when I did the command. Is this a crucial step to be sure that the BQ35100 detects the impedance change with short and long trend. I am getting values for short and long trend, but the difference is at maximum 0.03 %.  (e.g., Short 819809, Long 824544). I ran my test for 10 days and I still did not get any impedance and scaled r update (always 0).

To have reproducible builds I am using an electronic load (MP710772).

Best regards
Victor

Hello Victor,

Yes, it is crucial to send that command with a fresh battery. Also, are you following the guidelines based on this app note: https://www.ti.com/lit/an/sluaal7/sluaal7.pdf

Regards,

Adrian

Yes, I have read application note SLUAAL7.

I updated the chemistry information with BQ Studio and set EOS mode. Then in my test firmware I send only once the new battery command at the beginning of the test. Afterwards I do the following actions in a loop and print relevant information (Trend, impedance, Alert status, OCV errors)

Loop:

1. Set GE pin HIGH.
2. Wait for INITCOMP to be 1.
3. Turn on the electronic load (100 mA)
4. Set Gauge start command
5. Wait 10 seconds
6. Set electronic load to 40uA (simulate sleep)
7 Send Stop command
8. Wait for interrupt from ALERT pin with G_DONE flag.
10. Set GE pin LOW.
11. Wait for 15 seconds.

From my tests the following behaviour as explained in the Technical Reference manual (sluubh1c) is working:

1. When sending the stop command, after "R Data seconds (0x4255)", G_DONE sets to 1.
2. After Pulse threshold count reaches the threshold (0x425E):
    a.  register R Table Scale Update Flag (0x425A) changes to 0
    b. R Table Scale (0x4257) changes from -1 to a positive integer value.
    c. Short Trend (0x4260) and Long Trend (0x4264) change from 0 to an integer greater than 0.
3. Current command (0x0C) and Voltage command (0x08) are accurate.


Just as additional info, I changed the EOS Pulse threshold count  (0x425E) from the default 120 to 10. Should I change it back to 120 ?

I will order some new Batteries to ensure that I can run again the test.

HEre is a graph with the last test I ran for 10 days, just in case the values seem odd or you spot something that is not right

Hello Victor,

You can have EOS pulse threshold count set to 10 for now (for testing purposes), you can change this to an appropriate number once you get a full complete data set from testing.

I want to change your test procedure slightly.

1. Same as before

2. Same as before

3. Set Gauge start command

4. Wait 1 second, then apply 100 mA

5. Wait 2 seconds, then completely turn off load

6. Send gauge stop command

7. Wait for interrupt from ALERT pin with G_DONE flag.
8. Set GE pin LOW.

Now for step 9 this is what I would recommend, you should discharge the battery 1% SOH and then let the battery relax for 5 hours and then loop back to step 1. We want to do this to gather the impedance data for each SOH step of the battery to track the impedance of the entire battery. Now this testing could take a while, so you could also do a discharge of 2% SOH.

I fear that your procedure is taking EOS measure too many times since there is only a 15 second wait before gathering new EOS data. That is not what this mode is designed for.

Regards,

Adrian