BQ34Z100-G1: Learned Pack - AvailableEnergy Strange Behavior

Hello Joshua,

We have started an internal discussion on how to correct this, for now this will probably be the only way, unless it is extrapolated out using the data available in the gauge.

Sincerely,

Wyatt Keller

Wyatt,

Sounds good. I was just chasing this to make sure I wasn't doing anything wrong on my end. I think I will encourage the firmware team to not present this value to the customer for now in order to avoid any issues. Looking at old data, it appears that most, if not all, designs I've done in the past have exhibited this behavior.

I know you said about 4 months ago that the R2 version was going to have this resolved but I never really got far into testing it because of the surprise jump to 100% SOC issue that would happen on a pack at pretty much any standing SOC if you just briefly charged ~100mAh into the pack and then stopped and waited 5 minutes. Did that team ever figure out why it was happening?

Hello Joshua,

It may be best to do the calculation based on other reported gauge data if needed.

There are some issues with the units and scaling factor I believe that might be linked to this, which are being looked into now, still waiting on our firmware/systems team for the final release.

Sincerely,

Wyatt Keller

Bump regarding the R2 FW and surprise jump to 100% SOC after a brief period of charge while at a significantly lower SOC.

Hello Joshua,

Was this behavior confirmed to be due to VCT or were the conditions not met? I remember you said the bit to force FCC = RemCap at charge termination is set for your configuration. That is the most common reasons for jumps in RSOC upwards, there's not much else which will force that type of behavior. The voltage criteria may be set too wide so it always qualifies, then any small charge current could cause charge termination. 

Sincerely,

Wyatt Keller

Wyatt,

I double checked. It was confirmed that VCT was not the case.

FC doesn't assert. In both previous test logs a short pulse of charge brings remcap to ~95% on the first try. I checked the flag too and it is not asserting.

Taper current is a typical 100mA, Min taper cap is 25, and Cell taper voltage is 40mV.

Hello Joshua,

I just checked the log again, it seems this is related to the DOD0 for the voltage correlation the gauge uses, it looks like it may have taken a bad OCV or the chem ID is not a good match since DOD0 changes so much with very little change in voltage. The small charge current just allowed the gauge to run a new simulation based on the new DOD0 and start to force SOC to the corresponding OCV last OCV point we took. This could be related to some of the R2 issues we discussed before with the scaling factor.

Sincerely,

Wyatt Keller

The ChemID  used is the same that I had with theG1 firmware and that tracked really well.

Moreover, these cells were sent to TI in order to generate that specific ChemID so we should be good on that.

It looks like it is not using the previous OCV but taking a new one 60sec after the charge current stops.

Also pretty interesting. Every month or so I put ~100mAh into the pack just to keep it maintained at around 60%. As usual, 60sec later it jumps to ~93%. I let the pack sit for the week and it did go back to the percentage that it ought to be at. So clearly the OCV table is correct. I just don't know why it is doing it immediately after charge.

Yes I was considering that scaling factor to be an issue possibly. What I still don't understand here is that, moving from G1 to R2, using the same calibration values I get a new pack voltage that is above 65535mV. The only way to resolve this is to set Volt Scale = 6 which then displays the appropriate pack voltage and really messes up the fuel gauging, OR I can set the Voltage Divider parameter to one sixth of what it used to be and now I get the correct pack voltage and okay fuel gauging.

It seems that this changed from one FW to the next:

G1 -- Voltage Divider = 1000 * Vmax [mV] / 900mV

R2 -- Voltage Divider = 1000 * Vmax [mV] / 900mV / Number of series cell

Either way, looking at R2_Single_Pulse.log from before, all I see is FIRSTDOD being asserted at the same time that the RemCap dramatically changes. 

Hello Joshua,

The FIRSTDOD should only indicate the gauge has entered a RELAX state (then clears when OCV is taken). Checking when new firmware will be published, seems that it has been finished and is being validated now.

Sincerely,

Wyatt Keller

Thread bump.

Thread bump.

Hello Joshua,

I will update the thread when there is anything changes in the status of this.

Sincerely,

Wyatt Keller

Yes that was understood when you stated it a month ago.

None of these bumps have ever been directed at you. I just keep the forum from locking out the thread by doing this every couple of weeks. It's happened to me before with something unresolved and then I needed to start a new post and reference the old thread. Get's kind of annoying and can split up info and add confusion. I don't like that.

If you have perceived them as directly to yourself, I am very sorry. That was never my intention.

I want to always convey my utmost respect and gratitude for the engineers at E2E as they have frequently delivered excellent technical support.

Hello Joshua,

No problem I understand having to open another thread makes it harder to track. The bump also opens it from our side so we need to take an action each time which is why I put in a response.

I'm really sorry for the delay, our teams have been working on this but it is taking much longer than expected.

Sincerely,

Wyatt Keller

Wyatt,

