Learn Cycle "Error: [RUP_DIS: Not Clear]" after discharge relax

LearningCycleOverview_bq274xx.pdfRup dis gets cleared when the dv/dt condition is reached and an OCV measurement is taken. See the attachement below on how to carry out learning on our ROM based gauge. Did you check to make sure you cells can work with the default chem ids on this chip.Data sheet contains the max charge voltage for the different types of Li-ion cells that this chip supports. Also pls read the quick start guide of the device. It is on the product folder on ti.com. this will enable you avoiding mistakes when using the gauge.

Onyx,  I appreciate the learning cycle overview as that has given me a better understanding of the learn cycle.  I am still failing in the same way, but I "may" understand some of the issue.

I had been using the automated learn cycle using the EV2300 GPIO controling N and P channel discrete MOSFET pairs.  I was under the assumption based on the learn cycle information, that the learn cycle started with a full battery to start the learn cycle test and depleting the battery during the learn cycle.  I now understand that the learn cycle test first depletes the battery to be able to "start" the actual learn cycle.  After the set battery discharge threshold of 3000 mV is attained, it waits for (up to) 360 minutes for the dV/dT to be 1uV/s and fails and cancels the learn cycle if after 360 minutes the RUP_DIS is not cleared (which is my issue).

My first issue is trying to measure to verify the 1uV/s stability rate.  The best I currently have to measure is a 5 1/2 digit benchtop DMM (HP 3478A).  Is the sampling rate really per second, or is it averaged over some other number like 10 seconds or other (could coupled "noise" cause an issue?).  The fuel gauge itself only has a resolution of 1 mV.  It does appear that over time, the resting battery is still gaining small voltage.  The battery has been at rest for over 13 hours now.  The Control Status remains at 0x009E and the Flag is set at 0x010E.  The update status remains at 0x00.  The battery is made up of two LiCoO2 batteries in parallel with a PCM which cuts off at 2.5V.  The battery capacity is 5000 mAh.  Would it be reasonable for the battery resting voltage to be within 1uV/s after 12 hours?  Should I give the battery an extensively long time to settle (more like a week to become < 1uV/s)?  If the battery does eventually settle after many days, will the automated test continue, or am I not able to run the automated test?  Do I have to perform the learn cycle in a way other than the automated test due to this issue?

In the meantime, I will continue the rest state until and if the RUP_DIS and VOK clear.

Any information that you can give me on expectations for this specific battery in the attempt to release the RUP_DIS and VOK by attaining < 1uV/s resting battery voltage so that I can continue the learn cycle would be greatly appreciated.

Note: I have verified that there is no leakage current from the implemented charge source P channel MOSFET significant to have a voltage that could leak into the battery.

Thank you.

David,

Are you running these tests on an EVM. If yes, do you have a 10k resistor from BIN pin to ground? Do you have the BIE flag set in operation configuration register?

You do not need to make the 1uv/s measurements. The gauge takes care of that. You will have to make sure that your cells are relaxed. if the voltage continues to rise after a discharge then it means the cells are not well relaxed; 13 hours is a long time though, the cell ought to have relaxed after 5 hours. Even if it isn't after 5 hours the gauge will automatically take an OCV measurement relaxed or not. So i suggest  after waiting for 5 hrs and 30 minutes, start the charge to full and then rest 2 hours and check to see if qmax value in the dataflash will get updated. pls log your data using bestudio or bqevsw and extract a gg.csv file from your devcie file before and after learning so we can see if and why learning fails.

thanks

Onyx

Onyx,

I had been working off a modified version of our product.  The interest at that time was to be able to use multiple master I2C interface with the processor on the board to be able to monitor status.  There apparently was an issue with multiple mastering the I2C, so I held the processor in reset.  The modifications that I made were to bypass the battery charger and fuel gauge with direct mains input power to the processor.  I needed the power supplies to be up for the 1.8V pullups for the I2C bus.  The other modifications are the load connection through MOSFET pairs and the MOSFET pairs to allow charging to the battery for learn cycle automation.

