BQ34Z100-R2: Wrong full charge capacity on OCV sample

I just noticed that I have "NiMH_PbA VCT_DT" and "NiMH_PbA VCT_DV" enabled, for some reason. Looks like it was ON by default. Could it be the problem?

I re-did measurements for the GPC chemID tool with slightly different discharging rate and it gave me way different report.

The previous report:

Chemistry ID selection tool, rev=2.54		
		
Configuration used in present fit:		
ProcessingType = 2		
NumCellSeries = 6		
ElapsedTimeColumn = 0		
VoltageColumn = 1		
CurrentColumn = 2		
TemperatureColumn = 3		
		
Best chemical ID : 5754	Best chemical ID max. deviation, % : 1.21	
		
		
		
Summary of all IDs with max. DOD deviation below 3%		
		
Chem ID	max DOD error, %	Max R deviation, ratio
5754	1.21	0.78
1327	1.42	2.41
2224	1.48	0.72
1373	1.53	1.03
1452	1.54	1.16
1374	1.55	1.12
1531	1.6	1.1
1345	1.6	0.78
1344	1.62	0.75
1375	1.67	1.06
1362	1.67	0.69
1371	1.71	0.95
1376	1.76	0.96
1359	1.79	0.96
584	1.83	0.96
1619	1.83	0.96
1377	1.84	0.96
120	1.87	0.79
1378	1.88	0.96
1328	1.97	1
469	2.01	0.97
2118	2.01	0.97
1372	2.02	0.77
1356	2.11	0.75
149	2.13	0.95
2117	2.14	0.9
468	2.14	0.9
1763	2.14	0.83
5716	2.35	0.97
1450	2.36	0.97
148	2.36	0.82
1497	2.45	0.96
326	2.72	0.87
1208	2.75	1.41
1529	2.82	1.07
7577	2.86	0.82
1287	2.89	0.83
		
Max. deviations for best ID is within recommended range. Chosen best chemical ID is suitable for programming the gauge.		
		
		
Selection of best generic ID for ROM based devices like bq274xx		
		
		
Device / Family #1		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
354	bq27411-G1C: 4.35V LiCoO2	2.56
128	bq27421-G1A: 4.2V LiCoO2	2.76
3142	bq27421-G1D: 4.4V LiCoO2	4.38
312	bq27421-G1B: 4.3V LiCoO2	4.41
Best generic ID 354		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		
Device / Family #2		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
354	bq27621:  (ALT_CHEM2) 4.35V LiCoO2	2.56
1210	bq27621:  (ALT_CHEM1) 4.3V LiCoO2	2.99
1202	bq27621: (default) 4.2V LiCoO2	3.07
Best generic ID 354		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		
Device / Family #3		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
1202	bq27426: (ALT_CHEM1) 4.2V LiCoO2	3.07
3230	bq27426: (default) 4.35V LiCoO2	3.27
3142	bq27426: (ALT-CHEM2) 4.4V LiCoO2	4.38
Best generic ID 1202		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		
Warning: First OCVpoint has non-zero current I=  -0.014 Please make sure you have a 2 hr relaxation period before the beginning of discharge.		

The new report:

Chemistry ID selection tool, rev=2.54		
		
Configuration used in present fit:		
ProcessingType = 2		
NumCellSeries = 6		
ElapsedTimeColumn = 0		
VoltageColumn = 1		
CurrentColumn = 2		
TemperatureColumn = 3		
		
Best chemical ID : 1535	Best chemical ID max. deviation, % : 1.83	
		
		
		
Summary of all IDs with max. DOD deviation below 3%		
		
Chem ID	max DOD error, %	Max R deviation, ratio
1535	1.83	0.71
2951	2.52	1.04
1620	2.8	2.27
		
Max. deviations for best ID is within recommended range. Chosen best chemical ID is suitable for programming the gauge.		
		
		
Selection of best generic ID for ROM based devices like bq274xx		
		
		
Device / Family #1		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
128	bq27421-G1A: 4.2V LiCoO2	2.76
354	bq27411-G1C: 4.35V LiCoO2	3.15
312	bq27421-G1B: 4.3V LiCoO2	4.82
3142	bq27421-G1D: 4.4V LiCoO2	4.88
Best generic ID 128		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		
Device / Family #2		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
354	bq27621:  (ALT_CHEM2) 4.35V LiCoO2	3.15
1202	bq27621: (default) 4.2V LiCoO2	3.21
1210	bq27621:  (ALT_CHEM1) 4.3V LiCoO2	3.23
Best generic ID 354		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		
Device / Family #3		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
1202	bq27426: (ALT_CHEM1) 4.2V LiCoO2	3.21
3230	bq27426: (default) 4.35V LiCoO2	3.55
3142	bq27426: (ALT-CHEM2) 4.4V LiCoO2	4.88
Best generic ID 1202		
Max. deviations for best generic ID is within recommended range. Please chose this ID in your device configuration or device family.		
		
		

