BQ27750: Question regarding remaining energy in cWh

Can you also provide your gg file? Thanks.

Hi Andy,

you will find the corresponding gg-File attached.

Thanks and best regards,

Marcel

BQ27750_gg-File_clean.gg.csv

Hi Marcel,

I have checked your log file and it doesn't seem like a bqStudio log.  I would need your help to provide a bqStudio file so that I can see much more detailed information.  Also, make sure you set the log interval to 3 or 4 seconds.

Andy

Hi Andy,

first of all sorry for my late reply - I was on vacation in the meanwhile.

You're right that it's not a log file which was written from bqStudio.

The log file was directly written by a script which operates with our device.

That's also the reason why I can't provide you a bqStudio log, because we need to discharge the battery pack in our device.

I cannot reproduce exactly the same load for the battery pack when logging with bqStudio.

But you can find all relevant registers from BQ27750 chip in the given log file.

Best regards,

Marcel

Hi Marcel,

The bq27750 has a lot of run-time information. Without sufficient data,  it is almost impossible for me to tell you the cause.  That's why I require a bqStudio log file.

Andy

Hi Andy,

I'm currently trying a test setup where the battery pack I2C terminals are connected to bqStudio which is logging every 3000ms.

The plus/minus terminals are connected to our device for discharging the battery pack.

The only problem is that our device now doesn't know that it will be powered with a battery pack because there is no I2C communication available.

The load should be the same but the battery pack will be discharged until cut-off voltage now.

Normally our device shutdown and stops discharging in a controlles manner with a certain reserve of remaining capacity.

 I'll let you know tomorrow if it worked well.

BR's

Marcel

Hi Andy,

attached you will find the bqStudio log file.

You can see in line 1881 that "TrueRemE" jumps from 596 cWh to 609 cWh during discharging process without any changes of the load.

That's not really nice because it leads to a suddenly increased displayed remaining runtime during discharging process.

BR's

Marcel

EDIT:

It seems that the remaining energy after about 100 minutes of device runtime (after the jump) is more reliable regarding the calculation of the remaining runtime.

bqStudio_log_FMO1_clean.log

Marcel,

TrueRemCap and TrueRemE will change anytime the gauge triggers a new simulation. Each simulation is run with a different set of inputs. Rate, Resistance, and temperature all all things that change. The amplitude of the change depends greatly on the new conditions. 

The jump you see if most likely a small resistance update and is expected behavior. 

If you want the value to not change please use the "Smoothed" value. This will remain constant but would makeup and delta over the remaining section of the discharge. 

Thanks,

Eric Vos

Hi Eric,

thanks for your reply.

We don't get what you mean with "smoothed" value ?

Where can we get it and what does it make ?

We're also wondering why the simulation seems to start everytime after about 100 minutes of device runtime.

There is no change of temperature or anything else.

Is there a way to let the gauge trigger a new simulation after some seconds of device runtime ?

Best regards,

Marcel

Marcel,

During discharge the gauge will hit points that we call grid points which will trigger a simulation. This is where resistance is calculated and gets updated.

If you have [SMOOTH] enabled in the settings DataMemory page then the gauge will report a filtered FCC and remcap on [Full Charge Capacity] and [Remaining Capacity]. In addition, [Flt Remcap] and [Flt FCC] are also reported. 

Thanks,

Eric Vos

Hi Eric,

thanks for your reply.

It seems that we've got [SMOOTH] enabled because you can find filtered values "Flt..." in the given bqStudio log file.

But we're still talking about RemainingEnergy value so I think you mean "FltRemE" in this case.

In the given bqStudio log file you can also see in lines 1881-1882 that both "TrueRemE" and "FltRemE" are jumping in the same behavior.

It looks like "smoothing" won't work for the RemainingEnergy value.

Best regards,

Marcel

Marcel,

I just confirmed with the team. For the bq27750 there is no energy based smoothing. Smoothing is only available via mAh mode. 

Thanks,

Eric Vos

Hi Eric,

thanks for your reply.

That leads me to the conclusion that "FltRemE" doesn't make sense at all because it's equal to "TrueRemE".

Am I right?

I have to say that it's really not easy to implement an exact runtime prediction for devices with constant power consumption with BQ27750 gauge chip because it seems to be optimizied for runtime prediction based on current (AverageCurrent) only.

AverageTimeToEmpty() is based on AverageCurrent instead of AveragePower.

For us it would be the smartest solution to use AverageTimeToEmpty() calculation based on AveragePower value.

Is it planned for the future to improve the AverageTimeToEmpty() function by also using the AveragePower value for calculation? 

Best regards,
Marcel