[参考译文] CC1312R：传感器发送消息算法

嗨, Zildhous,

我已将该主题分配给一位同事。 他们会很快回复给您。  

此致、
SID

尊敬的 Alex：  

感谢您的答复。  

提升超级帧顺序对我来说是行不通的、因为对于电池供电的协调器来说、功耗太高了。  

感谢您的测试、我会 将此策略应用于我的应用、并会确认这是否解决了我的问题。

Žilvinas

嗨, Zildhous,

 您成功解决了您的问题吗？

此致、

亚历克斯

您好、Alex、

我自己进行了测试、结果如下。 首先、我更新了应用、以便提高 可观察的测试结果。 每第二个信标上的应用程序都有消息 供所有加入的 传感器发送警报消息、而其他信标不包含来自传感器的任何请求、并且不应接收任何消息。  

测试1。 868MHz ETSI、BO = 10、 SO=3 (RxOn ~38ms) 最小 BE = 1，最大 BE = 2。 连接的传感器= 3

监听器数据表明应用程序按预期运行。 每第二个信标、一个或两个传感器传输报警消息。 留下静默信标、用于跟踪当前未实现的消息。 但是、由于电流消耗较高、这种 Stack 配置不合适。

测试2。  868MHz ETSI、BO = 10、 SO=2 (RxOn ~19ms) 最小 BE = 1，最大 BE = 2。  连接的 传感器= 3

第二项测试 的 SO=2、根据监听器数据、我们可以观察到只有少数信标静默。 这是不合适的。  

测试3。  913 MHz FCC 、BO = 10、  SO=2 (RxOn ~19ms) 最小 BE = 1，最大 BE = 2。  连接的 传感器= 3

此处的应用在所需的 RX 通话时间内表现正常。  

我进行此测试的原因是、我认为 LBT 算法使应用的行为类似于测试2中的行为、并在 CCA 级检测到占用信道时放置消息以进行重新传输。

那么我的问题是、 如何实现 LBT 算法、以及它与蓝牙  CONFIG_MAC_MAX_CSMA_BACKOFFS  函数参数。 您可以指出主题或文档链接。

Žilvinas

尊敬的 Alex：

关于填充传输队列计时的问题。 传感器应用程序在接收信标时填充 TX 队列、这自然会进行同步。 不过、我设置了要在其中捕获3个传感器器件的信号的设置。

应用程序的配置相同：

捕获的信号包括：

RX -设备开启了无线电的 RX

TX -设备正在发送

SetMsg -当 MAC 被消息请求填满时的时刻(调用 ApiMac_mcpsDataReq)

接下来是监听器捕获的数据图像和与捕获的器件电气信号时刻相同的图像。  

以下是预期行为的示例。 监听器日志中突出显示的信标就是我们在电气信号捕获打印屏幕中看到的信标。 所有3个器件的 RX 都显示、 当 MAC 被填充消息请求(调用 ApiMac_mcpsDataREQ)时、接收到信标、SetMsg 信号是瞬间。 器件0x0002没有捕获 SetMsg 信号、但它执行与0x0001和0x0003相同的操作。 我们可以看到、这三个器件都执行 CCA、并且仅能传输0x0003。 DataCnf 回调在同一信标内返回0x0001和0x0002的状态、代码指示"ApiMac_STATUS_channelAccessFailure = 0xE1"此示例正是我所期望的。

另一个示例是不希望出现的行为。

这里我们可以看到、所有传感器器件收到信标后会立即将消息放入 TX 队列。 0x0001器件能够传送消息。 0x0002器件在 CCA 级检测到通道已被占用并返回"ApiMac_STATUS_channelAccessFailure = 0xE1"状态。 不过、0x0003会及时向 TX 队列明确放入消息、但甚至不会尝试执行 CCA。 在下一个信标0x0003成功 传送消息。

您能解释一下根据 EN 300 220-1礼貌频谱访问的 LBT 机制吗？ 如果我理解正确、在将消息放入 TX 队列后、MAC 堆栈会在 CCA 阶段之前随机生成的等待时间。 如果检测到通道被占用、则会由于我具有 CONFIG_MAC_MAX_CSMA_BACKOFFS 0和 CONFIG_MAX_RETRIES 0而丢弃事件。 如果为真、什么是基于退避指数的随机时间公式？ 随机等待时间是否比协调器 RX 通话时间(~19ms)长且消息设置为在下一个信标上传输？  

