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: Tx/Rx turnaround

Part Number: CC1200


I am having a problem with the CC1200.  My application is a mobile unit transmitting

data to a base station.  Since a high data rate and accuracy are important I would

like to transmit at 1.25 Mb/sec and have the base station ack/nak each packet.  When

sending data one way (mobile to base station) the data packets have about a 1% error

rate (240-byte packets). Good but not good enough.

When I try to send back an ack/nak packet (base station to mobile) , the ack/nak

packet always has isolated but multiple bit errors (16-byte packets).

 

 The sequence for the mobile unit is:

 1) Reset the CC1200 and load the registers.

 2) Manually calibrate.

 3) Transmit 240 bytes.  (Multiple fills to the Tx FIFO required.)

 4) When Tx complete, load the registers with Rx values and go from Tx to Rx.

 5) When Rx complete, read Rx FIFO, check for Rx FIFO errors.

 6) Load the registers with Tx values and go to Tx. Back to step 3.

 

 The base station sequence is:

 1) Reset the CC1200 and load the registers.

 2) Manually calibrate.

 3) Go to Rx. (Multiple Rx FIFO reads required.)

 4) When Rx complete, load registers with Tx values and go to Tx.

 5) Load the Tx FIFO and transmit 16-byte ack/nak packet.

 6) When Tx complete, load the registers with Rx values and go to step 3.

 

Although the sequence is written as a loop, I have been debugging the first pass. 

That is, the mobile is set to breakpoint after the Rx FIFO is read.

The timing sequence appears perfect (using SPI bus scope) but the CRC is never good

and there are random but isolated bit errors.  I have tried adding delays before

sending the ack/nak, going through idle rather than going directly from Rx to Tx and

recalibrating in idle, whitening on/off, but nothing makes an improvement

(recalibrating seemed to be worse).

I know that I am pushing the limit on data rate and Rx/Tx turnaround time but I am

staying within the CC1200 specifications. Any ideas?

 

All of the radio control registers where determined and tested by using SmartRF

Studio 7.

Mobile Registers:

// RX filter BW = 1666.7 kHz

// Address config = No address check.

// Fixed packet length = 240

// Symbol rate = 625 kHz

// Carrier frequency = 915 MHz

// Bit rate = 1250 kbps

// Packet bit length = 0

// Manchester enable = false

// Modulation format = 4-GFSK

// Packet length mode = Fixed

// Deviation = 400 kHz

static const cc1200::RegisterSetting_t CC1200SettingsTable[]=

{

  {IOCFG2,            0x06},

  {IOCFG0,            0x02},  // Tx FIFO interrupt

  {SYNC_CFG1,         0x88},  // 3 sync bytes

  {DEVIATION_M,       0x47},

  {MODCFG_DEV_E,      0x2F},

  {DCFILT_CFG,        0x1E},

  {PREAMBLE_CFG1,     0x10},  // 2 byte preamble = 0xAA

  {PREAMBLE_CFG0,     0x8A},

  {IQIC,              0x00},

  {CHAN_BW,           0x01},

  {MDMCFG1,           0x42},

  {MDMCFG0,           0x05},

  {SYMBOL_RATE2,      0xD0},

  {SYMBOL_RATE1,      0x00},

  {SYMBOL_RATE0,      0x00},

  {AGC_REF,           0x2F},

  {AGC_CS_THR,        0x01},

  {AGC_GAIN_ADJUST,   0xAE},  // -82 dBm adjustment

  {AGC_CFG2,          0x60},

  {AGC_CFG1,          0x12},

  {AGC_CFG0,          0x84},

  {FIFO_CFG,          0x49},  // 54 byte threshold in Tx FIFO

  {SETTLING_CFG,      0x03},  // manual calibration, 75/30 usec settling

  {FS_CFG,            0x12},

  {PKT_CFG2,          0x00},

  {PKT_CFG1,          0x43},

  {PKT_CFG0,          0x00},  // 0x20 for variable packet length

  {RFEND_CFG1,        0x3F},  // 0x0F to go to Idle after ack

  {RFEND_CFG0,        0x30},  // 0x30 to go to Rx after packet

  {PA_CFG1,           0x7F},  // (3F + 1)/2 - 18 dBm = 14 dBm

  {PKT_LEN,           0xF0},  // 240 byte fixed packet

  {FREQOFF_CFG,       0x23},

  {MDMCFG2,           0x00},

  {FREQ2,             0x5B},

  {FREQ1,             0x80},

  {IF_ADC1,           0xEE},

  {IF_ADC0,           0x10},

  {FS_DIG1,           0x04},

  {FS_DIG0,           0xA3},

  {FS_CAL1,           0x40},

  {FS_CAL0,           0x0E},

  {FS_DIVTWO,         0x03},

  {FS_DSM0,           0x33},

  {FS_DVC0,           0x17},

  {FS_PFD,            0x00},

  {FS_PRE,            0x6E},

  {FS_REG_DIV_CML,    0x1C},

  {FS_SPARE,          0xAC},

  {FS_VCO0,           0xB5},

  {IFAMP,             0x0D},

  {XOSC5,             0x0E},

  {XOSC1,             0x03},

  {PARTNUMBER,        0x20},

  {PARTVERSION,       0x11},

  {MODEM_STATUS1,     0x10},

};

 