Even though the new one has higher DOD errors it seems to match more closely to the kind of battery I have. I was not able to figure out what batteries 1535 and 2951 correspond to, but 1620 is for a fullymax LiPo battery. So I'm going to try another learning cycle with 1620 as chemID.

And I have a question: is it absolutely necessary for chemID to match the total capacity? 1620 corresponds to a fullymax LiPo 16Ah battery, while I work with a 12Ah battery.

After disabling the NiMH_PbA flags and setting ChemID to 1620, I received a more or less adequate capacity estimate - while charging it accumulated 11733 mAh, and then on the next OCV sample it updated the estimate to 10970 mAh. Then to validate the estimate, I discharged the battery at C/5, and the actual capacity was around 11450 mAh. So around 4% of error. Seems to be acceptable considering I chose the ChemID with a 2.8 DOD error and 2.27 R deviation. I'll test other suggested ChemIDs too later.

So I created a golden image file. Applied it to another bq34 which was calibrated after that. And it was not clearly stated in any of bq34 related documents:
1. if I need to change anything on the golden bq34 before exporting a golden file
2. in what state should the golden bq34 be - charged, discharged, or anything in between
3. the same question about a bq34 that is programmed with a golden file

I've reproduced the issue again. Can someone from TI gurus please take a look?

Probably best to check the latest logs. Here is the learning cycle :
* The log starts from me finishing charging at the taper current
* VOK has been cleared in 10 minutes, I suppose it's because I was charging at the taper current for quite a long time - 1 hour logged, and at least 1 hour before that
* After an hour of rest, I discharge at C/5=2.4A
* Finally, after an hour of rest, the update status changes from 5 to 6

So my next steps:
1. Change "Update Status" to 02
2. Set "Cycle Count" to 0
3. Export a golden image
4. Program another bq34z100-r2 attached to a discharged battery with the golden image
5. Calibrate
6. IT_ENABLE
7. RESET
8. Start logging a charge-discharge cycle: sb004_cycle.csv

On this log, I see the following:
* FCC starts increasing when the battery is almost charged
* After some relaxation time, RC/FCC are updated from 11574/11575 to 10896/11191
* RC starts decreasing on discharge but it reaches 0 way before the battery is drained
  * according to the log, the error is ~550 mAh
  * the previous RC/FCC jump removed 678 mAh (11574-10896)
* Then after some relaxation time, FCC updates from 11191 to 11374 (+183mAh still not enough to cover the error in discharge though)
* And finally the most interesting part begins:
  * FCC starts growing on charge until it reaches 16033 mAh
  * then after rest, it jumps to 11296 which seems close to the previous numbers BUT it also adjusts the RC to 4394 mAh so SOC becomes 39% instead of 100%

Please advise

One more cycle with the same battery but this time RC/FCC were updated to 0 after charge: sb004_cycle_2.zip

Hello George, 

Before we can solve your other issues can you redo the voltage and current calibration, and confirm it was done correctly, section 3.4 and also refer to the links below.

Link to reference:
(+) BQ34Z100-R2: Voltage and temperature calibration issues - Power management forum - Power management - TI E2E support forums

Perform voltage calibration with the BQ34Z100-G1 | Video | TI.com

(+) [FAQ] BQ34Z100-G1: How to Calibrate Gauge at High Voltage - Power management forum - Power management - TI E2E support forums

(+) BQ34Z100-G1: Commands for calibration procedure - Power management forum - Power management - TI E2E support forums

Technical reference manual: 

https://www.ti.com/lit/ug/sluuco5a/sluuco5a.pdf?ts=1741728944785&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ34Z100-R2

Thank you,
Alan

Hello Alan, thank you for your help.

I just went over all the links you referenced.

Alan Frias said:

(+) BQ34Z100-R2: Voltage and temperature calibration issues - Power management forum - Power management - TI E2E support forums

There was no need for me to do such manipulations. It was enough to measure the voltage and enter it as is. The gauge evaluated the "DF-Calibration-Voltage Divider" to 4661 and the reported voltage resembled the actual voltage quite precisely (~10mV of error). So please let me know if I must do it the way it was done by the original poster.

