[参考译文] LP-EM-CC1314R10：多传感器网络 — 断开问题-监听器日志

尊敬的  Muniyappan：

A) 是的、它们是 ACK。 收集器会确认每条消息。 由于没有信标、因此这是传感器知道它仍在网络中的唯一方式。 在丢失一定数量的 ACK 后、传感器将开始发送孤立通知。

b) 和 c) 我不知道限制、我要做一些更多的研究、然后再回到您的身边。 您使用的是哪个 SDK 版本？ 您是使用 Linux 主机运行完全嵌入式收集器项目还是协处理器？

此致、

Daniel

尊敬的 Daniel：

感谢您的宝贵反馈。

、我将进行更多研究并返回给您。 您使用的是哪个 SDK 版本？ 您是使用 Linux 主机运行完全嵌入式收集器项目还是协处理器

我正在使用 SDK 版本 7.41.00.17 和完全嵌入式收集器工程。

注意：
此问题无法直接重现、因为它取决于在前一个传感器（即 Sensor1）报告数据包的 150ms 内传输 sensor2 报告数据包。 但 Sensor1 和 Sensor2 没有任何常见信号。  

从您对问题 A 的回答中）

>>因此、这意味着收集器将转到 传输模式  （即收集器天线将处于 Tx 模式？）  接收到来自传感器的任何数据包后立即发送 ACK。 我的理解是正确的吗？


此致、
Muniyappan R.M.

尊敬的  Muniyappan：

从您的捕获结果来看、数据包似乎是 105 字节（或者这是有效载荷，没有 MAC 和 PHY 标头？ )。 在任何情况下、如果数据包为 105 字节、则数据包传输约为 105* 8/5kbps = 168ms。 这意味着在 150ms 的窗口中、第一个数据包的尾与第二个数据包的头重叠。 显然、这还不够、您至少需要 168ms 的间隙、甚至可能 还需要多一点、以便能够传输 ACK。

如果 105 字节只是有效载荷、则数据包约为 120 字节、这样传输时间为 192ms。

此致、

Daniel

尊敬的 Daniel：

感谢您的答复。

您的回答中  

意味着在 150ms 窗口中、第一个数据包的尾部与第二个数据包的头部重叠。 显然、这还不够、您至少需要 168ms 的间隙、甚至可能 还需要多一点、以便能够传输 ACK。

实际上、我在网络中使用多传感器、因此无法保持网络中传感器传输的 160ms 延迟（因为一个传感器不知道另一个传感器何时传输数据包）。

有没有办法解决这个问题呢？

是否有任何选项可为收集器中连接的每个传感器设置预定义插槽？

我们的客户要求是将 14 个传感器连接到一个网关、然后将数据传输到网关。 请帮助我们满足我的要求。

此致、

Muniyappan R.M.

尊敬的  Muniyappan：

非信标模式使用非时隙 CSMA 算法、当器件希望传输时、会等待一个随机周期；如果通道空闲、则器件会传输、否则会再次回退一个随机时长。 对于 远距离模式、我们应增加退避时间、建议使用以下值：

您可以在 Sensor 's SysConfig > TI 15.4-Stack > Network > MAC 中进行更改。

您能尝试一下并检查它是否有助于避免碰撞吗？  

如果报告间隔符合您的要求、您也可以增加报告间隔。

通常、大部分通信是否从传感器传输到收集器？

此致、

Daniel

尊敬的 Daniel：

感谢您的答复。 我们将更改此退避间隔、并使用一个收集器和 5 个传感器+一个监听器测试网络。
我们将向您更新我们的结果。

通常、大部分通信是从传感器传输到收集器吗？

>>是的。 实际上 、我不希望传感器向收集器发送轮询数据包、因为除了传感器配置和 OAD 外、收集器不会更频繁地向收集器发送数据。
在我的当前设置中、我将轮询间隔设置为 20（每个传感器还无需每 20 秒发送一次轮询数据包）。


0x0001 /0x0002/0x0003/0x004 -> 0xaabb（轮询请求）

我亦已在这里就投票时间间隔提出质询：  
关于：LP-EM-CC1314R10：为每个传感器配置不同的轮询和报告间隔。

我仍然在为我的客户要求设置报告和轮询间隔。

一个简短的问题：您提到了 NBCN 模式使用的 是未开槽的 CSMA 算法。 这会导致数据包不同步传输,它是否更好地与跳频?. 请提供您的意见。

此致、
Muniyappan R.M.

