• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 55 subscribers
  • Views 321 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

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

Didier Nicoulaz
Prodigy 10 points
Part Number: CC1125

Hello,

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.

  • 0
    TI__Genius 10255 points

    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).

    Regards,

    Zack

  • 0 in reply to ZC
    Prodigy 10 points

    Hi Zack,

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

    Regards,

    Didier

  • 0 in reply to Didier Nicoulaz
    Prodigy 10 points

    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
  • 0 in reply to Didier Nicoulaz
    TI__Genius 10255 points

    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.

  • 0
    Prodigy 10 points

    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,

    Regards,

    Didier

  • 0 in reply to Didier Nicoulaz
    Genius 5610 points

    Have you tested with FREQOFF_CFG = 0x23?

  • 0
    Prodigy 10 points

    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.

  • 0 in reply to Didier Nicoulaz
    Genius 5610 points

    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)

  • 0 in reply to TheGhostOf
    Prodigy 10 points

    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). 

  • 0 in reply to Didier Nicoulaz
    TI__Genius 10255 points

    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.

    Regards,

    Zack 

  • 0 in reply to Didier Nicoulaz
    Genius 5610 points
    Didier Nicoulaz said:
    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? 

  • 0 in reply to Didier Nicoulaz
    Prodigy 10 points

    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.

    failure_patterns1.txt