bq34z100-G1: YUASA NP7-12 (Chem ID 0808) batteries with deviation

Hi Sebastian,

I will look into this and get back to you shortly.

Best Regards,
Ben Lough

Sebastian,

I would recommend performing a learning cycle on the bq34z100-g1 with your specific chemID. This will tailor Qmax, Ra and thermal coefficients used in the impedance track algorithm and should increase the accuracy of the gauge. Here is more information about the process: http://www.ti.com/tool/GPCRA0.

Instructions for data logging: www.ti.com/.../sluubc9.pdf.

This will create a new golden file which you can use to program your gauge. Perform another discharge cycle with the new golden file and let me know if the results improve or not.

Best Regards,
Ben Lough

Ben,

i thought the process to match a Chem ID is independent from any optimization or learning cycle.
I want to be sure that i have a very good Chem ID match and that my test procedure (charge and discharge cycle) is correct before continuing with the optimization cycle and creating a golden file.
Would you say the discharge cycle in the log is ok to continue?

Regards,
Sebastian

Sebastian,

Regarding your data: It looks like the discharge was terminated too soon. I would recommend using a C/20 discharge rate and terminate the discharge once the battery reaches the termination voltage.

Could you also provide some detail about your test setup? This would assist me in further analyzing your data.

Best Regards,
Ben Lough

Thanks for the answer Ben.
I will run another discharge cycle at C/20 rate. The termination voltage is currently set to ~21V6. According to the discharge characteristics graph it should be at 10V5 or 10V6 for C/20 rate. So for our two NP7-12 in series the termination voltage should be 21V or 21V2 at this rate i guess.

The test setup is the following:
Charging the two new NP7-12 batteries in series at 27V3 (laboratory power supply) floating charge voltage until the charging current is really low (below 50mA). Then discharging batteries via load resistors. The load resistors are automatically disconnected when the voltage is too low (separate device where the voltage for switching a relay can be set via analog input).

Best Regards,
Sebastian

I've run another discharge cycle. This time the deviation is at 4.57%. Much better but not perfect.

Here are the files:

GPC report: YUASA_NP7-12_ChemID_Cycle_2-report.zip

Logfile of discharge cycle: 7711.roomtemp_rel_dis_rel.log

It would be interesting how the deviation looks like/ in which direction there is deviation.

Best Regards

Sebastian

Thank you for the feedback Ben.

I will run an optimization cycle then as the next step.

Could you please verify if this procedure is ok:

1. Even though accurate capacity is unknown, set Qmax and design capacity to the cell capacity shown in the data sheet. Do not send IT enable command 0021.

(2. Send SMB command 46, word 0006 to turn on the FETs.) Not possible/necessary with bq34z100-G1

3. Discharge the pack down to termination voltage at a C/5 rate.

  We use C/10 to C/20 since our load resistors don't withstand higher currents.

  Termination voltage for our application: 21V

4. Let it relax for 5 hours or more.

5. Send the IT enable command (0021). Bits QEN and VOK in Operation Status are set.

6. Charge pack to full capacity until the taper current is reached and the FC bit is set.

7. Let it relax for 2 hours. Qmax is learned at this point; this can be verified by MaxError changing to 3% and Update Status to 5%.

8. Discharge the pack down to terminate voltage at the typical low rate of your application. For laptops, it is usually C/5. The MaxError changes to 1%, and the Update Status changes to 6%.

  For our application: C/20 (~350mA)

9. Repeat steps 4 and 6 to 8 one more time to verify the gas-gauging accuracy.

I've copied it from slua334b and added notes for our application.

If you don't mind it would be nice if you could check if my settings in the data flash make sense for the optimization cycle:

bq32z100-G1_firmware_and_dataflash_20160725.zip

Best Regards

Sebastian

Sebastian,

Your procedure looks good. A couple added notes:

4 and 5. Send the IT_Enable command when your discharge is done (update status register should change to 0x04). QEN and VOK should get set. When dV/dt of the battery voltage is less than 1 uV/s the device will take an OCV reading and clear QEN and VOK (could take up to ~5 hours). You will want to wait for these bits to clear before beginning your charge.

6. I would recommend charging at a C/20 rate.

In your data flash, Design Capacity and Design Energy looks like it needs adjusted but the other values seem reasonable.

Best Regards,

Ben Lough

Thank you for the notes Ben.

We have two YUASA NP7-12 batteries in series (2x6 cells = 12 cells => 7000mAh / 24V).
My calculations for Design Capacity and Design Energy are the following:
Design Capacity = 7000 mAh / 6 cells = 1167 mAh
Design Energy = Design Capacity * 2 V per cell = 2334 mWh
I've found similar settings posted by others in the forum, so i thought this is the correct calculation.
But maybe i misunderstood something.
What would you say is the correct way to calculate these settings?

EDIT:

After a long search i found this post:

