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.

[参考译文] CC1310:CC1310与旧收发器的兼容性

Guru**** 2446240 points
Other Parts Discussed in Thread: CC1310, CC110L, CC1020, CC1101

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/631343/cc1310-cc1310-compatibility-to-older-transceivers

部件号:CC1310
主题中讨论的其他部件: CC110LCC1020CC1101

您好,

我们正在尝试将使用CC1310收发器的新产品集成到由使用CC110L和CC1020收发器的产品组成的现有生态系统中。 由于TI员工在本论坛上的帮助,我们成功地使CC1310和CC110L器件能够相互通信-发送和接收数据包在两个方向都能工作。 但是现在我们在尝试接收旧CC1020设备上的CC1310s数据包时遇到了困难。 在CC1310设备上接收CC1020s数据包工作正常。

令人遗憾的是,CC1020s的配置并不完全为人所知,下面是我们所知道的:914.65 中心频率,150kHz带宽,2-FSK调制,曼彻斯特编码。 但是,由于与CC110L的通信工作100 % ,我认为它的设置是正确的:频率,调制和编码如上所述,偏差为31.73kHz,数据速率为20.4kBaud。 我们使用的是同步字(0x1234),我们的数据包的长度可变。 我将在下面附上CC1310和CC110L的配置文件。

我知道这不是什么事情要做,但也许有人有想法。 据我所知,CC1310s和CC110L的设置是相同的(两者之间的通信工作正常),所以我不明白为什么CC1020只处理CC1310s数据包。 同时使用CC1310和CC1020时是否有任何注意事项? 是否存在任何已知的兼容性问题?

此致

e2e.ti.com/.../cc110l_5F00_11_2D00_10_2D00_17.xmle2e.ti.com/.../cc1310_5F00_11_2D00_10_2D00_17.xml

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    CC1101和CC1020在前导码,同步和有效负载上执行曼彻斯特编码。 CC1310仅在有效负载上。 =>必须在CC1310端手动对SYNC单词进行曼彻斯特编码(dev.ti.com/.../index.html)

    我假设您从CC1020中得到一些细节。 如果您在载波检测中使用门控,您会在给定的空中已知数据包的输出上看到什么?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    已在CC1310上手动对SYNC单词曼彻斯特进行编码,前导码已设置为0x6666。 CC1310和CC110L之间的通信工作正常,所以我认为没有什么问题。

    我有两个应用程序可以与CC1020设备配合使用:一个是每秒发送一个测试数据包,另一个是在空中捕获数据包。 唯一需要注意的是,它只显示符合特定格式的数据包:必须有一个长度指示字节,然后是一些数据字节,最后是8位CRC,之后是零字节。 我看不到任何已接收但不符合此格式或存在CRC错误的数据包。 这意味着即使接收到的数据只有一点距离,我也看不到任何内容。

    我在这里真正感到困惑的一点是,为什么CC1020设备从CC110L接收时没有问题,但从CC1310接收时却没有问题,因为两者都以完全相同的方式进行传输,或者至少应该以相同的方式进行传输。 遗憾的是,我没有CC1020评估板来测试CC1020和CC1310之间是否存在固有问题,或者这是否是与我们的配置有关的问题。 也许您可以帮我解决这个问题。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    CC1101和CC1310不支持在CRC之后直接插入'0'的数据包格式。 可能是CC1101意外地对数据包进行斜坡/结束的方式会创建一个尾随'0'。 我怀疑你必须做的是计算MCU中的CRC,并将这个+'0'添加到有效载荷中,然后关闭自动插入CRC。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    很抱歉我没有说明这一点-这就是我们已经在做的事。 CC1310和CC110L中的CRC都已关闭(因为我了解它们都不支持8位CRC)。 我提到CRC的原因是,它导致未正确接收100 % 的数据包被抛出。

    基本上我所做的就是让CC1020设备发送一个样本包,看起来像这样:0C 00 01 00 00 F1 d8 b4 01 CB C5 ef 00

    如您所见,第一个字节表示长度,有11个字节的数据,一个字节的CRC以及那个尾随的0。 现在,当使用CC110L和CC1310发送它们时,我将它们设置为固定长度,关闭内置的CRC功能,让它们发送这个确切的封装。 正如我所说的那样,它从CC110L发送时工作正常,而不是从CC1310发送。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    由于CC1101工作正常,而CC1310不工作,我会假设他们出于某种原因实际上正在发送不同的有效负载。 您是否有可用作接收器的CC1310或CC1101 (必须使用同一设备来收听CC1101和CC1310)?

    如果是这样,您可以将同步字编程为前导码,并设置固定的数据包长度,然后比较您在这两种情况下收到的数据。 最好不要启用曼彻斯特编码,因为CC1310和CC1101的编码方式不同。 这里的基本要点是查看芯片之间的差异。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    非常感谢! 我使用CC1310 LaunchPad从我们的自定义CC1310板和CC110L接收相同的数据包。 在LaunchPad上,我禁用曼彻斯特解码并将同步字设置为0x6666.6666万。 查看收到的数据,我注意到CC1310使用0x66作为前导码(正如我之前设置的那样),而CC110L使用0x99。 我没想到这会有什么不同,但当我将CC1310设置为使用0x99作为前导时,CC1020设备开始正常接收其数据包。