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.

[参考译文] CC1312R:CRC 计算

Guru**** 1091470 points
Other Parts Discussed in Thread: CC1125, CC1352R, CC1310
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1222653/cc1312r-crc-calculation

器件型号:CC1312R
主题中讨论的其他器件:CC1352RCC1310、CC1125

大家好、

您能回答以下有关 CC13xx 系列的客户问题吗?

1.出于兼容性原因,我们必须保持434 MHz ISM 频带和我们的"旧"电报结构。 RX 带宽为10kHz 和50kHz 时、数据速率为4.8 kBaud 和19.2 kBaud、如下所示:

标头82*0x55、同步暂停(0xFF、0xFF、0xFF)、0x01、数据长度、数据长度、用户数据(不同长度)、CRC-CCITTL、CRC-CCITTH。
(----- 在这一范围内进行 CRC 计算---)
目前、我们可以通过 SmartRF Studio 和 CC1312R1 LAUNCHXL 板收到电报、但总会收到 CRC 错误。 当然、随后可以在软件中进行 CRC 计算、但最好由 SOC 提供 CRC 计算功能(当然采用上述格式)。
以下是 μ µC 此后使用的格式:

我们还没有收到我们的电报--人们担心会出现类似的问题。
该报头如此长、因为我们始终在4个频率下连续"侦听"。 3是工作频率、要检查标头中的数据、第4个始终是我们使用的频率之一、用于统计目的、以便能够在干扰到另一个通道组的情况下发生变化。

2. 在开发中我们主要使用带有 µVision 的 ARM Keil MDK5并且我们惊讶地发现上面提到的 SOC 不能用它进行编程。 根据 Keil、仅支持 MSP432系列。 我们在那里错了吗?

3、 我们详细了解了 CC1310/CC1312和 CC1352R。 遗憾的是、CC1352R"仅"具有接收器类别1.5 / 2。 接收器类别1在安防行业较为理想。 CC1310并未对此进行记录、但如果我查看数据表、它将无法在我们的数据速率/RX 带宽下实现接收器类别1、尤其是在阻塞方面。

Auszüge Aus EN 300 220-1 V3.1. (2017-02)

表36:相邻通道上的接收器饱和

要求限制

相邻通道饱和(OCW≤25kHz)≥-20dBm

相邻信道饱和(OCW > 25kHz)≥-10dBm

表38:杂散响应抑制

要求限制

杂散响应抑制(OCW≤25kHz)≥-44dBm

杂散响应抑制(OCW > 25kHz)≥-34dBm

注意:对于与所需信号分离的杂散响应测试、小于

工作频率的0.1 %、则限值会放宽到25 dB。

表43:RX 类别1的阻塞级别参数

要求限制

接收器类别1

在±中心频率≥2MHz 时阻断、则为-20dBm

在±中心频率≥10MHz 时阻断、则为-20dBm

在中心频率的±5%或15MHz 时进行阻断、

以较大者为准≥-20 dBm

谢谢!

弗朗茨

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

    尊敬的 Franz:

    1.客户可以按照本页面提供的指导、在射频内核中重新配置 CRC 多项式: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_41_00_17/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf/packet-format.html?highlight=crc#overrides

    我认为无线电覆盖将是、给定 CRC16-CCITT 如下、我们实际上在文档中有一个示例:

    static uint32_t overrides[] =
    {
        // ...
        // Configure new CRC-16 polynom
        HW32_ARRAY_OVERRIDE(0x2004, 1),
        // The CRC-16 polynome: CRC-16-CCITT normal form, 0x1021 is x^16 + x^12 + x^5 + 1
        0x10210000,
        // ...
    };

    可以在 SmartRF Studio 7中对其进行测试、如下所示:

    回答其他问题。

    2.我们确实不支持 Keil uVision。 我建议您使用我们的免费 Code Composer Studio IDE 或 IAR。 我们的 CC13xx_CC26xx SDK 支持这两种解决方案。

    3.我会把这个问题留给我们的一位硬件专家。

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

    尊敬的 Franz:

    CC1310不适用于1类接收器。

    而 CC1125正是如此。 以下应用手册详细介绍了868MHz 下的性能、但数据表指出、410-480MHz 下的频率也符合 ETSI EN 300 220 1类法规。  SWRA424.  (CC1125在869MHz 下的25 kHz 通道内运行、ETSI 1类): https://www.ti.com/lit/swra424

    此致、
    扎克

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

    感谢您的快速回复。

    特别是对于 CRC 的计算、我有以下备注或问题:

    在 CC1352的文档中、我发现可以通过覆盖来设置以下设置:
    -生成器多项式
    -起始值
    -异或值

    为了获得所需的 CRC、我们必须进行以下额外设置:

    -在输入处通过算法的每个字节必须首先反转(LSB 变为 MSB)。 这通常被描述为"输入数据反转"。
    在 Renesas 文件中、这可通过描述"LSB First"来查看。
    最后,计算出的 CRC 也必须被求反。 描述为"输出数据反转"。

    这些参数通常也被描述为 REV_IN 和 REV_OUT。 是否可以为 CC1352设置这些参数?

    此致、

    弗朗茨

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

    Franz、

    那么、为了确保他们所需的 CRC 是什么、他们能否提供一个数据包示例? 例如、它们现在是否得到 CRC=0x80C4、是否希望 CRC=0xC480?

    此致、

    Arthur

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

    尊敬的 Franz:

    这一请求是否有任何更新?

    此致、

    Arthur

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

    Arthur、您好!

    我很快就会回复您、以防在 Zack 对问题3的回答后这仍然有意义。

    谢谢。

    弗朗茨

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

    Arthur、您好!

    下面是一个示例数据包:

    0x04 0x04 0x06 0x01

    如果现在是根据前面介绍的程序计算 CRC、则得到以下结果:
    0x54D4

    在我们的电报中、高字节和低字节会互换、从而最终发送以下内容:

    0x04 0x04 0x06 0x01 0xD4 0x54

    您也可以使用以下工具重现 CRC 计算:
    http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

    设置:
    - CRC-16.
    -定制
    -输入和输出已反射
    - Polynomial: 0x1021.
    -初始值: 0x0
    -最终 XOR 值:0x0

    感谢您的努力。

    此致、

    弗朗茨

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

    尊敬的 Franz:

    感谢您提供信息。 我们可能有解决方案、我将通过直接消息与您联系。

    此致、

    Arthur