[参考译文] CC1352R：如何在发现同步事件时冻结 RSSI？

我相信您使用的是错误的覆盖。 您所使用的覆盖内容似乎适用于 CC13x0、而对于 CC1352R、您应写入0x6098：

HW_REG_OVERRIDE (0x6098、0x35F1)

您是否有一些数字显示您在使用和不使用此覆盖时测量的 RSSI？  

非常感谢！

我没有注意到使用 HW_REG_OVERRIDE (0x6098、0x35F1)和不使用之间的区别。

我如何复制您在我身边看到的内容？ 我假设我应该能够使用 SmartRF Studio 进行快速测试。  

我无法使用  SmartRF Studio 再现它。  因此、我将根据 rfPacketTx 和 rfPacketRx 对进行几个测试项目。

意味着您在使用 Studio 时看不到问题？ (意味着精确的 RSSI 值)

是的、我在使用 Studio 时没有发现任何问题。 更重要的是、我认为问题在 Tx 侧的某个位置。 我已经准备了几个简单的测试项目。 只有当我的主项目通过无线方式发送数据包时、才会出现问题。 当测试项目发送数据包时、RSSI 值相当准确。 遗憾的是、我无法公开共享我的项目、因此我必须准备一个精简版本。

不跟随你。 我假设您使用了相同的 TX 源、并通过 Studio 接收并使用您的代码？ 如果 Studio 在这种情况下提供预期结果、则 TX 侧应该正常？  

我认为这些问题和其他问题最好由我准备的测试项目来回答。 我没有附加 tirtos_builds_cc13x2_cc26x2_release_ccs 项目、因为它通常出现在 SDK 5.20参考项目中。 当我在终端921600/8/1连接到 Rx 侧的情况下运行项目时、我可以看到 RSSI 值的差异高达20dBm。

e2e.ti.com/.../rf500kbps_5F00_32_5F00_24_5F00_8_5F00_0_5F00_Rx.zip

e2e.ti.com/.../rf500kbps_5F00_32_5F00_24_5F00_8_5F00_0_5F00_Tx.zip

Studio 提供了不准确的 RSSI 值、因此问题可能与 Tx 有关。

当我完成了其他几项任务时、我需要仔细查看代码。  

您如何知道 Studio 提供的值不准确？  

我尝试编译您发布的项目之一。 我从一个干净的工作区开始、然后从 simplelink_cc13x2_26x2_SDK_5_20_00_52导入了"empty"项目、以获取引用的 TI RTOS 项目。 然后、我收到以下错误消息：

****配置的纯净构建 rf500kbps_32_24_8_0_Tx 项目的调试****

"C：\\ti\\ccs1040\\ccs\\utils\bin\\gmake"-k -j 4 clean -o

DEL /F "syscfg\error.h" rf500kbps_32_24_8_0_Tx.hex" rf500kbps_32_24_8_0_Tx.out"
del /F "main_tirtos.obj""rfPacketTx.obj"
del /F "main_tirtos.d"rfPacketTx.d"
rmdir /S/Q "syscfg\"
找不到 C：\apps\codes\rf500kbps_32_24_8_0_Tx\Debug\syscfg\error.h
已完成清理

****构建完成****
发生构建文件生成错误..
编译配置"com.ti.ccstudio。buildDefinitions.tms470.Debug.1107030127"不存在于引用的工程"tirtos_builds_cc13x2_cc26x2_release_ccs"中。 请参阅"属性">"编译">"依赖项"页面以选择现有编译配置。
构建停止..

--

项目缺少什么？  

我的项目需要构建索引为1107030127的 tirtos_builds_cc13x2_cc26x2_release_ccs。
但是、当您从 simplelink_cc13x2_26x2_SDK_5_20_00_52导入"empty"项目时、您具有不同的构建索引。 这是正常情况。

您需要在 Properties>Build> Dependencies for rf500kbps_32_24_8_0_Rx 和 rf500kbps_32_24_8_0_Tx 项目中查看相关内容、并删除其中列出的项目、然后再次添加 tirtos_builds_cc13x2_cc26x2_release_ccs。 通过这种简单的方法、您可以更改  引用工程的编译索引。

我已修改测试项目。 现在、您可以将它们配置为0位、1位和4位 CRC。 或者、您可以将它们配置为1位或2字节数据包有效载荷。

通过使用不同的设置、您可以看到、如果 CRC 为0位或1位、则在1字节有效载荷的情况下、Rx 侧无法正确估算 RSSI。 这些测试显示问题仍然在 Rx 侧、这是一个严重的问题、因为无线电内核在尝试估算数据包尾部的 RSSI 时出错。
e2e.ti.com/.../rf500kbps_5F00_32_5F00_24_5F00_x_5F00_x_5F00_Tx.zip
e2e.ti.com/.../rf500kbps_5F00_32_5F00_24_5F00_x_5F00_x_5F00_Rx.zip

我将了解一下、我今天早些时候成功地编译了您以前的项目。

您使用哪种方法来了解测试设置中的正确 RSSI？  

我不使用任何其他工具来测量 RSSI、也不能分辨 CC1352报告的正确值。 我认为这些 RSSI 值不正确、因为在短时间内紧密发送的100个数据包不能具有10dBm 或更高的 RSSI 扩展。 你认为不是这样吗？

我查看了您的设置。 看起来您刚刚使用了50kbps 设置并更改了数据速率、偏差和 RX BW。  

当您尽可能更改其中一个预定义 PHY (设置)时、您必须将其视为一个新的 PHY、并执行多项测量以验证该 PHY 是否提供了所需的性能。 本应用手册 ：https://www.ti.com/lit/pdf/swra682 介绍了您应查看的参数和测量值。  

