[参考译文] CC1101：更高数据速率(125K 和250K)下的 CRC 误差

使用中断是使用无线电的推荐方法。 为什么要使用轮询代码？

"不超过50ms ..."的意思是什么？

我无法使用中断。 为什么改用中断来解决这个问题？

轮询之间存在50ms 的延迟、因为根据 CC1101勘误表、某些寄存器可能会由于高速轮询而出现问题。 轮询之间的50ms 延迟使得它的速度相对较低、并且被引入以避免勘误表中的所有问题。

顺便说一下、在我的测试代码中、TX 端每秒发送几个字节。

RX 侧具有以下观察结果

1)成功接待的人很少。

2) 2)接收到几个 pkts、但有 CRC 错误。

3) 3)大多数 pkts 都完全丢失、没有任何指示

由于 SPI 流量、轮询会产生更多的噪声、并且在许多情况下需要 MCU 处于不需要的状态。

首先、使用 SmartRF Studio 控制的电路板作为接收器进行测试、以检查您是否能够接收数据包。 这是为了确保 TX 侧按需要运行。

其次、如果不知道代码的任何信息、就不可能猜测出问题的发生。

这是不是一个业余项目、因为它看起来像您在使用 Arduino、还是一个用于以后批量项目的原型？

它适用于实际的生产系统。 CC1101在 Arduino 上用作原型、而最终产品将使用 ESP32。 在生产过程中、该库已在两个系统上以74.8 kbaud 的速率工作。 在遇到此问题后，执行了更长的测试以测量74.8千波特时的 pktt 损耗。
无论使用哪条通道、在74.8KBaud 下都测量了4% pkt 压降。
在使用 CC1101的大多数产品中、我们使用"始终运行 MCU"、因此轮询不会成为问题。

这些器件正在以足够的 TX 功率在1M 的距离内进行测试。 是否已知在 CC1101中的高数据速率接收中会出现 SPI 噪声？

距离为1 m 时、您针对此测试中接收到的数据包测量的 RSSI 是多少？ 我认为您需要更近一点才能看到此问题、但您是否检查过您是否未处于饱和状态？

我们完成的所有灵敏度测试均基于中断、这意味着我们没有任何用于轮询的灵敏度数字。 我们刚刚看到一些迹象、表明在接收期间引脚活动会降低一些灵敏度。

从您编写的内容来看、问题听起来像是从74.8 kbps 开始、而对于更高的数据传输速率、问题就会变得更糟。 我会怀疑时间问题。

我查看了您链接到的 GitHub 代码、但无法找到如何在 RX 中完成轮询。 这里有更多详细信息吗？

您是否能够使用已知良好的接收器(由 SmartRF Studio 控制的电路板)来检查 TX 侧是否按需要工作？

如果它是饱和问题、那么它也应该在较低的数据速率下发生、此时接收器灵敏度更好。 但此问题仅在较高的数据速率下发生。
正如我在第一个帖子中提到的、GitHub 库已被修改、以支持非中断轮询模式以及原始库不支持的更多数据速率。 我是否可以通过个人消息传递代码？

我将以较低的4.8k 波特检查 pktloss %、如果它发生的时间问题小于它的时间问题、并且需要探索中断模式。

由 SmartRF Studio 控制的电路板需要一些时间才能启动并运行。