[参考译文] HDC2010：温度湿度的突然变化

尊敬的 Toshi -  

请参阅此常见问题=>  

https://e2e.ti.com/support/sensors/f/1023/t/878721

尊敬的 Josh

这个问题不是 I2C 时序问题。
这些现象偶尔发生，虽然我是长期测量的，没有任何问题。
另外、在其他检查中也会出现类似的问题。 这些可能不是仅针对 IC 的问题。
我不知道我现在应该如何确认。我希望根据您的经验获得帮助。
请再次考虑。

此致、
Toshi

Toshi -从您的案例2 %RH 捕获中、这似乎是我在我指向您的常见问题解答中记录的固件问题。 根据我为该器件编写固件的经验、最好的方法是在该器件上放置一个逻辑分析仪、并自行查看您的时序、使器件返回0x00 0x00获取湿度数据、 因为没有足够的时间完成转换。  

对于情况1 temp 和 RH、捕获放大了相当多的幅度、并且该器件看起来在 temp 和%RH 的预期范围内-无法确定、因为我不知道代表多少个样本。 这里有一些移动、但同样、它看起来是合理的、您的腔室可能稍微移动了一些、HDC 发现了这一点。  

尊敬的 Josh

在 CAE-1中，我认为会议厅中的变化也必然成为触发因素。
但温度湿度的变化很大、如外壳1x、而不是 I image。
由于试验箱的指令水平大致恒定、我认为温度湿度变化不大。
我认为我不能只以敏感的态度来解释。
您为什么认为它以这种方式运行？

在 CASE2中、您似乎被视为转换问题、但我随后提出了一个新问题。
转换延迟的原因是什么？
我认为内部时钟的频率变化不大。
由于某个值不稳定、通过平均处理来执行直至保证精度、转换是否会延迟？
在这种情况下、转换不会在1500usec 内结束？
请告诉我、是否有方法可以猜测每次的转换时间。

此致、
Toshi

Toshi -  

该图的图例是什么？ (第28、29、51和54号代表什么)

您是否拥有用于测试和固件的电路板和测试设置的图像以及原理图和确切代码流程(流程图形式)？  

此外、如果您有逻辑分析仪捕获、这将会有所帮助(首选 Saleae、但不需要)

尊敬的 Josh

由于.xx 是任何样本编号、请不要介意。
样片 PWB 约为20mm□、并且有一个连接器。
我使用带有恒定温度箱(800升)(40℃80%RH)的阿鲁蒂诺进行了评估。
用例1x 是同时评估四个样本的结果。
下面是一个简单的流程图。 可以看到、它重复了简单的工作。
随着数据变得庞大、我不使用逻辑分析仪。 但是、我认为 I2C 没有问题、因为 Ack 的误差不会发生。 换句话说、寄存器的值似乎是正确的。

此外、经测量请求后、寄存器转换的值确认 DRDY 标志在 DRDY 标志变为1之前已读取。
因此、对于我来说、温度湿度值不会变为0x0000。

此致、
Toshi

Toshi -

在查看案例1图后、我得出结论、即这些器件会在您的室中拾取变化。 当温度下降时、%RH 上升、这是有道理的。 我们一直在自己的室中看到这一点、因为它正在尝试在高%RH 条件下保持稳定的环境。   

尊敬的 Josh

在案例1中、您认为湿度温度的关系是正确的。
不过，我在返回之前应记住这一点。
大约需要10分钟的时间才能恢复。
在同一个试验箱中、四个样品应具有类似的趋势。
然而、四个样本不一定具有相同的趋势。
您如何解释这一点？

此外、我完全不理解案例-2的来源。
在实际使用时、这更是一个问题。
为什么湿度在大约10分钟内显示为0%？
然后、其他样本给出正常水平。
这种现象在两周内发生了几次。
案例2的解决方案非常紧迫。

此致、
Toshi

Toshi -  

如果您有要共享的原理图或逻辑捕获、这可能会使事情加快一点。 对我来说、这看起来可能是固件错误、我知道您目前不相信这一点、但如果您可以使用逻辑分析仪捕获这种错误、那将会很好。 在这种难以重现的问题中、一种方法是将 GPIO 设置为在%RH 变为低电平时触发、触发逻辑分析仪开始捕获。 然后、您可以查看您的系统/固件使用的时序、并与我们分享以进行分析。    

尊敬的 Josh

我也在计划使用 GPIO 的方法。
但是，这一问题的爆发需要很多时间。
我觉得我只是等待的方法不是很好。
我想假设这种现象，我认为我应该加以证实。
我需要您的帮助来思考一个假设。

此致、
Toshi

Toshi -  

我返回到这篇文章 https://e2e.ti.com/support/sensors/f/1023/t/968639

