This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] MSP430FR6047:TI 算法无法分析波形、但会报告有效结果

Guru**** 2380860 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1248776/msp430fr6047-ti-algorithms-fail-to-analyze-waveforms-but-report-valid-results

器件型号:MSP430FR6047

自从使用该芯片以来、我们一直遇到一个问题、那就是 TI 算法无法分析波形。 就像 TI 拒绝分析这些问题一样。 您可以复位模块、重新初始化所有内容并采取许多不同的纠正措施、但在执行复位之前、TI 算法永远不会再次工作。 有时 TI 算法会以该状态启动。 我们也不认为波形重要。 我们已尝试将波形存储在代码中、并反复使用相同的波形。 有时 TI 会处理这些错误、有时会在完全相同的波形上失败。 请在下面找到简短的调试控制台日志。 它已添加注释、以显示该问题。

Reset reason: PMMSWBOR software BOR <------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
********************************
reconfigure_meter
Waiting for temperature
Waiting for temperature

# Debug code:
    USS_absTOF_status_object status;
    USS_message_code code = USS_getAbsTOFStatus(&gUssSWConfig, &status);
    printf("%d  UPS(%d  %f  %s  %0.3f)  DNS(%d  %f  %s  %0.3f)    %+0.2f   %d   %d\r\n", code,
           status.UPS.indexMaxAmplitude, _IQ16toF(status.UPS.iq16Index), _stateText(status.UPS.state), data->algResults.totalTOF_UPS * 1e6,
           status.DNS.indexMaxAmplitude, _IQ16toF(status.DNS.iq16Index), _stateText(status.DNS.state), data->algResults.totalTOF_DNS * 1e6,
           data->algResults.deltaTOF * 1e12,
           data->algResults.messageCode, // <-- from TI's USS_Algorithms_Results
           signalAnalysis_getLastMessageCode()); // <-- USS_runAlgorithms() return value
# Annotated output:
#     (MaxIndex 1stPeakIndex Mode AbsTOF)      (MaxIndex 1stPeakIndex Mode AbsTOF)     dTOF     AlgResults.MessageCode   USS_runAlgorithms()
0  UPS(0  0.000000  search  59.227)         DNS(0  0.000000  search  59.227)           -25.41   0                        122

# ADC Delay adjusted for current temperature and body size:
#    gUssSWConfig.measurementConfig->startADCsamplingCount = newValue;
#    USS_updateSAPHConfiguration(&gUssSWConfig);
#    USS_initAlgorithms(&gUssSWConfig);
ADC Delay SAPH Count:  345 (69.00 us)  -->  348 (69.60 us, computed 69.65 us, error -51.7 ns)
0  UPS(0  0.000000  search  59.227)  DNS(0  0.000000  search  59.227)    -25.41   0   122

# Where we found the first peaks using our own algorithm
ADC First Peaks:  32 u  32 d

# TI always returns index 0 or 1 when in error.
# The AbsTOF numbers are very close to the ADC delay.
# TI always returns: 	USS_message_code_valid_results = 122
# even though the numbers are wrong.

ti failed to find a first peak
0  UPS(0  1.000000  search  59.228)  DNS(0  1.000000  search  59.228)    -22.68   0   122
ti failed to find a first peak
0  UPS(0  1.000000  search  59.228)  DNS(0  1.000000  search  59.228)    -22.68   0   122
ti failed to find a first peak
0  UPS(0  1.000000  search  59.228)  DNS(0  1.000000  search  59.228)    -22.68   0   122
ti failed to find a first peak
0  UPS(0  1.000000  search  59.228)  DNS(0  1.000000  search  59.228)    -22.68   0   122

# Meter detects the TI error and eventually resets. 
# It can take only 1 reset or hours of resets before the TI algorithm works as seen below

Reset reason: RSTIFG RST/NMI
********************************
reconfigure_meter
Waiting for temperature
Waiting for temperature

0  UPS(0  0.000000  search  0.000)  DNS(0  0.000000  search  -0.000)    +0.00   11240   122
ADC Delay SAPH Count:  345 (69.00 us)  -->  348 (69.60 us, computed 69.65 us, error -49.7 ns)
0  UPS(0  0.000000  search  0.000)  DNS(0  0.000000  search  -0.000)    +0.00   11240   122
ADC First Peaks:  32 u  32 d
# Annotated:
# Water Temp                         v-- where math says the avg(U+D) AbsTOF should be      v-- where TI found it (our math isn't perfect)
 76.370 F | Center (+-5%)   60.47    63.65    66.83                                       | dTOF_Center  63.10 | AbsTof_Center  63.10