static const cc1200::RegisterSetting_t RxSettings[]=

{

  {PKT_LEN,           0x10},  // 16 byte fixed packet length

  {FS_DIG1,           0x07},  // determined by SmartRF Studio

  {FS_DIG0,           0xA0},  // determined by SmartRF Studio

  {PKT_CFG1,          0x03}   // whitening off for ack/nak

};

 

static const cc1200::RegisterSetting_t TxSettings[]=

{

  {PKT_LEN,           0xF0},  // 240 byte fixed packet length

  {FS_DIG1,           0x04},  // determined by SmartRF Studio

  {FS_DIG0,           0xA3},  // determined by SmartRF Studio

  {PKT_CFG1,          0x43}   // whitening on for data packet

};

 

 

Base Station Registers:

// RX filter BW = 1666.7 kHz

// Address config = No address check.

// Fixed packet length = 240

// Symbol rate = 625 kHz

// Carrier frequency = 915 MHz

// Bit rate = 1250 kbps

// Packet bit length = 0

// Manchester enable = false

// Modulation format = 4-GFSK

// Packet length mode = Fixed

// Deviation = 400 kHz

static const cc1200::RegisterSetting_t CC1200SettingsTable[]=

{

  {IOCFG2,            0x06},

  {IOCFG0,            0x00},  // interrupt on Rx FIFO > threshold

  {SYNC_CFG1,         0x88},  // 3 sync bytes

  {DEVIATION_M,       0x47},

  {MODCFG_DEV_E,      0x2F},

  {DCFILT_CFG,        0x1E},

  {PREAMBLE_CFG1,     0x10},  // 2 byte preamble = 0xAA

  {PREAMBLE_CFG0,     0x8A},

  {IQIC,              0x00},

  {CHAN_BW,           0x01},

  {MDMCFG1,           0x42},

  {MDMCFG0,           0x05},

  {SYMBOL_RATE2,      0xD0},

  {SYMBOL_RATE1,      0x00},

  {SYMBOL_RATE0,      0x00},

  {AGC_REF,           0x2F},

  {AGC_CS_THR,        0x01},

  {AGC_GAIN_ADJUST,   0xAE},  // -82 dBm adjustment

  {AGC_CFG2,          0x60},

  {AGC_CFG1,          0x12},

  {AGC_CFG0,          0x84},

  {FIFO_CFG,          0x49},  // 73+1 byte threshold in Rx FIFO

  {SETTLING_CFG,      0x03},  // manual calibration, 75/30 usec settling

  {FS_CFG,            0x12},

  {PKT_CFG2,          0x00},

  {PKT_CFG1,          0x43},

  {PKT_CFG0,          0x00},  // 0x20 for variable length

  {RFEND_CFG1,        0x3f},  // 0x3F for stay in Rx mode, no timeout

  {RFEND_CFG0,        0x30},  // 0x30 for Rx after Tx

  {PA_CFG1,           0x7F},  // (3F + 1)/2 - 18 dBm = 14 dBm

  {PKT_LEN,           0xF0},  // 240 byte fixed packet length

  {FREQOFF_CFG,       0x23},

  {MDMCFG2,           0x00},

  {FREQ2,             0x5B},

  {FREQ1,             0x80},

  {IF_ADC1,           0xEE},

  {IF_ADC0,           0x10},

  {FS_DIG1,           0x07},

  {FS_DIG0,           0xA0},

  {FS_CAL1,           0x40},

  {FS_CAL0,           0x0E},

  {FS_DIVTWO,         0x03},

  {FS_DSM0,           0x33},

  {FS_DVC0,           0x17},

  {FS_PFD,            0x00},

  {FS_PRE,            0x6E},

  {FS_REG_DIV_CML,    0x1C},

  {FS_SPARE,          0xAC},

  {FS_VCO0,           0xB5},

  {IFAMP,             0x0D},

  {XOSC5,             0x0E},

  {XOSC1,             0x03},

  {PARTNUMBER,        0x20},

  {PARTVERSION,       0x11},

  {MODEM_STATUS1,     0x10},

};

 

