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.

[参考译文] CC1352P7:CC1352R7-4的915MHz 无线电唤醒

Guru**** 2410870 points
Other Parts Discussed in Thread: CC1310, CC1101, CC2500, CC1352P7, CC1312R

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1195369/cc1352p7-915mhz-wake-on-radio-for-cc1352r7-4

器件型号:CC1352P7
主题中讨论的其他部件:CC1310CC1101CC2500CC1312R

我们有数千个 CC1310传感器和数百个1310接收器在工作、并尝试制造1352接收器。 我们之前测试过 R4-1和 R4-2型号、没有问题。 但是、我们使用 CC1352R7-4构建了一个原型、代码的工作方式似乎存在很大差异。 来自1310传感器的数据流仅适用于 其中的一些传感器、其他传感器的某些位已损坏、但损坏是可重复的、发送数据接收不良的传感器始终使用相同的不良数据流接收。  所有传感器在使用基于 CC1310的接收器时都能正常工作。 我们发现、我一直在使用 CCS 项目、处理器设置为 CC1352R7-2而不是  CC1352R7-4。 当我使用.syscfg 生成工具更改它时、整个过程都很糟糕。 编译器将不再编译代码。 由于编译器不再识别对当前缺失的 uart.h 文件的引用、因此 UART 文件存在差异。 我必须将所有这些更改为 uart2.h 引用。 这些都是可以解决的、但现在的大问题是没有任何射频命令起作用。 使用 CC1352R7-2代码、我的所有命令都是基于 RF_cmdF 的。 在 CC1352R7-4上、我必须更改我选择的所有 PHY 方法的调用、当前是自定义868模式、该模式需要命令基于 RF_cmdFs_custom868_0。 我尝试了其他几种配置、每次都更改基本命令(即总的 pita)、但不起作用。 另一个问题是、我必须从"RF Command Symbols"部分下的复选框列表中手动选择要使用的每个 PHY 命令。

最接近的配置是将其设置为"50kbps、25kHz 偏差、2GFSK、100kHz RX 带宽、自定义 PHY 设置、868MHz 频带"、并更改基本命令 (射频命令符号)以匹配该命令。 这样、我收到了数据流、但它被移位以不包括长度字节(第一个字节)和数据的第一个字节。 看起来数据流是移动的字节2字节。 但是、由于监听操作、我仍然会获得 PROP_DONE_RXERR。

使用自定义868设置、 接收到的数据流中根本没有可识别的字节。 无线电唤醒功能适用于我尝试过的所有变体、这意味着我在发送带有传感器的数据包之前不会跳转监听回调函数、只是传入的数据不好、结果始终为 PROP_DONE_RXERR。

BTW:我设置了以下两个选项,以便可以在 Steam 中看到坏数据:

rf_cmdPropRxSniff_custom868_0.rxConf.bAutoFlushIgnored = 0;
rf_cmdPropRxSniff_custom868_0.rxConf.bAutoFlushCrcErr = 0;

请注意、我目前正在使用 custom868、这就是命令在这些变量的末尾添加这些变量的原因(CCS 使我这样做)。

所有这些都与 CC1352R7-2芯片上运行的 CC1352R7-2编译代码一起工作、该代码在 R7-4芯片上运行得更好。 更改 syscfg 中的 CPU 型号。 工具  

我尝试对基频(最高5kHz)、RW 带宽、偏差和波特率进行小幅更改、以测试48MHz 晶体中是否存在关闭的情况。 这些都不会产生任何影响。

借助 R7-2和 R7-1型号、TI 为无线电唤醒提供了一个工作示例代码、这正是我构建项目的基础。 但是、CC1352R7-4在915MHz 范围内没有无线电唤醒示例的工作版本、只有433MHz、这似乎与我之前为1352的两个变体使用的代码没有什么不同。 该代码也非常类似于 CC1310在无线电代码上唤醒、唯一的变化是使用.syscfg 生成工具而不是 SmartRF 文件。 由于我已经提到的代码更改必须使用 RF_cmdF 命令以外的其他命令、该代码将不适用于915MHz。

我还应该注意的是、CC1310使用4.20版本的编译器、而 CC1352要求我将编译器更改为 RTOS7 (TI Clang v2.1.0 LTS)、因为这是您的示例程序所使用的内容。 实际上、它无法在任何传感器上工作的主要问题是、我更改了 syscfg 工具中的"基于射频设计"选项。

我的所有工作传感器和接收器都使用以下射频配置。 所有这些值都使用 CC1352的.syscfg 生成工具插入到适当的位置。

//
//由 SmartRF Studio 版本2.23.0生成(构建号306)
//应用的模板与 CC13x0 SDK 版本2.10.xx.xx 或更高版本兼容。
//器件:CC1310 Rev. B (2.1)。
//
//


