CC2652P7: Recommendation for CenterFreq

Hello Alex,

What SDK version and example project are you developing from?  Please refer to Section 25.10.5.2 of the TRM and the rflib APIs.  The centerFreq of the CMD_PROP_RADIO_DIV_SETUP should be determined from the SysConfig frequency selection for the ti_radio_config.c generated file.  Then using the Radio_setFreq command during runtime can determine a new frequency for which the radio is configured automatically.

Regards,
Ryan

Hello Ryan,

The version of currently used SDK is 7.10.01.24. We have worked with Wireless MCUs for almost decade.

My question is: What is the limit for frequency band's width for frequency hopping radio when the same CenterFreq could be used: e.g. 10MHz, 20MHz, 50MHz, 100MHz...? What radio's parameters will be compromised when the width of frequency band is e.g. 200 MHz for the same CenterFreq ?

Can be changed CenterFreq and loDivider without time consuming RF_close(rfHandle) and RF_open(&rfObject, &RF_prop,  &RF_cmdPropRadioDivSetup, &rfParams) ?

Thanks,

Alex

The rfDiagnostics Radio_Builtin_setFreq API demonstrates changing the centerFreq during runtime.  This will still call RF_yield to power down the radio which allows the new settings to take effect. 

I will loop in a HW expert to address your frequency band width and turnaround time questions.

Regards,
Ryan

Hello Ryan,

Do you have any response from TI's HW team about Frequency band width for a selected centerFreq ? Is it possible to change centerFreq, intFreq, loDivider on-fly (without using RF_open() and RF_close() ?

Thanks,

Alex

Hi Alex,

I apologize for the delay.  You can modify the rxBw setting of the radio setup to configure the RX filter bandwidth.  You can review the recommended values and possible configurations for each PHY inside of SmartRF Studio 7, and this software will also allow you to test the effect of such changes alongside the center frequency with RX/TX command interfaces.  The maximum BW supported is no more than 5 MHz (considering 2.4 GHz proprietary PHYs)

You will need to use RF_yield for changes to the RF radio settings to take effect.

Regards,
Ryan

Hi Alex,

When you say bandwidth do you mean the spacing between each channels?

Best regards,

Bun

Hi Bun,

No, it is distance from F_start to F_stop: e.g. for the frequency band 902-928 MHz (frequency width = 26 MHz) can be used one centerFreq at 915 MHz or I need more than one?  Can be used a single centerFreq for the wider frequency band 50 MHz, 100 MHz, 200 MHz, ... for frequency hopping radio modem?

The tuning time for frequency hopping modem is critical. Is it possible to change centerFreq, intFreq, loDivider on-fly (without using time consuming RF_open() and RF_close() )?

Thanks,

Alex

Hi Ryan,

My question was about centerFreq: What should be distance from start to stop frequency for frequency hopping radio modem in order to use the same centerFreq ? I try to minimise the number of parameters that I need to change in order to switch from one frequency to another. Can be used the same centerFreq for the frequency intervals: 25, 500, 100 MHz, ...? What radio's parameters will be compromised if this frequency interval is too wide?

Regards,

Alex 

The TI 15.4-Stack User's Guide may be able to provide a better reference, or allow you to develop using an available and tested frequency hopping solution.

Are you using a Sub-1 GHz SimpleLink device?  The CC2652P7 is a 2.4 GHz-only product and TI has not invested in 2.4 GHz frequency hopping solutions.  I concede that the Datasheet does not specify 2.4 GHz Proprietary RF PHY parameters well, outside of the standard BLE and IEEE PHYs.

Regards,
Ryan

Hi Alex,

Yes, it is possible to reduce the number channels to one and use the entire bandwidth. This would allow you so use any bit rate but the device's max bit rate is 2Mpbs. Additionally, you can extend the bandwidth, but we did not test and validate any frequencies beyond the range specified in the datasheet so we cannot guarantee good performance.

I will need to follow-up with the RF drive team regarding your question on RF_open and RF_close.

Best regards,

Bun

Hi Bun,

I'm looking forward to hearing from your RF drive team: is there faster way to change at some frequency point for frequency hopping radio:

.centerFreq,

.intFreq,

.loDivider

on-fly (without using time consuming RF_open() and RF_close() )?

Best regards,

Alex

Hi Alex,

Can you please confirm that you do not accept my solution of using RF_yield to apply radio changes?  What is your target SimpleLink device and frequency band?

Regards,
Ryan

Hi Alex,

See their response below.

What you want, can and should do might provide different answers to this question – so I will split your question up a bit to answer as best as I can.

• Can you change frequency on-the-fly, without calling RF_close -> RF_open? Yes.

The frequency synth programming command, CMD_FS, is intended for this. This command can also be chained, to program a different center frequency for each TX/RX operation.

• Can you change loDivider on-the-fly, without calling RF_close -> RF_open? Yes, but probably not in a way to meet the requirements of the E2E use case.

The .loDivider configuration is part of the setup command, provided as part of RF_open, and cached in the RF client object. This is because the configuration is re-applied to the radio whenever the radio is powered up from standby. We do provide an RF_control() API, for certain corner cases. Together with the argument ‘RF_CTRL_UPDATE_SETUP_CMD’, this does enable re-configuration of the setup command, but

- It is only applied at the next wakeup of the radio, and only once (i.e. reset to the original RF client object config used in RF_open)

- It increases the next wakeup by a margin, to enable special boot steps

• Additional suggestions

Depending on the use case, and how often the ‘lodivider’ must be changed, you can define two RF clients / handles. They can be the same PHY, but differ on the .lodivider option (or more?). This way, the PHY switching (and .lodivider configuration) will be handled by the RF driver, according to the client tied to your RF (TX/RX) command. If this meets the requirements of the use case, I do not know. Even RF_close -> RF_open of a “Client 2” to reconfigure .lodivider for a third option, while “Client 1” already serves requests for the radio, might be more efficient than a single client.

Thank you for so detailed response. I need some time to implement your recommendations into my project.

Alex