// Register settings for Tx

static const cc1200::RegisterSetting_t TxSettings[]=

{

  {PKT_LEN,           0x10},  // 16 byte fixed packet length

  {FS_DIG1,           0x04},  // determined by SmartRF Studio

  {FS_DIG0,           0xA3},  // determined by SmartRF Studio

  {PKT_CFG1,          0x03}   // whitening off for ack/nak

};

 

// Register settings for Rx

static const cc1200::RegisterSetting_t RxSettings[]=

{

  {PKT_LEN,           0xF0},  // 240 byte fixed packet length

  {FS_DIG1,           0x07},  // determined by SmartRF Studio

  {FS_DIG0,           0xA0},  // determined by SmartRF Studio

  {PKT_CFG1,          0x43}   // whitening on for data packet

};

  • Hello Ed,
    you are pushing the limits of CC1200 but more than knowing your registers setup should be interesting to know what HW you are using (custom board or SDK), antenna type, the distance between the base station and the node(s) and so on.

    Do you need packet mode or transparent mode? Are they both OK for your application?


    Another useful information is to know if you wrote your own 802.15.4g SW stack or if you are using TI or other libraries.

    But difficult to help you without some testing.

    Kind regards,
    Massimo

  • Hi Massimo,
    I am using two CC1200/TrxEB eval boards in the 902-928 MHz ISM band with the supplied whip antennas. The transmit distance is short (bench setup) of about 1 meter (although works at 500 meters, too). The code started as the CC120x_EasyLink sample code (packet mode). With one eval board setup to Tx and the other to Rx, 240-byte packets, 1.25 Mbps, 4-GFSK, the transmission has <1% CRC failure rate (pretty good). This is with one manual calibration on startup.
    When the code is modified to Tx and then Rx, to ack/nak the packets, the timing seems right (by logic analyzer) but the Rx FIFO has bits errors. Adding delays and/or going into idle between Tx and Rx doesn't appear to help. The application is a for a high data rate in one direction but the data needs to be accurate, hence the ack/nak to allow for re-transmission. (Wouldn't transparent mode defeat the advantages of using the CC1200?) Do you/anyone have sample code that runs the CC120x in transceiver mode?
    Best Regards,
    Ed
  • I don't understand what HW you have.

    There is CC1200-DK: it has 2 mother boards (with LCD and buttons), 2 daughter boards with CC1200 on board, 2 antennas and 1 MSP430 debug interface (the mother boards use that MCU). Do you have it?

    If you have it: when you reported the packet error rate, it was the result using the boards with PER Test (Main menu 1/3)?
    Because in the lab is quite normal to obtain 0 packet errors... I remember only some problems using car remotes or in the field near high voltage tracks. Nothing else similar to your results.

    If the results you reported come from a different HW or using your SW... it is possible and as a first result is not so bad.
  • - You have different FS_DIG1 settings for packets going from the base station to the mobile unit vs. the opposite direction. Why? This could explain the difference in BER.

    - Whitening is OFF in one direction and ON in the other. Again, this could explain the discrepancy.
  • - As pointed out in this thread: You should use the same setting for both directions, at least when you use the same datarate. What is the outcome if you do this?
    - What happens if you use a lower datarate with the settings from SmartRF Studio? (A check of your software etc to see if it's something else that the radio settings that cause something)
    - Would you be able to use 1 Mbps?
  • Hi TER,

    Thanks for the response.  I am using the register settings generated by SmartRF Studio and yes, they are different in Tx and Rx. (This surprised me since that is not the case in other symbol rates.) But, I will try running with them the same on both sides. Of course, the packet size changes depending on direction.  I will also try slower data rates.  I have not wanted to do this because 1.25 Mbps is appears to allow a 1 Mbps throughput which just satisfies the requirement for this application but a slower rate will verify the code is working correctly.

    Best,

    Ed

  • Hi Massimo,
    Yes, the hardware is as you described. I used SmartRF Studio and EasyLink to generate the register settings and test communication in one direction. Zero packets errors were common. Longer packets (240 bytes) did produce more bit errors but still less than 1% of the packets had a CRC error. I have been very happy with the one-way communication. I am having problems when I try to return an ack/nack. Utlimately, I would like to retranmit bad packets to get closer to 100% accuracy.
    Best,
    Ed
  • I have to admit that I don't looked into the differences. Some of the FS_* registers are different in Rx and Tx and should be different.
  • Whitening is enabled for longer 240 byte packets and disabled for the shorter ones. What happens if you enable it in both directions?
  • Hi Andrew,

    Whitening helped the BER on the long packets and may help on the shorter packets.  It was tried both ways but turned off just so it would be easier to verify the data in the ack/nak packet.

    Ed

  • Hi TER,
    As a follow up, I used SmartRF Studio to generate the configuration registers for 2-FSK and a 500K symbol rate, keeping the code, packet length, and whitening the same and I get good results. (The ack packet comes back without errors and a good CRC.) Have you, or anyone, been able to get the CC1200 to do two-way communications using 4-GFSK at a 625KHz symbol rate?
    Ed
  • Hi TER,
    I was able to get the CC1200 working in two-way mode using 4-GSFK at 500KHz symbols per second. I am wondering if I messed up with SmartRF Studio 7. Since the 625KHz symbol rate isn't accepted through the GUI, I manually went in and changed the symbol rate registers, 0xD0, 0x00 and 0x00 respectively. Is it possible that SmartRF Studio did not recompute the other configuration registers when the symbol rate was changed? Keep in mind, one way transmission works and the problem doesn't show up until two-way transmission is attempted. But without understanding the internal workings, it is hard for me to imagine which registers should be adjusted.
    Best,
    Ed
  • It looks like you have to do some minor adjustments, see this post:
    e2e.ti.com/.../330911
  • TER, thank you. (And thanks to Sverre!) The changes that made 4-GFSK, 1.25 Mbps, work in two-way communication are:

    DEVIATION_M = 0x47 to 0xC3, changed the deviation from 400 KHz to 550 KHz
    AGC_CFG2 = 0x60 to 0x20, changed Zero-IF mode to Normal operating mode
    FS_DIG0 = 0xA3 to 0xAB, changed RX_LPF_BW from 200KHz to 400 KHz

    The only registers that change with Tx/Rx are:
    PKT_LEN (in my application packets are bigger in one direction)
    FS_DIG1 = 0x07 in Rx and 0x04 in Tx

    Thanks again for everyone's help.
    Ed