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: Changing battery capacity

Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: GPCCHEM, BQ34Z100, EV2400

Hello there,

I have a question regarding this one:

In that thread we have obtained help in configuring the BQ34Z100-G1 device to work with 2S lead acid cells 5000 mAh each. Now we need to use the same config, but the cells are replaced with a bigger ones - 8000 mAh. I have loaded the old config and changed:

  • Design capacity from 5000 to 8000,
  • Design energy from 10000 to 16000.

Then I have charged the battery to full. The problem is that the design capacity remains 4730 mAh (see bellow screenshot). Now I am discharging the cells through a 10 ohm resistor.

I have also attached the gg.csv file. What am I doing wrong here?enersys_e.gg.rar

I would appreciate all help regarding this problem.

  • Hi Lukasz,

    With the new cell, please determine the chemID of the new cell using the GPCCHEM tool. With the chemID matched, please use the chemistry tab to program the new chemID to the gauge.

    the gpcchem tool and instructions may be found here: http://www.ti.com/tool/gpcchem

    Sincerely,
    Bryan Kahler
  • Hello Bryan, thanks for answer. I knew which chemid it is, since its the same battery but higher capacity. knowing the chemid I have programmed it again but the Full Charge Capacity did not change

    I am still discharging those cells. Would it update after next full recharge?:

  • Hi Lukasz,

    If they are the same cell and the percent difference in capacity is within qmax update limits, then yes, qmax will update to reflect your new capacity after the completion of a learning cycle.

    For this learning cycle, please set the maximum qmax change parameter to 100%. This value may be reduced after the learning cycle is complete.

    Sincerely,
    Bryan Kahler
  • Hi Bryan, thank you for answer.

    So to summarize the method (please correct me anywhere I m wrong):

    1. I remember my current Max QMAX Change value,
    2. I change Max QMAX Change to 100,
    3. I discharge the cells fully,
    4. I charge the cells fully,
    5. I enter the old Max QMAX Change,

    Is that correct? Or should I change something more for the learning cycle?

  • Hi Lukasz,

    If using a gg.csv from an already learned gauge, yes. Please make sure to add in time for allowing the cell to fully relax after full charge has been reached, and fully relax after full discharged. Please monitor the qmax of the device as well as the values in the RA tables to ensure they have updated.

    Alternatively, you could set learned status = 0x04 and perform the learning cycle (as you did with the last pack). This way you will be able to monitor the gauge as status changes from 0x04 to 0x05 and then from 0x05 to 0x06.

    Sincerely,
    Bryan Kahler
  • Hi Bryan,
    I will try your first suggestion first asap and let you know the results. Thank you very much for help.
  • Hi Lukasz,

    I look forward to seeing the results.

    To help aid others with a similar question, could you please leave this thread as 'TI Thinks Resolved.' This indicates that TI believes the question has been answered. If there are issues with the test, please feel free to post in this thread or a new thread and link to this thread so we may continue the discussion.

    If testing goes well and you can confirm that the advice helped resolve your issue, please click on the green 'resolved' button.

    More information on this system may be found here: e2e.ti.com/.../694649

    Sincerely,
    Bryan Kahler
  • No problem. I will let you know at the beginning of the next week. Thank you.
  • Hi Bryan,

    So today Im back at work and wanted to discharge the cells charged during the weekend and change Qmax before that. The problem is that the Maximum Qmax Change was already set to 100:

    I will now start to discharge the cell, but I havent set this value before. Why did it change by itself? Should I just discharge now and hope for Qmax Cell 0 to change itself to around 8000 mAh?

  • Hi Lukasz,

    100% is the default value for Qmax with this gauge to allow for removable batteries with the gauge being system side. The advice was incase you brought this value in from default.

    When pack side, this value is normally brought in so an erroneous reading that would may a resultant, erroneous, large shift in Qmax would be discarded.

    Please run a charge and discharge cycle. Two complete discharges may be required to see both the Qmax and RA tables update.

    If issues persist, please set update status to 0x04 and perform a learning cycle with 2 complete discharge cycles.

    Sincerely,
    Bryan Kahler
  • Hi Bryan,
    Ok, so today I left the batteries discharging at the office. Tomorrow morning they will be left at around 3.3V. I will check the Qmax values and perform a full charge. Thanks.
  • Hi Lukasz,

    Sounds good. Just as a reminder, with Lead Acid, the Qmax and Ra tables update only on a discharge. If you see one has updated but not the other, please perform another discharge.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    After I turned on Bq studio today on the discharged battery I noticed that the capacity finally changed!

    I am charging the batteries now. Is there anything else I should change before I export the file for production?

  • Hi Lukasz,

    Please check the RA tables to confirm they have updated as well.

    Here is the old going to production guide for the bq34z100: www.ti.com/.../slua665

    A newer version with respect to the bq34z100-g1 should be released soon, however, there are important details that are not toolchain specific in the document that should be of note.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    The battery is now fully charged with correct real capacity. The problem is that the RA values are exactly the same as in previously programmed packs with 5000 mAh batteries.

    This is the old pack:

    And here is the new one:

    What does this mean?

  • Hi Lukasz,

    The RA tables have not updated. If the RA Flags for the other device are also ff55 and ffff, the RA tables have also not updated beyond default values for your first device, either.

    To ensure the RA tables do update, please set update status = 0x04 and perform a learning cycle. Since this chemistry is lead acid, this will require 2 complete discharges.

    Sincerely,
    Bryan Kahler
  • Hi Bryan,
    Ok so I have set the update status register to 4 (was set to 2) and now I am discharging the fully charged cells. What should I do after 2 discharge cycles? Should I check for update status to become 5 and then manually set it to 2?
  • Hi Lukasz,

    It will automatically update from 0x05 to 0x06 during rest after the second discharge. After it sets to 0x06, manually set it to 0x02 after testing SOC performance in preparation for production. Also manually set other parameters such as cycle count to 01, and other parameters to 0, as discussed in the going to production guide linked above.

    Sincerely,
    Bryan Kahler
  • Hi Bryan,

    I have completed 2 full discharge cycles. The SoC is 0% now.  The problem is that the Update status is set to 4, not 5 or 6. The RA tables did not update as well.  What should I do?

    Additionally, my design capacity went back to ~4700 mAh, and it was ~7800 mAh already (correctly). I am wondering either the problem could be that during discharge SoC did not drop to 0% at once. It was dropped to 2 % and alert pin disconnected the discharge resistor. I then manually discharged it down to 0 % 1 day layer. At this point I set the following values:

    In my hardware configuration #Alert signal is used to cut the load:

    So with the current config, I hope the load is going to be disconnected exactly at 0% SoC or 3.1 V. Is that correct for learnig cycles?

    I need to add that I cannot really turn the alert protection off, because I am unable to manually disconnect the load just in time- it would be night and I am at home, not in the office. If I would not disconnect it and there would be no #alert configure, the batteries would be drained completely.

  • Hi Lukasz,

    The cell will bounce back after terminate has been reached. The device does not need to hit 0% on a discharge to learn qmax. With lead acid the required DOD drop is only 50%. Please send your gg.csv file from before the test, after the test and the log of the test so I may analyze the log and offer suggestions.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Ok, thank you for help. In that case I am now attaching the pre-test gg file:

    before_test_charge.gg.zip

    At this point the battery is nearly fully discharged. I am now turning the logging ON and starting to charge the battery.

  • Hello Bryan, here I attach the registers and logs after some charging time. The logs are chopped on many files, because the EV2400 device was keep disconnecting from USB. I had to manually reconnected the EV2400 and restart the application. After a while, I replaced the EV2400 device with the EV2300 device- it works correctly. The test08 log is obtained using EV2300. I have managed to only charge the device to around 65%, as now I have to leave the office. I will leave the logging ON for the weekend if fully charged log is needed by you.

    6470.data.zip

    I will continue the charging process now. I am saving the log in a cloud based folder. The Battery management studio software is kind enough to close to file after each log line is appended. This means The file will be gradually updated and I will be able to check when the SoC is 100% from home and post it here. Please let me know either you need me to do anything else.

    PS: The EV2400 is not working correctly since it keeps disconnecting. What can I do with it? This happens only during charging the device.

  • Hi Lukasz,

    I look forward to seeing the full log. 

    With respect to the disconnections of the EV2400, please ensure that the unit is upgraded with the latest firmware found here:

    Could you tell me more about your environment?  What version of windows are you using?  Is the device plugged into a hub?  If so, please directly connect the EV2400 to the USB port on your computer.

    If this does not improve the situation.....

    As a test, please go into device manager on your computer and open up the USB host controller that controls the USB port that the EV2400 is plugged into.  Please disable the 'allow the computer to turn off this device to save power' option.  Please let me know if the issue is resolved after this test.

    Sincerely,

    Sincerely,
    Bryan Kahler


    Find out more about the BQ34Z100-G1 including technical documents and tools/software/firmware and frequently asked questions.  To get up and started, please refer to the quickstart guide, learn how to find your chemID and perform voltage and current calibration.


  • Hi Bryan, thanks for answer.

    The EV2400 is connected to the PC using a hub inside a monitor. The monitor is connected to the docking station. Eventually, the docking station is connected to the PC with USB C port. Monday morning I will try to connect the EV2400 directly to the PC, but I doubt that is the problem. Like I said, this occurs only during charging. The device is up to date, I remember checking that like 2 weeks a go regarding this topic:

    As for the OS, I am using Windows 10 64 bit. If connecting the device directly wont help, I will disable power saving in device manager like you said. But since its a generic ftdi driver as far as I recall, then it should be fine, as I use FTDI in other devices all the time.

    As for the logging, the SoC is 81% now:

    test09.zip

    The charging current is very low now and 100% SoC will be reached probably tommorow. I will post the file after its 100 %. Please let me know in case you need any more info.

  • Here is the 100 % charged battery log.

    8463.test09.zip

  • Hi Lukasz,

    Thank you for the charging potion of the log. Please allow the device to fully rest before beginning the discharge portion (followed by a rest).

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Here is the gg file after full charge (should come along with the full charge log):

    after_full_charge.gg.gg.zip

    There are only 2 differences between this file and the one obtained before charging:

    1:

    Before: "Gas Gauging","State","Cell V at Chg Term","2235","mVolt"

    After: "Gas Gauging","State","Cell V at Chg Term","2185","mVolt"

    2:

    Before: "Calibration","Data","CC Offset","-1410","num"

    After: "Calibration","Data","CC Offset","-1413","num"

    But i gues this is not unusual?

    I will not proceed with discharge logging.

  • Hello bryan,

    Here are the discharge files (log and gg file).

    disch.zip

    The discharging stopped at 1 %, meaning that there is an error in the datasheet:

    And my SOC1 Threshold was set to 1, meaning the #ALERT should trigger only after 0 % SoC is reached, not 1 %, like it did. Do I understand correctly?

    I hope all the files I provided will be helpful. The Full Charge capacity register is still faulty. Please let me know the next steps as soon as you will be able and have time. Thank you.

  • Hi Lukasz,

    Thank you for the updated logs, I will analyze them and provide an update by EOD Friday.

    Sincerely,
    Bryan Kahler
  • Hi Lukasz,

    My apologies for the delayed response - you're correct, the SOC1 parameter should read as less than or equal to.

    More accurate wording is found on page 16 of the datasheet ---- SOC1: State-of-Charge Threshold 1 reached. True when set.

    Sincerely,
    Bryan Kahler
  • Hi Bryan,
    No problem.
    Till the end of the week I wont have the possibility to test the setup. Still, please let me know if you were able to find something out. The battery capacity is long stuck at around 5000 mAh instead of 8000 mAh and the status does not change. Looking forward to your answer.
  • Hi Lukasz,

    Could you please send the chemID command and chemID checksum command and send us the results? What values were returned by the chemID and chemID checksum command?

    I have sent you a PM with further steps for the chemID.

    From the logs, it appears that the discharge is right on the edge of the 50% DOD drop required for learning. Please reduce to discharge current on the next discharge.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Here is the chem_id command and checksum:

    I will now discharge with reduced current and let you know.

  • Hi Lukasz,

    Thank you for the update. The chemID looks to be programmed properly. Looking forward to the new logs with reduced current.

    Two charge/discharge cycles will be required to update from 0x04 to 0x06. The updates should occur after each discharge.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,
    Here is the 1st discharge log:
    dschrg_20R.zip

    I will now charge the batteries again, then discharge and provide both logs.

  • Hello Bryan,

    Here is the charge log. Unfortunately, the EV2300 adapter stopped working at around 70% SoC. I connected it again today morning to read a short log for you after the full charge. I will now wait a while and start the second (slow) discharge.

    logs_chrg.zip

  • Hi Lukasz,

    Thank you for the logs. Can you consolidate them when sending the discharge log?

    Sincerely,
    Bryan Kahler
  • Hello Bryan,

    Sorry for this, since this one all logs will be consolidated if communication fails. Here is the discharge log:

    dschrg_20R_2_cons.zip

    The learned status did not update, and this is the second discharge...

    Also, please notice an interesting feature. In this application, the #ALERT signal disconnect the load from the battery. The #ALERT asserts when remaining capacity drops to 1 mAh or voltage drops to 3.2V. Then in order to be deasserted, remaining capacity needs to go up to 100 mAh if I remember correctly, and voltage above 4 V. The interesting fact is that the battery seems to be "self charging". In the log you can see that after the discharge, over time, the remaining capacity goes up to 120 mAh (3% SoC). Although I can understand how does the voltage on the battery ramps up after the load is disconnected, why is the SoC growing?

  • Hi Lukasz,

    Thank you for the logs. I'll analyze and due to heavy loading, update this thread by EOD Friday.

    Sincerely,
    Bryan Kahler
  • Hello,

    No problem, thank you.

  • Hello Bryan,

    For couple days now the battery is left discharged. I have noticed that according to BQ it is charging itself (even thought there is no external charging, only internal loads). After some days it self charged up to 4%:

    Can this be due to some invalid Bq chip configuration? While I can understand why does the voltage ramps up gradually, I dont get it for the state of charge.

  • Hi Lukasz,

    Have you calibrated (1) board offset and cc offset (3) voltage and (3) current for the device? If not, please make sure to do so

    Ghost current may be caused by small sense resistors or noisy boards - if this is the case, please increase the value of the Deadband parameter. Please log the board at rest to determine if the rise in SOC is due to a 'ghost current'.

    Your gg file indicates that you are using a 10 mOhm sense resistor, so this is less likely, but if the issue persists, please log the behavior with all columns enabled so we may analyze the SOC increase at rest.

    Sincerely,
    Bryan Kahler
  • Hello Bryan, thank you for answer. Yes, the device was calibrated using the calib method you mentioned. I will log the device at rest, but could you tell me what did you mean exactly "all columns enabled"? In Bq studio I can see only a single log button.

    Also, what is the exact name for the "Deadband" parameter?

  • Hello Bryan,

    I have a discharge log ready. It was logging for about 2 days. It starts with a quick discharge and then remains calm. I have noticed some peculiar activity regarding remaining capacity... After the initial discharge, it gradually started to arise (is this the ghosting charge?), but the weird thing is that around 40-50 mAh left it restarted to 0 in order to start rising again. Please take a look at the log anytime you have a chance.

    PS: Disconnecting the EV2300 from the docking station and connecting it directly to the laptops USB port seemed to help regarding the tool periodic disconnection.

    dsch_ghost.zip

  • Hi Lukasz,

    Thank you for the updated log.  I'm glad to hear that removing the external hub helped resolve the connectivity issues with the EV2300.

    To ensure all columns are logged, please perform the following steps:

    1. In Window > Preferences > All Global Settings select advanced views as shown below:

      This will allow you to see the checkboxes for log and scan in the registers and bit registers windows.  Please ensure that all are selected, as shown below:

    2. In Window > Preferences > Data Memory please select Export All Columns so all Columns are exported in the gg.csv file

    Sincerely,

    Bryan Kahler

  • Hi Bryan, thank you for answer.
    I checked everything like you instructed and will continue to log. Tomorrow morning I will send you the new log.
  • Hello Bryan,

    Here I attach the further log file file, after all the settings fixing after your post.

    dsch_ghost_2.zip

  • Hi Lukasz,

    Thank you for the updated log. Due to current loading, will have a response by EOD Thursday.

    Sincerely,
    Bryan Kahler
  • Hello Bryan,
    No problem, thank you. Looking forward to your answer.
  • Hi Lukasz,

    Could you please send me a log of your entire learning cycle?  All I see in the last log is a gauge resting at 0 current.  I have included the image below.  The voltage looks to be bouncing, but this an effect of the scale (4 mV difference).  The reported voltage in this log is between 3866 and 3870 mV. That being said, the format of the log is excellent and there are very few communication errors this time.

    Sincerely,
    Bryan Kahler