I have pulled the battery from the circuit completely to rule out any possible charging leaks (from potential processor IO currents through the unpowered battery charger).  The unconnected battery is still increasing in voltage > 1uV/s some 16 hours after discharge.

The direction I am going now, is to run a lighter load for the depletion process.  I had been charging at C/3 and also discharging at C/3 which probably accounts for a more powerful (and longer lasting) rest cycle.  The battery probably would eventually get to V < 1uV/s, but it would probably take quite a while.  The learn cycle application probably can not handle the longer relax time and times out after 6 hours.  I will run a 5 Ohm load which between 4.2V and 3V remains between C/5 and C/10 for the discharge over the weekend and see if I have better results on Monday.

To follow up on your questions, there is a 10K pulldown to ground from the BIN pin.  Yes, the BIE flag is set as you can see in the register dump I originated this thread with.  Probably more importantly is the Flag battery detect BAT_DET is set as noted by 0x010E (bit location 0x0008).  My understanding is that the relaxed state is determined by the change of voltage being less than 1uV/s.  So in able to determine if that parameter is satisfied, I figured I would have to qualify that by measuring it.  It does appear that by measuring that, I was able to determine that that is probably at least one of the issues.  I did not see an OCV_TAKEN during my search from the log file earlier, but I will look again from the log last night.  QMAX had not been updated, but then I was under the impression the QMAX could not update if RUP_DIS was never set low (I might be misunderstanding that, and it may just be the Ra tables).  I am hesitant to charge the battery now that I know the learn cycle starts with a fully depleted battery.  Charging and discharging again will add another day (or more) of run time, and I would like to get past the relax threshold and see the RUP_DIS and VOK bits clear.  I am using Battery Management Studio (bqstudio) 1.3.42 which is the latest that is promoted for this fuel gauge.  I am hesitant to switch software interfaces to beststudio or bqevsw since that will likely confuse me with interface differences without known benefits (unless it is determined there is an issue with the promoted software I am using).  I extracted the register file originally, and they have not changed much (I did change the design energy to the ratio for this battery construction based on the information you sent before).

Monday I will have more information, and after I digest the information and log files, I will give an update.  I will determine after that if I should run another charge cycle before running the learn cycle again.

I apologize for the delays in responding as it is quite time intensive to run test iterations and log file decomposition.  Thank you for your patience and your assistance.

Dave

Hi Onyx,

I understand and appreciate the complexity of the device to be able to accurately monitor SOC for many chem IDs, capacities etc.  It is a learning curve for me since there are so many different fuel gauges and software interfaces, and application notes that refer to similar, but different devices.  There are subtle differences between parts and software packages that make it a bit confusing as well.  We have been running this device for a while, but I need to be able to run battery cycles to evaluate the RSOC and be able to log and track the trend consistently.  I need to understand the accuracy of a long running device as well as a device who's battery PCM has cut out losing the fuel gauge memory.  I have been plagued with configuration issues from automation setup such as designing an interface for the GPIO which isn't well documented in my opinion (active state high/low) as well as logging that fails due to PC power saving shutting down the USB interface over night.  The state of charge by default has not been very accurate originally, but may be getting better as I understand the parameters better and define the setup better.  I hope to be able to create repeatable charge discharge cycles monitoring RSOC both with steady loads and true usage loads.

Hopefully I will be able to eventually understand the nuances of the configuration and learn cycle, so that I can create a golden image that the software group can use to get the most accurate RSOC from a newly powered unit.

