CRC calculation on CC1310 radio

The default use is to let the radio calculate and send CRC. This is done in the examples we have included in TI-RTOS. If you look in 23.7.2 in www.ti.com/.../swcu117f.pdf you will see that CMD_PROP_TX and CMD_PROP_TX_ADV has a field telling the radio to append CRC or not.

Hi TA,

Thank you for the information and the link for calculating the CRC.

However, for now I will go as per the information given by TER that radio calculates the CRC value before send the packet and we can add it to the packet by writing pkConf.bUseCrc = 1 in the PROP_TX and PROP_TX_ADV command.

Also at the receive end the RF driver verify that CRC is correct of not based on the pOutput structure value.

But I would like to ask a question.

Is it wise enough to calculate the CRC and add it to the payload just before the actual data goes out in the txPacket and than on the receive end to separate the CRC from the payload and calculate the CRC value of remaining data to cross check the CRC validation?

Thank you

Vikram

Hi TER,

Thank you for highlighting this information so for now if the data is not received accurately, the receiver will calculate the CRC of the data received and will show in the pOutput structure indicating nRxNok = 1.
Is my understanding correct?
Thank you
Vikram

The most efficient is to let the radio do the CRC calculations. You don't save anything by adding it to the payload as you suggest.

I would suggest that you look at the software example (packetTx, packetRx is a good start) in TI-RTOS how to do this .

Good morning TER,
I agree with your point to let the radio do the CRC calculation.
But when I enabled the "rxConf.bIncludeCrc = 1" in the smartrfsetting file in the packetRx example, radio is not able to receive any data and the status field shows meaning it is pending on the data to be fetched.

Why would this happen?
Thank you
Vikram

Hi

If you have configured the TX and RX differently when it comes to length info/header byte, if the CRC is calculated over different fields on the TX and RX etc, you will potentially get a CRC error on the receiver side:

In our rfPacketRX example we use the following config:

RF_cmdPropRx.rxConf.bAutoFlushIgnored = 1; /* Discard ignored packets from Rx queue */

RF_cmdPropRx.rxConf.bAutoFlushCrcErr = 1;   /* Discard packets with CRC error from Rx queue */

RF_cmdPropRx.pktConf.bRepeatOk = 1;

RF_cmdPropRx.pktConf.bRepeatNok = 1;

In this case, only packets with CRC OK is put in the data entry and all packets with CRC errors are removed from the RX queue and RX is restarted.

That means that you will only get a callback when packets with CRC OK is received.

Please take a look at the rfPacketTX and rfPacketRX example. This uses CRC both on the RX and TX side.

Siri