BQ27421-G1: Sharp dip with SMOOTHEN enabled

Hi,

Would you be able to provide a .gg file so I can look at your settings and a full BQStudio log so I can observe the status of some other registers when this jump occurs? I suspect that you may be crossing an Ra gridpoint here and this resistance update may factor in to the jump in RSOC but I will need these files to dig deeper and confirm this.

Best Regards,

Hi Jackson,

We haven't used BQStudio and are not using the evaluation kit.  This is on our custom hardware and software in our prototype product being used by beta testers.

Can you let me know which commands or registers you would like logged?  We can log anything that may be relevant.

Without BQStudio, how have you programmed the correct ChemID to the gauge?

Hi Jackson.

My understanding is that the bq27421 does not allow you to program the chemistry, but it is fixed based on part number.  See here in quick start guide.  Am I missing something?

This is correct. My apologies, I forgot that your design was using the BQ27421. Is this something that happens consistently on every chg/dsg cycle or does this only happen occasionally? I am trying to deduce whether this is a configuration issue or if the gauge is just learning and updating parameters such as FCC over time which leads to this jump in RSOC.

Best Regards,

Jackson

It seems to be occasional, but this is a new design so we don't have a ton of data yet.  If it were gauge learning and updating parameters, what can we log to determine this?  

Can you also share more info on the expected smoothing behavior, so we know what kind of jumps are expected, versus those that should not be expected?

Hi Stephen,

Typically, its is good to log I/V/T as well as all protections and gauging parameters such as dod0, Qmax, and REST. This gives us a fighting chance at finding the root cause of the behavior. In general, the more registers logged the better for debug purposes.

I am reading through the firmware code currently and will update you with a summary on the smoothing function's behavior tomorrow.

Best Regards,

Jackson

Hi Stephen,

Essentially, smoothing on this device works by ensuring that neither FullChargeCapacity() or RemainingCapacity() experience large jumps that would be uncharacteristic for a real world battery system to encounter. Since RSOC = RemCap() / FullChargeCap(), this also prevents RSOC from experiencing large jumps as well.

The exception to this rule is if RemainingCapacityUnfiltered() reaches 0, the gauge will allow a jump to 0% RSOC to prevent over-discharge and damage to the battery.

Best Regards,

Jackson

Hi Jackson,

For the logging, can you list the exact commands or data memory class / subclass / offsets that you'd want?  I'm not sure exactly what to log based on your description of dod0, Qmax, and REST.

We currently log Voltage(), AverageCurrent(), and Temperature().  These were shared in my original plot.  Unfortunately AverageCurrent() is often not reported, I think due to the default Deadband setting of 5mA.  Would you recommend reducing this value for debug?

For the smoothing, can you give me any idea of time constants or cutoff frequency used here?

Thanks

Hi Stephen,

I think we may need to backtrack here a bit just so I can ensure that I understand what phase of the development process you are in and by extention, what the gauge will know about the cell that is attached.

Have you completed a successful learning cycle yet and obtained a golden image? these sort of jumps may be expected during the learning cycle as the battery you have attached to the gauge may differ slightly from what the default ChemID tells the gauge to expect.

Best Regards,

Jackson

Hi Jackson,

Sorry for the late reply.  It's possible we have not completed a learning cycle yet.  How would you recommend we confirm whether these dips are due to the lack of a learning cycle or not?

Hi Stephen,

Our team is currently out at the BMS seminar. I will get back to your question tomorrow.

Thanks for your patience,

Jackson

Hi Stephen,

This RSOC jump is definitely caused by a jump in Remaining Capacity. This is likely occurring due to a DoD/QMax update being taken and a new simulation being run to update these values compensated for load and temperature. I would recommend going into the settings of the device and setting OpConfigB [SMOOTHEN] = 1. This will use RemainingCapacityFiltered() rather than unfiltered and therefore prevent jumps in RemCap and by extension RSOC.

Best Regards,

Jackson

Hi Jackson,

Smoothing is already enabled.  But we don't save data from the fuel gauge every time it has a new sample, so the smoothing may not help us if the time constant is too short.  That's why I asked you about the time constant of frequency cutoff of the smoothing.  Right now I have no idea what to expect from the built in smoothing because it is not sufficiently documented.  "Preventing large jumps" is not enough detail.

