BQ35100: Locating the cause of SOH_MERIT

Hello Rene,

The SOH_merit issue is from the voltage measured was higher than the original OCV taken.

I'm not sure if you have seen this thread but it explains it in further detail: e2e.ti.com/.../636077

Sincerely,

Wyatt Keller

Hello Wyatt,

It mentions: "For future tests please ensure a more rested battery and less time between GE high and Gauge Start CMD". I understand the need for a 'rested battery'. But 'less time between GE high and Gauge Start CMD' is a bit vague.

When GE is made high and the BQ35100 measures the battery voltage, the voltage drops slightly before that, because the MPU wakes up and consumes more power. When the MPU goes back to sleep, the voltage rises again. At which moment does the current battery voltage compared to the OCV result in a SOH_MERRIT? Is this only a single moment or can this occur at some time between the Gauge Start and Gauge Stop?

After GE=high the BQ35100 initializes and this takes some time. When checking this initialize status the MPU needs to periodically wake up and poll this status. This also has influence on the battery voltage level. So I let the MPU sleep for 2 seconds to keep it as quiet as possible. Is this 2 seconds too long, and to which delay should this be shortened to get to 'less time between GE high and Gauge Start CMD'?

Does the BQ35100 use a filter to prevent incorrect OCV measurements because of noise and these small voltage drops?

Regards,

Rene

Hello Rene,

A lot of these questions depend on your system, if you MCU is pulling enough current to cause voltage fluctuations it could definitely trigger the  SOH_MERIT flag.

The bq35100 doesn't have filters on the voltage reading.

Sincerely,

Wyatt Keller

Hello Wyatt,

I'm trying to locate the moment at which the problem causing the SOH_MERIT occurs. The Control Status register is updated with the SOH_MERIT status right after the Gauge Stop command. So somewhere between Gauge Start and Gauge Stop the battery voltage must get above OCV. As you mentioned, the OCV value is sampled at GE=high.

At which moment or moments is the battery voltage again sampled and used in the comparison which results in the report of SOH_MERIT at the end of the Gauge measurement? So is it only sampled again at the Gauge Start command moment, or are other moment between Gauge Start and Gauge Stop also important?

Is the difference between OCV and the battery voltage at some moment the only possible cause for the SOH_MERIT error?

Regards,

Rene

Hello Rene,

The SOH _MERIT flag will trigger anytime there's a bad value calculated by the algorithm (for the examples used, an OCV which increases without current will cause the error)

There's more information on the forum discussing this issue: e2e.ti.com/.../833628

Sincerely,

Wyatt Keller

Hello Wyatt,

Regarding e2e.ti.com/.../833628 it is unfortunate that no confirmation is given for the provided solutions. The situation seems to be very similar to my case.

In this forum discussion the following is stated: "This bit sets when the EOS algorithm fails due to a negative value in the math. The most common reason for this is when GE goes high the gauge takes what is assumed to be an OCV voltage measurement. From there the time it takes to issue the "Gauge start" command if the battery is not relaxed and a higher voltage is detected the algortihm falls down because you cant have a higher voltage than OCV without chg current."

So if this is the most common reason, does this apply to my case, of do I experience a less common reason?

Below you see the wake up, transmit and receive sequence which results in the SOH_MERIT error right after the Gauge Stop command.

When zoomed in on the GE=high and the Gauge Start command

The two functions which are used to create this sequence are as follows:

void gauge_on(void) {
    sleep(2000);
    DelayMs(50);
    GpioWrite(&gauge_GE, 1);
    sleep(100);
    /* Wait for bq35100 to initialize.*/
    sleep(2000);
}

bool gauge_start(void) {
    bool result=false;
    bool active;

    DelayMs(150);
    result = bq35100_gauge_start();
    DelayMs(150);
    if (result) {
        sleep(200);
        for (int i=0; i<20; i++) {
            result = bq35100_get_active_status(&active);
            if (!result) {
                return result;
            }
            if (active) {
                break;
            }
            else {
                sleep(100);
            }
        }
        gauge_started = true;
    }
    return result;
}

Can't the BQ35100 cope with the rise of the battery voltage when the MCU is in sleep? So during sleep the current consumption is lower and the voltage higher, than during a DelayMs().

When I change the gauge_on() function slightly to:

void gauge_on(void) {
    sleep(2000);
    DelayMs(50);
    GpioWrite(&gauge_GE, 1);
    DelayMs(100);
    /* Wait for bq35100 to initialize.*/
    DelayMs(2000);
}