尊敬的 Muniyappan：

请告诉我测试过程是怎样的

我仍在努力为我的客户要求设置报告和轮询间隔。

“你在担心什么?“

更适合跳频吗？

我将仔细检查、但我相信这无助于事、因为传感器仍需要以收集器正在侦听的频率进行传输。

您也可以尝试以下方法： 如果所有传感器都同时启动、则可以尝试在启动时添加随机休眠功能、以便它们不再位于同一个插槽中。

此致、

Daniel

尊敬的 Daniel：

我们将 使用更新后的退避间隔测试网络、并将向您更新网络稳定性。 也许我们将运行夜间测试并更新您。
 

您在这里遇到了什么问题？

>>我正在为我的最终网络（即以最小数据丢失连接到一个网关的 14 个传感器）选择适当的报告和轮询间隔。 此外、网络中不应出现传感器断开问题（因为断开连接会触发来自客户站点的服务请求）、但某些不可预测的情况除外。

您也可以尝试以下方法： 如果所有传感器都同时启动、则可以尝试在启动时添加随机休眠功能、以便它们不再位于同一个插槽中。

>>是的,这也是一个很好的方法。 但在我的例子中、传感器可能不是在 Sam 时间配置的。 当我们构建像网关传感器模型这样的产品时、用户可以随时将新传感器连接/配置到网络。

再次感谢您的持续支持。

此致、
Muniyappan R.M.

尊敬的 Daniel：

我们使用更新后的退避间隔测试了网络。
5 个传感器 — 1 个收集器和一个额外的嗅探器。 NBCN 模式 — 5kbps PHY。 报告间隔为 10s、轮询间隔为 20 秒
安装程序运行了 12 小时。 所有传感器均放置在距离收集器 20 英尺的范围内。

以下是观察结果：

因此、我认为与之前的场景相比、网络更稳定。

您也可以尝试增加未被确认数据包的阈值、在这些数据包中、传感器将成为孤立的数据包。

>>当然、我们将查看代码并增加该计数。

您现在可以尝试使用报告和轮询间隔。  [/报价]

>>我想增加轮询间隔,但我们需要从收集器（即从网关）配置传感器。 如果我增加轮询间隔、这可能会受到影响。 该传感器配置不会被频繁触发、但会在用户需要时触发。
>>我计划将轮询间隔从收集器动态更改为特定传感器、但似乎我们无法单独更改一个传感器的轮询间隔。 因此、我正在寻找一些方法。

现在我们将增加距离。 并测试网络。
 
我们非常感谢您的支持。 如果您有任何其他建议,请与我们分享。

此致、
Muniyappan

尊敬的  Muniyappan：

不确定跳频低延迟广播模式（跳频低延迟广播模式—SimpleLink CC13XX/CC26XX SDK TI 15.4-Stack 用户指南 7.31.00.00 文档）是否更合适。 下周我将与我的同事讨论。

也可以看看此示例： CC1352P：如何在 15.4 网络 FH 低延时广播模式中将数据从收集器发送到特定的传感器 — 低于 1GHz 论坛 — 低于 1GHz - TI E2E 支持论坛

简而言之、收集器发送具有匹配器件地址的心跳广播消息、每个传感器都唤醒、保持在 RX 上、如果地址不匹配、则返回睡眠状态。 像在 NBCN 中执行轮询请求一样、传感器不会进入 TX、因此功耗 很低、除非地址与传感器自身的地址匹配。 因此、您将能够使用特定传感器、根据您的要求更改配置。

根据我的理解、您希望大约每 10s 从传感器向收集器发送一次 数据、同时让收集器向特定的传感器发送数据、不是很频繁、但在发生这种情况时响应速度很快。

此致、  

Daniel

感谢 Daniel 的宝贵见解。 我正在研究这个。 FH 模式。

此致、
Muniyappan R.M.

尊敬的 Muniyappan：

我刚刚与同事讨论过、并认为 FH 低延时模式是一种很好的方法。 能够针对特定的传感器、并让它们以极低的延迟运行、这会以牺牲功耗为代价。 但是、由于 5kbps PHY 上的数据包的空气时间较长、因此我担心广播时间和停留时间。

我的问题是、您能否简单地解释一下您的应用是什么、预计涵盖的范围是多大、您的要求低功耗多高、以及您需要多长时间报告传感器（每 10 秒一次？） 能否放宽这个要求、能否将数据速率提高到 5kbps 以上？

此致、

Daniel