BQ34110: BQ34110: Cycle count does not increment after qualified discharge

Hi Peter,

Thank you for capturing the gg file, logs, and notes. I have started looking through these and should be able to reply back tomorrow.

For setting the gauging parameters, have you already submitted the needed log files to the GPCCEDV tool? (www.ti.com/.../GPCCEDV)

Best regards,
Matt

Matt - I have not submitted the GPCCEDV logs, I was hoping to solve the current problem separately before running those cycles.

Hi Peter,

Okay, let's try this. I made several changes to your .gg file to see if we can resolve some of the strange observations. My goal is to automate this process more in the near future since so many changes are needed to modify the settings based on battery chemistry. 

The parameter I suspect most is the 'FC Set Voltage Threshold' and 'FC Clear Voltage Threshold'. However, to perhaps provide a better starting point, I heavily leveraged settings from previous known working gg files for LiFePO4 batteries. Some of the parameters I have updated may not have a direct impact, but I think it is good to start with a proven staring point.

Can you load these settings and see if it resolves the issues?

/cfs-file/__key/communityserver-discussions-components-files/196/3438.acu_5F00_bq34110_5F00_lfp26650_5F00_8s4p_5F00_updated081518.gg.csv

thanks,

Matt

Matt - awesome effort! I will gladly run some cycles using your config and let you know how that goes. I may not be able to get back to this until Monday due some other current priorities this week, but this is my next task.
thanks, -pete u.

Matt - I attempted uploading the gg.csv file you prepared, from Data Memory view in bqStudio. The local updates get reflected in the bqStudio SW but when I did Write All, bqStudio just seems to do a Read All instead, and now it looks like the 34110 has done a full data reset because neither of our profile values are coming up from the chip. What's there looks similar to where I started with this, out of the box.

I am probably missing something simple, please advise ...
thanks. -pete

Hi Peter,

Sorry to hear about the troubles. I don't think it's possible for the data flash values to reset. One thing that might be preventing the data flash from being written is the 'Flash Update Ok Voltage' parameter. The default setting is 2.8V and you will not be meeting this requirement with the external resistor divider. If this is the cause, the you can work around this by pressing the CAL_TOGGLE button on the Commands panel. When you click this button, you should see the CAL_EN bit go high on the Registers screen. This will enable you to write to the device.

Otherwise, it might be good to unplug and replug your EV2400 and restart bqStudio in case communication is broken.

Matt

Matt - Flash Update OK Voltage is well above min threshold. CAL_TOGGLE did not help, even though the bq went into active CAL mode. There is an error message in bqStudio: "Value is beyond maximim value defined for parameter.:Calibration.Data.CC.Delta (set to 3.171) which makes me wonder if this problem has anything to do with my 3x scaled current (i.e. amps) calibration setup because we have to track up to 90 amps on discharge.
If you don't think scaling is a factor in this, I will probably go for a full start-over with a reload of the original .srec and rebuild that way, but I hope I don't have to go that far.
-pete

Hi Peter, Just to clarify, what is the Flash Update OK Voltage setting currently? If you are not able to modify the data flash settings, I would recommend to use CAL_TOGGLE to set this parameter to a low value (i.e. 100mV). Then try again to see if you are able to write to the data flash.
I will look into the error you are seeing on the current calibration with regards to scaling, but first I think it's important to make sure you can write the data flash settings.

Matt

Matt - at time of my previous reply, batt V was measuring just over 23.6, or 2962mV/cell. I had Flash Update OK Voltage set to 2625, and I was able to write individual changes (bit-configs, etc) to the bq. So that prompted me to go through just the diffs of your config to my config, and individually apply your values. That seems to have gone ok. I can now do a Read All from the bqStudio Data Memory page and I get no diffs to your gg.csv file values.

So at this point I am going to run a charge/discharge cycle capture again and see what happens. I'll collect the logs & configs too. Might be a couple of days to get back to you (FYI).
Thanks for the input.
-pete

Matt - thinking about the 3x scaling I use, is it necessary to apply /3 to ALL the current thresholds and mA specs across Data Mem? Case in point, if Quit Current Threshold (Configuration.Current Thresholds) is suppose to trigger at 40mA, 3x scaling would say the bq sees 40/3 (~13)mA as the crossing point. I am curious if this and other similar settings by scale are what contribute to the lack of cycle-count sensing.

regards, -pete

ACU_logs_bq34110_22-aug-2018.zipMatt - here's the logs with your configs.

let me know what you think. thanks, -pete u.

Hi Peter,

I will take a look at the logs and send a reply tomorrow.

Thanks,
Matt

Hi Peter,

I went through the logs today and noticed a few problems that we can hopefully work through.

The first thing I noticed is that the FC (full charge bit) in the GaugeStatus register never goes high. It looks like all of the required conditions are met in the log, but what I think might be happening is that the Current falls below the Quit Current which takes the device out of charge mode. This is happening very soon after the taper current is reached, so it might prevent the full charge from being properly detected. I think we need to set the Taper Current higher based on your battery capacity, maybe to 200mA (C/20).

The second thing I noticed is that the discharge at ~700mA is only taking about 5 hours before the battery voltage falls below the EDV2 voltage. I wonder if this is because the battery was not fully charged. Do you have the datasheet for your battery with charging specifications?

Thanks and best regards,
Matt

Matt - funny thing here, I posted some stuff on the old thread about this very topic which explains why you didn't reply, 'cuz you never saw it. My bad, so I'll reiterate here: 

I believe you are onto what I suspect as well. The 8s4p FPP26650 stack is 10.4Ah with our application demand for up to 90A discharge for 4min, typically 50A for 10min. To get that 90A range I scaled the discharge-current calibration at initial setup, resulting in 3x so that 90A fits into 32767 bq limit. It came out pretty close as our physical Rsense is 1mOHM and the CC table reflects 3.1+mOHM recalculated.

So yes, Quit Current might need to be down-scaled, as well as other factors which is where my knowledge starts dropping off a bit because the TRM doesn't make it very clear about all parameters in any given class affected by scale. 

To your other point, the ~700mA discharge for 5h is then actual ~2100mA discharge for 5h, or C/5 which I understand to be appropriate for cycle testing. 

Knowing this, can you give me a comprehensive list of the parameters affected by scale, or if you're willing send another scale-adjusted gg.csv? 

Thanks, I think we're getting somewhere now. -pete u.

Hi Pete,

I did see you ask about the scaling factor earlier, but it slipped my mind when I reviewed the logs. In this case, the discharge time does make sense. I checked with our firmware engineer, and all current parameters should be scale-adjusted. So for your .gg file, I am thinking we should change the taper current to ~67mA. I will go through the .gg file today to see what other adjustments might need to be made, but hopefully the taper current adjustment will help to get successful full-charge detection.

Matt