Alan Frias said:

Perform voltage calibration with the BQ34Z100-G1 | Video | TI.com

That's exactly how I calibrated the voltage.

Alan Frias said:

(+) [FAQ] BQ34Z100-G1: How to Calibrate Gauge at High Voltage - Power management forum - Power management - TI E2E support forums

I use 430kOhm/16kOhm voltage divider, so the maximum voltage of 25.2V is seen by the gauge as 904mV. And the VOLTSEL bit is set. I've verified the gauge toggles the VEN pin and voltage drop is in the expected range.

Alan Frias said:

(+) BQ34Z100-G1: Commands for calibration procedure - Power management forum - Power management - TI E2E support forums

I use bqStudio for all manipulations.

Alan Frias said:

can you redo the voltage and current calibration, and confirm it was done correctly

I confirm. I use the default unit scales for voltage and current. "Voltage" and "Current" registers report correct values at all times. They were calibrated and verified using keithley 2000.

Hi George,

Thanks for calibrating and verifying the results. 

You are using a ChemID with less than 3% dod% error? The less the dod error the better. 

Looking at the log file it appears that a learning cycle was completed, but FCC was over estimated. Can you share your .gg file for review?

Regards,

Diego

Hi Diego,

Diego said:

You are using a ChemID with less than 3% dod% error? The less the dod error the better. 

I use 1620 ChemID with 2.8 DOD error and 2.27 Max R deviation. I've shared the GPC ChemID report earlier. Look for "the new report" in this thread.

Diego said:

Can you share your .gg file for review?

Sure. Here is the latest .gg: 7026.sb004_250314.gg.csv.

I see that the learning cycle logs I uploaded earlier are not valid anymore. So I reupload them here for completness: 7026.learning_250308.zip. This file contains periodic .gg files that correspond to the learning cycle.

If there is anything else I could share or if perhaps I need to gather more data, please let me know

Hi,

Thanks for confirming the ChemID.

The learning cycle provided looks good update status reached 6 but at the end of the log reset to 2, what happened at this point? Why was IT disabled?

After the learning cycle is completed, FCC should be accurate.

Regards,

Diego

Hi Diego, perhaps I logged accidentally the moment when I changed the “update status” to 02 right before creating a golden image after a successful learning cycle, as per requirements I saw in a few TI sources. But the original problem reproduces even if I don’t do that at all, meaning if I keep using the battery after a learning cycle without any additional manipulations. Just in a cycle or two this issue shows itself. Do you see any other suspicious things?

I can make a single non-interrupted log starting from a learning cycle until the issue happens. Would it help to narrow the issue down? I’m a bit desperate already and I really don’t see what else could I do to bring the bq34z100-r2 to production.

Diego said:

After the learning cycle is completed, FCC should be accurate.

And yeah, FCC is accurate after the learning cycle. But it’s quickly deteriorating after a cycle or two.

George Shakula said:

On this log, I see the following:
* FCC starts increasing when the battery is almost charged
* After some relaxation time, RC/FCC are updated from 11574/11575 to 10896/11191
* RC starts decreasing on discharge but it reaches 0 way before the battery is drained
  * according to the log, the error is ~550 mAh
  * the previous RC/FCC jump removed 678 mAh (11574-10896)
* Then after some relaxation time, FCC updates from 11191 to 11374 (+183mAh still not enough to cover the error in discharge though)
* And finally the most interesting part begins:
  * FCC starts growing on charge until it reaches 16033 mAh
  * then after rest, it jumps to 11296 which seems close to the previous numbers BUT it also adjusts the RC to 4394 mAh so SOC becomes 39% instead of 100%

Like described here

Hello George, 

This has been assigned and we will get back to you when possible.

Thank you,
Alan

Hi George,

After completing a learning cycle you do not need to reset update status, if you have not completed testing of this device. Reset update status before creating your golden image that you will use in production.

Can you share a log file of an interrupted charge discharge cycle with update status at 6. I will debug this log file in combination with the .gg file previously provided. If there is a new .gg file that corresponds with the next log file shared, please provide that as well.

To confirm, your cells are being balanced?

What is the pack configuration? (ex: 3s2p)

Also please share the data sheet for the cells used if possible.

Regards,

Diego

Hi Diego,

Diego said:

After completing a learning cycle you do not need to reset update status, if you have not completed testing of this device. Reset update status before creating your golden image that you will use in production.