0  UPS(0  31.952118  track  63.096)  DNS(0  31.949249  track  63.096)    +14.27   0   122
0  UPS(0  31.946564  track  63.096)  DNS(0  31.952118  track  63.096)    +39.85   0   122
0  UPS(0  31.953186  track  63.096)  DNS(0  31.948669  track  63.096)    +13.19   0   122
0  UPS(0  31.950378  track  63.096)  DNS(0  31.952484  track  63.096)    +17.85   0   122

由于 TI 算法是闭源代码、我们无法对其进行调试。 我们只能抛出代码、然后查看 TI 结果是否发生变化、而不知道原因。

谢谢。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    测试过后、我想我已经发现了问题的一部分、但我无法访问与度量参考文档中的 TI 源代码以及 TI 算法描述进行组合的信息并且这些信息不完全准确、我无法确切地描述所发生的事情。

    回顾一下、我们在开发早期注意到、ADC 缓冲器在采样开始时通常会出现一个微小的峰值、其指数通常<= 5。 我们在评估板和我们自己的板上都看到了这种"牙"(我们称之为"牙")。 您还可以在论坛的此处屏幕截图中看到它、在一些 TI 文档中勉强看到(在索引0处)。 有时候、牙齿的振幅虽然很小、但具有很大的斜率。 TI 将该小峰值内插为有时接近阈值的非常高的峰值。 则 TI 使用该峰值。 为了解决这个问题、我们开始将缓冲器的前 N 个样本归零。 我们将 ADC 延迟设置为确保永远不要将信号定位得离起始点太近。 尝试的技术:

    *归零——并不总是起作用,因为第 n + 1个数据点可能会从先前的零点创建一个峰值

    *平坦--所有达到 N 的值都得到与 array[N]相同的振幅--大部分工作正常,但我们试图在 TI 代码中节省处理时间,所以...

    * ramp down -- array[0]= array[N]+ N ,然后降1直到 array[N]。 TI 算法认为平坦线上的每个点都是一个峰值: if (N-1 <= N <= N+1 ) doInterpolation()。 所以、我们聪明巧妙、能够降低信号速率、这样测试绝不可能成立。 这是我们当前的代码。 我怀疑 TI 可能有一个错误(我在代码中也有这个错误)、您可以在索引0而不是在索引1上正确地开始峰值搜索。 例如,如果 PreviousValue=0并且 array[0]由于硬件而具有30的 DC 偏移,则索引0处会出现来自振幅0->30的峰值。 正确的路径是设置 PreviousValue=array[0]并在索引1处开始搜索。 我不确定 TI 是否在这样做、但可能会解释索引0或1的固定方式。

    *平(太高)--我不小心做了这个。 我将所有点设置为等于初始的斜降点。 将其可视化为数组[N]上方的水平线。 TI"跟踪" N 处的第一个峰值。然后、在下一次测量时、跟踪 N-1。 然后是 N-2、依此类推、直至达到索引0。 我不知道它为什么会这样、但它可能会提示 TI 算法的工作原理。

    我删除了所有初始数据的操作,问题基本上消失了。 但是、现在我们仍然偶尔会遇到以下问题:TI 内插 ADC 工件并找到指数0-5附近的第一个峰值。

    • 您能否解释一下 TI 算法发生了什么?
    • 我们如何防止 TI 找到赝像峰?
    • 此外、还有一个相关的注意事项、为什么 TI 算法在缓冲器中后面出现信号时变得越来越差? 如果信号从索引30开始、则通常没有问题。 但是、一旦信号从指数50或更高开始、TI 算法就会以高得多的速率出现故障(错误的 dtof、dtof 移位错误、未找到信号)。 即使在验证它找到正确的第一个峰值后、也是如此。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我已经转向平坦的方法,它似乎是有效的。 不过、我还没有做过任何实际测试。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    您是否可以在您的测试以及 USS_userConfig.h 文件中向我发送 UPS 和 DNS 数据? 所以我可以看看发生了什么。  

    此外、在相关说明中、为什么 TI 算法在缓冲区中后端出现信号时变得越来越差? 如果信号从索引30开始、则通常没有问题。 但是、一旦信号从指数50或更高开始、TI 算法就会以高得多的速率出现故障(错误的 dtof、dtof 移位错误、未找到信号)。 即使在验证它找到正确的第一个峰值后也是如此。

    您能否提供所说的相关说明? 我们认为算法失败与信号在缓冲器中的起始位置无关。  

    此致、

    现金豪

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    很抱歉耽误你的时间。 我在工作中处理其他东西。 我会在时间允许的情况下回复。 谢谢你。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    slaa837a 第3页

    可能会在文档后面部分给出更多提示。 不过我很快就找到了。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    明白。 别着急,慢慢来。  

    slaa837a 第3页。 这只是提醒客户、ADC 开始时间应早于信号到达的时间。 我们不希望错过接收信号的起始部分。 因为它对于计算很重要。

    此致、

    现金豪