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.

BQ4050: GPC Report Error - data format issues

Part Number: BQ4050

I've performed the set of 6 tests as instruction in the GPC documentation. Once packaged and uploaded to the GPC tool, I've received a vague error: 

The following errors were reported by the calculation engine:
Error: Fit failed due to data format issues. Check settings, data format and test schedule.

I'm not exactly sure what to check - as far as I can tell, the column mapping is correct, the config file is correct, all the data looks correct. 

both the package and report are attached to facilitate troubleshooting. 

74825.GPCPackaged.zip3718.GPCPackaged-report.zip

  • Hello Kienan,

    what chemistry are you using? You have set the chemistry to Li-ion in the config (chem 1) but it looks more like LiFEPO4 (chem 4) or LTO (chem 5) based on the voltages. I'm not sure if fixing that alone will help you, so feel free to follow-up if it still doesn't work after changing that parameter.

    thanks,

    Alex M.

  • We're using UB123A cells which are LiMnO2, which is unfortunately not available out of the few chemistry options provided. I figured option 1, the default, would be closest. 

  • Hello Kienan,

    I see, I think that explains some of what we are seeing. The tool can handle the chemistry assigned being off since it uses that to form a guess which is then fitted to the data. However, I had more success using LiFePO4 since its OCV curve is closer to your chemistry than Li-ion. Also, the main reason it was failing to fit is because there was not enough data before the cutoff (2000mV) in some cases, particularly cold.

    I have attached data from a run set to LiFePO4 and cutoff = 1800mV. If this works for your application you can use this. However, if 1800mV is too low, then you will likely have to re-run the data at a lower discharge rate to ensure enough data is collected before the cutoff. You may also want to experiment with the max/min SOC settings to see if that helps also.

    5826.GPC_report.zip

    Best of luck,

    Alex M. 

  • Hi Alex, 

    Would you be able to provide some more details regarding there not being enough data before reaching the cutoff voltage? It's easy enough to reduce the load in the case of the low temp discharges to compensate for the reduced voltage, I'd just like to know about how much I should reduce it by as it would be a bit time consuming to just try a few different values. 

    A lower cutoff of 1.8V is fine. 


  • Hi Kienan,

    If you look at the raw data for lowtemp_highrate, you see that it goes below the cutoff (2000mV*3 = 6000mV) almost immediately. If you look in GPC CEDV.txt in the folder I sent, you can see which tests were able to get a good fit and which were not able to. The three worst are:

    Lowtemp_highrate

    Lowtemp_lowrate

    roomtemp_highrate

    The others were okay, but hightemp_lowrate was the only one to meet the recommended SOC deviation. As for the best currents to use, we can do some estimations. Assuming that the impedance of the cell stays the same in each temp condition, we can assume a linear relationship between the current and the magnitude of the IR drop. for lowtemp_highrate, we see about a 2500mV drop once current is drawn. If we drew 50% of the current, we would expect roughly 50% of the IR drop or 1250mV. comparing this to the OCV curve for your battery will let you see what % will be above your cutoff and you can select like that. Even reducing these currents to 80% would likely vastly improve the amount of data above 6000mV. 

    However, this is if you wanted to use 2000mV cutoff, with 1800mV your data got a usable fit and could likely be improved just by moving the max/min SOC around a bit and re-submitting. You can try changing one at a time, and seeing if it helps or hurts the fit and iteratively resubmitting. 

    thanks,

    Alex M.

  • Understood - that makes sense. Thank you for the guidelines for the current selection - I'll adjust accordingly for the low temp discharges and resubmit with the new data. 

    With some tweaking to the max/min SOC I'm able to get the following sets within the recommended deviation: 

    roomtemp_highrate
    hightemp_lowrate
    hightemp_highrate

    roomtemp_lowrate is not far off at -4.15%, but both low temp sets are >20% error, so I'll start there. 

    Another question just because I'm curious - is it a problem if the discharge conditions used for the CEDV characterization do not match the expected discharge profile in our application?

  • Hello Kienan,

    I'm happy to see that adjusting the SOC settings is helping get them with in recommended. Unfortunately, the algorithm is most accurate when the discharge rate matches the expected discharge in the application. Having a different current will cause a bit of error, particularly at the end of the discharge. So this will put a bit of a limit on how far you can limit the currents for fitting purposes. That's another reason why it may be beneficial to see how far you can push it it by only messing with the SOC settings. 

    thanks,

    Alex M.

  • Hi Alex, 


    Ok - that may present a bit of an issue for us in practice. We'll see how good we can get it by adjusting the SOC settings. 

    Our actual load conditions in our device consists of a 150-200mA baseline current draw with 10-15s pulses of about 2.5A. Typically there would only be a maximum of three pulses per device use, which should only last about 10-15 minutes. 

    Is a discharge profile like this suitable for use in the characterization process, or should we stick to the constant-current (ish) method? I'm not exactly sure how this would look in practice - perhaps for the high rate/low rate we could leave the baseline current the same and either adjust the pulse current magnitude or frequency to get the desired high or low average current. 

  • Kienan,

    It depends on the goal. Can your application handle going lower than EDV0 to where you want 0% to be reported when the baseline load is present. If so you will want to set EDV_Hold times longer than your 2.5A pulse duration. This will avoid you collapsing the RSOC due to the pusle. Then for the CEDV based data submission you would want to submit using the constant current method of the baseload.

    If you want the gauge to report 0% exactly when the 2.5A load hits EDSV thresholds you should submit using a Constant current with this high rate. I would use 2A as the current because in the application the pulse will have a transient response so you wont be under the full 2.5A according to the battery. 

    Thanks,

    Eric Vos

  • Hi Eric, 

    I believe the first case you outlined would make the most sense for us - our device will know if during a pulse there is insufficient energy remaining in the battery to do what we need to do, we are more concerned with making sure we don't end up in that situation in the first place by ensuring we can track the capacity accurately enough during normal operation to trigger a battery change warning prior to being at 0% SOC. 

  • Hello Kienan,

    that sounds reasonable, and I would agree that the first method sounds like the best way to do this. Let me know if anything else comes up.

    Best of luck,

    Alex M.