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.

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

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

  • 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。
  • 噢,这个5.6ms 是怎么计算的? 如果我需要检测500ms要如何设置呢 那是我之前理解错了这个IDLE_TIME_US的意义
  • 我纠正思路后 直接把重试次数设置到了2000 然后可以, ,,, 但是还是对这个时间计算有疑问 我这个2000 到底能持续检测多久
  • 按照他意思 cs命令250us 10次2.5ms 剩下的3.1ms=5.6-2.5 是branch计数和nop命令的?