Strange results on TimeToEmpty and StateOfCharge measurement

Fabien

Which gauge are you using?

Tom

Fabien 

It will be difficult to tell what is going on just from the graphs. Can you provide logs of the cycles ran and the gg file extracted from the gauge. Is this problem reproducible and do you see it on multiple devices?

thanks

Onyx

Hello Onyx,

Please find attached the log file of the device. The sample time is 1 min. You will find %, TimeToEmpty and Battery voltage.

Find also the .dfi file load into the gauge.

Yes the problem is reproducible but we are not able to be predictable, we don't when it will append again - every 5, 6, x charge/discharge cycles. And also yes, it happens on several devices.

Many thanks

Log+DFI.zip

Hello everybody,

Please find attached new data log with 6 consecutive bad cycles.

This is really surprising, 6 consecutive bad cycles, and until now (on this same machine) everything is correct.

What could happen ? It looks like during this time current is close to 0, but on the same way, at the end of the cycle the percent come again with a correct value (close to 0 but looks correct) ?

See attached also a case tracked today where we can read the flash during the default (StateOfCharge is blocked to 89% for a long time). Things strange : The SOH Status = 20 !  StateOfHealth = 170 ! and regarding other machine RUP_DIS is at False - but i don't if it normal or not.

Many thanks for your help

OneEventsLog-20150720103346.zip

Hi Jason,

Many thanks for your help. 

This is really surprising, we made new test and on 5 machines the problem occures at the same time about 6 cycles !

If we disconnect the battery, power down and up the gauge, the value is correct and we can imagine to have 5 or 6 good cycles more.

I notices that the QEN was not Set. We launch new cycles with it selected. We should have the result on 2 or 3 days (charge and discharge takes 12 hours each time).

Do you think it could be the explanation ?

This is really surprising, everything is correct and sudendly it fails !!!

I will try to provide the data from the gauge.

Jason,

Please find attached 3 .gg files zipped. 2 concerns the machine #7b before and after has been blocked et the #10b blocked as well.

On the machine 7b, I put IT Enable on DataFlash to 1, but it does not change anything. It was to put QEN at 1, do you think it has the same effect as putting 0021 into the control status.

Thanks

GG Files.zip

Hi Jason,

I appreciate your help on this so strange issue !!!

We have another data, gauge fails at 6 cycles (charge/discharge) each time !

The battery voltage on the excel file has to be divided by 10 to have the right voltage. This a 7 cells battery with a nominal at 25.2V.

We will try to provide log with control status.

Another assumption : test we ara doing is to keep the charge for 6h and the discharge during 6h also. After 6h charge is just complete. Same for the discharge. That's mean that relation times could be very small and may be absent on some cases. Do you think it could have an impact ?

After fail, the gauge is not able to recover is correct state alone, we have to get out the battery to reset the component.

I cannot understand how the calculation can stay to the same value ?

Hi Fabien,

Now that you mentioned it, is there a particular reason you are using a single-cell gauge like the bq27510-G3 in a multi-cell configuration? It's not necessarily a bad thing to do this, but TI has a new gauge, the bq34z100-G1, that is explicitly designed to support single-cell and multi-cell configurations (so you can program that gauge so it knows it is being used in a 7-cell battery).

Also, to clarify, are you running the cycles with no resting time in between (so once the discharge stops, the charging starts immediately)? Impedance Track needs the battery to "relax" for a while (about 1-5 hours), so that it can take a good open-circuit voltage measurement to update the Qmax and State of Charge readings.

I'm not sure why the State of Charge readings stop updating after the sixth cycle, but it is hard to tell what is going on inside the gauge without detailed logs.

Regards,

Jason

Hi Jason,

Yes we heard about the BQ34z100 but it was too late for this design. We planned to use it on a new product.

Yes, the test we are doing (which is not really the current use - but it could happen) is to charge and discharge with sometimes 10min until 1hours between phases. So yes, that's mean that Qmax is not updated each time and perhaps never on some test, but it is not a real issue for us because even if Qmax is not updated, the accuracy of the result given is enough for us. Our problem is to have % blocked at the same level during a big part of the discharge, and the same after a new charge, and we don't know why, sometimes, it recovers his good level after a few cycles, but not all the time.

Tell me if i'm wrong, if Qmax is not updated the risk is just to have a bad accuracy ? that's all ?

We will try to log data from the gauge. "Control Status" every 1 minutes could be enough ?

Thank you Jason

Fabien,
The gauge does not have to update Qmax every cycle to maintain accuracy, but it should get updated every 1 to 2 months. The problem that you are seeing where the capacity does not change during the first part of discharge is due to the Passes Charge counter and the pack is probably over charged. The Passed Charge counter continues to increment after RM has reached FCC and the excess charge has to be decremented at the beginning of discharge before RM starts to count down. The Passed Charge will get cleared, if there are adequate rest periods and you should not see this.
Tom