BQ34Z100-G1: Available Energy counter wrapping

Hi Batt, thank you for your quick answer. You will find below a zip file with the gg files of the different cycles highlighted:

GG_files.zip

We paid special attention to the scaling factor and energy scale in order to meet the recommendations of the datasheet for a maximum capacity of 110Ah, is there something wrong in our calculations?

The scaling factor of 4 is hardcoded into the host software, I hope we can find another solution to correct this issue.

Best regards,

Jérémie

Hi Batt,

Any news from the fw team?

Regards,

Jérémie

Hi Jeremie,

I have posed this question to them again. I will follow up today and get back to you by tomorrow.

Hi Jeremie,

The overflow is a result of wrapping around of available energy. It can only handle MAXINT which is 32767 in this case. So, you may need to revisit your scaling.

Hi Batt,

Thank you for reaching back.

Actually the Available Energy is already less than 32767. If you look at the graph I uploaded, you will see that the wrapping happened way before hitting 32767.

We set a current scaling of 4 and an energy scaling of 2. Up to now the maximum capacity I used was 64Ah for 3.2V cells, which scales down to a maximum available energy of 25600 mWh.

The issue seems to appear for batteries with a capacity between 41.6Ah and 54.4Ah, that would mean between 16640 mWh and 21760 mWh energy after scaling.

Could you please ask again the fw team?

Regards,

Jérémie

OK, l will check with them again. Please allow me until Monday to get back to you.

Hi Batt,

looking back at the graph I sent you, it seems there is something wrong even when wrapping is not happening. The Available Energy should be roughly equal to the remaining capacity (RemCap) multiplied by the voltage. Taking every scaling into account the exact calculation is:

Available Energy (Wh) = (RemCap / 1000) * (Voltage / 1000) * Current_scaling = (AvailableEnergy / 1000) * Current_scaling * Energy_scale * NbSeriesCell

Which for a 12.8V battery leads to:

Available Energy (Wh) = (RemCap / 1000) * (Voltage / 1000) * 4 = (AvailableEnergy / 1000) * 4 * 2 * 4

However when tracing these two graphs for the constant current discharge of a learning cycle, we can see that the curve for available energy is excessively 'ballooning' toward an overestimation of the available energy before quickly decreasing.

Even without wrapping this curve shape does not match with a constant current discharge. It seems there is something going wrong in the available energy calculation also during discharge.

Do you have new insight from the fw team?

Best regards,

Jérémie

Hi Batt,

Load Mode is already 0 for all our learning cycles, this is the default value for this parameters (Constant Current model). We also use the default value for Load Select (1).

Do you mean that the AvailableEnergy() command should be discarded when using Load Mode 0? Please confirm this point.

Regards,

Jérémie

No, you don't need to disregard the availableenergy command.

Hi Batt,

As I told you the Load mode as already the default value of '0' on every learning cycles we have performed so far. For the sake of completeness I tried a learning cycle with Load mode of  '1' (constant power) and I have the exact same behavior of the AvailableEnergy counter.

From my point of view this energy counter is unusable: 1) during charge because of unknown wrapping of the value, 2) during discharge because of excessive overestimation of the available energy.

What solution can you offer to obtain a reliable "availbale energy" information from the gauge?

Looking forward to you insights.

Best regards,

Jérémie

Hi Jeremie,

Looking at a few of your logs, the fw engineer came back with the same answer that I provided above. If you need us to look into this further, we will need the srec to see if your config is what is causing the issue.

If you need more debugging, please send us before and after cycle exports of the srec, this will contain some hidden parameters that can help with the debug.

Hi Batt,

You will find below the srec files of the last learning cycle I performed on a 12.8V 83.2Ah battery. The first file has been exported after calibration but before the learning cycle, the second file has been exported after the learning cycle. Since the capacity of this battery was larger I used a design energy scale of 4 this time.

BEFORE_LEARNING_HET_LiFe_12.8V_83.2Ah_GI-bq34z100G1.zip

HET_LiFe_12.8V_83.2Ah_GI-bq34z100G1.zip

This learning cycle did not exhibit the wrapping of the AvailableEnergy counter, though the value went past the point where the wrapping occurred with a 54.4Ah battery. However the overestimation of the AvailableEnergy during discharge is still an issue. You can see in the file below a comparison of the learning cycles of these two batteries (i.e. 12.8V 54.4Ah with wrapping and 12.8V 83.2Ah without wrapping, both show an overestimation of available energy during discharge).

learning cycle comparison.docx

I can also provide the srec file of the 12.8V 54.4Ah battery after its learning cycle for comparison, you will find it below. I do not have an srec file before learning for this battery, however it was generated in the same way than for the 83.2Ah battery, only the capacities and design energy scale will be different.

HET_LiFe_12.8V_54.4Ah_GI-bq34z100G1.zip

These two issues, namely the wrapping of the AvailableEnergy counter during charge and its overestimation during discharge, must be addressed so we can be confident in the readings that are provided by the gauge to our system.

I hope you will be able to find out the root cause. Feel free to ask additional data if you need so, I will try to provide as much as possible.

Best regards,

Jérémie

Jeremie,

Thanks for this, I'll try to work with you on this to close it out in a week.

Hi Julian,

Can you please send me your char data for the cell? Not the learning cycle, but the battery chem ID data.

Hi Batt,

We are using Chem ID 0x0463

Best regards,

Jérémie

Hi Jeremie,

This cell was characterized for -20C and optimized for that. Please recheck your chem ID match or if you have the logs for the match, please send them.

Hi Batt,

Concerning the GPC tool, I submitted several charge discharge profiles of my battery made of 3.2V 3.2Ah cells (chemID 463) but the tool indicates other chemIDs for much bigger cells:

- 456 (10000mAh cell, max deviation 18.11%)

- 464 (20000mAh cell, max deviation 20.87%)

- 457 (70000mAh cell, max deviation 14.85%)

I think I'm missing something about how to scale the data for submission to the GPC tool. Could you tell me how to scale the data of a battery pack to match a single cell?

Regards,

Jérémie

Hi Jeremie,

That is acceptable. All the tool does is try to match the dsg curve of your battery to known IDs and estimate the error in each match. Therefore you will find batteries with varying capacities as matching yours. This is OK because when you run your learning cycle, the resistances will update to yours. You can use the best match among these for your cell.

Hi Batt,

Thank you for your answer, I'll have a closer look to these Chem ID.

However could you explain briefly how using a chem ID optimized for -20°C can be an issue here?

Best regards,

Jérémie

Hi Jeremie,

It might be best to close this thread and open a new one. However, most chem IDs have Rb coefficients optimized for room temp, in your case the match is generating a high deviation. With a lower deviation, your accuracy will be a whole lot better. Usually when you don't get a match, you have a problem. But in your case, you may want to try running GPCCHEM again to see if you get better matches.

Hi Batt,

Thank you for your answer. I'd like to run another learning cycle with one of these new Chem ID before closing this thread. We have no proof yet that it is the root cause of the AvailableEnergy misbehaving.

Regards,

Jérémie