//
//参数摘要
// RX 地址0:0xAA
// RX 地址1:0xBB
// RX 地址模式:无地址检查
//频率:921.75MHz
//数据格式:串行模式禁用
//偏差:5.000kHz
//数据包长度配置:变量
//最大包长度:255
//数据包长度:30
//数据包数据:255
// RX 滤波器带宽:49kHz
//符号速率:5.00031 kBaud
//同步字长度:32位
// TX 功率:14dBm 要求在 ccfg.c 中定义 CCFG_FORCE_VDDR_HH = 1、请参阅 CC13xx/CC26xx 技术参考手册
// Whitening:CC1101/CC2500兼容

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

    这句话:"我们之前测试过 R4-1和 R4-2型号、没有问题。"

    应改为:"我们之前测试过 R7-1和 R7-2型号、没有问题。  "

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

    我尚未阅读所有详细信息、而是一个简短的问题:  

    [引用 userid="504868" URL"~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1195369/cc1352p7-915mhz-wake-on-radio-for-cc1352r7-4 ]CC1352R7-4[/quot]

    这话意思是什么

    LAUNCHXL-CC1352P-4*:433MHz 时最高为14dBm、2.4GHz 时最高为10dBm

    如果是这种情况、该 LP 的目标频率为433MHz、但您尝试在915MHz 上使用它?  

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

    您好!

    正如 GhostOf 提到的、您能澄清一下您的工作频率吗? LAUNCHXL-CC1352P-4的低于1GHz 输出网络针对433MHz 运行进行了优化、但根据您提供的设置、其运行频率看起来仍然设置为 921.75MHz。

    此致、

    Zack

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

    我在写它时输入的速度很快、因此我将输入的速度慢、并尝试更加清晰。

     

    一些历史记录:

    我们制造的基于 CC1310的传感器和接收器在无线电唤醒模式下使用915MHz 频带、因此我们在该系列处理器使用的所有工具中都有经验、并克服了所有问题。

    我们现在需要执行更复杂的任务、而 CC1310正耗尽 RAM、因此我们使用 CC1352P74T0RGZ 处理器构建了接收器的原型、因此目前我们不使用您的开发套件之一。 我想指出的是、我没有选择这个处理器。 我的印象是、我们将使用 LP-CC1352P7-1开发套件上用于开发固件的同一处理器。

     

    问题:

    在过去2个月中、在使用基于 CC1352的新接收器并使所有新外设正常工作后、我开始测试射频接收器、这就是我注意到问题的时候。 我们所有基于 CC1310的旧传感器工作正常、但其他传感器、尤其是较新的传感器工作正常。 在完全可重复的基础上、这些传感器在每个数据包中缺少相同的位、而 TI 检查的 CRC 不匹配、因此每次传输都在 PROP_DONE_RXERR 中结束、从而导致在无线电命令唤醒结束时出现 RF_cmdPropRxSniff.status 变量。 在我的故障排除过程中,我发现我们使用的 CPU 与我在“syscfg 工具”中所想的不同,因此我在“射频设计->基于射频设计”菜单选项下将 CPU 类型更改为 LP_CC1352P7-4。 之前、该值已设置为 LP_CC1352P7-1。 在我这样做之后、由于我在之前的帖子中所述的原因、代码将不会编译。 我认为最好的选择是首先使用 CC1352P74T0RGZ 处理器的无线电唤醒(WOR)设计示例、但我注意到您没有示例。

     

    当我没有此处理器的 WOR 工作示例时,如何使该新接收器板正常工作? 显然、我们必须以915MHz 或实际902-928MHz 运行、这与我们的 CC1310产品相同、以保持兼容性。

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

    在继续之前、最好仔细检查我是否理解了您的问题-请根据需要更正:

    • 您正在从 CC1310迁移到 CC1352P7。
    • 您使用了 LP-CC1352P7-1进行 FW 开发、这是按预期工作的。
    • 您现在正在自定义硬件上测试 RX 性能。
    • 每个数据包中都缺少位、CRC 校验不匹配-这是您需要调试的问题。

    根据您提供的信息、有几个要点:

    • LP-CC1352P7-1和 LP-CC1352P7-4使用相同的处理器(CC1352P74T0RGZ)、因此切换到使用 LP_CC1342P7-4示例不可能解决该问题。  LP-CC1352P7-1和 CC1352P7-4电路板之间的差异是输出匹配网络针对(分别为868/915MHz 和433MHz)进行了优化的频率:

    • 当您在915MHz 频带下运行时、您使用了正确的板进行固件开发(LP-CC1352P7-1)。 LP-CC1352P7-4没有915MHz 示例的原因是、您可以选择 LP-CC1352P7-1示例以915MHz 运行。

    • 您在第一篇帖子中提到了 CC1352R7、在您的回复中提到了 CC1352P7 -您正在使用哪些器件(R 器件 仅在低于1GHz 时具有+14dBm 输出)?  

    •  您最初是否使用 LP-CC1352P7-1开发板测试了射频性能(即、当所有内容都根据您原来的帖子正常工作时)?

    此致、

    Zack

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

    好的、我已经确定了问题所在、现在需要修复。

    由于您曾暗示我们的硬件必须存在问题、因此我将您的 WOR 计划放入 CC1352P7-1开发套件中、并将所有内容保留为仅限制问题中的变量。 然后、我转到我们的传感器、更改了我们程序中唯一与您不同的4个参数(见下文)、以匹配您的传感器、一切正常。 然后、我开始更改这4个参数中的每一个、并找到导致问题的是哪一个。

    我们的4个关键参数(与您的参数不同的参数):

    WOR_WAKEUPS_PER_second 10.

    符号速率= 5kbaud

    RX 滤波器带宽= 49KHz

    偏差= 5KHz

    唯一的问题是#4、调制偏差、它调节传输带宽。 我尝试了以下所有12.5KHz、10kHz、8kHz 和7kHz、所有这些都正常、每次传输都被接收到、并且没有丢失或损坏的位。 很显然、我还更改了这些值、以匹配进行传输的传感器。 6kHz 和5kHz 不起作用、虽然它们都导致触发监听中断、但数据流已损坏、在这两个数据流上、我以字节计数的形式获得16个字节、而不是31个字节。 我仔细检查了6kHz 和5Khz 上的工作、只是为了确定我没有犯错。

    问题在于、我们已经售出了数百个这些传感器、我们必须通过 FCC 测试、这并不便宜、我们对射频传输所做的任何更改、如带宽将要求我们重新认证、 我们不想这样做、因为任何更改也会使新接收器与现有传感器不兼容。 因此、我真正需要的解决方案是让 CC1352在偏差设置为5KHz 的情况下工作。

    我还检查了 CCS 是否在代码中放置了正确的变量、也就是说、当 选择5kHz 时、它将 RF_cmdPropRadioDivSetup.modulation.deviation 设置为0x14、这与 CC1310和 CC1352P7处理器的 SmartRF Studio 的 Code Export 功能相匹配。

    在此提醒一下、此代码在所有 CC1310传感器和接收器中都能完美地工作、我们已经使用永久寿命测试中的器件对其中的许多传感器和接收器进行了制造和测试、但从未出现过此问题。

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

    感谢您提供的其他信息、 我将 尝试在我们的终端上重新创建此问题(使用 LaunchPad 并更改您在示例中的默认设置)、并从该起点着手解决此问题。

    请留出几天时间进行此操作、我将在下周早些时候再次与您联系。

    此致、
    Zack

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

    没问题、请记住为发送器使用 CC1310、为接收器使用 CC1352。 使用 CC1310时我们没有问题、因此此时、我不知道它是否是发送器或接收器的问题。

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

    问题迎刃而解!

    使用示例 rfWakeOnRadioRx 和  rfWakeOnRadioTx 代码的 CC1352开发套件将 XOSC 电容器阵列增量设置为错误值、这会使射频无线电的中心频率关闭约8KHz 至高电平。 很抱歉、我不能再准确了、因为我的频谱分析仪在915MHz 时的分辨率不够、无法获得准确的读数。 但是、我可以将 CC1310套件的输出与 CC1352套件的输出相匹配、并查看它们的重叠位置。

    示例代码中的值为0xC1、应为0xE3。 设置为该值后、开发套件现在将从基于 CC1310的传感器接收数据包。 如果使用大于7kHz 的调制偏差、则不会看到问题。 您的示例使用25kHz、因此您不会看到它、因为 TX 和 RX 具有足够的重叠。

    因此、请查看此信息、因为您可能需要更改 CC1352R-1示例代码。 我没有您的所有电路板、但我知道您的 CC1312R 示例代码也设置为0xC1、因为我将其用于我们的新 CC1312R 接收器、而这正是我确定问题所在的地方、因为我必须将电容阵列增量调整到 正确、我注意到默认值0xC1在我们的电路板上导致了相同的问题。 我们在 CC1310传感器上使用 TI 推荐的晶体和电容器、而这正是物有所值。

    需要更改的值同样位于 TI DEVICes->Device Configuration->XOSC Cap Array Delta 下的 syscfg 文件中。

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

    915MHz 上的8kHz 约为9ppm。 大多数 xtals 的变化要比这高得多、尤其是在温度和老化方面。 使用不重复位的5kbps 将会产生很差的频率偏移容差、并且不是这些芯片的正确选择。 在 CC13x2上、您可以使用 TCXO 解决部分问题、但 CC1310不支持 TCXO。  

    请参阅 https://www.ti.com/lit/an/swra566/swra566.pdf 和 www.ti.com/.../swra682.pdf