Got it, thank you for confirming. I did reset the update status this time because I intended this bq34 to serve as a golden sample.

Diego said:

Can you share a log file of an interrupted charge discharge cycle with update status at 6.

Please clarify what kind interruptions do you keep in mind. Or perhaps you meant an uninterrupted log starting from a learning cycle and ending when the issue reproduces?

Diego said:

To confirm, your cells are being balanced?

I've disabled cell balancing specifically to avoid unexpected interactions with bq34. But before starting a learning cycle I ensured that all cells are within 10mV. I use bq76952 for battery protections and cell balancing. So bq34z100-r2 and bq76952 share the same sense resistor. I could also log information from bq76952 if that can be of any help (if so, let me know what should I include besides per-cell voltages). When learning/calibrating I was not disconnecting bq76952 because its power consumption is negligible. Please let me know if you see any issues with that.

Diego said:

What is the pack configuration? (ex: 3s2p)

6s1p 12000 mAh 22.2V Li-Po - https://genstattu.com/tattu-30c-22.2v-12000-6s1p-ec5.html.

Diego said:

Also please share the data sheet for the cells used if possible.

The manufacturer only provides this quite high-level manual: Lipo-Manual.pdf. I could try to get more specifics from them if you tell me what you need to know.

Hi George,

Thanks for the file!

Please clarify what kind interruptions do you keep in mind. Or perhaps you meant an uninterrupted log starting from a learning cycle and ending when the issue reproduces?

Sorry, that was a typo, please share an Uninterrupted log file.

I've disabled cell balancing specifically to avoid unexpected interactions with bq34. But before starting a learning cycle I ensured that all cells are within 10mV. I use bq76952 for battery protections and cell balancing. So bq34z100-r2 and bq76952 share the same sense resistor. I could also log information from bq76952 if that can be of any help (if so, let me know what should I include besides per-cell voltages). When learning/calibrating I was not disconnecting bq76952 because its power consumption is negligible. Please let me know if you see any issues with that.

Please log with the BQ34z100, but in general it is important that the cells are balanced for the BQ34z100 to estimate soc/Remcap/etc correctly.

Regards,

Diego

Hi Diego,

Got it. I will start this process today or tomorrow. I expect it to take at least 2 days. I will get back to you as soon as I reproduce the issue. Thank you!

Hi George,

Sounds good!

Regards,

Diego

Hi Diego,

here is the log: 250320_full_reproduce.zip.

Timestamps:

2025-03-21 13:23:00 - Discharge to empty
2025-03-21 16:56:00 - Relax
2025-03-21 20:06:00 - Charge to Full
2025-03-21 22:58:00 - Relax
2025-03-22 03:48:00 - Discharge
2025-03-22 09:00:00 - Relax - learning successful
2025-03-22 17:00:00 - Start Cycle#1
2025-03-23 16:31:00 - The issue happens
2025-03-23 18:03:00 - Start Cycle#2
2025-03-24 00:18:00 - End Cycle#2

The maximum cell disbalance I've observed was around 10-15 mV.

Hi George,

Thanks for the files! See my feedback below.

If you look at the Ra tables they are vastly different, this leads me to believe that the Ra tables are incorrect and/or updating abnormally. I recommend using the GPCRa tool to optimize the Ra values. Please share the Ra values once available, once we have Ra values were confident in, we can monitor how they update. If they continue to update abnormally there are parameters to tweak to stop this from happening. 

GPCRA0 Application software & framework | TI.com

Simple Guide to GPC Golden GG Maker Tool

I also recommend that you switch your load mode from constant power to constant current. This should improve performance.

In Pack configuration (A) and B, you have both the NiMH bits (bits 4 and 3) and the LFP bits (bits 2 and 1) set. The NiMH bits should only be used for NiMH cells and the LFP bits should only be used for LFP cells, if a different cell chemistry is being used, please disable both bits.

Another thing I noticed is that DOD0 is updating at the wrong time. Once we make the above changes, I will continue to monitor this and if it continues to occur, we can tweak parameters to prevent this from happening.

Regards,

Diego

Hi Diego,

Diego said:

I recommend using the GPCRa tool to optimize the Ra values. Please share the Ra values once available

Here is the report I received: GPCRa-Mar25-report.zip. Please note I could not quickly do exactly as the instruction recommends - "place cells exactly how they will be used and discharge at high load". I will definitely do that after the issue we discuss here is dealt with. Let me know how this report looks to you, and whether we could be confident in such values. I will keep testing the battery the same way I did before to avoid any issues.

