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 RX: using sync word detecion in combination with synchronous serial mode

Other Parts Discussed in Thread: CC1120, CC1020

Hi TER,

I'm trying to get the CC1120 to operate as follows:

Sync serial output (clock and data) on GPIO when sync word is detected

- Clock and data are idle until sync word is detected

- Clock and data outputs 12 bytes payload.

- Clock and data idle again until next sync word is detected.

I've set:

PKT_LEN = 0x0C

PKT_CFG2 = 0x05, PKT_CFG1 = 0, PKT_CFG0 = 0

However once the first sync word is detected the CC1120 continues to send clock and data continuously (i.e. doesn't stop after 12 bytes).

What am I missing?

  • Hi Mark

    Is there any particular reason for you to use synchronous serial mode? This mode is most often used for applications that needs backward compatibility. Synchronous serial mode supports sync word search, but after sync is found and the radio starts to clock out data, the application has to handle the rest.(e.g. end transmission)

    It seems to me it would be a better idea to use the radio in normal FIFO mode. Then the packet engine wil do al this for you. The radio will then search for sync word and when this is found it will get the rest of the packet (12 bytes of payload) and put this in the RXFIFIO ready for you to read out through the SPI interface. The PKT_LEN register is used in normal or FIFO mode in two ways. If you use variable packet length the PKT_LEN register states the maximum allowed length of the packets, while in fixed packet length it states the fixed packet length. 

  • Hi Martin,

    We do have variable length messages, the length is embedded in the message but not in a way that is easy for the CC1120 to see.

    If you update PKT_LEN while the CC1120 is decoding a message will is use the new value immediatly?

    e.g. Say the PKT_LEN is 10 and the chip finds a sync and starts decoding. When it gets to the 4th byte we decide that the message is actually 15 bytes long and so we update PKT_LEN. Does the chip read upto 10 or the new value 15?

    Regards,

    Mark.

  • Sorry I should have answered your first question. The CC1120 is replacing a CC1020.

    In another thread I was told that the CC1120 gives better performance if it does the sync detect so I was going to let it do this bit then let my application's legacy (CC1020) code do the rest.

    Say I want to operate continuosly in RX mode with sync detect and sync serial output (i.e. never idle or Tx) as follows:

    - Rx clock and data idle until sync detected.

    - application reads clocked data out of the CC1120 until it deems that is has reached the end of the message.

    - application follows 'a procedure' to put the CC1120 back in to Rx with clock and data idle until sync detected.

    My questions are:

    1. What would be the most convinient 'procedure' to follow above? Do I have to come out of Rx mode then back in?

    2. Would I see better performance if I kept all the above inside the CC1120 (i.e. not just sync detect, also use the FIFO and PKT_LEN)

    3. My question above about updating PKT_LEN on the fly.

    Thank you for your help on this,

    Mark.

  • Hi Mark

    To clarify: In synchronous serial mode you can let the radio automatically search for sync word. But after sync word is detected the radio will output whatever data that follows the sync word out on the GPIO. Regardless of what the PKT_LEN register is set to. It is up to the application to determine when you have received enough bytes. In order to stop the data flow and serial clock output, you have to take the radio into IDLE mode and then re enter RX.

    So to answer your questions:

    1. Application has to determine when you have received enough data. You have to take the radio out of RX and then back in order to start a new sync word search.
    2. I would reccomend to use the CC1120 packet engine (FIFO mode) if your packet format allows it. This will offload your MCU and simplify you SW code. See section 7.1 of the user's guide for packet format.
    3. The PKT_LEN register can be updated on the fly, but it does not apply fir synchronous serial mode. See section 7.1.4 on example of how to use this. 
  • Hi Martin,

    Just to confirm on point 2 above:

    As I read your answer there is no performance gain on the radio side of things if I use the internal packet engine for the message body (unlike sync detection).

    The only benefit of using the FIFO is to make it easier for the external application to extract the packet (fast dump over SPI on completion rather than drawn out clock and data in real time).

    Cheers,

    Mark.

  • Just re-read my comment above: "the only benefit...." - didn't mean to sound like I was poo-pooing the chip I appreaciate this is quite a significant help on the application side.

    I just wanted to make sure that the internal packet decoder isn't doing a better job of decoding than an external app could with sync serial.

    Also on point 1 above will SIDLE followed by SRX do the job?

  • No offense taken ;)

    The main purpose of the packet engine is like I said to offload the MCU. This feature frees the MCU to do other tasks or helps to reduce current consumption by letting the MCU sleep while the radio deals with the packet handling.  RF performance is the same regardless of what mode (FIFO or synchronous serial mode) you use.

    An SIDLE strobe followed by SRX will do the job.

  • Thanks again for the help Martin, much appreciated.

    Regards,

    Mark.

  • You're welcome, and good luck.