BQ28Z610EVM-532: Using the GPCRB tool, but getting an error that Ra table could not be extracted from GG file

6574.GPCRB.zipHere is my zip file:

Thanks so much for your response Nick. I resubmitted after reprogramming the chem IDK4.zip

But I got the below error



It doesn't specify what went wrong, but maybe something with the procedure? Do you know what this could be from? I didn't stop the log until long after the final stage (I'm usually discharging in the evening and then letting it relax through the night, then I stop the logging in the morning)

Could it be something like that? Should I try deleting part of the end of the log files? Or did something else go wrong during the charge, relax, set temperature, discharge, relax procedure?

Thanks,
Kelvin

Hey Kelvin,

Send me the zip file that you submitted to the tool so I can check it.

Regards,

Nick

Hi Nick, I attached it in my previous message

0003.K4.zip

Thanks so much for all the help

Hey Kelvin,

So sorry, I missed it in your previous message. I believe the issue is column 0 should be elapsed time and not the time stamp. The GPCRB tool is expecting this column to always be increasing.

Regards,

Nick Richards

Hi Nick,

Thank you so much. I modified the roomtemp and lowtemp csv files, where I made a new column for elapsed time. It still didn't take it, so I formatted the time column into a "general" cell instead of a time formatted cell. I have it exactly as the example shown in the GPCRB documentation, but it still gives the same error. I also changed the config file to account for the new columns for time, V, I, and T

Is there some other formatting issue I have here?
K6.zip

Thanks,
Kelvin

Hey Kelvin,

Looks like there is still formatting issues. The elapsed time column still has some formatting issues. It will sometime show "#VALUE!"

Regards,

Nick Richards

Hi Nick,

Thanks so much for the info. I was able to get the formatting correct and then get back the GPCRB results.

I programmed the new chemDAT ID, and then imported the new gg. Both were from the GPCRB output.

However, at cold temperature I'm seeing that there is a hold at cold temperature 0% SoC.

I have a simple setup with only the battery connected to the gauge, and I'm charging and discharging using a power supply. connected to Pack+ and Pack- of the gauge. I'm charging with 1A current

I see that at 0C, it takes a long time to reach 1% SoC, about 16 minutes of charging. I thought there was some issue with a hold setting (Like the Lock0 bit, but I have that bit disabled), so I tried the same scenario at 25C, and it only took 3 minutes of charging to go from 0% to 1% SoC. I know at cold it should take longer because of higher impedance of the cell, but I think there is some issue here with some setting.


0C vs 25C 


Is there a specific setting that is causing this hold at cold? The strange thing is, I did a little bit of testing without the GPCRB output and it didn't have this long of a hold. I think something may have changed with the GPCRB to cause this. Maybe something in the low temp charging section of the advanced charging algorithm? Here is my gas gauge file:

GPCRB_Loaded_HoldAtCold.gg.csv

Log results for 0C and 25C (quick tests): 0C_Charge_BadHold.log25C_Charge_HoldQuestion.log

Please let me know if you need me to create a new question since this is a different topic. Thank you for your help

Hey Kelvin,

Please allow me some time to look over this. Can you also send me the current gg file from the gauge.

Regards,

Nick Richards

6076.GPCRB_Loaded_HoldAtCold.gg.csv

Hi Nick,

Thanks for your help! The GG file is attached in my previous message but I also attached it here. I suspect it has something to do with the low temp charging section because the hold at 0% SoC only occurs at 0C, not at 25C. However, I'm not sure how to configure this and the TRM doesn't say much about low temp charging other than default values.

Thanks,
Kelvin

Hey Kelvin, 

Thank you for the gg file. I must have missed it in your previous response. Can you also send me the report zip file that you got from GPCRB tool and also send me the srec file from your gauge. I first want to verify that the file that was given in the report zip was programmed successfully just to cover all bases.

Regards,

Nick Richards

GPCRB_Results1.zip

Thanks Nick, I just exported an SREC file, and then put it in a zip folder along with the results from the GPCRB tool

Thanks,
Kelvin

Hello,

Today's a national holiday. We will get back to you tomorrow.

Regards,

TI Apps Team

Hello Kelvin,

I made some changes to the settings in the data memory. I saw that the Ra table was not updated properly according to the gg_out file in the zip file. I made that update, try this new srec file and let me know if it resolves the issue you are seeing. 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/KELVIN.srec

Regards,

Nick Richards

Thanks a lot Nick!

I loaded the SREC file in the programming tab of BQ studio. I saw the Ra table update:



Now I'm starting a basic discharge test at 0C. Hopefully the hold at 100% SoC and 0% SoC (during charge) doesn't happen. I will let you know the results when its finished, thanks!!

Best,
Kelvin

Hey Kelvin,

Sounds good, keep me updated!

Regards,

Nick Richards

Thanks Nick,

It resolved the hold during discharge. It doesn't take a long time to decrease from 100% to 99% at 0C anymore so this worked. But for charging at 0C, the hold is still there. It takes about 20 minutes to change from 0% to 1% with a 1A current from the power supply:



0C_Charge_Hold_NewSettings.log

This did happen before at room temperature, and I got advice from Jonny to disable the lock0 bit. That did fix the problem at room temperature, but at cold I am seeing this still happen at the beginning of charge (I confirmed that the lock0 bit is still disabled)

One thing I did do this time was begin charging when the battery voltage was 6.0V. (I have the discharge voltage set to 6.2V). From my understanding, the gauge should still increase SoC soon after the charging, right? Is there another setting that I may have wrong that is causing this hold at the beginning of cold charging? Do I have to perform more charging cycles at 0C for it to learn?

Thanks,
Kelvin

Hello Kelvin,

Can you send me the current srec file that is programmed on the gauge. I can look through the settings to see if there is anything else that needs to be changed.

Regards,

Nick Richards

Hi Nick, it is the same SREC that you gave to me, I didn't make any changes, just loaded the SREC, did a charge test at 0C, and then a discharge test at 0C. Here it is (it wouldnt let me attach the SREC directly, so I put it in a zip file with my gg file):
NewSettings_HoldAtColdCharge.zip

Thanks a lot for all the support!
Kelvin

Hey Kelvin,

Thank you for sending me the new files, allow me some time to review them. I asked for the most current SREC since the gauge updates parameters like Qmax and Ra table every cycle. I just want keep all the settings up to date.

Regards,

Nick Richards

I see, thanks so much! They likely were updated because I did 2 cycles at 0C and -10C

Thanks,
Kelvin

Hey Kelvin,

Sorry I am extremely backlogged at work currently. I should get back to you later in the week.

Regards,

Nick Richards

No worries, thanks so much for all the support!

Hey Kelvin,

Is it possible to get a full bqstudio log file, there are some other registers I would like to check to help me narrow down the root cause for the issue.

Regards,

Nick Richards

Hi Nick,

I collected a log file for a charge cycle at 0C. Here is the log: Charge_0C_Hold_LOG.log

This happened to be an exaggerated case. Before, it would take about 20 minutes to go from 0% to 1% with a constant 1A charge. This time it took much longer:



Please let me know if you need me to collect any more logs in a different scenario

Thanks,
Kelvin

Hey Kelvin,

This issue you are seeing is very strange and is probably going to take a lot of back and front of trying new settings. Can you change Charge Term Taper Current to 50mA. Then run 2 cycles of a charge, rest, discharge, rest.

Regards,

Nick Richards

Thanks Nick for the suggestion. I will begin doing that now. The GPCRB test that I sent in was done at -10C (room and -10C). If I want to optimize for 0C or -10C, should I do the 2 cycles of charge, rest, discharge, rest, at 0C? Or just perform the cycles at room temperature, and then decrease to 0C after?

Thanks,
Kelvin

Hello Kelvin,

Do the cycles at -10C since this is the temperature you optimize the gauge for.

Regards,

Nick Richards

Hi Nick,

Thanks, this battery is only rated to charge at 0C, so I will do the cycles at 0C.

Also, is it okay that I discharge down to 6.0V, instead of 6.2V? (6.2V is what I have listed as the full discharge set voltage). My setup is just the battery itself connected to the gauge, and using a power supply to charge and discharge. Would it learn anything incorrect if I discharge to 6.0V instead of 6.2V?

Thanks,
Kelvin

Hello Kelvin,

No, you should discharge to 6.2V since this is what is set as the terminate voltage on the gauge. It will affect the gauge learning.

Regards,

Nick Richards

I see, so I think this is what caused the problem. I was discharging to 6.0V for a few cycles before.

So how can I have it "unlearn" those previous 6.0V cycles? Can I just perform the charge and discharge cycles but this time, only discharge down to 6.2V, and it will adjust? Or will I have to reprogram the GPCRB output that you sent above and then do the cycles?

Thanks,
Kelvin

Hey Kelvin,

I don't think it is necessary to unlearn the previous cycles. You can just run additional cycles, and the gauge will adjust as it continues to learn. However, I would recommend reprogramming the GPCRB output and make the other changes we made before and then starting fresh.

Regards,

Nick Richards

Hi Nick,

I did your recommendation of reporgramming the GPCRB output, and then having it learn at 0C, this time only discharging to 6.2V. I did several charge and discharge cycles, probably about a dozen at this point. But I still see that it takes 20 minutes to go from 0% to 1% during charging at 0C. This doesnt happen at 25C, and it didn't happen before I did the GPCRB at 0C.

Is it possible that the GPCRB data is somehow bad or made it worse by having it learn something incorrectly?

If not, I may just get rid of the GPCRB altogether for 0C charging

Thanks,
Kelvin

Hello Kelvin,

I might have a solution, however, I would need you to send me the current srec file from the gauge.

Regards,

Nick Richards

Thank you Nick, here is my SREC: CurrentSREC_8_9.zip

(I zipped it because of that bug where it doesn't let me attach the .srec file directly)

Thanks,
Kelvin

Hello Kelvin,

Thank you for the file. Allow me some time to make some changes to the configurations.

Regards,

Nick Richards

Hi Nick,

I was able to find something that helped with the hold at 0% SoC during charging at cold. So the issue was that charging would take 10-20 minutes of charging at 1A to finally change from 0% to 1% at 0C. So during a discharge cycle 0C, I would stop discharging as soon as it went from 100% to 99%, and then let the voltage settle for about 20 minutes. Then I continued discharging. Then when it hit 0%, around 6500mV or so (discharge voltage is 6200mV), I stopped discharging again, let the voltage settle, and then continue discharging to 6200mV. Then let it relax, and then begin the charging cycle

When the charge cycle began, I saw that the hold at 0% was fixed. However, it looks like the hold just transferred to the end of charge, because now it instantly jumps from 94% to 100%:

0C_Charge_Real.log

Maybe this could indicate that the gauge benefits from learning near 0% and 100%? Is there anything I can do to stop the jump from 94% to 100%?


Thanks,
Kelvin

Hello Kelvin,

Sorry for taking a while to get back to you. I was out on a business trip. After looking back at everything I believe the issue might be this one setting in IT Gauging Configuration. I believe the CSYNC bit is set to 1 on your gauge. Please change this bit to 0 (green) and run 3 new cycles with this settings and see if this fixes the jump.

Regards,

Nick

Thanks Nick for the suggestion. I will do that now

Sounds good, let me know of the results from the testing.

Regards,

Nick

Hi Nick,

I've done two cycles now at 0C, and charging is significantly improved! There is no hold at 0%, and there's no jump from 94% to 100%. However, there is still the issue during discharge where there is a hold at 100% (It takes about 7 minutes of discharging at 1A current to go from 100% to 99%). Would CSYNC affect this? I see that CSYNC allows remaining capacity to equal full charge capacity at the end of charge. Full charge capacity is the capacity value that comes from the GPCRB tool, right? And remaining capacity is the learned value from charging/discharging cycles? Wouldn't it be better to have this bit enabled so that we can use the learned capacity?

Anyway, is there another setting I can change to get rid of the hold at 100% during 0C discharging?

Thanks,
Kelvin

Hey Kelvin,

Can you send me the log file so I can look at the data. Can you also send me the latest gg file. Full charge capacity is the value that is calculated by the gauge after every cycle, therefore this value is constantly being updated. Having this bit enabled was causing the remaining capacity to jump at the end of charge which also caused SOC to jump which is unrealistic in your application which is why it is best to leave that disabled.

I will need to look through the current gg file and log file to determine the next step to see why is holds at 100%.

Regards,

Nick

HoldAt100_Log.log

Thanks Nick! Above is the log file. Sorry that it is so long, I forgot to stop the log over the long weekend.

Latest GG: Latest_gg_Holdat100_.gg.gg.csv

Plotted SoC showing long hold: Discharge_Hold_Log.xlsx

Hello Kelvin,

Thank you for sending me those files. I will need some time to review them.

Regards,

Nick

Hello Kelvin,

Sorry for the delay, I have reviewed the files and have determined what I believe might be the reason for the hold at 100%. Can you please send me the latest srec file from the gauge. There will be some changes I need to make to data memory on my end.

Regards,

Nick

Thanks Nick, 

Here is the SREC that I just got now: Newest100Hold.zip

(I had to zip it because it wouldn't let me attach the SREC file only)

Hello Kelvin,

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/forKelvin.srec

Here is the updated srec file.

Regards,

Nick

Thanks so much Nick

This fixed the issue at 0C. What was it that changed? I noticed that there is no hold at 0C, but I tried discharging at -10C with this same SREC right after, and it takes 7 minutes of discharging at 1A to change from 100% to 99%. Is the change simple enough where I could do it myself for -10C as well?

Thanks,
Kelvin

Hello Kelvin,

Whenever you did the GPCRB tool, was the test done at 0C or -10C. The change I made will apply for all temperatures. However, the GPCRB tool optimizes the parameters for the certain temperature that the gauge will be used for.

Regards.

Nick