[参考译文] CC1312PSIP：ApiMac_attribute_responseWaitTime 需要为 UINT16

您好、Andrew、

我正在与开发人员核实、并很快回来联系您。

此致、

Daniel

您好、Andrew、

不幸的是,这是不可能的。 需要修改响应时间等待的所有 MAC 使用情况。

此致、

Daniel  

您好、Andrew、

您能解释一下您的用例吗？ 是否需要等待更长时间、或者是否存在问题且 ACK 未到达传感器？ ACK 周转时间非常短。 如果到 100ms 您尚未收到 ACK、则永远不会收到该 ACK、表明未收到或丢弃该数据包。

您是否未收到 ACK 或关联响应？

能否擦除两个电路板上的 NV 并重试？ （如果您使用的是 TI Launchpad、则可以在重新启动时按住 BTN2 来完成此操作）

此致、

Daniel

您好、

感谢您的答复。 为了简单起见、我说过、我们有一个基于收集器/传感器的示例、但实际上、网络差别很大、因为它具有路由器、寻址、自生、自愈功能、在某些方面与 ZigBee 非常相似。  

因此、如果传感器（终端设备）执行关联请求、它可能会与路由器通信、该路由器有多个跃点、通过其他路由器返回到收集器（协调器）、因此可以集中验证加入。 已将增加的响应等待时间设置为 10 秒、以允许路由器随后将唯一的消息发送回收集器、然后由收集器对路由器作出响应、路由器随后向加入的终端设备发出关联响应。

如您所见、在地理位置较大的网络中、这可能需要一些时间、通过多个跃点将设备返回到收集器。 除了这种延迟之外、收集器还对关联执行其他任务、这会给关联响应增加一些延迟。

我看到、如果直接连接到收集器、加入的终端设备会错过关联响应、时间仅为 100ms 左右、因此在这种情况下时间没有很大差异。

我们运行该网络已有几年、运行速率为 20KSPS LRM、响应等待时间为 200 相当于大约 10s、这很正常。 我们现在还有一个 50ksps 868 网络、这个网络以 4s 响应等待时间运行、这仍然可以。 问题现在转移到 915 FCC WB-DSSS、该产品具有强大的 480ksps 采样率、因此这个 10s 响应等待时间减少到~400ms。  

915 网络上快速响应等待时间的结果是设备将无法关联、因为它们在等待关联响应时超时太快。 我已经证明了这一点,因为我可以从关联确认回调调用另一个关联请求,然后允许先前尝试通过 Mac 传播的响应,但这是一个相当讨厌的竞争条件和关联请求仍然可能被错过。

鉴于我无法更改响应等待时间、我可能需要提出另一个解决方案、但我不确定这是什么。

除了解决和测试此问题外、该产品已准备好发货、因此我希望 TI 能在此处提供一些支持。

非常感谢、

Andy

尊敬的 Andy：

现在问题非常明显、需要更长的轮候时间。 我将与堆栈开发人员一起研究它、我会尽快回复您。

此致、

Daniel

尊敬的 Daniel：

您有任何更新吗？

非常感谢、

Andy