And so the MPU doesn't sleep after GE=high and during the initialization phase (INITCOMP=0). Now the BQ35100 not only reports a SOH_MERIT but also an EOS_BAD_OCV. The BQ35100 technical reference manual describes the EOS_BAD_OCV as: "Indicates the measured voltage exceeds the initial OCV voltage". But this was also the most common reason for the SOH_MERIT. Also replacing the sleep() function calls within gauge_start() also results in the EOS_BAD_OCV error.

So sleeping after GE=high and during initialization seems to be good to prevent an EOS_BAD_OCV error.

But the BQ35100 technical reference manual describes the SOH_MERIT as: "Indicates the quality of the SOH calculation was limited". So what could be happening here, and what is the less common cause of the SOH_MERIT error?

Regards,

Rene

Hello Rene,

It may be due to the load applied during the measurement, usually there's a learning pulse applied for the gauge to update the resistance values. The sequence looks correct to me, the only variable I see from other applications that don't see this error is the load profile.

Sincerely,

Wyatt Keller 

Hello Wyatt,

The applied load is a fairly straight forward load created by a LoRaWAN transmit and receive sequence.

Do you have any detailed documentation regarding this learning pulse? When the MPU (re)boots it presumes a new battery is applied and so starts with a NEW_BATTERY command. During my current tests I don't use a full battery every time, and so I presume the BQ35100 will start at SOH 100% and walks towards the actual SOH of the battery using the R and Z measurements. This is however never reached and it always end at 0%, but the battery is not empty. The BQ35100 technical reference manual has some limited description in '5.3.1 Initial EOS Learning'. Is this what you mean with the learning pulse?

Should the NEW_BATTERY command be send to the BQ35100 prior to the first Gauge Start/Stop measurement sequence within the same GE=high window?

You see a difference in the load profile of my application compared to other applications which don't see this error. What is the difference? Do you have an example image of such an error free load profile?

Regards,

Rene

Hello Rene,

The gauging algorithm will not work correctly if an older battery is used because the initial pulses after the new battery command is sent are used to find the offset from the chem ID resistance values. It would need to be a new battery for the algorithm to work correctly.

This is the method we have used in some of our testing:

Are you looking for SOH data or only EOS warning in EOS mode? If you are only looking for the EOS alert this warning should not influence the final result.

The discharge would be continuous and ideally a single pulse.

Sincerely,

Wyatt Keller

Hello Wyatt,

We are looking for both SOH data and also the EOS state. In our IoT application the SOH data is also send to the server to be able to monitor the state of health, so the SOH value can be used for battery replacement planning. In some applications the access to the IoT device and its battery is restricted, like when the IoT device is located on a railway marshalling yard or in an ATEX area. Replacement of the battery has to be planned to limit the huge cost for the safety precautions. So the SOH data is more important than the EOS alert/state. The moment at which the BQ35100 reports the EOS alert should be avoided using planning, and is only used as last resort.

In the ideal world a battery is always replaced by a full one. But in the real world this does not always happen, which is caused by a number of reasons. The actual SOH of the battery can't be checked prior to the installment of the 'new' one. So also in the case of a non-ideal replacement of a non-full battery the SOH data should show a valid value, although it doesn't have to be very accurate.

After the NEW_BATTERY command the BQ35100 uses the 'State of Health Max Delta' of 2% to lower the SOH value in steps. I assumed this was to slowly use the 'Scaled R' to map on the 'Ra table' and interpolate to a SOH value. But the BQ35100 reports the SOH_MERIT and never reaches a valid SOH value, although the 'Scaled R' value remains somewhere between Ra0 (100%) and Ra14 (0%).

I have ordered a few new batteries to check the SOH_MERIT error doesn't occur with a full battery, but this could take some time because of the hollidays. And hopefully the SOH value doesn't reach 0% after 50 cycles.

Are there ways to improve the SOH calculations when a non-full battery is used during battery replacement? The source code of the TIDA-01236 contains a demo trick to use non-new batteries by changing 'State of Health Max Delta' to 100% prior to the NEW_BATTERY and back to the old value (2%) after the NEW_BATTERY command. Is something like this also available for the EOS mode for Li-SOCL2 batteries?

Regards,

Rene

Hello Rene,

Yes make sure to use a new battery when you are performing a test.

Sincerely,

Wyatt Keller

Hello Wyatt,

The new batteries have arrived, and I will soon test them to see this solves the issue.

Regards,

Rene

Hello Wyatt,