How can we confirm that a DoD/QMax update is being taken?  I'd like to confirm this rather than assuming.

Thanks,

Steve

Hi Steve,

If you log the status of QMaxCell0 you can see when this value changes and confirm when a Qmax update is occurring.

This being said, with smoothing enabled it is impossible for an RSOC jump to occur. This leads me to two possible causes for this behavior.

1. A reset is occurring on the gauge where the algorithm does a voltage lookup to re-estimate RSOC causing the jump.

2. For some reason, your settings on the device did not stick and smoothing is not actually enabled. 

Best Regards,

Jackson

Hi Jackson,

I apologize for the long delay in replying to this ticket.  Some other issues came up that I needed to deal with.

We did get logging of QMaxCell0 setup and deployed to our devices in the field.  The logging shows that we see big dips in capacity (~10%) and this does not coincide with QMaxCell0 changing.  

We do not log SOC to the cloud every time it is sampled by the gauge.  Instead we only have one sample every 5 minutes or so.  For this reason, I think the smoothing won't help us, but I"m not sure, because I don't know the characteristics of the smoothing filter.

I"m trying to do a learning cycle using bqStudio and the BQ27421-G1B evaluation kit.  I'm using the Learning Cycle GUI inside bqStudio.  The cycle failed the first time.  I attached logs.    The error that was printed from the Learning Cycle tab console is:

"Wed Nov 16 15:46:23 EST 2022: Error: [RUP_DIS / RDIS: Not Clear]
Wed Nov 16 15:46:23 EST 2022: Learning cycle cancelled "

Can you review the logs and let me know what may be the problem?

Thanks so much!

learning_trial_1_failed.zip

Hi Jackson,

Please let me know if you have any feedback on these issues.  We are starting to ship to customers and need to find a solution quickly.  Appreciate your support.

Hi Stephen,

I looked at your log file and I have a few questions for you.

1. This log file does not include any discharge information. Are you doing the following? 

• discharge battery completely
• send RESET command to the gauge
• charge fully and relax until REST bit sets.
• discharge fully and relax again until REST bit sets.

2. For some reason the log is showing your current to be 0mA for the entire log. do you know why that is?

If you follow the bullet points in question 1, this should allow you to complete the learning cycle.

Best Regards,

Jackson

Hi Jackson,

Thanks for getting back to me, appreciate it.

I hadn't charged yet because the GUI errored out before instructing me to do so.  Like I said , I'm using the Learning Cycle GUI inside bqStudio, it gives step by step instructions.  But maybe it has a bug.

I was actually just trying to do it manually, similar to how you described.  But your procedure is not very complete.  Can you add more detail?

For instance:

1) When do I load the configuration (e.g. design capacity, design energy, etc)?  I think before sending RESET (also please confirm by RESET you mean SOFT_RESET command).

2) Is a rest needed between first discharge and charge?   The doc linked below says you should.

www.ti.com/.../slua777.pdf

3) Which bits in CONTROL_STATUS and FLAGS should be checked at each point in time?  There is no REST bit in the bq27421.  I think the relevant bits to pay attention to may be VOK, RUP_DIS, OCVTAKEN, QMAX_UP, RES_UP, and maybe some others

4) Can you confirm if I need to pay attention to BAT_DET?  In my current test it is cleared, the reference manual said it should be set but I don't want to interrupt this test.

Thanks,

Steve

Thanks Jackson.

I'm particularly interested in learning a resistance profile.  When should I expect RES_UP to get set?

Thanks,

Steve

Hi Jackson,

Please check out the attached files output from bqStudio.  I was planning to discharge again, but I shorted out the battery by mistake and it lost configuration.

You can see there is a full charge and discharge cycle, but RES_UP never got set, and resistance is not updated.  Any idea why?  QMAX_UP did not get set until I went through a full charge discharge.  Do you need a discharge after QMAX_UP is set to see RES_UP get set?

Thanks

manual_cycle_1a.zip

Hi Steve,

Yes, you will need an initial QMax update before resistance updates. When you send the RESET command, resistance updates are disabled on the first discharge cycle after the reset. This is so you can discharge to empty without updating resistances. You then should charge and relax until QMAX_UP is set, then discharge until RES_UP is set as well.

I think that depending on when you send the RESET command that the initial discharge may have resistance updates disabled which could be why we are seeing this behavior.

Best Regards,

Jackson