CC2652R: CC2652R

Hello Ashish,

Ashish Shrikhande said:

But when we import the same settings in CCS for Antenna

How is this being accomplished?  Have you changed your SysConfig -> RF Design settings to match your custom board design?  I recommend that you further review the Custom Hardware section of the TI 15.4-Stack User's Guide along with the Hardware/PCB Design Recommendations from SWRA640.

Regards,
Ryan

Yes exactly.

1) We have changed the settings  SysConfig -> RF Design settings from Internal Bias, Differential mode which was default to External Bias Single Ended RFP

2) While designing custom board we refered to SWRA640 as you have mentioned.

3) So for configuring the analog front end when we are changing to External Bias Single ended RFP, anything else need to be done. We went through the  TI 15.4-Stack User's Guide but did not get anything.

4) The hardware we think is correct, as from RF STUDIO we are able to TX and RX with -40dbm RSSI.  

What changes were made from SmartRF Studio which work for your custom hardware design?  Have you previously evaluated the sensor and collector examples before, and does their application run as intended (i.e. do not crash or assert after initializing the radio and attempting to commission the network) with the front-end change?  Are you able to sniff the intended channels and determine whether any beacons are being sent by the devices?

Regards,
Ryan

Hi Ryan,

1) We only changed the antenna settings to External Bias RFP. Below is the screen shot

2) We have been working with the LAUNCHXL - CC26X2R1 for 8 months now and we have a fully functional system at our end with 8 nodes working. This system is 24x7 working now since 28 days with no issues observed using Eval boards. We wanted to replace the Eval boards with the custom design which we made. So there is no software crash etc. We are getting data from the sensors and all.

3) We are using non Beacon mode. The only issue what we are facing is when we do the same antenna settings in CCS, the collector does not connect to any of the node. The antenna settings which we have is External Bias Single Ended RFP. Can you please guide us why this may be happening.

Hi Ashish,

Those are the same changes which are applied to the generated ti_radio_config.c file from the rfc_CMD_RADIO_SETUP_t constant.  You can review your output syscfg folder to verify.  Can you send/receive packets using your custom hardware and prop_rf examples?  Have you made sure to erase all device memory before programming, and configure the channels/network properly on the collector?  Are the sensors attempting to joint on the same channel with permit join enabled from the collector?  Also, did you submit your custom hardware to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for further review from TI?  

Regards,
Ryan

Hi Ryan,

1) Yes we verified the changes in SYSCONFIG are being reflected in ti_radio_config.c

2) We have not used prop_rf. We will check it and come back to you asap. But I think since we tested with RF studio it should also work. Correct me if I am wrong.

3) Yes we are erasing complete flash, and configuring channels properly thats why RF studio is working for us. The sensors are also attempting to join same channel/network property on the collector.

4) We have not  submitted our custom hardware to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for review from TI. Still we are thinking it as a software issue because through RF STUDIO we were able to TX and RX properly with no issues. Is this understanding correct?

There is no indication in the TI 15.4-Stack code that RF_cmdRadioSetup_ieee154 settings frontEndMode and biasMode are overwritten.  RF Studio uses ROM RF commands and is not dependent on flash application contents.  Also, it should be possible to use the incorrect front-end settings and still receive packets.  For context, I am able to use "External Bias, Single ended RFP" in the 2.4-GHz RF configurations of my LAUNCHXL-CC26X2R1 sensor/collector examples, and although the RSSI is significantly poorer (about -75 dBm packet reception) I am still able to commission the devices and communicate on a 15.4-Stack network.  I know that the SysConfig change works because when I switch back to "Internal Bias, Differential Mode" (only software change) the RSSI is around -30 instead.  This is why I am recommending a hardware evaluation. 

What is your custom hardware's noise floor in RF Studio (RSSI when running RX continuously without receiving any packets)?  TI 15.4-Stack implements a CSMA/CA which will not send out packets if it believes the channel is too noisy.  As a test, are you able to connect a LaunchPad sensor to a custom PCB collector or vice versa?

