BQ35100: Parameters to be updated in BQstudio for BQ35100 EOS detection

About #3: The bq35100 can be programmed either way. It's up to you. I recommend using bqStudio during development.

I assigned this to Adrian for further comments.

Thank you Dominik Hartl11. Looking forward to detailed response.

Hello Sudarshan,

1 & 2. Can you send the data over for me to analyze? Section 7 of this document explains what parameters need to be configured. https://www.ti.com/lit/an/sluaal7/sluaal7.pdf

4. When the gauge is powered up, the gauge_start and gauge_stop should be sent before a major discharge.

Regards,

Adrian

Hello Adrian,

Thank you very much for reconnecting with me.

Referred to the document and observed that two parameters i.e. "New batt R scale delay and EOS trend detection" need to be configured. I was wondering that once the learning cycle is completed by 100% and Final configuration is set, how will value of "New batt R scale delay" be compared in our real-time project. Because Passivation layer went off after 3 readings, each reading is a discharge by 2% in an hour but in real-time the product may run on battery for longer duration (say 10 hours). Are we required to send GAUGE_START/STOP commands there also ?

With regard,

Sudarshan Chaudhary

Hello Sudarshan,

I would say that New Batt R Scale Delay should be set to trigger the same time in real application as was seen in testing. So if after 3 reading in the testing the passivation layer went away. A similar calculation will need to be made for the application. After "X" amount of time in application you expect the passivation layer to go away you then need to figure out how many times the GAUGE_START/STOP will be sent. You are required to send these commands every once in a while for the application. They should be sent when a major discharge happens, and then be in rest for a long period. 

Regards,

Adrian

Hello Adrian,

1. In real application, our product is Battery backed running on a Main 12V DC Mains supply. Whenever this  Main 12V DC supply goes off then product switches to the Battery supply. Now, product may run on Battery as long as Mains power comes back. There is no detection mechanism for in-built STM32 microcontroller to differentiate that which power supply product is running on. Hence, issuing of GAUGE_START/STOP command will be impossible for microcontroller because product is powered up 24 * 7, either on Main supply or on Battery supply. Product may run on Battery supply  for any amount of time depending on unavailability of Main power. Therefore, a definite rest time for battery is also not possible because Main supply may be available for any amount of time and Battery supplies power automatically once Main supply goes off.

2. During testing, passivation layer went away after '3' reading of New Batt R Scale Delay. Each time battery was discharged by 2% in an hour. So, passivation layer went off after 6% of discharge of Battery. But, in real application, how can we keep a track of these readings because sometimes Battery will be supplying power for 5 minutes, sometimes 10 minutes or sometimes 2 hours (say).

With regard,

Sudarshan Chaudhary

Hello Adrian,

Looking forward to your response for my comment above. Kindly help.

Also, Please find attached PDF for complete learning cycle data during test. Each time battery is discharged by 2% in an hour and Voltage drop was nearly 250mV or more.  Although, Short trend average is more than 1.2 times of Long trend average after 45th pulse count i.e. 90% discharge of battery but EOS bit is not set even after 100% discharge during test.

Note: EOS mode was correctly set in "Operation config A" register and EOS bit was also set in "Alert config" register. You can check in attached images.

With regard,

Sudarshan Chaudhary

Card #81.pdf

Hello Adrian,

Awaiting your response.

Hello Dominik Hartl11,

Request you to reply or assign someone to my post as Adrian seems to be unavailable to answer.

With regard,

Sudarshan Chaudhary

I informed Adrian and asked him to update this thread. Please allow for some time as this is a holiday week in the USA.

Dear Dominik Hartl11,

Thank you very much for your kind help.

A much needed support is required on aforesaid problem as this has stuck our project. I request your team to understand the problem mentioned in above comments in detail. If any information is required, I will provide that.

Thank you

Sudarshan Chaudhary

Hello Sudarshan,

There must be some way to know when the power is switched to battery power. Maybe the host can monitor the battery voltage to know when a slight voltage drop occurs to know when the system is powered by the battery. For the passivation period, I would see what is the average time the system is on over the span of maybe 24 hours, and then find the average current during the time the system is on to get a rough estimate.

Can you send me your configuration file (gg file) so I can look into possibly why the EOS bit did not set?

Regards,

Adrian

Hello Adrian,

1. If the Host tries to detect some voltage drop, we might be late to send the GAUGE_START command or we might be left out with voltage drop of less than 150mV after sending GAUGE_START command. Likewise is the case of GAUGE_STOP command. So, we may get a deviation in readings.

