• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Subscribers 63 subscribers
  • Views 2315 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 full charge relax results in drop in SOC

Bryce Billing
Intellectual 260 points
Other Parts Discussed in Thread: BQ34Z100-G1, BQSTUDIO, GPCCHEM, GPCCEDV

Hi There,

Getting some pretty good results with my system so far with the bq34z100-g1 and a 4S LiFePo4 pack - I have one last problem.

After charging, when the pack goes into relax, when the bq34z100-g1 measures OCV, the SOC drops by a few percent, from 100% to 98%-95%, differs each time.

Is there a setting that can stop this or is it actually indicating that the battery is not fully charged?

See below plot, there are several charges and several discharges.

Thanks, 

Bryce

  • 0
    TI__Guru 73830 points
    Bryce
    Can you provide the log file and an srec from the pack? I need these to analyze the waveforms more closely to see whether we can improve the SOC performance.
    Tom
  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Hi Thomas,

    I've attached the srec.

    I have an EVM that I use to make the golden image, then load it onto the target hardware system - I only have one log files from the EVM at this stage with this particular which i have attached, however it doesn't show the behavior in this particular discharge as we have largely been testing without bqStudio at this stage - i'll try to gather another log file with this over the next few days with the EVM. Otherwise I have some older log files with a previous srec that demonstrate the issue, not sure if they would be useful?

    Thanks,

    Bryce

     v2_log_srec.zip

  • 0 in reply to Bryce Billing
    Intellectual 260 points

    Here is the log and srec for the image in post1, the v1 srec should be very close to the most up to date v2 which is provided in post2. The key difference is the v2 is using a different chemistry profile, recommended by the battery manufacturer, which I had hoped would help this issue, but i'm starting to think that is not the issue.

    v1_log_srec.zip

    Thanks,

    Bryce

  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Hi Tom,

    Did you ever get an opportunity to look at this?

    I'm still having this issue.

    We have found that within 24 hours the pack relaxes and the SOC goes down to 95%, this is when our maintenance recharge threshold is set for and so it is causing excessive charge cycles on the battery.

    Regards,

    Bryce

  • 0
    Intellectual 260 points

    Bump.

    I have performed some more testing over the weekend to provide a fresh bqStudio log file.

    Please find it attached.

    I'm not sure what is causing the issue, but it looks like the OCV bit is getting set too soon? It is set after ~2 hours battery relaxation, but the battery appears to take around 15-20 hours to fully relax.

    Regards,

    Bryce

    relaxTesting-13-Jan-17.log

  • 0 in reply to Bryce Billing
    TI__Guru 73830 points
    Bryce
    I reviewed your log file. The gauge checks for cell voltage stabilization over consecutive 100s windows and the voltage stabilized enough to set a DOD point at that point. The Qmax DOD point continues to update throughout the rest period as the voltage continues to drop, so this should not cause a problem with your gauging.
    Tom
  • 0 in reply to ThomasCosby
    Intellectual 260 points
    Hi Tom,

    Thanks for taking a look.
    I don't really understand. How can we stop the SOC dropping like it is in the relax period?
    Or do you think this is due to very slow discharge, so the updated SOC reported by the IC is actually correct?

    What does Qmax DOD mean?

    Kind Regards,
    Bryce
  • 0 in reply to Bryce Billing
    TI__Guru 73830 points
    Bryce
    The RM and and SOC adjustments were due to a capacity simulation and the downgrade was correct based on the voltage. You could set the RELAX_JUMP_OK bit to 0 and this should keep these values from changing until the start of discharge, but they will drop at the start of discharge. You could try using the GPCCHEM tool to see whether you can find a better ChemID match that will have a lower top OCV threshold. ChemID 401 has one of the highest top OCV thresholds for all of our LiFePO4 ChemID's. You could also try reducing the taper current to allow the cells to charge fuller and perhaps not drop as much during rest.

    The Qmax DOD is used in Qmax updates. It get adjusted during rest as the cells change.

    Tom
  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Hi Tom,

    Thanks for all the info.

    I'm guessing that if we change RELAX_JUMP_OK to 0 then the SOC will never change until the Flags:DSG bit gets set (ie: when a discharge starts)? We are using the SOC to tell us when we need to do a top up maintenance charge cycle of the battery so we would need to consider the ramifications if this would no longer change at all when we run on mains power.

    Looks like I changed the CHEMID of the cells to 437 in September last year from a recommendation from the battery manufacturer, hopefully you read CHEMID 401 from the original srec I uploaded maybe?  I've attached the most recent one if you could be so kind as to have another look please?

    By changing the taper current do you mean changing the actual charger CV termination current or do you mean changing the SOC's taper current value that it uses to register when FC occurs?

    Thanks,

    Bryce

    0100_0_16-bq34z100G1_09Sept2016_URB1270ver3.zip

  • 0 in reply to Bryce Billing
    TI__Guru 73830 points
    Bryce
    I checked the srec file and found it to contain ChemID 437. The top OCV threshold is higher than the rested OCV for your cells, so a drop is expected during rest. I suppose that I was referring to the CV termination current, although this is usually just below the taper current.
    Tom
  • 0 in reply to ThomasCosby
    Intellectual 260 points
    Hi Tom,

    Ok so i guess this is just a limitation of the device because the top OCV threshold would be set during the learning cycle (?) and there is no way to change when this occurs? If the OCV measurement is taken during the learning cycle before the cell is fully relaxed then this would result in this situation (?).

    Is it worthwhile attempting another learning cycle with some different parameters? or is it basically down to a decision to change RELAX_JUMP_OK or not.

    I will look at running the GPCCHEM tool although last time i tried I did not have much success.

    Regards,
    Bryce
  • 0 in reply to Bryce Billing
    TI__Guru 73830 points

    The OCV table is part of the ChemID and it never changes. The only way to reduce the top OCV threshold is to change the ChemID. If you have trouble running the GPCHEM program, then I can help. If you have the log file from the previous ChemID check, then send it and I can work with it.

  • 0 in reply to ThomasCosby
    Intellectual 260 points
    Thanks Thomas, I think that's what i was looking for. Do you have a link to the most up to date guide on using the GPCHEM program? I only have log files for ambient temperature discharges, how to do i tell it to ignore the other files it wants?
  • 0 in reply to Bryce Billing
    TI__Guru 73830 points
    Bryce
    The User's Guide on the GPCCHEM website is the only one that we have. I am not sure what you are referring to regarding multiple log files. Do you mean unused columns is a log file? the config file defines which columns to use.
    Tom
  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Ok i must not be defining the log file correctly, i get the following response after submitting my zip.

    I'm following "www.ti.com/.../slva725.pdf" as a guide as linked from the GPCHEM website.

    2 - Required Data The GPC tool requires a single .zip file containing one configuration file, one data file, as input. The name of the .zip file is not important. The .zip file should contain the following files: • config.txt • roomtemp_rel_dis_rel.csv

    Typical settings are: ProcessingType=2 NumCellSeries=1 ElapsedTimeColumn=0 VoltageColumn=1 CurrentColumn=2 TemperatureColumn=3

    Excuse the crude copying from the .pdf.

    Please let me know the correct settings for the config file. 

    I have a 4S5P battery and a few datafiles logged with bqStudio.

    Regards,

    Bryce

  • 0 in reply to Bryce Billing
    TI__Guru 73830 points

    It looks like you submitted the file to GPCCEDV instead of GPCCHEM. Here is a sample config file for GPCCHEM.

    Fullscreen 2727.config.txt Download 
    ProcessingType=2
NumCellSeries=3
ElapsedTimeColumn=0
VoltageColumn=1
CurrentColumn=2
TemperatureColumn=3

  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Hi Tom,

    I've just stepped through the process again.

    I'm using the tool at the link; http://www.ti.com/tool/GPCCHEM.

    Everything seems to point to me using GPCHEM.

    Attached is the zip file i'm submitting. Please let me know what i'm doing wrong.

    URB1270.zip

    Regards,

    Bryce

  • 0 in reply to Bryce Billing
    TI__Guru 73830 points

    Bryce

    I cleaned up the files and it should pass if you submit these files.

    Tom

    5773.input_data.zip

  • 0 in reply to ThomasCosby
    Intellectual 260 points

    Thanks Thomas that is really helpful.

    Re-ran the GPCCHEM tool and got some interesting results.

    Where can I find the details for sending in the batteries to be characterized (if we do go down that route?)

    Thanks,

    Bryce

  • 0 in reply to Bryce Billing
    TI__Guru 73830 points

    Bryce

    I will contact you offline.
    Tom