[参考译文] CC1310：CC1101与可变长度数据包与放大器兼容；曼彻斯特编码

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/704219/cc1310-cc1101-compatibility-with-variable-length-packets-manchester-encoding

大家好、

这不是一个问题，而只是我关于这个专题的一些调查结果。 我在这一论坛上寻求帮助、ter 和 M-W 提供的答案让我很有希望。

简而言之：如何与基于传统 CC1101的无线电系统兼容、该系统使用可变长度数据包、CRC 校验和和曼彻斯特编码！

TI 提供了一个有关 CC1101迁移的文档(请参阅末尾的链接1)、 这是获取曼彻斯特所需配置(CMD_PROP_xxx 参数和覆盖)的良好起点、但要使系统启动并运行、需要更多技巧。

RX：

CMD_PROP_RX_ADV 关键设置：

pktConf.bUseCrc = 1、//尽管所有硬件 CRC 校验失败、仍必须在那里
.pktConf.bCrcIncHdr = 1、
rxConf.bIncludeHdr = 1、
rxConf.bIncludeCrc = 1、
syncdwor0 = 0x9656A65A、// 1101 SYNC 为0xD391D391、这将被曼彻斯特编码为0xA65A.9656A65A.96556
syncdWord1 = 0、
.hdrConf.numHdrBits = 16、//到报头将会有0xD3 (=曼彻斯特解码同步剩余0x9656)和长度指示字节
hdrConf.lenPos = 0、
.hdrConf.numLenBits = 8、

现在、假设 CC1101发送"0x04 0x11 0x22 0x33 0x44 CRC2"。 0x04为数据包长度、其余为有效载荷加上16位 CRC。

CC1310接收到此信息后、我们的 Rx 队列数据具有"0x04 0xD3 0x11 0x22 0x33 0x44 CRC2"。

看到了吗？ 这里有0xD3、至少根据我的知识、没有办法消除它。 但是、使用 hdrConf 参数时、长度字节被正确解释、并且接收端在正确的点结束。 剩下的唯一事情是计算接收到的数据的 CRC (当然不包括0xD3！)、如果可以、继续处理。 CRC 算法是具有位反转的 CRC16 "Modbus"。 对于 CRC、有一个很好的站点、请参阅链接2)！

TX：

这更简单、可以使用"正常"版本(CMD_PROP_TX)。 唯一需要记住的是将 syncword 设置为"0xA65A9656"(即、经曼彻斯特编码的0xD391、请记住、CC1310不会对前导码和同步字进行编码/解码！)、以及其他几种设置：

CMD_PROP_TX 关键设置：

.pktConf.bUseCrc = 0x0、
.pktConf.bVarLen = 0x0、
.pktLen = 、
syncdWord = 0xA65A9656、

不过、有一点小问题：CC1101期望 synctword 为"0xD391D391"。 在标准配置下、它将仅接收一半-不会接收！

解决方法是在有效负载开始时包含字节0xD3和0x91、以便 CC1101认为它是正确的同步字(并且与有效负载一样、CC1310很高兴在将位移入空位之前对其进行曼彻斯特编码！)。 因此、请注意"bUseCrc"为零、因为这些手动 添加的同步字节会使自动 CRC 失效。

让我们发送与 RX 示例中相同的5字节数据包："0x04 0x11 0x22 0x33 0x44"

缓冲区必须与此类似： "0xD3 0x91 0x04 0x11 0x22 0x33 0x44 CRC2"。 CRC 的计算方法与 RX 的计算方法相同。 ".pktLen"字段将设置为0x09、因为同步字节和 CRC 会产生4字节开销。

这样、我就能很好地运行它！

谢谢、

－皮特里·哈里

--------------------------------------------

1)迁移指南： http://dev.ti.com/tirex/content/simplelink_cc13x0_sdk_1_50_00_08/docs/proprietary-rf/proprietary-rf-users-guide/cc1101-migration-guide/index.html

2) CRC 资料： http://sunshine2k.de/coding/javascript/crc/crc_js.html