Diego said:

I also recommend that you switch your load mode from constant power to constant current. This should improve performance.

In the end, our load is going to be of constant power. Will it be fine if I use constant current while learning the battery values and then switch to constant power when it's used in the actual device? Or should I use constant current at all times?

Diego said:

In Pack configuration (A) and B, you have both the NiMH bits (bits 4 and 3) and the LFP bits (bits 2 and 1) set. The NiMH bits should only be used for NiMH cells and the LFP bits should only be used for LFP cells, if a different cell chemistry is being used, please disable both bits.

Done.

I just applied the gg_out from GPCRa0 and started another cycle under full logging.

Diego said:

If they continue to update abnormally there are parameters to tweak to stop this from happening.

What would be the consequences of stopping it from happening in the long run? Wrong SoH and aging SoC compensation?

George Shakula said:

I just applied the gg_out from GPCRa0 and started another cycle under full logging.

After a charge-relax-discharge-relax cycle, FCC jumped to 0 again: 250325_after_GPCRa0.zip.

Please suggest the next actions.

Hi George,

George Shakula said:

Here is the report I received: GPCRa-Mar25-report.zip. Please note I could not quickly do exactly as the instruction recommends - "place cells exactly how they will be used and discharge at high load". I will definitely do that after the issue we discuss here is dealt with. Let me know how this report looks to you, and whether we could be confident in such values. I will keep testing the battery the same way I did before to avoid any issues.

Got it values appear acceptable.

George Shakula said:

In the end, our load is going to be of constant power. Will it be fine if I use constant current while learning the battery values and then switch to constant power when it's used in the actual device? Or should I use constant current at all times?

It would be best to replicate the expected load.

George Shakula said:

What would be the consequences of stopping it from happening in the long run? Wrong SoH and aging SoC compensation?

If we stop Ra updates all together, as the cells age the increase in resistance will not be taken into consideration, this will affect SOC and SOH accuray. What I am suggesting is not completely disabling Ra updates but tightening when the Ra tables are allowed to update and how much they are allowed to update at once.

George Shakula said:

After a charge-relax-discharge-relax cycle, FCC jumped to 0 again:

Thanks for the log, I will work on building a configuration to test and provide it once complete, please allow me sometime.

Regards,

Diego

Hello George,

Diego is out of the office today and will be back the following day but he left the note to "Increase the ResRelax time within the parameters to 30 seconds", he noted that this would a step to the solution and will follow up in the office the next day.

Thank you,
Alan

Hi Alan,

Thank you for letting me know. I just finished testing with this change and it indeed took me 1 more cycle to reproduce the issue. Unfortunately, bqStudio did not start writing .gg logs when I activated auto-export (and I did not verify it). So I only have logs of registers: 250328_ResRelax.zip. Which I understand could be useless. The starting .gg file corresponds to the previously uploaded GPCRa0 one. And here is the ending .gg file: 250328_ResRelax_end.gg.csv.

Hi George,

Thanks for the log files, it appears that FCC is still crashing to 0. It is unusual how this is happening after the second cycle. Do the Ra tables change drastically after the first cycle? Can you log multiple charge/discharge cycles in a row.

Regards,

Diego

Hi Diego,

Diego said:

Do the Ra tables change drastically after the first cycle?

Cant say right now. I’ll to re-do the test with logging.

I also want to log what’s happening in a real device. I could not wire an ev2400 there. And I’m sure I’ll not be able to fully replicate logging capabilities of bqStudio. So if you can, please list the minimum I need to log so that you can make any sense of it.

Are there any other settings worth to try in the next few cycles besides the ResRelax?

Hi George,

Please log FCC, Remcap, SOC , DOD0, voltage, current, temperature, and DODpassedQ.

Potentially, the reason I have not recommended any more changes is because, there appears to be decent performance during the first cycle but then FCC crashes to 0. This is making it very difficult to pin point why this is happening. 

Regards, 

Diego

Hi Diego,

Here the issue happened right after a single discharge: 250409_ResRelax.zip. I'm gonna do one more cycle with this battery for completeness.

Hi George,

Thanks for the file, something is definitely wrong here

Can you share the datasheet for the cells you are using?

Can you share your pack configuration? (ex:2s3p)

Regards,

Diego

Hi Diego,

Sure.

George Shakula said:

Diego said:

What is the pack configuration? (ex: 3s2p)

