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.

[参考译文] CC2652P7:如何将 rfWakeOnRadioRx 项目的 WOR(无线电唤醒)机制集成到 RCP 和 otbr-agent 项目中?

Guru**** 2644745 points

Other Parts Discussed in Thread: CC2652P7

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1588117/cc2652p7-how-to-integrate-the-wor-wake-on-radio-mechanism-from-the-rfwakeonradiorx-project-into-the-rcp-and-otbr-agent-projects

器件型号: CC2652P7

我有两台路由器配备了 CC2652P7 芯片。 在这些路由器上运行的 otbr-agent 与 Thread 无线电协处理器 (RCP) 进行通信。 我打算将 rfWakeOnRadioRx 项目中的无线电唤醒 (WOR) 机制集成到 CC2652P7 芯片的 RCP 项目中。 但是、在编译过程中无法找到 RF_cmdPropRadioDivSetup、RF_cmdFs 和 RF_cmdPropRx 等变量。 我是否可以询问需要对 rfWakeOnRadioRx 项目的代码进行哪些修改?

rfWakeOnRadioRx.c  

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

    尊敬的 Zhimin:

    我知道您希望创建低功耗 RCP 解决方案、但是无线电唤醒概念需要 与基于 IEEE 的无线电栈不兼容的特定调制 (2-GFSK) 和命令 (PropRF)。  因此、即使您确实解析了 RF_cmd*结构(在更改 PHY 时重新命名、并可通过 SysConfig 设置或对无线电应用文件进行细微修改来寻址)、也无法为 IEEE PHY 寻址 RFC_CMD_PROP_RX_snif_t。  按照设计、FTD(全 Thread 设备)边界路由器或路由器节点旨在成为随时接收和路由数据包的常开设备。  MTD/SED(最小线程设备/休眠终端节点)设计为进入睡眠状态、因为它不承担此类数据包责任。   

    此致、
    Ryan  

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

    我明白了。 我想实现一种解决方案、让路由器(基于 IEEE 标准)可以在 Thread 网络保持活动状态的同时进入睡眠状态、从而实现 Thread 设备之间的通信。 当我在一台路由器上杀死 otbr-agent 时、Thread 端的 RCP 固件是否可以从另一台配备 Thread 原型的路由器接收 IEEE 无线数据包? 如果可能、应如何修改两侧的 RCP 固件?

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

    当 Thread RCP 处于低功耗待机模式时、它将无法接收或路由 Thread 数据包。  如果 RCP 的主机脱机、但 Thread RCP 处于活动模式、则它可以通过 Thread 网络路由数据包并在本地接收 IEEE 数据包、但除非主机恢复、否则它将无法将 IEEE 数据包传递到主机应用。

    此致、
    Ryan