[参考译文] BQ35100：对 EOS 进行了几次说明

您好、Onyx、

感谢您的回答。 为了详细说明、

1) 1)我们正在探讨在无线传感器发送器模块中使用此器件。 这意味着应在每个活动尖峰(在本例中为传感器轮询和无线电 TX)情况下启用监测计、以准确跟踪电池寿命？ 理想情况下、我们将考虑至少一年的寿命、例如5分钟间隔传输。

2) 2)在进一步实验和实际循环 GE 后、我遇到 了本主题中描述的相同情况。 在每个监测计停止点的末尾、位4 (SOH_Merit)为 up。 它不显示何时触发监测计启动、可能是因为我现在实际上在循环 GE。  

我尝试了另一个线程中建议的解决方案(在 GE 之后立即开始触发监测计)、但如果我在没有至少睡眠(1)的情况下执行该操作、bq35100似乎反应太快。  

bq35100 pdf 的8.2.2.2.1.2第3步说明了命令监测计在高脉冲之前立即开始。 在 MCU 执行 i2c 传感器轮询并在仅在无线电 TX 之前将 GE 和监测计启动置为有效时、我是否最好关闭监测计？

5) 5)几个新问题：
a)我按照 slua904中的指南在 EOS 中设置监测计。 提到 EOS 检测脉冲计数 Thrshd、但我不确定是否应该调整该值。
b) SOH (0x2E)每周期下降2%... 这相当剧烈、在3次重置为0%(即150个周期给出或接受)后、我仍然能够运行、因此很明显、设置中的其他位置也存在问题... 电池化学成分和 mAh 正确。 我还应该检查什么？ 这显然也是另一个线程中的问题

您好、Onyx、

仅为了澄清当您每小时说一次时、您指的是每小时进行一次 EOS 测量(激励 GE、监测计启动等)。 由于电池必须为此而放松、这意味着我无法在电池需要的任何窗口(x 分钟)内运行我的其他流程、是吗？

也就是说、如果我在正常条件下每分钟进行一次温度传输、我必须为所有活动停止(x 分钟)的窗口进行预算、以便监测计可以在下一个活动周期进行测量？

如果是这种情况、例如、如果我让设备以5分钟的间隔传输、然后每天午夜休息(x 分钟)以读取 EOS 读数、它是否仍然准确测量？ 这意味着我大约每120次传输获取一个 EOS 读数。

或者、我们是否说 bq35100 EOS 模式仅在整个设备以>(x 分钟)的间隔传输时对我有效？

您好、Onyx、

感谢您迄今为止的耐心等待。 遗憾的是、我似乎在动摇这个 SOH_Merit 位时遇到了很大困难... 我已经尝试过您的建议、并在 这里提到了 Eric 的回答。 也没有工作。

我还尝试使用了全新的电池和不同制造商的新电池(在调整化学成分后)、结果基本上相同。 我能够实现的最佳效果是每2个周期出现一次 SOH_Merit。  

我是否能够提供其他信息/其他信息、以便更清楚地了解错误情况为何持续存在？

另一个侧向问题是、假设我忘记了 SOH %读数、如果此 SOH_Merit 错误仍然存在、监测计是否仍能够提供准确的 EOS 状态(用于 EOS 警报)？

编辑：在先前的帖子中、您提到了电池放松。 我将其解释为没有显著或脉冲负载的周期。 这是否是指负载关闭(即开路)的时间段、这也会阻止 MCU 在低功耗模式下运行？

您好、Onyx、

感谢您的说明。 已多次尝试建议的放松例行程序。  

这种方法效果更好、但需要10分钟以上的时间、甚至不是100%。 这似乎更适合器件大部分时间都在其他一些主电源上运行、偶尔会读取以跟踪备份电池的情况、这种备用电池很少使用。 或者该单元具有某种由单独机制管理的外部触发器(因为将 MCU 时钟作为计时器运行仍需要为其供电(待机期间偏差为0.002v、仍会产生 SOH_Merit)。

在我的情况下、电池将提供主电源、并且我无法完全关闭 MCU、因此我需要放弃 SOH 读数选项。  

这使我将 EOS 警报作为与电池故障前相关的唯一形式的警告。 如果 EOS 算法确实与 SOH 近似值分开工作、这是可以的。 需要澄清这一点，因为第5.3节第一段的结尾  似乎意味着它们在某种程度上是相关的。

那么、我还有两个关于 EOS 的问题：

1) 1)根据短趋势平均值> 120%长趋势平均值的默认 EOS 条件、在电池电压降至终端电压以下之前、我们可能会考虑哪种剩余寿命？ 它可能高度依赖于负载/使用情况、但我想了解为什么选择120%作为默认值、而不是其他任意数字。 这会导致问题2。。。

2) 2)假设使用场景是 MCU 在返回待机状态之前每3分钟切换一次待机以执行传感器轮询和 TX、每小时采样(大约每20个周期一次)应该足以用于 EOS 算法？

当然、我们需要注意的另一点是、采样间隔应小于(EOS 警报和端子电压之间的时间)、否则我们永远不会捕获 EOS 条件...