在这种情况下、从已经可用的500kbps phy 开始。 检查您是否获得了所需的行为、如果确实如此、请更改偏差。 当仅更改偏差时、不需要重新验证 phy。

由于您使用的是高调制指数和非默认同步字、这是否是传统的 phy？  

谢谢你。 实际上、我设计了 PHY 500kbps、并将 Smart RF Studio 作为参考。 Studio 中有许多不同的 PHY、这是一个很好的来源。 此外、我还使用您发布的文档。 对基本原则有很好的解释。 但是，我认为这不足以完成我的特定工作。 在我的项目中、我有几个比特率介于50kbps 到500kbps 之间的动态 PHY。 这不是一个传统的 PHY 项目，而是一个前瞻性项目：)我对查找新 PHY 设置的详细信息非常感兴趣，但这次我想谈谈我关于同步事件 RSSI 冻结的非常简单的问题。

请尽情使用我的新测试项目。 我准备了最基本的 PHY - 50kbps、25kHz 偏差、2GFSK、100kHz RX 带宽。 除了链路层外、我没有更改任何内容。 我刚刚将数据包长度配置从变量更改为固定值和 CRC。 即使这个 PHY 配置也不能按预期工作！ 与500kbps PHY 相比、操作上的唯一区别是、为了使50kbps PHY 正常工作、一个 CRC 位就足够了、并且对于500kbps PHY、您至少需要4个。 除了我进行 PA 升降实验之外、我还可以得出结论、即无线电内核无法正确估算一个字节数据包的 RSSI、并且在 GFSK 数据包顺利消失的时间点进行估算。  此外、HW_REG_OVERRIDE (0x6098、0x35F1)不起作用。 我已经处理这个问题超过三个月了、但我没有找到更具说服力的版本。 您可以通过某种方式解决这个问题吗？

谢谢。

e2e.ti.com/.../rf50kbps_5F00_32_5F00_32_5F00_x_5F00_x_5F00_Rx.zip

e2e.ti.com/.../rf50kbps_5F00_32_5F00_32_5F00_x_5F00_x_5F00_Tx.zip

昨天我稍微看了一下您的代码、但为了便于调试、我使用 SmartRF Studio 进行了一些 RX/TX 测试。

观察结果：

-如果我使用固定数据包长度、关闭 CRC 并使用1字节数据包长度、我认为我看到 的情况与您相同、这意味着数据包的 RSSI 的变化为8 - 10dB。

-如果 包含或不包含 HW_REG_OVERRIDE (0x6098、0x35F1)、则 RX 侧似乎没有影响。  

-将 TX 侧设置为发送一个额外的字节(RX 侧仍然设置为接收1个字节)、从而使接收到的数据包的 RSSI 变化为1dB。  

-将 PA 斜坡关闭时间 HW_REG_OVERRIDE (0x6028、0x00XX)减少到一个低值(I 使用0x4进行了测试)会使接收到的数据包的 RSSI 变化为1dB。 在本例中、TX 侧使用了1字节有效载荷。  

-如果 TX 侧和 RX 侧都设置为2字节、无 CRC、则 RSSI 在额定 PA 斜坡上有1dB 变化。  

-同步字长度似乎没有影响(使用16、24和32位进行了测试)

似乎这可能与仅发送1个字节时 TX 信号的外观有关。  

--

您只发送1个字节而不发送 CRC 的原因是什么？  

感谢您尝试我的项目、现在您已经看到了问题、我可以更轻松地解释我的困难。

在我的项目中、我需要非常高效和准确地了解节点之间的飞行时间(ToF)。 为此、我将使用与 SDK 中提供的几个 rfEchoTx 和 rfEchoRx 项目类似的项目。 通过在一个突发中执行几个 Ping 请求、然后对其求平均值、我得到往返时间、最终得到 ToF。 我的系统在不同环境下的行为不同、因此我使用 CRC 数据包和非 CRC 数据包。 为了实现高效处理、我只需要一个数据字节和一个 CRC 位。 我需要 RSSI 来验证测量并正确确定节点的接近度。

您的答案是否意味着我对 RSSI 报告错误的担忧得到了确认、我们无法通过延长数据包来解决它？ 我在 CC1352的行为中发现了许多其他奇怪的东西、这些东西使我无法进行正确的 ToF 测量。 我会将我的问题与所提出的 RSSI 问题分开发布、但无线电内核中可能存在的错误可能与我的其他问题有关。

这看起来仍然是一个具有1位数据包的解决方案。 请注意、这将影响杂散发射。

我想使用具有1字节与2字节默认设置的频谱分析仪查看信号、看看我是否了解正在发生的情况。 我怀疑在仅具有1字节有效载荷的情况下、没有 CRC、PA (采用默认设置)在发送此字节时开始下降。 但不确定为什么2个字节的情况不是这样、以及冻结 RSSI 为什么不起作用。  

这是我计划下一次在办公室(1月的第一周)执行的一项任务   

非常感谢！
我期待着结果。
新年快乐，圣诞快乐

昨天我看了 TX 端、我看不到发送1个字节或2个字节的行为有什么不同。  

最新的理论是、RX 链中的延迟会导致这种情况。 在找到 SYNC 时、接收器也将接收到以下字节、这些字节的能量将贡献到总 RSSI、即使找到了同步冻结也是如此。 当能量在1个字节后开始下降时、 由于延迟、这将影响 RSSI。 它是固定的延迟。