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.

CC1200 FEC causes RX Processing Delay

Other Parts Discussed in Thread: CC1200

We are using a CC1200 with packet handling support and FEC. Using the PKT_SYNC_RXTX signal on GPIO3 as an indicator, we notice that the received packet is delayed about 3.7msec from when the transmitted packet concluded. Further investigation shows that two related settings are FEC and fixed/variable packet length mode.  If the packet length mode is changed to be fixed, then the delay is reduced to 2.04msec. My theory is that since the packet length byte, in a variable length packet mode, is encoded within the FEC, the receiver cannot tell the length until the packet is decoded and therefore another method (may be carrier sense) must be used to detect the packet end. If FEC is eliminated, then the delay is about 1.1 msec, no matter what mode of packet length.

Can you address these delays? Why the 1 msec delay? Whey the additional delay if FEC is used, and why the extra lond delay of 3.7msec if FEC is used with a variable length packet?

  • Hi Don

    What data rate are you using and how many bytes are you packets?

  • The data rate is 9600 bps. The packet sizes are varied. Sometimes they are fixed and sometimes they are variable and have a length byte.  Size could be 1 byte plus CRC to 67 bytes plus CRC.

    Thank you

  • Hi Don

    This is not caused by the fact that you use either fixed or variable length. The reason why you see a difference is caused by the total length of the payload. In order for the FEC algorithm to work, it has to fill/padd the payload with tail bits depending if it is a odd or even number of bytes in the payload. Changing between variable and fixed packet length will change the total number of bytes in the payload, hence influence the number of padding bits for the FEC.