I have connected a new EVE ER34615 battery and started the tests with a cycle of 30 minutes. The BQ35100 still reports SOH_MERIT as described before, and the SOH value steps down with 2% steps.

How can I debug the cause of the SOH_MERIT error and how can I find what I doing wrong?

Regards,

Rene

Hello Rene,

Let me take a look tomorrow with an update, backed up from new years.

Sincerely,

Wyatt Keller

Hello Wyatt,

I'm very curious regarding the update. Hope to hear from you soon.

Regards,

Rene

Hello Rene,

This battery may have a very flat resistance and OCV, making it hard for the gauge to calculate SOH reliably. This is mentioned in many other posts on the forum, EOS mode uses resistance correlation for SOH, and is not ideal for calculating SOH while in EOS mode and with primary batteries that have extremely flat voltages (like the batteries recommended for EOS mode)

Sincerely,

Wyatt Keller

Hello Wyatt,

I have checked the Ra tables of every potential LiSoCl2 battery which we could use and buy, and the Chem Id 651 is indeed very flat.

In a different post on the forum Chem Id 645 was suggested to be used with the EVE ER34615, and so I used Chem Id 645, which is far from flat.

After a NEW_BATTERY the SOH starts at 100% and steps down with steps of 2% during the phase in which the 'Scaled R' has the same value as 'Measured Z'. When 'Scaled R' gets the right value after this initialization phase the SOH has (in the mean time) dropped to 94%, and stays at 94% for every subsequent measurements. I think the actual SOH is higher than 94%, but it seems it can only step down and never step up.

But the SOH_MERIT error is still present. Do you know of any other tests to figure out the source of the SOH_MERIT?

Kind regards,

Rene

Btw. TI should debug the chemistry database. I found several oddities:

• The 'description' text of Chem id 612 states it is a 'Lithium Thionyl Chloride', but it is actually a Lithium Manganese Dioxide (Li/MnO2).
• The 'Model' text of Chem id 626 contains (42500mA), which is incorrect
• The Ra table of Chem Id 650 only contains the value 32000 for Ra 0 to Ra 14.

Hello Wyatt,

I have searched for the explanations for the cause of SOH_MERIT, and found only a few.

Voltage difference

The forum post https://e2e.ti.com/support/power-management/f/196/p/833628/3085094#3085094 contains:

First, lets start with the SOH_MERIT that is being triggered. This bit sets when the EOS algorithm fails due to a negative value in the math. The most common reason for this is when GE goes high the gauge takes what is assumed to be an OCV voltage measurement. From there the time it takes to issue the "Gauge start" command if the battery is not relaxed and a higher voltage is detected the algortihm falls down because you cant have a higher voltage than OCV without chg current. I suspect there is not a sufficient rest period between the pulses and the voltage is still relaxing back up in the positive direction.

So the most common reason has to do with the difference between the voltage at GE=high compared to the voltage at "Gauge start" or because of a rise of the voltage between GE=high and "Gauge start".

Other less common reasons are not mentioned.

If you look at the discharge profile of a measurement and transmit cycle during one of my tests, how should the profile look to prevent this issue?

The uC wakes up to make GE=high and goes to sleep right after this. This causes a small discharge and a drop of the voltage of about 50mV. The voltage rises during the sleep state. About 2 second later the uC wakes up again, and so discharges the battery causing a voltage drop of again 50mV, and the "Gauge Start" is given. So between GE=High and "Gauge start" the voltage has risen, but not because the battery is not relaxed, but because of the wake-up and sleep of the uC. The voltage at GE=high is however about the same as at "Gauge Start". Does this voltage drop of 50mV influences the measurement causing the SOH_MERIT, or is the 50mV too small for this?

Could the SOH_MERIT also be caused by the higher voltage level after "Gause start" and before transmit?

Or has the profile up to "Gauge Stop" also influence on the SOH_MERIT?

Is the BQ35100 in EOS mode capable of performing it's measurements when the uC is sleeping and waking up constantly causing the fluctuations on the measured voltage, or is the voltage drop too small too have influence, since it is not a discharge of 100mV minimum? Or does it only use the GE=high and "Gauge Start" as sampling moments?

EOS Impedance calculation

The forum post https://e2e.ti.com/support/power-management/f/196/p/636077/2424689#2424689 contains:

SOH_MERRIT is better named EOS_MERRIT. It comes on when there is a problem in the EOS Impedance calculation. What this means is that during the measurement a voltage was seen that was higher than the initial OCV measurement gethered at the time GE was put high. 

