MSPM0G3507: problem about MSPM0 Gauge L2 Solution Guide

Hi Jerry,

Have forwarded the thread to the expert in my team, will come back and comment sooner.

B.R.

Sal

the CircuitTableOverRangeFlg will be set when it try to search the SOC with OCV(Vcell) input into the table. That means the Vcell is above the circuit table range. Please see the note in the gauge level2 doc:

I think the root cause may lies on that the circuit table in the 3507 project is for LiFePO4. You may need to genrate your own circuit table, if the battery type is different. Or you can copy the circuit table from this project.

Currently we don't have Rcell, cap factor and slope rate information, we only have OCV and SOC relation. Have any way to skip Rcell, cap factor and slope rate data from gauge algorithm? or fixed data?

Can you follow the doc to generate the test pattern?

Then input the file into the GUI

Here is the test pattern example:

We are doing it now.

one question, in the code definition, the Rcell element is fourth, but document.

code definition

Document,

Thank you for the notification. I will update this problem in the next version. 

About FullOcvMatrix and EmptyOcVMatrix, could we keep it "0"? or need some value?

//u16FullOcvMatrix is related to TempThd_C. it means the FullOcv between the settled temperature range shown as bellow
// 50 30 15 5
// TempThd_C[0] TempThd_C[1] TempThd_C[2] TempThd_C[3]
// | | | |
//Matrix[0] Matrix[1] Matrix[2] Matrix[3] Matrix[4]
//Users can input these information ahead to reduce the SOC error at beginning. The data can be get by charging the battery to full
// and rest for 1 hour. These inputs can also leave to be 0 and it will be learnt when algorithm runs.
.u16FullOcvMatrix[0] = 0,
.u16FullOcvMatrix[1] = 0,
.u16FullOcvMatrix[2] = 0,
.u16FullOcvMatrix[3] = 0,
.u16FullOcvMatrix[4] = 0,
//u16EmptyOcvMatrix is related to TempThd_C and CurtThd. it means the EmptyOcv between the settled temperature range
// and settled current range, in a 2D matrix, shown as bellow
//j: means matrix column
// -300 -600 -1500 -3000
// CurtThd_mA[0] CurtThd_mA[1] CurtThd_mA[2] CurtThd_mA[3]
// | | | |
//Matrix[5*0+j] Matrix[5*1+j] Matrix[5*2+j] Matrix[5*3+j] Matrix[5*4+j]
// TempThd_C[0] 50
//Matrix[4*0+j] .....
// . TempThd_C[0] 30
// .
// .
//Users can input these information ahead to reduce the SOC error at beginning. The data can be get by discharging the battery to empty
// and rest for 1 hour. These inputs can also leave to be 0 and it will be learnt when algorithm runs.
.u16EmptyOcvMatrix[0] = 0,
.u16EmptyOcvMatrix[1] = 0,
.u16EmptyOcvMatrix[2] = 0,
.u16EmptyOcvMatrix[3] = 0,
.u16EmptyOcvMatrix[4] = 0,
.u16EmptyOcvMatrix[5] = 0,
.u16EmptyOcvMatrix[6] = 0,
.u16EmptyOcvMatrix[7] = 0,
.u16EmptyOcvMatrix[8] = 0,
.u16EmptyOcvMatrix[9] = 0,
.u16EmptyOcvMatrix[10] = 0,
.u16EmptyOcvMatrix[11] = 0,
.u16EmptyOcvMatrix[12] = 0,
.u16EmptyOcvMatrix[13] = 0,
.u16EmptyOcvMatrix[14] = 0,
.u16EmptyOcvMatrix[15] = 0,
.u16EmptyOcvMatrix[16] = 0,
.u16EmptyOcvMatrix[17] = 0,
.u16EmptyOcvMatrix[18] = 0,
.u16EmptyOcvMatrix[19] = 0,
.u16EmptyOcvMatrix[20] = 0,
.u16EmptyOcvMatrix[21] = 0,
.u16EmptyOcvMatrix[22] = 0,
.u16EmptyOcvMatrix[23] = 0,
.u16EmptyOcvMatrix[24] = 0,

You can keep it to be 0, that is also what other customer's doing. Making it not to be 0 will has less SOC error before a learning cycles, as the emptySoc and fullSoc is already inputed into the system. Please check this chapter.

One question about below setting, do you have any document to explain u8SysTikShift of gauge algorithm?

//*****************************************************************************
//
//! \var gaugeApp
//! This structure stores the global settings for this application.
//
//*****************************************************************************
tGaugeApplication gaugeApp= {
.ui8NrOfCell = CELL_NUMBER,
.pBattGlobalParamList = battGlobalParamsArray,
.pBattParamsCfg = &battParamsCfg,
.u8SysTikShift = 8, //As the least sys clock is 500ms, we multiply it with 2, Hsin chnaged to 50ms (20)
.sysTikFreq = eSystemTik_1000MS,
};

