[参考译文] BQ28Z610-R1：当电池充满电时、SoC 会逐渐下降

e2e.ti.com/.../summary.bq.log.xlsx

迭戈,我能够用 Studio 采集数据时,电池处于混乱状态。 5次电池1 (具有坏的 SoC)和电池2 (正常)的附加文件。 请注意、这2个电池位于一个单元中、一起经过充电/放电阶段。

A -单元在充电器上运行、电池1 SoC 已降至91%、而电池2保持在99%。

B -放电至4%/6%。

C -充电至90%/99%。

D -放电至63%/70%。

E -充电至94%/99%。

我已经附上了所有 gg.csv 文件、但我看到序列中唯一的变化是周期计数。 电池1仅计数一、而2仅计数两个周期、因此这可能是一条线索。

汇总电子表格列出了 A-E 点处两个电池的 bq.log 数据 电池1正在正确跟踪剩余容量(与电池2接近)、但满电荷值全部过高、因此 SoC 读取为低电平。 由于这些电池开始时使用的是相同的闪存数据、因此我们使用的一些器件导致一些电量监测计重新计算满电量错误。

我希望我们能够防止满容量计算错误、或者能够对其进行重置。

e2e.ti.com/.../4341.data.zip

Jim、您好！

感谢您发送数据、我们将开始研究它。 ~这些电池的初始.gg 文件、电池2似乎正在计算相对于电池容量更大的 QMax 更新、而电池1的 QMax 大于6 μ V 150mA 监测计的 SOC 计算在很大程度上依赖于这些值、那么您能否确认两节电池之间是否有任何差异？ 我看到电池二的周期数更低。

此外、您能否确认每个步骤之间是否有任何放松时间？

此致、

Anthony

电池开始时完全相同-我们的电池组供应商提供的相同 golden gg.sv。 为了实现冗余安全性、有两节电池、但它们通常通过电子保险丝并联、因此它们在漏极期间保持在一起、但由于它们具有独立的充电器、因此充电可能有点不同步。
在测试中、系统负载始终存在、因此一旦关闭充电器、就立即加载电池。
我假设周期数不同、因为电池1不认为它已充满电、但我不理解这样做的标准。 在实验室测试中、他们看到了在其几个月的使用寿命内相同的充电/放电循环顺序。

Jim、您好！

周期计数依赖于累积放电百分比大于 Cycle Count 参数(在.gg 文件中、该参数为90%)。 因此、对于步骤 B、这将增加周期计数、但对于步骤 D、仅放电不足(无法)来增加周期计数。 在这些步骤的每一个步骤之间、是有一段放松时间、还是它们之间一个接一个地发生？

此致、

Anthony

"松弛"是指既不充电也不放电？ 如果是、我们无法保证弛豫期。 在充电器随机打开和关闭的情况下、装置可能会打开数周。 因此、电池将在没有弛豫的情况下从充电到放电。

Jim、您好！

明白、如果电量监测计在没有任何种类的静止期的情况下长时间处于工作状态、则由于缺少 QMax 更新、计算中可能会累积误差。 这也可能导致此时的 SOC 表示出现问题、不过有趣的是、系统中的一个电芯工作正常、而 SOC 压降仅在另一个电芯中出现。 当 SOC 下降时、您在上方确认电压不发生变化、并且此时充电器仍处于应用状态。 此时 FCC 计算是否有任何变化、还是只是此时的剩余容量下降？

此致、

Anthony

Anthony、您好！

我还没有在系统中连续读取和记录 FCC、因此我不知道它是逐渐增加还是逐步增加。 我知道、在充满电后并且充电器为系统供电(并且在脉冲负载期间补充电池、如我的 BQ25792博文所述)的情况下、SoC 会在一段时间内以1%的步长递减。 剩余容量保持相当恒定并与良好的电池接近、因此 SoC 压降的全部原因是 FCC 增加。

至少在某些时候、具有低 SoC 的电池具有稍高的电压并提供补充脉冲电流、因此它可以看到电流变化最大。 这种较小的放电/再充电循环是否会令 FCC 计算感到困惑？ 是否有方法可以限制 FCC 计算在某些条件下(例如电压高于 X 时)不会更新？

吉姆

Anthony、

