CC1125: Consistent reception error in 4-GFSK (0x88 bytes)

Part Number: CC1125


We are experiencing a major problem with the CC1125 in 4-GFSK mode with consistent byte errors even at very high SNR. We observe with communication between two TI eval boards in SmartRF that when disabling the data whitening (for debug purposes), data bytes 0x88 are never received correctly. It looks like it corresponds to transitions between -fdev/3 +fdev/3. 100% of the transmissions are wrong!

This leads in the application with the whitening to a BER floor of around 4e-5. We cannot go below even with a very good SNR. But very annoying is that the same data payload can be sent multiple times, but never go through a single time.

The bitrate is 133Kbps and the configuration is as follows. 


static const registerSetting_t registersSetting2[] = {
  {CC112X_IOCFG3,            0xB0},
  {CC112X_IOCFG2,            0x06},
  {CC112X_IOCFG1,            0xB0},
  {CC112X_IOCFG0,            0x40},
  {CC112X_SYNC_CFG1,         0x07},
  {CC112X_DEVIATION_M,       0x68},
  {CC112X_MODCFG_DEV_E,      0x2E},
  {CC112X_DCFILT_CFG,        0x04},
  {CC112X_PREAMBLE_CFG1,     0x18},
  {CC112X_FREQ_IF_CFG,       0x00},
  {CC112X_IQIC,              0x00},
  {CC112X_CHAN_BW,           0x01},
  {CC112X_MDMCFG0,           0x05},
  {CC112X_SYMBOL_RATE2,      0x9B},
  {CC112X_SYMBOL_RATE1,      0x3D},
  {CC112X_SYMBOL_RATE0,      0x08},
  {CC112X_AGC_REF,           0x3C},
  {CC112X_AGC_CS_THR,        0xEC},
//  {CC112X_AGC_CFG3,          0x83},
//  {CC112X_AGC_CFG2,          0x60},
  {CC112X_AGC_CFG1,          0xA9},
  {CC112X_AGC_CFG0,          0xC0},
  {CC112X_FIFO_CFG,          0x00},
  {CC112X_SETTLING_CFG,      0x03},
  {CC112X_FS_CFG,            0x12},
  {CC112X_PKT_CFG1,          0x45},
  {CC112X_PKT_CFG0,          0x20},
  {CC112X_PA_CFG0,           0x03},
  {CC112X_PKT_LEN,           0xFF},
  {CC112X_IF_MIX_CFG,        0x00},
  {CC112X_TOC_CFG,           0x0A},
  {CC112X_FREQ2,             0x56},
  {CC112X_FREQ1,             0xA6},
  {CC112X_FREQ0,             0x66},
  {CC112X_IF_ADC0,           0x05},
  {CC112X_FS_DIG1,           0x00},
  {CC112X_FS_DIG0,           0x5F},
  {CC112X_FS_CAL0,           0x0E},
  {CC112X_FS_DIVTWO,         0x03},
  {CC112X_FS_DSM0,           0x33},
  {CC112X_FS_DVC0,           0x17},
  {CC112X_FS_PFD,            0x50},
  {CC112X_FS_PRE,            0x6E},
  {CC112X_FS_REG_DIV_CML,    0x14},
  {CC112X_FS_SPARE,          0xAC},
  {CC112X_XOSC5,             0x0E},
  {CC112X_XOSC3,             0xC7},
  {CC112X_XOSC1,             0x07},
  {CC112X_END_OF_TABLE,      0x00},

But this behavior occurs even with the 200kbps configuration given by SmartRF as shown on the following figure (out of the box).

We can also observe that for the 133kbps configuration, that the error rate depends a bit on the RX filter bandwidth. In the first figure, we can barely send one or two correct bytes (0x88) per packet, while on the second one, it is more 2 or 3.

Is it a know problem in the CC1125 for the 4-GFSK? Is there any wrong with the configuration that we used? We are looking for any help and any hint. Thank you.

  • Hi,

    I will first need to try and replicate this issue.

    I will get back to you next week once I have done this (so that you are aware that we are working on it).



  • Hi Zack,

    Thank you for the reply and let me know if you need any info for your tests.



  • Just want to confirm the procedure,

    1. Use smartRF Studio with 2 CC1125 kits
    2. Setup 200kbps, 4-GFSK max throughput (869MHz)
    3. one module in Packet RX mode
    4. one module in Packet TX mode with payload data full of 0x88
  • Hi Didier,

    I have had issues finding a CC1125 kit to test. Resources are a little constrained at the moment during the summer months but I will get back to you as soon as I can. Apologies for the delay in responding to this.

  • Hi Zack,

    Thank you for heaving tried on your kits and for your message. I hope you can find some time soon to move forward on this issue.

    Looking forward hearing from you,



  • Have you tested with FREQOFF_CFG = 0x23?

  • Thank you, we tried with FREQOFF_CFG = 0x23 but we don't observe any improvement compared to our original code that used FREQOFF_CFG = 0x20. 

    As we have also a very accurate crystal, we also tried FREQOFF_CFG = 0x00 (disable update), but not improvement as well.

  • For 2-GFSK, using FREQOFF_CFG = 0x23 typically help when sending long sequences of either '1 or '0' after the sync word. This is because the modem needs transitions to keep the bit sync, with no transitions it starts to loose the sync. the 0x23 setting slows down the loop. It could seem that 4-GFSK something else. Does it matter where you put the 0x88 sequence? (meaing if you use all 4 deviation levels before the 0x88)

  • The data shown on the screen shots above are just examples for investigation. But indeed, the problem occurs what ever is before the short sequence of data. We observed this at first because we were surprised that one packet was never received correctly. And then, doing extensive tests by sending million of packets, we discovered that the errors occur everywhere in our packet of 240 bytes (head, middle, tail) but always around a short sequence of 0x88 or similar. Whatever is before. At least we couldn't identify anything consistent just before the error. The only thing really constant for the hundreds of faulty packets, is this short sequence of 0x88 (or similar, odd bits constant sequence). 

  • Hi Didier,

    I've managed to locate some CC1125 EMs and can recreate the issue on our end (also with the 200kbps default settings).

    I've reached out to the designers for some more insight into this - I will update you when they get back to me.



  • a short sequence of 0x88 or similar.

    Do you have a list of patterns that cause issues since it sounds like it's not only 0x88? 

  • Please see the attached text file that has many failure patterns. The first pattern of the file is 

    {'errors': ['0x15'],
      'idx': 1,
      'locations': [24],
      'rx': [['0x82', '0xae', '0x8c', '0x3e', '0xf4', '0x6', '0x45', '0x87', '0x6d', '0x70', '0xdb']],
      'tx': [['0x82', '0xae', '0x8c', '0x3e', '0xf4', '0x6', '0x45', '0x87', '0x6d', '0x70', '0xce']],
      'type': 'rx'},

    that has one error and where:

    errors = 0x15 is a bit xor between receive and transmit bytes.

    locations are byte number where there is the error

    rx and tx are 10 bytes before the error of received and transmitted frames (the last byte is where there is the error), 0xbd != 0xce.

    You can see that most of the errors pattern (rx xor tx) is 0x55. Same bits. Then, we found by chance that 0x88 create errors all the time, but you can see from the file that there are infiit patterns that fail.