If the cell is not rested the voltage will increase between GE high and Gauge Start. This will cause an error. For future tests please ensure a more rested battery and less time between GE high and Gauge Start CMD. Also be sure the send the gauge stop immediately after the load is removed.

So again this the voltage difference between at GE=high and "Gauge Start", but the time between GE=high and "Gauge Start" is also mentioned. In my situation this is about 2 seconds, which is the time it takes until INITCOMP is set.

But also "Gauge Stop" is mention. How does the moment of "Gauge Stop" relate to SOH_MERIT, and could this be the case in my tests?

On period

The forum post https://e2e.ti.com/support/power-management/f/196/p/799572/2960646#2960646 contains:

Also can you check if the SOH_MERIT, SOH_ERR, or EOS_BAD_OCV are set. These bit will go high if there was an issues in the calculation. The most common error is the battery is not relaxed when a learning pulse if performed. When you do GE high a voltage is assumed to be OCV and well rested. If at any point the gauge measures a higher voltage during that on period, the algorithm will not understand how to handle it since no voltage should be above OCV.

So here it says the SOH_MERIT is set if at any point during the on period (so between GE=high and GE=low) a higher voltage than OCV is measured. In my case the SOH_MERIT is only reported after the "Gauge Stop".

So the whole period between GE=high and "Gauge Stop" seems to be important.

What could be the moment and cause for the SOH_MERIT be, in my situation?

Can the BQ35100 handle the wake-up and sleep discharge fluctuations? And if not, how can the BQ35100 be configured to be able to, or should the discharge profile be changed?

Regards,

Rene

Hello Rene,

I can't give you a good answer right now, I need to look through our firmware to see what sets the bit. We use complex matrix operations for determining EOS and SOH information.

The posts by Eric Vos will be the most descriptive as he has the most experience with this gauge.

Sincerely,

Wyatt Keller

Hello Wyatt,

I also found the following thread with remarks by Erik Vos: https://e2e.ti.com/support/power-management/f/196/p/620859/2292847

The following is mentioned:

• SOH_MERIT will indicate is SOH was limited in the amount it was wanting to update. since is can only change by SOH Max Delta.

For my current test I'm using chem id 645 which is not as flat as 651. With 645 the problem of the decreasing SOH in steps of 2% down to 0% does not occur. The SOH started at 100% and stepped down with steps of 2% until the initial setup was finished (ScaledR adjusted to a value different from MeasuredZ). At that moment I changed the SOH to 100% as mention in a different thread. From that moment the SOH stayed at 100% for some time, and changed to 99%, at which it remains now for several days.

So this remark regarding the relation with SOH Max Delta doesn't apply.

• I just found out there is a typo in the configuration file. SOH_MERIT Should be named EOS_MERIT and this bit is actually set when the result from the algorithm for Impedance calculation fails a test on solution validity.

How does it fail a test on the solution validity?

• SOH/EOS_MERIT is useful if you attempted to do a MeasuredZ calculation, but it failed for some reason. it gives you an indication some debug might be needed

What are the possible reasons and how should these be debugged?

So the extra detailed information based on the firmware, which you mentioned, would be nice to debug the cause of this problem.

Regards,

Rene

Hello Rene,

SOH_MERIT should be labelled as EOS_MERIT because it looks at correlations with the resistance values calculated.

As I mentioned I will need to look through our information to give you a better answer, this will take some time. Does the error occur with a constant current discharge pulse and only that instead of your load? Many customers use this gauge without running into this issue.

Sincerely,

Wyatt Keller

Hello Wyatt,

I have created a test setup using several evaluation boards to test all ins and outs of the final design before we have our own PCB produced. So it mimics the final application and the load profile of this final design. Currently this setup consists of the BQ35100EVM-795 plus a LoRaWAN module and some extra sensor boards, all powered by the battery and monitored by the BQ35100. The uC controls the LoRaWAN RF, the BQ35100 and the sensors, and places all in sleep or have them wake up.

So the discharge pulse like in https://e2e.ti.com/support/power-management/f/196/p/963480/3563310#3563310 show the actual load of the application. And the main discharge pulse has a fairly constant current profile caused by the transmission of the data. But there are also other processes active, like the two receive cycles, and the wake-up/sleep cycles of the uC and the sensors.

This setup should be running without issues to know the final application will run without this issue. Using an ideal constant current discharge pulse is not a valid evaluation.

I will wait for your information. Please keep this thread open.

Regards,

Rene

Hello Wyatt,

Do you have any status updates regarding my question?

Regards,

Rene