Regards,
Ryan

Ryan,

1) Noise floor in RF STUDIO is -78dbm

2) I tried prop_rf but the example under rfEchoRx_CC26X2R1_LAUNCHXL_tirtos7_ticlang does not compile when I change the antenna to External Bias, Single ended RFP. I am using Below is the compilation error:

**** Build of configuration Debug for project rfEchoRx_CC26X2R1_LAUNCHXL_tirtos7_ticlang ****

"C:\\ti\\ccs1120\\ccs\\utils\\bin\\gmake" -k -j 8 all -O

Building file: "../rfEchoRx.syscfg"
Invoking: SysConfig
"C:/ti/sysconfig_1_13_0/sysconfig_cli.bat" -s "C:/ti/simplelink_cc13xx_cc26xx_sdk_6_20_00_29/.metadata/product.json" --script "C:/Users/Collins/workspace_v12/rfEchoRx_CC26X2R1_LAUNCHXL_tirtos7_ticlang/rfEchoRx.syscfg" -o "syscfg" --compiler ticlang
Running script...
Validating...
info: /ti/drivers/Board generateInitializationFunctions: The initialization functions are still being generated after switching to a device.
Generating Code (rfEchoRx.syscfg)...
subdir_rules.mk:16: recipe for target 'build-1640162847' failed
Error: FrontEnd not found[XS_RFP]
at Object.updateFrontendSettings (C:\ti\simplelink_cc13xx_cc26xx_sdk_6_20_00_29\source\ti\devices\radioconfig\.meta\cmd_handler.js:1584:19)
at subTemplateFunction (C:\ti\simplelink_cc13xx_cc26xx_sdk_6_20_00_29\source\ti\devices\radioconfig\.meta\settings\phygroup.c.xdt:89:13)
at C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\resources\runtime.ts:97:11
at templateFunc (C:\ti\simplelink_cc13xx_cc26xx_sdk_6_20_00_29\source\ti\devices\radioconfig\.meta\templates\rf_settings.c.xdt:111:10)
at func (C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\codeGeneration\templateRunner.ts:29:39)
at Object.allowPathVisibility (C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\pathsVisibility.ts:11:10)
at Object.runTemplate (C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\codeGeneration\templateRunner.ts:29:13)
at C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\codeGeneration\codeGenerator.ts:117:19
at new Promise (<anonymous>)
at t.CodeGenerator.generate (C:\ti\sysconfig_1_13_0\dist\webpack:\src\pinmux\services\codeGeneration\codeGenerator.ts:94:10)
gmake: *** [build-1640162847] Error 1
gmake: Target 'all' not remade because of errors.

**** Build Finished ****

I am using simplelink_cc13xx_cc26xx_sdk_6_20_00_29. Missed in points above

The prop_rf error you observed for the SimpleLink v6.20 SDK has been identified and is resolved in the v6.30 SDK which was released earlier this week.  Further prop_rf testing may no longer be necessary given my observations using different front-end modes with LaunchPads and TI 15.4-Stack examples.

The noise floor is higher than expected, is this across all channels (i.e. not due to specific channel noise)?  Are you able to connect a LaunchPad sensor to your custom PCB collector or a LaunchPad collector to your custom PCB sensor?  I believe the issue reside on hardware and that you should submit your custom hardware to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for review from TI.

Regards,
Ryan

Hi Ryan,

When I connect the LaunchPad CC2652SIP board the noise floor is -102dbm for channel 11,12,15,20,25,26. So how much should be the accepted noise floor. Because in our case it was -74dbm.

I would expect the noise floor to be below -90 dBm, and this will factor towards node link quality and noise channel rejection for TI 15.4-Stack.

Regards,
Ryan

But you mentioned in the earlier comments that with -74dbm the noise floor on the custom board is higher than expected. 

We will get the hardware reviewed. Thanks

To further align on terminology: I interpret -90 dBm as less than -70 , thus -110 < -90 < -70 where you want the noise floor to be in between -110 dBm and -90 dBm.