Žilvinas

尊敬的 Alex：

感谢您的答复。  

您是否测量了从接收信标到写入 TX 队列需要多长时间这可能导致延迟。

持续~1ms。  

-如果信道在时间窗口内不空闲，则5msec +随机时间在下一次侦听之前等待

我假设在第一个 TRY 通道上、通道被占用意味着不再侦听、因为我必须  CONFIG_MAC_MAX_CSMA_BACKOFFS 0。 如果是真、则我的案例中绝不涉及随机时间。 您能向我说明一下从数据包被放入 TX 队列开始的数据包传输顺序吗？ 我丢失了 CONFIG_MAC_MAX_CSMA_BACKOFFS、CONFIG_MAX_RETRIES 、 CONFIG_MIN_BE、 CONFIG_MAX_BE 参与该序列的方式。

此处可能适用的另一种方法是使用计时器删除 TX 队列中的消息。 您是否已经考虑了这一点来解决您的问题？  [/报价]

感谢您的建议。 我口袋中有这种方法、但当时这更像是一种权变措施。 我想知道问题的根源是什么。  

Žilvinas

嗨, Zildhous,

 仍使用 CONFIG_MAC_MAX_CSMA_BACKOFFS 是 LBT 失败后执行的重试次数。
 CONFIG_MAX_RETRIES 定义访问过程失败后 Mac 重新发送帧的频率。

CONFIG_MIN_BE、 CONFIG_MAX_BE 未在 LBT 中使用。

CONFIG_MIN_BE、 CONFIG_MAX_BE 未在 LBT 中使用。

这些功能替换为首次尝试时侦听5秒

并监听5s +一个随机数(0-5ms)。

我仍然认为、您的应用程序需要很长时间才能将消息写入队列、而计时可能也有问题。  

我调整了示例并使应用程序在我按下按钮后立即向 TX 队列发送消息将消息发送到 TX 队列。  

但是、只要我按全部3个按钮、就会发送一条消息、并转储其他消息。

您是否可以尝试在信标间隔的活动周期部分之后写入队列 并查看下一个信标间隔内发生的情况？  

我的测量结果显示：  

测试全部3个按钮(5)我刚用器件1发送数据

(8)我只使用器件2发送了数据

(11)我只使用器件3发送了数据

(14)按下全部三个按钮、仅发送一个数据包  

我可以在桌子旁重复多次、然后转储消息。

我认为，在你们的情况下，接收信标-->使用内容-->写入 txqueue 并等待访问以处理每件事都可能有轻微延迟，在你们的情况下，一个也是非常短的时间。

因此、我建议您在活动周期后发送消息、看看这是否能解决您的问题。

此致、

亚历克斯

嗨, Zildhous,

这是一个好主意。  

我使用的是最新的 SDK (7.10.00.98)。

使用此版本、我不存在您的问题。 至少对我的配置不适用。

在一个时间段内从3个器件发送消息、将发送一条消息、所有其他消息将被转储。

此致、  

亚历克斯

您好 Alex：

很抱歉最近未能解决此问题。

我已经将应用更新为最新的 SDK (7.10.00.98)。

它没有解决我的问题。 以下是监听器捕获的图像。 每四个信标请求来自传感器的警报消息。

从我的长期测试中可以看出、从将消息放入 TX 队列直至发送消息、之后可以是1个或2个信标、我们可以从监听器日志中看到。

关于 LBT 的工作原理：

这些功能替换为首次尝试时侦听5秒

并监听5s +一个随机数(0-5ms)。

[/报价]

 SDK 7.10.00.98的说明似乎不正确。

从上面的图片,我可以告诉,听部分总是240us ,但有随机部分在第一次尝试,这是等待时间之前听. 从我的观察来看、从接收信标到执行收听的周期从2.4ms 到7ms。 因此仍然不清楚 LBT 算法是如何实现的。 我假设用来衡量计时的方法是正确的。 该方法在这里定义的 调试射频输出。 您能否检查一下您是否使用最新的 SDK 获得5ms 侦听部分？  

尊敬的 Alex：

由于我将不再从事这个项目,我想介绍我的同事 Mindaugas , 他将继续与您沟通。 感谢您对此问题的支持。

Žilvinas