CC2652P: How to adjust the frequency offset in RF test?

Part Number: CC2652P
Other Parts Discussed in Thread: SYSCONFIG

I am using RF demo, such as rfpacketttx, rfpacketterrorrate, rfcarrierwave.
When I need to modify the frequency, I can use RFC_ CMD_ FS_ t 。 But when I need to modify the frequency offset, what do I need to do?
1、struct rfc_ CMD_ FS_ t ->fractFreq?
2、struct rfc_ CMD_ UPDATE_ HPOSC_ FREQ_ t -> freqOffset ?

#define CMD_FS 0x0803
//! Frequency Synthesizer Programming Command
struct __RFC_STRUCT rfc_CMD_FS_s {
uint16_t commandNo; //!< The command ID number 0x0803
uint16_t status; //!< \brief An integer telling the status of the command. This value is
//!< updated by the radio CPU during operation and may be read by the
//!< system CPU at any time.
rfc_radioOp_t *pNextOp; //!< Pointer to the next operation to run after this operation is done
ratmr_t startTime; //!< Absolute or relative start time (depending on the value of <code>startTrigger</code>)
struct {
uint8_t triggerType:4; //!< The type of trigger
uint8_t bEnaCmd:1; //!< \brief 0: No alternative trigger command<br>
//!< 1: CMD_TRIGGER can be used as an alternative trigger
uint8_t triggerNo:2; //!< The trigger number of the CMD_TRIGGER command that triggers this action
uint8_t pastTrig:1; //!< \brief 0: A trigger in the past is never triggered, or for start of commands, give an error<br>
//!< 1: A trigger in the past is triggered as soon as possible
} startTrigger; //!< Identification of the trigger that starts the operation
struct {
uint8_t rule:4; //!< Condition for running next command: Rule for how to proceed
uint8_t nSkip:4; //!< Number of skips + 1 if the rule involves skipping. 0: same, 1: next, 2: skip next, ...
} condition;
uint16_t frequency; //!< The frequency in MHz to tune to
uint16_t fractFreq; //!< Fractional part of the frequency to tune to
struct {
uint8_t bTxMode:1; //!< \brief 0: Start synth in RX mode<br>
//!< 1: Start synth in TX mode
uint8_t refFreq:6; //!< \brief 0: Use default reference frequency<br>
//!< Others: Use reference frequency 48 MHz/<code>refFreq</code>
} synthConf;
uint8_t __dummy0; //!< <i>Reserved</i>, always write 0
uint8_t __dummy1; //!< <i>Reserved</i>
uint8_t __dummy2; //!< <i>Reserved</i>
uint16_t __dummy3; //!< <i>Reserved</i>

#define CMD_UPDATE_HPOSC_FREQ 0x0608
//! Set New Frequency Offset for HPOSC
uint16_t commandNo; //!< The command ID number 0x0608
int16_t freqOffset; //!< Relative frequency offset, signed, scaled by 2<sup>-22</sup>

thank you~

  • HI FI

    I read the content of this link and learned how to read offset.
    Is this rfc_CMD_UPDATE_HPOSC_FREQ_s used to set offset?

  • hi, 

    I urgently need to know how to call API to set frequency offset.

    thank you ~

  • Part Number: CC2652P

    i see this link

    This may help me to read the frequency offset, but how to write?

  • Hi,

    The frequency offset as referred in the original question pertains to information regarding incoming packets, like LQI/RSSI and timestamps.  This is not a value that you would write.  Are you asking how to change the operating frequency during run-time?  Please refer to the RF lib API.


  • Based off the driver library documentation, that looks correct.

    Personally, I would recommend setting the frequency offset by modifying the XOSC Cap Array Delta in the sysconfig tool.

    If you're not using sysconfig, I'd recommend generating your RF settings through SmartRF studio as shown in the picture.

    Then, you can import them into your project so it works from the start.

  • At present, we use rftx(rfPacketTx) and rfper(rfPacketErrorRate), but we don't find any problems.

    However, we use CWM instrument to observe the carrier transmission. After the start of carrier transmission, the instrument only receives a short signal (maybe a frame), and then there is no more.

    I want to ask how to solve the problem of carrier transmission. Here is our code, which is similar to demo.(rfCarrierWave)

