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.

CC1120: There seems to be an error in the RX packet.

Part Number: CC1120

hello. experts

I an a  person who is experimenting with the CC1120 in the environment shown in the picture below.

The CC1120 module acts as a TX and is composed of an mcu and a CC1120 chip, the CC1120 chip is controlled by the MCU.

The CC1120 module is manufactured, not a commercial product.

BOOSTXL-CC1120-90 is used as RX and is a commercial product of TI.

BOOSTXL-CC1120-90 interworks with SMART RF so that I can check packets recived through Packet RX of SMART RF in my PC.

Currently, the payload being TX in CCC120 module is 0x54,0x45,0xE2,0x9A,0xF9,0x44.

However in SmartRF, packets like the picture below ar being received. 

The part marked with a red sqare shows the payload transmitted by the CC1120 module.

However , ox44 was not received and many other data that I did not write to the TX FIFO were received.

A CRC error is also ouput.

If you know of anything I haven't checked or know of a fix for this. I'd appreciate it if you could let me know.

As additional data, I will attach the code to write the payload to the TX fifo and the communication environment.

1. CC1120 module Code to write payload to TX FIFO : 

I know that the CC1120 chip itself automatically adds Preamble, Sync word, and CRC, so I wrote only the data to be transmitted, that is, the payload, in the TXFIFO.

2. Communication environment

Thank you for reading this long post. Any help would be appreciated.

- By kim -

  • Please share your configuration registers.

    If you are configuring the CC1120 for variable packet length mode (which is the default when using settings from SmartRF Studio) , you need to write the length byte to the FIFO as well.

    0x06, 0x54,0x45,0xE2,0x9A,0xF9,0x44

    BR

    Siri

  • Thank you very much. Check it out I set it to variable packet length mode, and as you said, as a result of adding the length to the beginning of the packet, the data I TX was properly RX