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.

Protection Against Erroneous Data using the CC1120

Other Parts Discussed in Thread: CC1120, CC1101

I have a customer that is implementing the CC1120 that during some testing received incorrect data in the FIFO and the CRC bit was not set as expected.  They have implemented application logic to prevent this in the future but are looking for some additional recommendations to prevent any other potential application data errors...

"I have protected against this condition, but I want to make sure there are no other conditions for erroneous data that I should protect against.  In particular, what if an over the air collision causes the cc1120 payload data to become corrupt, partially or entirely, and the CRC-16 value happens to match due to a 1/1024 chance for a 16 bit value.

This is the first radio product that I have implemented in which the encoding and decoding are done within the radio chipset.  This is also the first radio that I have worked with that does not use UART data over the air, which inherently checks each byte for framing errors, and filters out a large quantity of erroneous data bytes due to this.  So, guidance in these areas are appreciated…thanks."

Any input to help would be appreciated

  • Gregory, 

    These are good questions, for FIFO enabled transceivers like the CC1120 here is a list of things that can happen.

    • False negative, CRC frame error. This happens is the corrupt byte is only byte that contained the CRC check sum but the payload is otherwise ok.
    • False positive, the CRC frame ok but it is in fact bad. This happens because the CRC check is only 16 bits or 32 bits depending on setting. 
    • If you use variable length packets, if the length byte is has an error the FIFO will get corrupted.
    • Sometimes on the older CC1101 type radio it would randomly find a Sync word inside pure noise and start filling up the FIFO. This can theoretically still happen on the CC1120 but it is very uncommon. 

    Please read the errata on the CC1120, the silicon in the market today needs a calibration patch in software, if this patch is not considering there is a change the PLL does not lock and it does not receive you packet at all.

    That is the most common thing I can think of.

    Regards,
    /TA

  • Note also that has a collision detector. See User Guide (www.ti.com/lit/swru295), section 6.10