Helpful to understand how things work on your end as well.

No need for apologies on the delay. Some of these things can take time. Especially when rolling out a new firmware release.

This is my two-week thread bump.

Thanks.

Hello Joshua,

New firmware for bq34z100 was released last week. Wyatt can confirm if it is what you need

https://www.ti.com/tool/BQ34Z100-DEVICE-FW

Hello,

The -R2 firmware should have the latest fixes that were discussed earlier in this thread.

Sincerely,

Wyatt Keller

So concerning the original topic of this thread, it looks like the R2 FW now functions as expected. The overlay of SOC with AvailableEnergy looks like what I was originally hoping for:

Concerning the RSOC jump topic, I am waiting for the pack to rest to an OCV reading and cool off. I will try some charge pulses to see if it behaves appropriately. I will hopefully confirm soon.

I regret to inform that the SOC jump issue is still not resolved.

Full DSG, rest, 50mAh CHG pulse at 3.13A, wait ~1min and now at 99% SOC:

Let me know if you want any data or files and I'll be glad to provide them.

Thanks.

Hello Joshua,

Can you share the .gg file and the log file from the testing?

I've been reviewing the previous data again to see if I can find anything wrong, from what I can tell it looks like the gauge is taking an OCV and correlating that to SOC since the DOD0 is updated right when the jump occurs, that's about all I can see, and the gauge should not be doing this. What is your normal update process for parameters when you update the firmware? Do you manually update the settings from the default values?

Sincerely,

Wyatt Keller

Golden .gg file is included.

What I did was:

• Flash new FW
• Manually update flash parameters
• Program ChemID
• Update RA table with what was found in GPCRA0 and subsequent DSG runs
• Calibrate current since bqStudio won't let me do that manually for some reason
• Save golden .srec and .gg files
• Enable IT
• Charge (it was at ~63% when I started all this)
• Rest for OCV
• Begin logging
• Discharge
• Rest for OCV
• Pulse 50mAh of charge
• Observe SOC jump

R2_DSG.log

CL0027_R2_30.gg.csv

Hello Joshua,

Thanks for your detailed SOP, this is the correct way of updating parameters, I don't see any issues with your steps. I've also forwarded the new logs to the systems and firmware team.

Sincerely,

Wyatt Keller

Wyatt,

Thanks for checking my SOP and for forwarding the logs to the team.

Joshua,

No problem, sorry again for the delay, they are reviewing the logs and code now.

Sincerely,

Wyatt Keller

Wyatt,

No problem. Sounds good. Thanks for the update.

Hello Joshua,

It looks like some additional fixes were implemented and being evaluated now.

Sincerely,

Wyatt Keller

Wyatt,

Thanks for the update. Keeping the thread alive with this bump.

Joshua,

Still pending final release, waiting for approval to post.

Sincerely,

Wyatt Keller

Wyatt,

Thanks for the update. Keeping the thread alive with this bump.

Wyatt,

Just bumping the thread after two weeks. Have a good day.

Wyatt,

Just bumping the thread after two weeks. Have a good day.

Wyatt,

Looks like new FW has been released. I have updated the gauge and will repeat my test to see if the issue comes up again. I will likely find out tomorrow.

Hello Joshua,

Thanks for the update, looking forward to getting this resolved.

Sincerely,

Wyatt Keller

Wyatt,

So far so good. I repeated these steps with no SOC jump:

JOSHUA ANDERSON said:

• Flash new FW
• Manually update flash parameters
• Program ChemID
• Update RA table with what was found in GPCRA0 and subsequent DSG runs
• Calibrate current since bqStudio won't let me do that manually for some reason
• Save golden .srec and .gg files
• Enable IT
• Charge (it was at ~63% when I started all this)
• Rest for OCV
• Begin logging
• Discharge
• Rest for OCV
• Pulse 50mAh of charge
• Observe SOC jump

I wanted to test this just one more time at mid range so I charged the pack to 55% SOC from empty and am waiting for an OCV reading to happen. Voltage is changing at a rate of less than 4µV/second per cell but the REST flag won't assert. How long before the gauge forces a reading?

Hello Joshua,

That is good news!

The gauge should force an OCV 2 hours after charge and 5 hours after discharge.

Sincerely,

Wyatt Keller

Interesting. I let it sit overnight and the REST flag still didn't assert. Tried a 50mAh charge pulse anyway this morning and everything still works fine.

Is there a band in the flat region of the OCV curve where REST simply just won't assert? The reason I ask is because I bumped SOC up to 65% and got the REST flag in a very short amount of time.

Wyatt,

Thanks for that clarification. 

Here is a truncated version of what I threw at the gauge. No unexpected jumps in SOC:

A big thanks to Wyatt for providing 10/10 support on this thread that unfortunately ended up spanning multiple subjects and dragged on for ten months. Also thanks to the FW team for investigating this and the web team for rolling out the update.