CC112x: Using to FREQOFF_EST to measure constant carrier frequency

Bjorn Strandmark

Other Parts Discussed in Thread: CC1125, CC1120, CC1121

Hi,

We have a measurement system consisting of one transmitter (txer) and one receiver (rxer). The txer sends a constant unmodulated carrier. The rxer measures the txer frequency using the frequency offset estimate available in the FREQOFF_EST registers.

The system works according to the following outline:
1)      Start txer constant unmodulated carrier
2)      Start rxer
3)      Every 20 ms: read FREQOFF_EST a number of times and calculate an average frequency offset
4)      Calculate txer frequency = rxer frequency + freq offset
5)      Stop rxer and txer
6)      Done

The procedure above works in most cases, say > 99% of the cases. However, sometimes it fails due to the fact that FREQOFF_EST returns large values (e.g. -809 and +809), even under good circumstances where we expect it to succeed.

Now to my questions:

Is the above algorithm supported by CC112x? Obviously it works in a vast majority of the cases. However, official statements from TI (see post http://e2e.ti.com/support/wireless_connectivity/f/156/t/260273.aspx) indicate the FREOFF_EST is calculated during and settled after a SYNCWORD is received. The CC112x user guide does not contain information about this.
If the above algorithm is supported, why does it not work always? Maybe some special settings are required? Please share required settings!
If the above algorithm is NOT supported, why does it work in most cases? Please also propose an alternative method.

Factors that affect the algorithm:

Lower signal strength makes the algorithm fail more often. But the threshold is still quite “high”, somewhere around -70dBm where it should work without any problems
Having the system inside a rf-shielded box seems to make the algorithm fail more often. If we open the box lid, it works, but if we close it starts failing a significant number of times.

Any help is highly appreciated!

Best regards

Björn

Keywords:

CC112x, CC1120, CC1121, CC1125, AFC, Frequency Offset Correction, FOC

over 9 years ago

0 TER over 9 years ago

TI__Guru**** 317180 points

The CC112x contains at least 3 different frequency compensation loops. One of them is based on sync search.

We haven't tested how the frequency estimation works when sending CW. Before going into details, the frequency estimate consist of two registers. The chip has no mechanism to ensure that when reading FREQ_EST1 and FREQ_EST0 that the values are from the same sample. If one sample is 0x00FF and the next is 0x0100 and if you read one byte from each sample you risk read out 0x0000. When you get the large FREQ_EST values, due you get the same reading if you read the register more than once?

If so, we would need your register settings to look closer into this. Also, could you try to enable FB2PLL (FREQOFF_CFG=0x30) and see if this make a difference? (Different frequency compensation loop.)

0 Bjorn Strandmark over 9 years ago in reply to TER

Prodigy 40 points

Hi TER,

Thanks for your response.

First of all, we take the non-atomic update of FREQOFF_ESTx registers into account. The answer is is yes, we get the same result if we read the register more than once. (As a matter of fact, we tend to get the large values in a burst fashion; if a large value is returned sub-sequent readouts will also return large values. So if it works initially all readouts will work, if it fails initially all readouts fail)

I attach our register settings. The array in the attached file contains pairs: register address and register value. Registers not present in the array have default values. For your information we use a CC1125 with 40MHz TCXO XTAL on the rxer side, while the txer side is a CC1121 with a "normal" 32MHz XTAL.

Regarding FB2PLL, we already have FREQOFF_CFG = 0x32, which means FB2PLL is already enabled (?). We will try with value 0x30 also.

Looking forward to your feedback.

BR / Björn

4705.cc112x_radio_cfg.c

// Static radio settings
const uint8_t reg_array_RX_RADIO_PROFILE_868000_868600__868700_869200_2GFSK_BW100_DEV20_DATA38400_WHITE_15DBM[] = {
  REG_IOCFG3,             // GPIO 3 = HIGHZ
  0x30, //51, // TODO 0x30, 51 is HW0
  REG_IOCFG2,             // GPIO 2 = MARC_MCU_WAKEUP, sleep = 0
  0x14,
  //REG_IOCFG1
  REG_IOCFG0,             // GPIO 0 = PKT_SYNC_RXTX, sleep = HIGHZ
  0x06,
  REG_SYNC3,
  0xD3,                   // same default sync as cc1110
  REG_SYNC2,
  0x91,
  REG_SYNC1,
  0xD3,
  REG_SYNC0,
  0x91,
  REG_SYNC_CFG1,
  0x08,
  //REG_SYNC_CFG0
  REG_DEVIATION_M,        // Deviation = 20 kHz (0x48 = 20019.53125, 0x44 = 19775.390625) 0x44 is used for 1110 compability
#ifdef CFG_RADIO_OSC_FREQ_40
  0x03,
#else // CFG_RADIO_OSC_FREQ_32
  0x44,
#endif
  REG_MODCFG_DEV_E,       // Modulation = 2-GFSK
  0x0D,
  REG_DCFILT_CFG,
  0x1C,
  REG_PREAMBLE_CFG1,      // 4 bytes preamble, pattern = 0xaa 10101010
  0x18,
  //REG_PREAMBLE_CFG0
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_FREQ_IF_CFG,
  0x33,
#else // CFG_RADIO_OSC_FREQ_32
#endif
  REG_IQIC,
  0x46,
  REG_CHAN_BW,            // Channel bandwidth 100 kHz
  0x02,
  //REG_MDMCFG1           // manchester coding disabled
  REG_MDMCFG0,
  0x05,
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_DRATE2,             // data rate = 38.4 kbps
  0x8F,
  REG_DRATE1,
  0x75,
  REG_DRATE0,
  0x10,
#else // CFG_RADIO_OSC_FREQ_32
  REG_DRATE2,             // data rate = 38.4 kbps
  0x93,
#endif
  REG_AGC_REF,
  0x2E,
  REG_AGC_CS_THR,
  0xA6,                   // -90 dBm with RX BW = 100 kHz
  //REG_AGC_GAIN_ADJUST
  //REG_AGC_CFG3
  //REG_AGC_CFG2
  REG_AGC_CFG1,
  0xA9,
  REG_AGC_CFG0,
  0xCF,
  //REG_FIFO_CFG
  //REG_DEV_ADDR          // device address = 0
  REG_SETTLING_CFG,       // manual calibration = 0x03(0x0b for auto when going from IDLE to RX or TX)
  0x03,                   // (0x13 for auto from RX or TX to IDLE, 0x1b auto every 4th time to IDLE)
  REG_FS_CFG,             // out of lock detection enabled, 820 - 960 MHz band
  0x12,
  //REG_WOR_CFG1
  //REG_WOR_CFG0
  //REG_WOR_EVENT0_MSB
  //REG_WOR_EVENT0_LSB
  REG_PKT_CFG2,           // CCA disabled by default
  0x00,
  REG_PKT_CFG1,           // address check disabled, CRC enabled, append RSSI and LQI to RX packets, whitening enabled
  0x45,
  REG_PKT_CFG0,           // variable packet length
  0x20,
  //REG_RFEND_CFG1        // RXOFF = IDLE, RX timeout disabled
  REG_RFEND_CFG0,         // TXOFF = IDLE, terminate on bad packet
  0x08,
  REG_PA_CFG2,            // output power 15 dBm
  0x7F,
  //REG_PA_CFG1
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_PA_CFG0,
  0x7C,
#else // CFG_RADIO_OSC_FREQ_32
  REG_PA_CFG0,
  0x7B,
#endif
  REG_PKT_LEN,            // maximum packet size = 61
  0x3D,
  REG_EXTENDED,
  REG_EXT_IF_MIX_CFG,
  0x00,
  REG_EXTENDED,
  REG_EXT_FREQOFF_CFG,
  0x32,
  REG_EXTENDED,           // freq = 868.15 (LO_DIV = 4 for 820 - 960 MHz band)b
  REG_EXT_FREQ2,
  0x6C,                   // not osc freq compensated, will be overwritted by set channel
  REG_EXTENDED,
  REG_EXT_FREQ1,
  0x84,                   // not osc freq compensated, will be overwritted by set channel
  REG_EXTENDED,
  REG_EXT_FREQ0,
  0xCD,                   // not osc freq compensated, will be overwritted by set channel
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_EXTENDED,
  REG_EXT_IF_ADC0,
  0x05,
#else // CFG_RADIO_OSC_FREQ_32
#endif
  REG_EXTENDED,
  REG_EXT_FS_DIG1,
  0x00,
  REG_EXTENDED,
  REG_EXT_FS_DIG0,
  0x5F,
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_EXTENDED,
  REG_EXT_FS_CAL1,
  0x00,
#else // CFG_RADIO_OSC_FREQ_32
  REG_EXTENDED,
  REG_EXT_FS_CAL1,
  0x40,
#endif
  REG_EXTENDED,
  REG_EXT_FS_CAL0,
  0x0E,
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_EXTENDED,
  REG_EXT_FS_CHP,
  0x30,
#else // CFG_RADIO_OSC_FREQ_32
#endif
  REG_EXTENDED,
  REG_EXT_FS_DIVTWO,
  0x03,
  REG_EXTENDED,
  REG_EXT_FS_DSM0,
  0x33,
  REG_EXTENDED,
  REG_EXT_FS_DVC0,
  0x17,
  REG_EXTENDED,
  REG_EXT_FS_PFD,
  0x50,
  REG_EXTENDED,
  REG_EXT_FS_PRE,
  0x6E,
  REG_EXTENDED,
  REG_EXT_FS_REG_DIV_CML,
  0x14,
  REG_EXTENDED,
  REG_EXT_FS_SPARE,
  0xAC,
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_EXTENDED,
  REG_EXT_FS_VCO0,
  0x81,
#else // CFG_RADIO_OSC_FREQ_32
  REG_EXTENDED,
  REG_EXT_FS_VCO0,
  0xB4,
#endif
  REG_EXTENDED,
  REG_EXT_XOSC5,
  0x0E,
#ifdef CFG_RADIO_OSC_FREQ_40
  REG_EXTENDED,
  REG_EXT_XOSC1,
  0x07,
#else // CFG_RADIO_OSC_FREQ_32
  REG_EXTENDED,
  REG_EXT_XOSC1,
  0x03,
#endif
  REG_EXTENDED,
  REG_EXT_IRQ0M,
  0x00,
};


// Dynamic RXER setting when starting carrier wave measurement (this is to avoid receiving any packets)
  // start RX in deaf mode
  cc112x_spi_write_reg_extended(radio_handle->spi_handle, REG_EXT_PQT_SYNC_ERROR, 0x00); // deaf mode => no packet will be received
  cc112x_spi_write_reg(radio_handle->spi_handle, REG_SYNC_CFG1, 0x40);                   // PQT gating enabled
  ...
  cc112x_spi_command_strobe(radio_handle->spi_handle, STROBE_RX);

0 TER over 9 years ago in reply to Bjorn Strandmark

TI__Guru**** 317180 points

Not sure if you have set up the radio correctly:

cc112x_spi_write_reg_extended(radio_handle->spi_handle, REG_EXT_PQT_SYNC_ERROR, 0x00);

PQT_SYNC_ERROR is a read only register, if the intent was to set the threshold very strict, setting PREAMBLE_CFG0.PQT low is a better idea. Also consider altering the sync threshold.

Is this a conducted test?

0 Bjorn Strandmark over 9 years ago in reply to TER

Prodigy 40 points

Yes, you are correct, the wrong register is written, we will change according to your advise. But I wonder if this is the reason...

Yes, it is a conducted test.

BR / Björn

0 TER over 9 years ago in reply to Bjorn Strandmark

TI__Guru**** 317180 points

I did a similar test now where I use "device commands" in SmartRF Studio to read the FREQOFF_EST registers. I apply a CW @ -70 and -90 dBm, strobe Rx and press refresh. I get more or less the same reading every time. I could not see a large reading. Does the error readings have a pattern? I have limited time to write software to do this testing so if it's possible to trig it somehow it would help. The same if you have some simple software that run on the TRXEB or a launchpad that show the readings.

Another thing to look into is why you get more errors if you shield the receiver. I would assume it was the other way around. With noise at a given level I would assume the radio could start to track the wrong frequency but with a conducted test with -70 dBm this should not be an issue. Due to the wavematch sync search the probability of getting a false sync with a conducted test is very low.

0 Bjorn Strandmark over 9 years ago in reply to TER

Prodigy 40 points

Hi TER,

I will perform some tests based on your input so far. Which FREQOFF_CFG combinations are interesting to test?

0x32 is what we have today
0x30 - your proposal, to be tested
Other values?

Please provid input. I will come back when the tests are completed.

/Björn

0 TER over 9 years ago in reply to Bjorn Strandmark

TI__Guru**** 317180 points

FREQOFF_EST=0x3x vs FREQOFF_EST=0x2x, as an example 0x30, 0x32, 0x20 and 0x22, the most important will be FB2PLL or not.

Sub-1 GHz

Sub-1 GHz forum

CC112x: Using to FREQOFF_EST to measure constant carrier frequency