• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ34Z100-G1: SoC% changing to 0 randomly.

Karlis Tucs77
Intellectual 320 points
Part Number: BQ34Z100-G1

Hi. 

Sometimes some of our batteries which are equipped with BQ34Z100-G1 drop their SoC% to 0 and never change it.

This happens pretty randomly and usually after couple of cycles have been completed.

Can some of you please check the .gg file of our battery parameters?

We have not managed to recreate this "bug" in our lab environment, so there is not really more information to provide.

Any help will be appreciated. Thanks!

27.3.2017. bq34z100-g1 big battery product settings.gg (2).csv

  • 0
    TI__Mastermind 19195 points

    Hi Karlis,

    1. Does the chemID match the cells?
    2. Have you completed a learning cycle?

    You can check to make sure that the smoothing function is enabled. 

    Best regards,

  • 0 in reply to Nick Brylski
    Intellectual 320 points

    1. yes

    2. yes. Update status register shows - 0x6 which means learning cycle has been successfull.

  • 0 in reply to Karlis Tucs77
    TI__Guru** 105590 points

    Hello Karlis,

    What were the conditions the SOC stuck? Is it after resting for a period of time then charge, or is it just immediately stuck at 0%?

    There's registers to that can control the RSOC value in pack config C, changing these so the RSOC doesn't ever lock may fix the issue.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 320 points

    From info that I gathered it seems that after these 3 steps 0% appears in various scenarios. I does not happen always, but often enough to be bothering and costly to fix. We usually rewrite the .srec file to batteries to fix it, but it means customers must ship those batteries to us.

    1. Battery gets discharged to 0% 

    2. Battery gets charged to 100%

    3.Battery gets discharged to approx. 30-40 %

    0% appears in various cases:

    A. On the next day batteries is connected to load and shows 0%.(we do not know if it showed 0% before load, because the load is device which reads this SoC% and discharges the battery, it's camera)

    B. Battery is put in shelf in storing for few months. Then it is connected to load(camera which also reads SoC) and it shows 0%.

    C. At customers side, We do not have precise info if batteries have even been used. But we know for sure that we do not ship them with 0%.

    About what values in Configuration C register are you talking about? From these scenarios it seems like the learning cycle is not completed, but update statusu register shows 06...

    Thanks in advance

  • 0 in reply to Karlis Tucs77
    TI__Guru** 105590 points

    Hello Karlis,

    Is there any way you could share a log of the data? It is hard to debug what possible issues there could be without the log. Is the .gg file you shared after the SOC jump, was it exported from a bad pack or is it your golden file for original programming.

    We have seen some cases where the Ra values cause some SOC jumps, in your lab setting can you try increasing the Ra tables manually (maybe by 20%) to see if this is duplicated?

    Pack Config C is used to lock the RSOC at certain values, which originally it looked like may be happening.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Intellectual 320 points

    I added .gg file of 0% SoC battery to this reply.

    I will try to arrange some logging for batteries. Bad thing is that we do not know precise moment when this happens. 

    Ar_0%.gg.csv