Thread 中讨论的其他器件: Z-stack
与上一个主题中描述的问题相同、这次对于 CC2652P:
同样的权变措施:每500秒唤醒一次器 件、以轮询父级(POLL_RATE)的数据或尝试重新加入(示例应用中的 SampleApp_end_device_重新 加入延迟)。
是否有任何迹象表明何时会解决该问题? CC2652P 需要更大的电流、因此如果 器件与父器件的连接中断时间过长(例如数天或数周)、重新加入尝试会迅速耗尽电池电量。
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.
与上一个主题中描述的问题相同、这次对于 CC2652P:
同样的权变措施:每500秒唤醒一次器 件、以轮询父级(POLL_RATE)的数据或尝试重新加入(示例应用中的 SampleApp_end_device_重新 加入延迟)。
是否有任何迹象表明何时会解决该问题? CC2652P 需要更大的电流、因此如果 器件与父器件的连接中断时间过长(例如数天或数周)、重新加入尝试会迅速耗尽电池电量。
感谢 Ryan、
很高兴知道这是即将解决的问题清单上的问题。
我到目前为止的观察结果:CC2652P 在 数据轮询 或重新加入之间需要300秒或更短的时间。 较大的间隔会导致无法正常恢复睡眠。
我在一个器件上看到电池耗电、该器件在一天内未连接(parent_lost 网络状态)。 还不知道它是否相关以及如何重现:在具有相同设计和固件的另一个器件上没有发生过这种情况。 如果我发现问题、将进一步调查并在该论坛上发布新话题。
此致、
亚历山大
我的观察结果大致相同、轮询周期的值等于或大于540000 ms (9分钟)会导致问题。 我发现 v5.10和 v4.40 Z-Stack 示例中也存在此问题、但无法使用15.4-Stack 2.4GHz 传感器和收集器示例进行复制、因此它似乎专门与 Z-Stack 轮询模块相关。
我还设置 了一个10分钟的 OsalPortTimers_startReloadTimer、该计时器会在超时时清除标志、在此测试期间、低功耗条件保持预期。 但是、如果我在计时器事件案例中添加一个 zclGeneral_SendOnOff_CmdToggle 或 NwkPollReq、则在接下来的10分钟内会再次发生活动电源状况。 基于此、根本原因出现在 Z-Stack 而不是 OsalPortTimers 相关。
如果您发现更多信息、请告诉我、因为我也会这样做。
此致、
Ryan