2. Passivation period was over after 3 "EOS trend detection pulse counts" during testing i.e. 6% discharge of Battery (2% in each hour). But in actual application, in 1st go itself, the product may continuously run on Battery for 10 hours or 20 hours. So, GAUGE_START/STOP commands will not be issued and "EOS trend detection pulse count" value will not be changed.

3. Commenting on 'average time the System is ON on Battery'  is hard, as it depends on our different customers and different sites where the product is deployed. Product will run on Battery only when Mains power is not there and availability of Mains power can not be same at each location.

4. Configuration file (gg file) is attached herewith for your reference. Please find it.   3000.Config_File.gg.csv

With regard,

Sudarshan Chaudhary

Hello Sudarshan,

Is it possible to some how trigger a very short load spike on the battery when the battery is rest when the system is 12V DC power? This way the gauge can perform the correct calculations to update the EOS data.

Allow me some time to look into the gg file.

Regards,

Adrian

Hello Adrian,

It is not possible because when 12V DC is available then the load will be drawing power from 12V only and Battery will be idle.

Also, there is another interesting case. For example, my product is on for 'X' years on 12V DC always and in the meantime, Battery got exhausted due to leakage current or its shelf life. So, I never used Battery but due to shelf life restrictions, it got discharged. Now, BQ35100 will not be able to indicate us for timely replacement of Battery because GAUGE_START/STOP commands were never issued. So, after 'X' years whenever 12V DC becomes unavailable, my product will not find Battery backup as Battery was already exhausted.

With regard,

Sudarshan Chaudhary

Hello Sudarshan,

Customer's who use this device have implemented ways to trigger a short learning pulse on the battery to gather EOS data. This is how the device should be used.

Regards,

Adrian

Hello Adrian,

Did you go through the Configuration file (gg file) attached above to see why EOS bit is not set even after 100% battery discharge during testing ?

With regard,

Sudarshan Chaudhary

Hello Sudarshan,

The EOS bit did not set because the "EOS Detection Pulse Count Thrshd" was set to 120. As you see the "EOS Trend Detection Pulse Counts" is at 50 and this value needs to be greater than the threshold to set the EOS bit.

Regards,

Adrian

Hello Adrian,

Few more queries, Please elaborate each of the following points:

1. Can we set "EOS Detection Pulse Count Threshold" to a very low value like 1 or 2 ? This is because, in actual application, we may send GAUGE_START/STOP command any number of times before actually getting the EOS alert. During TESTING, EOS trend detection Pulse Counts appeared as 50 because we were doing fixed discharging i.e. 2% in an hour. So complete discharge took place in 50 hours so, 50 times GAUGE_START/STOP commands were issued. But in application, there can be any amount of discharge in 'x' amount of time and if we send GAUGE_START/STOP command each time after this major discharge and during short load spike then pulse count may reach anywhere.

2. Is it compulsorily required for Battery to be discharged by same %age each time before doing Short load spike testing in real application also ?

3. Rest period for Battery can't be definite each time. As during testing, we were providing a rest period of 5 hours between measurements but in Real time application, rest period for battery can vary. Sometimes, it might be just 10 minutes and sometimes 1 hour. But as you suggest that it should be minimum of 5 hours which is not possible everytime in application.

4. It seems that applications of this IC for EOS detection are extremely limited. User can deploy this IC only where he knows exactly how long system will run on Battery, then he can provide a rest period of 5 hours to Battery, then again he can do a short load spike to collect EOS data. Replicating exactly what we did during testing in real application also is not possible.

Looking forward to your response point-wise.

With regard,

Sudarshan Chaudhary

Hello Sudarshan,

1. Yes, EOS Detection Pulse Count Threshold can be set at a very low value.

2. No, this was just a recommendation for testing with the battery for development purposes. This way we could track the measured impedance of the battery over the life of discharge and also see the corresponding trend detection %. From here, using the results of the testing we can set an appropriate trend detection % based on the data from the test to have the EOS flag tripped at a specific time in the battery lifetime.

3. For testing purposes we wanted to the rest to be 5 hours. Ideally we want a long rest so that the battery voltage is relaxed before sending the gauge start command. Some testing can be done on your side to see how long the rest needs to be for your battery. It is very likely that the battery can be relaxed before 5 hours. The gauge will set the EOS_BAD_OCV bit if the battery was not relaxed for long enough.  

Regards,

Adrian