6s1p 12000 mAh 22.2V Li-Po - https://genstattu.com/tattu-30c-22.2v-12000-6s1p-ec5.html.

Diego said:

Also please share the data sheet for the cells used if possible.

The manufacturer only provides this quite high-level manual: Lipo-Manual.pdf. I could try to get more specifics from them if you tell me what you need to know.

Hi George, 

Thanks for all the information here are my thoughts. I have ordered them from most to least important, I would test each change and see if it fixes the problem.

1) I recommend removing both smoothing functions. 

2) is your battery pack being balanced with an external monitor?

3) I have doubts about your chemid since both reports shared are vastly different.

4) Your Ra tables look a little inconsistent, using the GPC Ra0 tool could help.

Regards,

Diego

Hi Diego,

Thank you for the thoughts.

Diego said:

I recommend removing both smoothing functions. 

Will do and share what I see.

Diego said:

2) is your battery pack being balanced with an external monitor?

For now, I still disable cell balancing while testing bq34z100-r2. To avoid any unexpected effects until the core issue is resolved.

Diego said:

I have doubts about your chemid since both reports shared are vastly different.

Yeah, this definitely raised my eyebrow before. But the second report pointed me towards big Li-Po batteries (such as Fullymax 16Ah). So that's why I kept relying on it as if it's true. I just received another batch of the same battery model. I will re-do all measurements (GPC, Ra0) with it.

Diego said:

Your Ra tables look a little inconsistent, using the GPC Ra0 tool could help.

The Initial Ra table match the one I acquired by running the GPC Ra0 tool. This one:

George Shakula said:

Here is the report I received: GPCRa-Mar25-report.zip

Though I have a question about the GPC Ra0 tool: does it require a .gg from a bq34 that successfully finished learning cycle or it can be a .gg from a properly configured bq34 (design values, number of cells, etc)? I wonder whether it actually optimizes the Ra table or builds one from scratch based on the data I upload

Hi Diego,

Diego said:

3) I have doubts about your chemid since both reports shared are vastly different.

4) Your Ra tables look a little inconsistent, using the GPC Ra0 tool could help.

I did GPCCHEM from scratch and received the following report: SB12503007-GPCCHECM-Apr18-report.zip. I chose 1531 chemid. And I went through a learning cycle with all the settings you suggested in this thread. Here is the resulting .gg file: 62_SB12503007-Apr18-learning.gg.csv. Please let me know if the Ra table looks consistent enough to you.

Hi George,

George Shakula said:

For now, I still disable cell balancing while testing bq34z100-r2. To avoid any unexpected effects until the core issue is resolved.

Are the cells fully balanced when discharge begins?

Are the cells relatively the same age?

George Shakula said:

Though I have a question about the GPC Ra0 tool: does it require a .gg from a bq34 that successfully finished learning cycle or it can be a .gg from a properly configured bq34 (design values, number of cells, etc)? I wonder whether it actually optimizes the Ra table or builds one from scratch based on the data I upload

The GPCRa0 will recalculate the Ra values based on the data provided.

George Shakula said:

I did GPCCHEM from scratch and received the following report: SB12503007-GPCCHECM-Apr18-report.zip. I chose 1531 chemid. And I went through a learning cycle with all the settings you suggested in this thread. Here is the resulting .gg file: 62_SB12503007-Apr18-learning.gg.csv. Please let me know if the Ra table looks consistent enough to you

Please use the Ra table from the GPCRa0 and decrease Max Res factor to 10. Ths issues is your Ra tables are changing drastically from 1 cycle to the next. The gauge will use the Ra0 values and update the Ra0x values during one discharge, during the next discharge the Ra0x will be used and Ra0 will be updated and so on.

Please share the test result with smoothing disabled once available.

Regards,

Diego

Hi Diego,

Here is the latest discharge-charge-discharge cycle: 250506-cycle.zip. Please check it.

I've applied all smoothing related changes and started this cycle on a battery balanced to 1 mV precision. All cells are of the same age.

Additionally, I had to change the current scale to 2 because our working currents are bigger than 32A. So please let me know if you see any mistakes on my side, because the documentation is somewhat lucking and vague in that regard. I divided all mA, mAh properties and calibrated the current by entering a divided current as well. I use 0.5 mOhm sense resistor, so the maximum current of 64A is well under the maximum voltage allowed on the sense resistor ADC.

I just noticed that AveragePower was overflowing each discharge interval. I'm going to test with EnergyScale=4. Please let me know if this overflow could be the cause