    RF_Handle rfCwHandle;
    RF_Object rfCwObject;

    RF_Params rfParams;

    RF_ScheduleCmdParams scheduleParams;

    scheduleParams.startTime = 0;
    scheduleParams.startType = RF_StartNotSpecified;
    scheduleParams.allowDelay = RF_AllowDelayAny;
    scheduleParams.duration = ~(0); // The CMD_FS will run until done
    scheduleParams.endTime = ~(0); // The CMD_FS will run until done
    scheduleParams.endType = RF_EndNotSpecified;

    RF_cmdTxTest.config.bUseCw = 1;

    rfCwHandle = RF_open(&rfCwObject, &RF_prop_2_4G_fsk_250kbps_t, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup_2_4G_fsk_250kbps_t, &rfParams);

    /* Send CMD_FS and wait until it has completed */
    RF_cmdFs_2_4G_fsk_250kbps_t.frequency = config->frequencyTable[config->frequency].frequency;
    RF_cmdFs_2_4G_fsk_250kbps_t.fractFreq = config->frequencyTable[config->frequency].fractFreq;
    RF_runScheduleCmd(rfCwHandle, (RF_Op*)&RF_cmdFs_2_4G_fsk_250kbps_t, &scheduleParams, NULL, 0);

    /* Send CMD_TX_TEST which sends forever */
    RF_runScheduleCmd(rfCwHandle, (RF_Op*)&RF_cmdTxTest, &scheduleParams, NULL, 0);


  • Hi Mingwei,

    I'm moving this over to the software team to handle. They'll be able to debug your code and assist you further.

  • Hi Mingwei,

    Can you please tell us what exactly you are trying to accomplish and why you need to change the crystal frequency offset during runtime?


  • hi Ryan,

    Considering the difference of hardware, we need to test and calibrate RF (test transmission, per test, frequency offset, etc.) during the factory inspection. As for the frequency offset, it is necessary to set the frequency offset during the operation of the equipment, and it is necessary to solidify and store the set value.

  • Hi Mingwei,

    Once you find the appropriate offset for a single design, each other device should be relatively the same, within ~4ppm. If you're mass-producing devices, you should not find that each identical device requires a different offset to configure it properly. Is that the case?

  • hi Nathan

    That is to say, with the same firmware and hardware, the frequency offset can be guaranteed in the 4ppm range, right?

    At present, setting and saving frequency offset through API will be used in PCBA test phase. The tester will change the frequency offset through the software interface, so as to adjust the hardware scheme.

  • hi Nathan

    As mentioned earlier, is there any progress on carrier transmission?

  • hi Ryan

    I tried to use API to change the frequency offset, but it didn't work.A restart was also attempted.




    #define CMD_UPDATE_HPOSC_FREQ 0x0608
    //! Set New Frequency Offset for HPOSC
    uint16_t commandNo; //!< The command ID number 0x0608
    int16_t freqOffset; //!< Relative frequency offset, signed, scaled by 2<sup>-22</sup>

    rfc_CMD_UPDATE_HPOSC_FREQ_t RF_cmdFs_FreqOffset_t = 


    .commandNo = 0x0608,

    .freqOffset= 0


    RF_cmdFs_FreqOffset_t.freqOffset = xxx;

    RF_runScheduleCmd(rfHandle, (RF_Op*)&RF_cmdFs_FreqOffset_t, &scheduleParams, NULL, 0);


    // RF_cmdFs_2_4G_fsk_250kbps_t.frequency = 2405;
    // RF_cmdFs_2_4G_fsk_250kbps_t.fractFreq = 0;
    // RF_runScheduleCmd(rfHandle, (RF_Op*)&RF_cmdFs_2_4G_fsk_250kbps_t, &scheduleParams, NULL, 0);

    // RF_cmdFs_FreqOffset_t.freqOffset = xxx;
    // RF_scheduleCmd(rfHandle, (RF_Op*)&RF_cmdFs_FreqOffset_t, &scheduleParams, NULL, 0);

  • Hi mingwei,

    How do you know that the API did not work and have you tried the RF_runCmd API?  The cap-array is tuned through the CCFG, please see Section 6.4 of

    There is also an rfCarrierWave example which can be referenced. 

    Please review your RF_scheduleCmd parameters and debug to determine which modification from the default example breaks the code.