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: CC1125 RF

Part Number: CC1125

Hi,

I'm using 2 TRXEB (CC1125 + MSP430) and sending 100 bytes of fixed data from 1 set to another set,

On receiving side I'm using TRXEB with Smart RF studio 

Observation - On receiving side 72 bytes are correct  but rest of the bytes are corrupted and showing CRC failure, I want to know Is there any register setting to send all data correctly?

Note - "If Smart RF studio used for Tx and Rx, data is correct"

  • To be able to answer that question you need as a minimum to provide an example of the data you are trying to send/ receive. 

  • As per RF studio 

    10:10:59.842 | 64 | 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 e7 2a 38 34 ae f1 7a 14 ad e6 96 55 0a cd 51 55 52 35 4a 9d 65 5b a1 ad 5f 4c 93 | -78 CRC error

    above data is in hex format and upto value 48-49  is correct and after that its corrupted upto 100 bytes 

  • If I understand correctly, everything works fine with Studio  for TX and RX, but with your custom TX code + Studio RX, you receive wrong data. Is that correct?

    If yes, please share your code showing how your write your packet to the TX FIFO and do the TX.

    Siri

  • Yes, your understanding is correct, 

    Code is simple

    for(i=1; i<(Buff_Size+1); i++)
    {
    Tx_buff[i] = i;
    }
    trxSpiCmdStrobe(CC112X_SFTX);         // Flush Tx buffer
    Delay(60000);//

    cc112xSpiWriteTxFifo(Tx_buff, (Buff_Size+1));      // buff_size + frame lenght size at start of frame

    // Strobe TX to send packet
    trxSpiCmdStrobe(CC112X_STX);               // Change Tx state

    Delay(60000);
    trxSpiCmdStrobe(CC112X_SIDLE);           // Change Ideal State

  • buff_size =100

    I

    Initially set the config register as below

    static const registerSetting_t preferredSettings[] ={
    {CC112X_IOCFG3, 0xB0},
    {CC112X_IOCFG2, 0x06},
    {CC112X_IOCFG1, 0xB0},
    {CC112X_IOCFG0, 0x40},
    {CC112X_SYNC_CFG1, 0x08},
    {CC112X_DEVIATION_M, 0x3A},
    {CC112X_MODCFG_DEV_E, 0x0B},
    {CC112X_DCFILT_CFG, 0x1C},
    {CC112X_FREQ_IF_CFG, 0x33},
    {CC112X_IQIC, 0xC6},
    {CC112X_CHAN_BW, 0x0A},
    {CC112X_MDMCFG0, 0x05},
    {CC112X_SYMBOL_RATE2, 0x6F},
    {CC112X_SYMBOL_RATE1, 0x75},
    {CC112X_SYMBOL_RATE0, 0x10},
    {CC112X_AGC_REF, 0x20},
    {CC112X_AGC_CS_THR, 0x19},
    {CC112X_AGC_CFG1, 0xA9},
    {CC112X_AGC_CFG0, 0xCF},
    {CC112X_FIFO_CFG, 0x00},
    {CC112X_SETTLING_CFG, 0x03},
    {CC112X_FS_CFG, 0x12},
    {CC112X_PKT_CFG0, 0x20},
    {CC112X_PA_CFG0, 0x7E},
    {CC112X_PKT_LEN, 0xFF},
    {CC112X_IF_MIX_CFG, 0x00},
    {CC112X_FREQOFF_CFG, 0x22},
    {CC112X_FREQ2, 0x56},
    {CC112X_FREQ1, 0xCC},
    {CC112X_FREQ0, 0xCC},
    {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_PARTNUMBER, 0x58},
    {CC112X_PARTVERSION, 0x21},
    {CC112X_MODEM_STATUS1, 0x10},
    {CC112X_XOSC_TEST1, 0x00},
    };

    and enable the manual calibration and finally send data

  • How long is delay(6000)? and why do you have a delay at all?

    With settings from SmartRF STudio, the radio is programmed to go back to IDLE once the packet is sent, and you do not have to send a SIDLE strobe.

    Your results indicates that you are exiting TX mode by manually BEFORE the complete packet has been sent. 

    This is why the end of the packet is not received correctly (you are not allowing your transmitter to send more than the first part of the packet).

    Siri

  • yes, 

    Ideal state was issue, Now its working fine after your suggestion

    Thanks Siri