我添加了 RemCap、FullChgCap、TrueRemE、TrueFullChgE 的日志记录、并运行了多个充电/放电周期、包括一些弛豫时间。 我为这些值看到的范围为：
电池1 (低 SoC)：FullChgCap = 484040 -4860 mA、TrueFullChgE = 3340-3560 cWh

电池2 (正常)：FullChgCap = 4580、-4580 mA TrueFullChgE = 3180-3340 cWh
因此、电池1的满量程容量和能量保持太高、容量完全没有变化。
我觉得 IT 算法太聪明了,被我们的使用条件所蒙蔽了。
遗憾的是、我尚未观察到增加日志记录后的全部容量增长、因此我不知道何时发生。
吉姆

Jim、您好！

很抱歉耽误时间、是否可以共享两个电池的日志文件、同时记录 RemCap 和 FCC 以及电量计设置的.gg 文件(如果不同、则适合每种情况)？

此致、

Anthony

gg 与已发布的 gg 相同。 随附的日志显示备用线路上的电池1+2。 RemCap、右侧标记为 mAh 的 FullChgCap、后跟 TrueRemE、TrueFullChgE 标记为 cWh。

按行号(第一列)划分的操作变化：

573充电

仅 BAT 1上的9367负载(BAT 2电子保险丝关闭)

35640负载关闭、电池1死机、放松

41101为两个电池充电

48661充电器关闭、负载关闭

两个电池上都有52301负载

仅 BAT 1上的56799负载(BAT 2电子保险丝关闭)

066667-100002日志间隙、但状态相同

100019充电器开启、空载

104968充电完成、空载(放松)

107808负载开启(由于我的充电器开机自检中的问题、BAT 1充电更多)

136013充电器关闭、在两个电池上加载

137175充电器开启、负载开启

e2e.ti.com/.../mAh-log.txt

Jim、您好！

感谢您的分享、我们将开始浏览数据、看看可能的原因。 只是为了确认、在这种情况下是如何选择 chemID 的？ 是否使用了 GPCCHEM 工具？

此致、

Anthony

Anthony、我们的电池组供应商予以解答...

Jim、您好！

我们已经研究了描述为故障包的电池1的数据、但电流和 SOC 测量可以在下面看到：

在电流为蓝色且 SOC 为橙色的情况下、SOC 似乎在不打算的情况下下降的唯一时间是弛豫的最后一部分、该部分从97%降至95%、大约降幅2%。 您能否确认此情况下出现问题的位置或是否遗漏了某些内容？

此致、

Anthony

Anthony、

我知道该日志未显示 FCC 的增长、但我希望它可以提供一些线索、以了解监测计如何看到我们的周期。 运行数周后、SoC 会发生大幅下降、充电器保持开启状态。 在某些情况下、当电池电量仍满时、SoC 将降至50%以下。 不幸的是、我们在我记录 FCC 之前发现了这些事件。 我认为此日志中的97到95下降只是始终开启的微控制器负载进行的正常放电、因此问题并不出现。

我将继续运行一个装置、充电器保持开启状态、有望实现 FCC 的一定增长。 是否还有我应该记录的任何其他项目(不可能就地运行 Studio 日志记录)。

吉姆

Jim、您好！

感谢您的澄清,如果可能的话,我还会记录 ITStatus()寄存器,下面显示的 QMax 值和温度读数(它们都可以在 DAStatus2 ()寄存器中找到),因为两个最大的组件可以引起 FCC 的变化是温度和 QMax。 ITStatus 寄存器将使我们能够检查是否正在进行正确的 QMax 计算、而 QMax 值使我们能够确认生成的值：

此致、

Anthony

Anthony、我要将这些项目添加到日志记录中。 使用此新日志记录可能需要一段时间才能捕获 FCC 增长、因此请保持 TT 打开、直到我为您提供更多数据。

谢谢！

Anthony、

请确认标记的项目是我应该记录的项目。 我的日志记录空间有限、所以我想确定一点。 我已经从标准命令0x06/07中记录温度。 是否与 DAStatus2中的 TS1值相同？

Jim、您好！

很抱歉混淆了。 是的、标准命令中的 Temperature()值应该在此处正确。 对于 QMax 值、请使用0x0075中的 QMax 值以及 GaugingStatus 中的以下位：

此致、

Anthony

