Other Parts Discussed in Thread: SYSCONFIG
器件型号: CC2340R5
主题: SysConfig 中讨论的其他器件
你(们)好
我使用 2652 作为协调器、2340 作为节点。 在工厂测试中、我希望加快 2340 网络连接的速度、以便在工厂中进行快速测试。 是否有任何方法可以提高信标请求的发送频率? 是否需要更改作为 2652 协调器的结束?
此致
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.
Other Parts Discussed in Thread: SYSCONFIG
器件型号: CC2340R5
主题: SysConfig 中讨论的其他器件
你(们)好
我使用 2652 作为协调器、2340 作为节点。 在工厂测试中、我希望加快 2340 网络连接的速度、以便在工厂中进行快速测试。 是否有任何方法可以提高信标请求的发送频率? 是否需要更改作为 2652 协调器的结束?
此致
您好、
转向失败时、下一次重试之间会有 10 秒的延迟
case ZB_BDB_SIGNAL_STEERING:
Log_printf(LogModule_Zigbee_App, Log_WARNING, "Steering failed, retrying again in 10 seconds");
ZB_SCHEDULE_APP_ALARM(restart_commissioning, 0, 10 * ZB_TIME_ONE_SECOND);
break; /* ZB_BDB_SIGNAL_STEERING */
您还可以 在 zb_config_common.h 中确定 ZB_ZDO_Nwk_SCAN_BUCKS 和 ZB_ZDO_Nwk_time_btwn_scans
此致、
Ryan
ZB_ZDO_NWK_SCAN_BUCKS
请提醒一下您要评估的 F3 SDK 版本和示例。 您是否通过开箱即用的示例观察到了这种行为? 在 SysConfig 中启用了多少个通道进行扫描? 以下示例将 on_off_switch.c (F3 SDK v9.14) 中的“restart_commissionin"频率“频率更改为每 3 秒一次、仅扫描通道 17。 我过滤掉了所有其他数据包、包括信标响应。

此致、
Ryan
您好、Ryan、也许我已经确定了我的工程信标请求速度缓慢的原因。 通过调试程序、我发现在我的程序进入 ZB_osif_sleep 后、它继续执行 SemaphoreP_pend (buttonSem、SLEEP_ticks);在这里花费的短暂时间会导致我的信标请求数据包发送得非常慢。 但当我使用该例程时、我几乎永远不会写入:SemaphoreP_pend (buttonSem、SLEEP_ticks);保持时间很短、因此信标请求间隔非常短。 我想知道如何使用 ZB_osif_sleep? 参数 SLEEP_TMO 从何而来? 为什么它会导致程序长时间卡住?
我的 SDK 版本为 V_911。
当应用程序 从 ZB_COMMON_SIGNAL_CAN_sleep 案例中调用 ZB_SLEEP_NOW 时、源代码会计算可允许栈睡眠的时间量、确认其高于睡眠阈值、并将“SLEEP_TMO"参数“参数发送到 ZB_osif_sleep 。 无论该函数是进入 SemaphoreP_PEND(并等待信标由 SLEEP_TICKS 发布)还是使用 ClockP_usleep、这都将导致任何无线电活动在该时间段内延迟、或完全取消/到期。 这不是默认行为(在开箱即用 v9.11 SDK 示例中确认)、因此需要仔细检查应用如何允许进入睡眠模式。
SIMPLELINK-LOWPOWER-F3-SDK v9.14 已发布并 启用 测试 API 、这些 API 可以使用 RF_TEST_START_TX_CW 连续发送载波。 如果您对此感兴趣、请下载最新的 SDK 并评估 ZigBee 文件夹中的 RF_test 示例工程。