So i guess the following would be correct:

Design Capacity = 7000 mAh (the same for one cell, six cells per battery or two batteries in series)
Design Energy = Design Capacity * 2 V per cell = 14000 mWh

Is this correct?

Best Regards,

Sebastian

Ben,
I have discharged the batteries and sent the IT_Enable command.
After more than 5 hours the VOK is already set to 0 again, but QEN stays 1.
In other discussions someone wrote that QEN just reflects the state of IT (enabled/disabled), so i guess it it should stay 1 (and would be a problem if it changes to 0). Is this correct?
I've began with the charge cycle now.

Best Regards,

Sebastian

The optimization cycle doesn't work as expected.

After sending IT enable, then charging and relax the batteries nothing changed (Max Error should change to 3 and Update Status to 5).

But after another discharge and relaxation Max Error was set to 3 and Update Status to 5. (Max Error now should have changed to 1 and Update Status to 6).

I'm now charging the batteries again. It looks like everything is shifted by a half cycle.

Can you have a look at the log and check if the optimization cycle is still ok or if i have to change and redo it in any way?

Logfile: 3386.bqstudio_yuasa_np7-12_optimization_cycle.zip

Data Memory: DataMemory_20160805.gg.csv.zip

Best Regards,

Sebastian

Sebastian,

I didn't see anything immediately in your gg.csv file that would cause you to fail the learning cycle. However, I was able to run the GPC optimization tool with the files you provided. Change the extension of gg_out.csv to gg.csv and import the file into data memory on your device. 

YUASA-report.zip

Best Regards,

Ben Lough

I really want the optimization cycle to work on the gas gauge.

I've finished the optimization cycle, but it failed. MaxError is still 3 and Update Status 5.

Here is the log: bqstudio.zip

I've run another full charge and discharge cycle, but MaxError remains 3 and Update Status 5.

Here is the log, and latest srec and data memory: 8507.Optimization Cycle 2.zip

Maybe there is still an error in the configuration?

Best Regards

Sebastian

Hi Sebastian,

I would recommend the following steps:

1. Reset your gauge. [RUP_DIS] should set and update status should be 0x04

2. Discharge your pack to empty. 

3. Send the IT_ENABLE command. Once the rest period is complete (5 hrs), charge your battery.

4. Once the battery is fully charged, the [FC] bit should set. Once the device has taken an OCV reading, update status should now change to 0x05. 

5. Discharge your battery using a C/20 rate. 

6. Once the battery is fully discharged, let the battery relax for ~5 hrs. Once the gauge takes another OCV reading, update status should change to 0x06

For reference, here is a learning cycle guide.

3527.LearningCycleOverview.pdf

Best Regards,

Ben Lough

I've sent the Reset command via bqStudio but the Gas Gauge remained at Update Status 0x05.
QEN was still set and RUP_DIS gets set after Reset. Seems like the Update Status hangs somehow.
I've disconnected the batteries to make the Gas Gauge completely power less, but the result was the same as it was by sending the Reset command.

Hi Sebastian,

Please send me a .srec and .gg.csv. I will take a look.

Best Regards,
Ben Lough

Thanks Ben,

here are the files:

bq32z100-G1_firmware_and_dataflash_20160906.zip

Best Regards

Sebastian

Since i really need a golden image now, i tried writing the gg_out.csv values calculated by the GPC tool via bqStudio.

But i then get the following error message:

Parameter value does not match type and data format.:Gas Gauging.State.T Rise

T Rise is -1606.78, which seems to be illegal.

Here is the file i sent to the tool:

GPC_Golden_GG.zip

Here is the report:

GPC_Golden_GG-report.zip

Any idea what went wrong?

Best Regards

Sebastian

 

Edit:

T Time Constant (which is 535507) is reported to be not valid too.

Sebastian,

Your T Rise and T Time Constant values are beyond the min/max limits. These are used by the thermal model for your battery pack. It will only affect your performance if the ambient temperature is changing while charging/discharging. For now, use a text editor to set T Rise to 20 and T Time Constant to 1000 and program your gauge. I will look into why the tool returned these thermal values tomorrow morning.

Best Regards,
Ben Lough

Ben,

i have replaced the values in the gg.csv file so it gets accepted now.

Any news why these illegal values are generated by the tool?

Best Regards

Sebastian

Hi Sebastian,

I asked someone in tools to look into this but I haven't heard back yet. By the way, how were you measuring temperature? Did you have a thermister attached to the battery pack?

Best Regards,
Ben Lough

Hi Ben,

no we don't have a thermistor attached, we use the internal temperature of the bq34z100-G1 since the device will only be used at room temperature and the currents are so low that the batteries will not warm up.
I remember that i read somewhere in the forum or a document that it is not really necessary to attach a thermistor in such a case.
But maybe i remember it wrong. Would you say a thermistor is absolutely necessary?

Best Regards
Sebastian