在这里、您有一些时间安排-我自己做了一些与您类似的研究、但我有一些不同的结果、我发现这些结果与数据表匹配、并且我们放置在数据表中的值是由大量样本制成的、因此这很有意义、 和表示我们对器件的特性以及添加的一些统计责任保护频带。 我想如果您可以查看代码并进行双次检查、您已经删除了重置、并且正在等待至少1270uSec (我使用1300uSec、您的工作中有1000uSec、这很好。 但是、您遇到问题并记录您认为1000uSec 的等待时间是可以的、这意味着您应该返回并查看、然后进行调整、以便您等待正确的时间量。 这正是我在前面的常见问题解答中提到的情况。 等待足够长的时间来完成温度转换、但不能等待足够长的时间来完成%RH 转换、这将为您提供零。   

尊敬的 Josh

我将采纳您的建议、并对使用 GPIO 的分析仪进行评估提出质疑。
最后、让我再问一个问题。

当测量聚酰亚胺电介质的电容时、在外部的影响下、转换时间是否会很长？ (例如、超过1500usec)
或者、湿度的转换时间是否不会随外界影响而变化？
哪一个？

此致、
Toshi

Toshi -  

如数据表中所示、14位转换的典型总时间(温度+%RH)为1270uSec。  

在特征评定期间生成的直方图中、%RH 转换的典型时间(这需要最长的时间)是数据表中的时间、至少有一个器件达到~689uSec、 其中一个器件在14位温度转换时达到了637uSec、因此如果您想涵盖所有基极、您可以将等待时间增加到1325uSec (1.325mSec)、并且可能永远不会出现问题。 此外、您还可以利用寄存器0x04和 DRDY/INT IRQ 线路为系统添加双冗余和三冗余、并避免与等待时间相关的任何问题。 当数据就绪时、IRQ 将触发、0x04将位7同时设置为1 (生成0x80)、如果您同时检查这两者、然后读取、我真的不会再看到您遇到这个问题。  

尊敬的 Josh
感谢您的讨论。 但是、问题的关键就在于此。 我再次安排问题。

・在案例2中、结果是每隔一分钟在等待时间3000usec 的情况下测量一次温度湿度。
3000usec 是1325usec 的两倍以上。
我已确认 HDC2010的转换时间。(e2e.ti.com/.../968639)
・但是、这种情况下湿度变为0。
我正在分析突然变为0的原因。
・我得到了以下关于等待时间的事实。
如果在 SOFT_RESET 情况下等待时间较短、则数据为初始值。(表3)
即使在测量触发条件下等待时间很短、湿度也不是0%RH。(表4)
而且、即使 DRDY 未变为1、湿度也不是0%RH。(表4)

目前、我将采纳您的建议、并对使用 GPIO 的分析仪进行评估提出质疑。
此致、
Toshi

尊敬的 Josh

您建议的观察 DRDY 的方法是有效的。 但是、这种方法在实际使用中存在很大问题。
当 DRDY 未更改为1时、问题正在处理。
如果不能离开回路等于传感器的故障、则大规模生产风险太高。
我不能在不调查软复位原因或确认其影响的情况下采取措施。

现在、我使用 GPIO 在环境中开始测量。
我继续进行测量、但问题没有在三小时内发生。 我打算在明天之后进行评估。

我也确认了一些样本的时间依赖性。
我用三个样本测量了三次相关性、但趋势是相同的。
每个样本都有一些分散、但单个样本的分散很少。

此致、
Toshi

Toshi -  

您的所有时间都太快了。 请遵循我的指南、该指南与数据表和器件的处理方式相匹配。  

尊敬的 Josh

我说过很多次。 每次收到测量请求后、我都会在3毫秒进行测量。

添加3.3V --(900毫秒)->写入0x0E "0x80"--(8毫秒)--> 0x0F "0x01"-(3毫秒)->数据读取... 等待...(重复：0x0F "0x01"-->数据读取... 等待...)

我只向您展示了 HDC2010的功能。

尽管等待时间比能力多3ms、但为什么会发生案例-2？
我要问您这个问题。

此致、
Toshi

Toshi、您之前的图表显示为 usec (微秒)、但您继续参考3mSec (毫秒)-很抱歉、混淆了、但我只能根据您提供的信息给出建议、对我来说、这似乎是这样的。  

如果您有任何逻辑捕获和时序、正如我向您提供的示例、这将向我们展示实际发生的情况。  

尊敬的 Josh

有关规格条件的更多信息、请向我解释。
电气特性表具有湿度的移动范围。
但书中有如下解释。

(11)建议的湿度工作范围为20至80%相对湿度(非冷凝)(在0至60°C 温度范围内)
超过这些范围的长时间运行可能会导致传感器读数发生偏移、恢复时间较慢

Q1：传感器读数的变化是多少？
Q2：恢复时间过慢？
请通过展示具体内容来教我。

这一问题成为低湿度问题的趋势很明显。
有些机器配备了温度湿度传感器、但在建议的湿度范围之外、会出现湿度过低问题。 (例如、它为40℃85%RH、25℃10%等)
您是否注意到任何问题？

此外、我的评估现在还没有能够重现问题、就没有进展。

此致、
Toshi