Hsin Wu

Please refer to this:

We use a timer with 4.096kHz as the system clock.

We want to enable customer if they want to change the systick freq. They only need to change .sysTikFreq, with the enum already listed. Please don't change the .u8SysTikShif. The fastest systick is 500ms.

So if we keep original setting .u8SysTikShif = 2 and change .sysTikFreq to eSystemTik_e500MS, does it mean that the gauge app is performing every 250ms?

No, it is just 500ms not 250ms.

The current solution don't support 250ms. The reason is that event there is some puluse current mismeasured by our solution, the error can be controlled by our data fusion method.

due to customer requested us to meet dynamic testing in first sample stage. The report and update rate will be every 50ms and just low SOC accuracy needed. Do you have any suggestion? Does gauge L1 can support?

Hi  Eason Zhou , 

Customer ask in "BQ769x2_protocol.c", DirectCommand(), after accessing AFE (BQ76952) by I2C, why does it need to delay 2000us + 2000us ? Does this depend on AFE BQ769x2 specification?

Thank you

Hsin Wu said:

due to customer requested us to meet dynamic testing in first sample stage. The report and update rate will be every 50ms and just low SOC accuracy needed. Do you have any suggestion? Does gauge L1 can support?

I would suggest you to update the Icell, Tcell, Vcell with 50ms. And input the Icell Tcell and Vcell with 1Hz into the algorithm. I think this can realize what is needed by your customer.

Jerry Kuo said:

Customer ask in "BQ769x2_protocol.c", DirectCommand(), after accessing AFE (BQ76952) by I2C, why does it need to delay 2000us + 2000us ? Does this depend on AFE BQ769x2 specification?

This code is just for demo, and written by us. Just to enable the capability to use the basic function of BQ devices. Some of the delay time can be removed by customers. Besides, the code also miss the calibration. 

Got it and thanks.

Can we adjust u8SysTikShift or sysTikFreq to achieve 50ms routine?

Yes. You can. But these two parameters are used by the algoritm to caliculate the Delta_Q. I would suggest you to use another timer to do this job.

If you want to use the same timer to do the job. Here is the following steps. 

Step1:

Change this timer to be 50ms at here:

Step2:

Remove the timer calibration function(calibrate LFCLK based on SYSOSC)

Step3:

Run the algorithm when systikflag is set be 1 for 20 times

Thanks

One question regarding AFE BQ769x2

Current design of AFE, how many slot in a loop and how many loops confoguration in current firmware?

Hsin Wu

One question about BQ769x2 setting, if we set the AFE userA from mA to 100mA, it seems the SoC calculation is wrong. 

BR,

Hsin 

Can you share the GUI log csv file with the userconfig files? Then let me check what is the error.

/ Set DA configuration Deciamp (100 mA) units are selected for user-amps - 0x9303 = 0x03
//BQ769x2_SetRegister(DAConfiguration, 0x03, 1); // 100mA user-amps
BQ769x2_SetRegister(DAConfiguration, 0x01, 1); // 10mA user-amps

Due to this project will support more than 450A peak current, so we have to configure userA of AFE to 100mA. It seems to cause the SoC wrong calculation. May I know the maximum current to be supported in your algorithm? Can we input 450A?

Hi Hsin,

No, the max current is ±32.768A. You need to intput the current to the algorithm by dividing it with 100times (450A ->4.5A).

Then the Capacity will also be divided with 100 times. But it will not influence the SOC calculation.

When you meet problem, can you send the GUI log csv file with the userconfig files? Then I can check if the problem lies on the setting or the algorithm.

Eason

Hi Eason,

The problem is the SoC calculation is too slow to update and not sure is is correct.

Currently the AFE setting of userA is 10mA. If we revised the u16DesignCap_mAh from 1085 t0 108 (unit 10mA), can we see SoC update quickly?

BR,

Hsin

Hi Hsin,

Sorry, I don't know about the AFE setting. Please don't inlcude any AFE related concept.

Here is the way we calculate the SOC: it will inlcude the capacity accumulated every second. So, its resolution will be above 1/108. Its real resolution is 1/(108*3600). On my side, if you meet any problem and share the GUI log csv file with the userconfig files, I can check what happens in the code. To be honest, I haven't run any test based on the batteries on your side.

If you use 10mA, as the resolution. The max current value will be 45000, which is still above the 32768. That is why I suggest you to use 100mA as the resolution. I just wandering, for this battery, you only need  1085mAh/450A = 0.0024hour to charge to full? It is really amazing. 

Eason

Hi Eason,

As the resolution, we can configure AFE with R sense value to 20mA per bit to let 32768 to support more than 600A.

Thanks for sharing, we know how to use it to meet our projects.

BR,

Hsin Wu