I will check the logs again (hadn't had time since last reply) to see if OCV_TAKEN was read in the last log file.  The current is definitely well below the quit current since the battery charger is turned off (zero volts input to the battery charger and zero current in the average current reading from fuel gauge).

Thanks again for the tips for running the device in alternate modes.

Hello Onyx,

After digesting the learn cycle log over the weekend, I do have some interesting information.  Here is some of the extracted data from the weekend log with associated comments.

Notice that RUP_DIS and VOK did actually clear.  Also notice that the run time when it cleared was over 19 hours after starting the learn cycle.  The learn cycle failed when it did not see the the RUP_DIS clear within 360 minutes.  I did not see QMAX or Update Status change from default settings.  I would love to be able to log the Update Settings with the register log, but I find that quite often it fails to log within the 5 second interval.

This brings up a slew of questions to go forward.

1) Can the learn cycle RUP_DIS be extended without failing within the current time limit settings (as well as any other timeouts on the charge portion)?

2) Does the learn cycle ONLY control the GPIO for source charging control and load control, or does it actually set parameters in the device through I2C?

3) Can the 1uV/s parameter be changed to something more manageable for a slightly less relaxed battery state?

4) Could the I2C pullups to 1.8V and the associated I2C traffic cause a slight charge current into the system that would potentially be an issue with the ultra low 1uV/s readings?

5) Could the fact that we are using 2 cells in parallel have anything to do with the extensively long relax time as the cells balance each other?

At this point, I believe the direction I should go is to now do a charge cycle manually (since the learn cycle won't continue) to be able to charge to get the FC and QMAX updated.  Then start the learn cycle application again to discharge the battery disconnecting the load at the proper cut off voltage (so as not to drain the battery below the PCM cutoff which would shut down the fuel gauge), then wait a couple days for the 1uV/s threshold and verify the Ra tables are updated.

I would really love to automate this process if at all possible and be able to log the data to follow the RSOC over multiple cycles without user intervention.

Note: The discharge on Friday when I started a log was on a depleted battery and not on a fully charged battery.  With a discharge from a depleted batttery it took over 19 hours to be below 1uV/s.  Discharging from a full charge to the 1uV/s threshold I assume would take quite a bit longer.

Thanks for any information that you can give me on being able to automate this extensively long learn cycle.

Dave

Hi Onyx,

After identifying that a learn cycle for our battery would take about a week, I would like to further understand the opconfigb setting that you mentioned above.  I see that bit is a reserved bit, so I want to understand it's function in updating the resistance tables.  Is there a way to understand what the QMAX and Ra table values would be?  QMAX appears to be a scale instead of direct capacity in mAh.  Would it be possible to enter a 5000 mAh equivalent value?  Can the Ra tables be entered manually based on known impedances?  Are there other registers that can be loaded directly based on the battery specifications used?

If this reserved bit is set, do I only set it temporarily, or for a sequence such as a depleted battery resting for only 5 hours (instead of 48 hours).  Should this bit be set back after the golden image is created?

I am now trying to understand if QMAX can be updated with FAST QMAX.  Are there several ways that QMAX can be updated?

I do want to correct an error that I sent in the last reply as I said it took over 19 hours for the depleted battery to relax.  That was an error because the log does not differentiate AM versus PM in the timestamp, so I created an elapsed time in the excel spreadsheet based on 2 second (which is the software default) for logging.  The actual log rate was set to every 5 seconds, so the relax time for RUP_DIS was not 19 hours, but over 48 hours.

Thanks for any detailed information that you can provide to generate the QMAX, Ra Tables, and any other registers that I should set for the best chance at an accurate RSOC until I can successfully complete a learn cycle.

Dave

Hi David,

if your learning cycle was successful, there really isn't a need to rerun the learning cycle again. You now have you learned resistance tables and qmax, essentially your golden file with those parameters in there. You should simply evaluate the gauge for accuracy to make sure the error in reported soc is an acceptable value for you. That really is the whole point in learning, i.e to ensure the qmax and resistance are learnt inorder to have the gauge accurately track SOC. see attached ppt on how to calculate the accuracy of a gauge.

When the gauge is in the field, it will dynamically learn the resistance of the battery it is attached to  during discharge. When you have rest periods and atleast 37% of design capacity passed charge between two rest periods you will have the qmax update as well

Analyzing Accuracy of a Battery Fuel Gauge System - Onyx Ahiakwo Jared Casey.pdf

thanks

Onyx