Anthony、我已将电量监测状态添加到日志记录中。 我对 TRM 中 ITStatus2的定义感到困惑。 当我运行 Studio 并监控 i2c 时、LStatus 好像位于数据的第5个字节(地址0x44)、我想它是字节"cc"。 但 TRM 说它是字节'BB'。 这是 TRM 排印错误吗？

编辑：我检查了另一个电池、前6个字节0x74为0x03、0x0E、0x00、0x00、0x36、 0x04。 我不知道 Studio 在哪里获得 LStatus 位！

Jim、您好！

如果从您的最终目的看 bqStudio、这样做会产生什么结果？ 我已将 LStatus 设置为0x04、并且可以在下面找到读数和细分信息：

基于此、寄存器的 TRM 布局似乎是正确的。 只是为了确认、GaugingStatus ()中的内容是否存在任何问题？

此致、

Anthony

Anthony、

测量状态正常-我的读取操作获得的数据与 Studio 相同。 但 LStatus 的工作方式与您的状态不同。 Studio 显示了正确的寄存器值、但高级通信读取错误。 两次读取的 i2c 布线看起来相同！

Jim、您好！

我明白您的意思了、高级通信会返回0x0E (十六进制的14)、这是从 L Status 寄存器中看到的值、但寄存器的按位表示似乎并不反映这一点。

"Data Memory"(数据存储器)->"Gas Gauging"->"State"(电量监测->状态)中的 Update Status 寄存器显示的值是什么？

此致、

Anthony

Jim、您好！

感谢确认、如果器件复位、寄存器位表示中是否有任何变化？ 此外、是否在会将此推至0x0E 的字段中发生了 QMax 更新？

此致、

Anthony

我检查了10个电池-所有报告0E、Studio 中的重置不会改变该值。 在寄存器视图中所有显示相同的 ITEN 位。
我们尚未特意采取任何措施来更新 Qmax。 您能多说一点吗-它如何将寄存器推入0x0E？
我想您仍然感到困惑、因为0x0E 在寄存器视图中显示为仅 ITE=1、对吗？

Jim、您好！

如果在学习周期完成后发生另一个 QMax 更新、则电量监测计会将 LStatus 推至0x0E、如果这是从电量监测计获取黄金映像.srec 时 LStatus 的值。

是否可以共享测量仪表的.srec、以便我们在最后对其进行探讨？

此致、

Anthony

e2e.ti.com/.../4AMG_5F00_REV_5F00_02.srec.txt

出于某种原因、论坛不允许我插入.srec 文件、所以我刚刚添加了这个 txt、但这是来自 Studio 的。

Anthony、

您能否确认 LStatus 位的错误表示仅是 Studio 错误吗？ 看起来它们会将4位转换为十进制、然后在位显示中将其解释为十六进制值。 我打开和关闭监测、这会将14切换至10以及切换回、ITEN 位会变为红色并返回绿色、这只是一个很有趣的巧合：在解释不正确的情况下、1110/1010 = 14/10 = 10100/10000！
无论如何、我会将这4位添加到我的日志记录中、并尽快将其加入到我们的实验室测试中。

Jim、您好！

感谢您发送 .srec 文件、我们将使用该文件对我们的一个器件进行编程、以查看我们是否可以产生相同的结果。 日志记录有助于查看是否发生 QMax 更新将此值推送到0x0E、或者按位显示该值是否正确。

此致、

Anthony

Anthony、

我注意到设置了充满电、完全放电和终止阈值、因此我们在任一端都不会满足这些阈值 由于相关的 BQ25792问题、我降低了最大充电电压、因此始终未能达到100% SoC。 我们通常在放电期间在达到0%之前关断。 如果电量监测计从未看到这些状态变化、这是否会导致充满电时逐渐漂移？

Jim、您好！

如果电量监测计在放电后的 Relax 期间处于关断状态、则可能会导致计算出现问题、因为这些计算不会在 SHUTDOWN 模式下完成。 您能告诉我们现在发生关断的原因吗？

此致、

Anthony

安东尼,对不起,我的帖子是误导的。 当我说"关断"时、我是说我们的器件会在电池电量降至0%之前关断、因此电量监测计通常不会看到 SoC 的低电量。 电量监测计本身绝不会关闭。 那么、我的问题是、如果电量监测计由于这些阈值超出 SoC 的正常范围而从未检测到满电或完全放电、会发生什么情况？ 更具体地说、如果器件始终通电且电池保持在95% SoC、且从不满足充满电阈值、但受上述脉冲负载影响、它是否会误导 IT 算法。

