rfListenBeforeTalk.c 历程与wor历程配合出现的问题

kun zhou

现在一个项目路由端常供电所以不需要wor模式接收但是终端设备需要wor接收，现在是500ms唤醒终端一次进行接收，所以路由端需要发送方500ms的载波，这就可能出现路由发送载波的时候终端发出数据接收不到，所以终端发送数据我移植了rfListenBeforeTalk.c里面的代码，都没问题，然后看了下原来代码只重试10次#define IDLE_TIME_US 5000而且这个时间值设置了5ms 意思是这个发送的载波检测只会等待50ms吗? 我按着这个思路把#define IDLE_TIME_US 改成了50000 也就是50ms ，然后把重试次数设置到了20 ，理论上是不是可以达到1秒整的重试时间/。但是实验的结果是没作用。如果路由在发载波的话，终端似乎没有进行信道检测直接发出去了，因为我从抓包的wireshark上看到的情况就是只有路由发送载波成功后的包没有终端的包，理论上应该抓包软件能先看到路由的包然后再看到终端的包的求指教i 急等

5 年多前

0 Alvin Chen 5 年多前

TI__Guru 56646 points

Example Summary
The Listen Before Talk (LBT) TX example illustrates how to implement a simple, proprietary LBT algorithm using command chaining.

When sending a packet, the radio first enters RX mode using CMD_PROP_CS. If the channel is IDLE (the RSSI is below RSSI_THRESHOLD) for IDLE_TIME_US, the the radio enters TX and transmits a packet. If the channel is BUSY (RSSI above RSSI_THRESHOLD), the radio enters RX again to check the channel once more. This is repeated max CS_RETRIES_WHEN_BUSY number of times. The command chain will either finish with a packet being sent (if the channel is IDLE), or after checking the channel CS_RETRIES_WHEN_BUSY times.

Default Settings:

CS_RETRIES_WHEN_BUSY: 10
RSSI_THRESHOLD: -90 dBm
IDLE_TIME_US: 5000 us

With the default settings it takes ~250 us to determine if the channel is BUSY or not. Considering a worst case of 10 retries, the execution of the whole chain takes around 5.6 ms, including CMD_NOP and CMD_COUNT_BRANCH.
上面的是LBT也就是说他会在检查你的状态如果正常就是发送，如果是busy，大概会花费5.6ms去check。