CC1312R: CRC calculation

Franz Schellhase

Part Number: CC1312R
Other Parts Discussed in Thread: CC1352R, CC1310, CC1125

Hi Team,

Can you answer the following customer question regarding CC13xx series, please?

1. For compatibility reasons we have to stay with the 434 MHz ISM band and our "old" telegram structure. The data rates are 4.8 kBaud and 19.2 kBaud at RX bandwidths of 10 kHz and 50 kHz and looks like this:

Header 82*0x55, Syncpause (0xFF,0xFF,0xFF),0x01, Data length, Data length, User data (different length), CRC-CCITTL, CRC-CCITTH.
(----- over this range the CRC calculation takes place ----)
We are so far that we can receive our telegram with SmartRF Studio and a CC1312R1 LAUNCHXL board, but there we always get a CRC error. Of course a subsequent CRC calculation in software would be possible, but it would be nice if the SOC would provide this (of course in the above mentioned format).
Here the format used by the µC since then:

We have not yet come to the sending of our telegram - there similar problems are feared.
The header is so long, because we always "listen" successively in 4 frequencies. 3 are working frequencies, there the data are examined for header, the 4th is always another one of our used frequencies and serves for statistical purposes, in order to be able to change in case of disturbances to another channel group.

2. We mainly use arm KEIL MDK5 with µVision in development and are surprised that above mentioned SOCs cannot be programmed with it. According to KEIL only the MSP432 series is supported. Are we wrong there?

3. We took a closer look at the CC1310/CC1312 and CC1352R. Unfortunately, the CC1352R "only" has receiver category 1.5 / 2. Receiver category 1 would be desirable in the security industry. This is not documented for the CC1310, but if I go by the data sheet, it will not achieve receiver category 1 at our data rate/RX bandwidth, especially with regard to blocking.

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

Table 36: Receiver saturation at adjacent channel

Requirement Limits

Adjacent channel saturation (OCW ≤ 25 kHz) ≥ -20 dBm

Adjacent channel saturation (OCW > 25 kHz) ≥ -10 dBm

Table 38: Spurious response rejection

Requirement Limits

Spurious response rejection (OCW ≤ 25 kHz) ≥ -44 dBm

Spurious response rejection (OCW > 25 kHz) ≥ -34 dBm

NOTE: For spurious response tests separated from the wanted signal by less than

0,1 % of the Operating Frequency, the limits are relaxed by 25 dB.

Table 43: Blocking level parameters for RX category 1

Requirement Limits

Receiver category 1

Blocking at ±2 MHz from Centre Frequency ≥ -20 dBm

Blocking at ±10 MHz from Centre Frequency ≥ -20 dBm

Blocking at ±5 % of Centre Frequency or 15 MHz,

whichever is the greater ≥ -20 dBm

Thank you,

Franz

over 1 year ago

0 Arthur R☑️ over 1 year ago

TI__Mastermind 18197 points

Hi Franz,

1. The customer can reconfigure the CRC polynomial in the RF core to their need following guidance from this page: 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

I think the radio override would be, given it is CRC16-CCITT the following, which we actually have an example for in the documentation:

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,
    // ...
};

They can test it in SmartRF Studio 7 like so:

As of the other questions.

2. We indeed do not support Keil uVision. I would recommend using our Code Composer Studio IDE, which is free, or IAR. Both of those are supported by our CC13xx_CC26xx SDK.

3. I will leave that question to one of our hardware specialists.

0 ZC over 1 year ago

TI__Genius 11215 points

Hi Franz,

The CC1310 is not designed to be a Category 1 receiver.

The CC1125 is, however. The following App Note details performance at 868 MHz, but the datasheet states that it is also suitable for compliance with ETSI EN 300 220 Category 1 at 410-480 MHz. SWRA424 (CC1125 Operating in 25 kHz Channels at 869 MHz, ETSI Category 1): https://www.ti.com/lit/swra424

Regards,
Zack

0 Franz Schellhase over 1 year ago in reply to ZC

TI__Expert 3605 points

Thank you for your quick replies.

Especially for the calculation of the CRC I have the following remark or questions:

In the documentation to the CC1352 I found that the following settings can be set by override:
- Generator polynomial
- start value
- XOR value

We have to make the following additional setting to get our desired CRC:

- Each byte that passes through the algorithm at the input must first be inverted (LSB becomes MSB). This is often described as "Input Data Inversion".
In the Renesas document this can be seen by the description "LSB first".
- Finally, the calculated CRC must also be inverted. Described as "Output Data Inversion".

These parameters are also often described as REV_IN and REV_OUT. Is it possible to set these for the CC1352?

Best regards,

Franz

0 Arthur R☑️ over 1 year ago in reply to Franz Schellhase

TI__Mastermind 18197 points

Franz,

So, to make sure, what is the desired CRC on their side, can they provide a packet example? For instance, are they getting CRC=0x80C4 right now, and want CRC=0xC480 ?

Regards,

Arthur

0 Arthur R☑️ over 1 year ago in reply to Arthur R☑️

TI__Mastermind 18197 points

Hi Franz,

Any update on that request?

Regards,

Arthur

0 Franz Schellhase over 1 year ago in reply to Arthur R☑️

TI__Expert 3605 points

Hi Arthur,

I'll get back to you soon, in case this is still relevant after Zack's reply to question 3.

Thanks,

Franz

0 Franz Schellhase over 1 year ago in reply to Franz Schellhase

TI__Expert 3605 points

Hi Arthur,

Here is an example packet:

0x04 0x04 0x06 0x01

If the CRC is now calculated according to the previously described procedure, the following result is obtained:
0x54D4

In our telegram, the high byte and low byte are then swapped, so that the following is finally sent:

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

You can also reproduce the CRC calculation with the following tool:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

Settings:
- CRC-16
- Custom
- Input and output reflected
- Polynomial: 0x1021
- Initial Value: 0x0
- Final Xor Value: 0x0

Thank you for your effort.

Best regards,

Franz

0 Arthur R☑️ over 1 year ago in reply to Franz Schellhase

TI__Mastermind 18197 points

Hi Franz,

Thanks for the info. We might have a solution, and I will contact you by direct message.

Regards,

Arthur

Sub-1 GHz

Sub-1 GHz forum

CC1312R: CRC calculation