Jim、您好！

应用将保持在什么典型的 SOC 范围内？ 如果没有足够的通过电荷、则 QMax 更新可能会出现问题、从长远来看、可能会累积误差并导致 SOC 计算出现问题。

此致、

Anthony

Anthony、在 SoC 缓慢下降的情况下、充电器为系统供电、电池保持满电量、通常高于90%。 但充满电的容量不断增长、SoC 不断下降、因此问题必须发生在 SoC 远低于90%的情况下。 我的软件是否有办法告诉电量监测计电池已满、以便它不会继续重新计算？

Jim、您好！

是否有记录显示 SOC 下降和 FCC 增加的日志文件？ 我认为这可以让我们更好地理解为什么它会发生。 关于软件、如果存在触发的仿真、FCC 将重新计算、该仿真通常发生在静止结束、放电结束、温度变化为5C 时。

此致、

Anthony

"我不知道你在说什么。" SoC 大幅下降需要数周时间、我必须登录我们的实验计划、因此可能需要一段时间。 这就是为什么我一直希望得到一些东西,在此期间尝试。

Jim、您好！

明白了、在发生此问题之前和之后、您是否有任何.gg 文件？ 这样、我们此时也可以查看电阻表。

此致、

Anthony

安东尼,这里是最初的.gg 在所有的包,当新. e2e.ti.com/.../5000.BAK.2022.03.22.csv
将其与我原始帖子中的 zip 文件进行比较：
33111.2.A.gg.csv -"良好"电池、其中满容量尚未增加。 电阻数据差异很大。
33111.1.A.gg.csv -满电量已增加的"坏"电池。 电阻数据几乎与原始数据匹配。

Jim、您好！

谢谢发送、E2E 目前不允许我查看以前发送的33111.2和33111.1文件、因此请重新发送、这会很好。

不过、这样我们就可以知道两个电池组之间的电阻存在一些差异、这在我们分析日志时会很有帮助。 您现在是否也可以运行 GPCRA0工具并分享结果？ 这也可以让您更深入地了解电阻差异。

https://www.ti.com/tool/GPCRA0 

此致、

Anthony

这是一个很好的例子。 e2e.ti.com/.../33111.2.A.gg.csve2e.ti.com/.../33111.1.A.gg.csv

GPC 指令听起来像是我们需要在安装电池的情况下对电流和电压进行精确的外部测量、但这很困难。 它能否正常工作、只是记录电量监测计 ADC 数据、还是不够准确？

Jim、您好！

感谢分享、此处测量仪表的电流和电压 ADC 值应该正常。

此致、

Anthony

ANTHONY, GPC Results is attached. 很多我不明白的错误。 config.txt 中的 ChemID 与 Studio 报告和供应商告诉我的内容相符。

e2e.ti.com/.../6204.amgis1_2D00_report.zipe2e.ti.com/.../6204.amgis2_2D00_report.zip

Jim、您好！

是否可以共享输入到 GPCCHEM 工具中的文件以便我们进行查看？

此致、

Anthony

当然可以。。。 e2e.ti.com/.../amgis1.zipe2e.ti.com/.../amgis2.zip

Jim、您好！

感谢您的发送。 由于 Ra Flags 未设置为 FF 或 FF55、该工具似乎遇到问题。 当将 chemID 编程到器件上时、这些标志应设置为此值、但如果进行了任何测试、这些标志可能会发生变化。 在输入的.gg 文件中、它们当前设置为0。 您能否再次尝试对 chemID 进行编程并拉取.gg 以确保将这些标志设置为正确的值？

此致、

Anthony

Anthony、我只使用 Advance Comm 对 ChemID 进行编程吗？

Jim、您好！

这必须通过 bqStudio 中的"Chemistry"选项卡来完成。 在列表中找到 chemID 后、按 Program Selected Chemistry：

此致、

Anthony

这些看起来更好...
e2e.ti.com/.../8787.amgis1_2D00_report.zip
e2e.ti.com/.../8787.amgis2_2D00_report.zip