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.

CC1350: RF Driver Multi-Client Mode problem

Part Number: CC1350
Other Parts Discussed in Thread: CC2650

Hi,

I have encountered an issue running multi-client with sub-1g and BLE.

Application is based on WsnDMConcentrator example.

RF design is single ended 433Mhz and 2.4 (based on CC1350STK).

Sometimes after transmitting a BLE advertisement, when transmitting a 433Mhz packet, the signal is very weak (assumption is that it is being sent with wrong rf configuration).

Adding a call for easylink_init before every 433Mhz sent solved the problem.

I guess the problem is related to the multiclient configuration.

Idle timeout is 4000 for BLE and 500 for 433.

Bellow is the configuration source for both 433 and 2.4.

433 Mhz:

/* Set mulitclient mode for Prop Sub1G */
EasyLink_setCtrl(EasyLink_Ctrl_MultiClient_Mode, 1);

/* Initialize EasyLink */
if (EasyLink_init(RADIO_EASYLINK_MODULATION) != EasyLink_Status_Success)
{
System_abort("4 failed");
}

EasyLink_Status EasyLink_init(EasyLink_PhyType ui32ModType)
{
if (configured)
{
//Already configure, check and take the busyMutex
if (Semaphore_pend(busyMutex, 0) == FALSE)
{
return EasyLink_Status_Busy_Error;
}
RF_close(rfHandle);
}

if (!rfParamsConfigured)
{
RF_Params_init(&rfParams);
//set default InactivityTimeout to IDLE_TIME_OUT_SUB_G
rfParams.nInactivityTimeout = IDLE_TIME_OUT_SUB_G;
rfParamsConfigured = 1;
}

if (ui32ModType == EasyLink_Phy_Custom)
{
if(ChipInfo_GetChipType() == CHIP_TYPE_CC2650)
{
memcpy(&EasyLink_cmdPropRadioSetup.setup, &RF_cmdPropRadioDivSetup, sizeof(rfc_CMD_PROP_RADIO_SETUP_t));
}
else
{
memcpy(&EasyLink_cmdPropRadioSetup.divSetup, &RF_cmdPropRadioDivSetup, sizeof(rfc_CMD_PROP_RADIO_DIV_SETUP_t));
}
memcpy(&EasyLink_cmdFs, &RF_cmdFs, sizeof(rfc_CMD_FS_t));
memcpy(&EasyLink_RF_prop, &RF_prop, sizeof(RF_Mode));
memcpy(&EasyLink_cmdPropRxAdv, RF_pCmdPropRxAdv_preDef, sizeof(rfc_CMD_PROP_RX_ADV_t));
memcpy(&EasyLink_cmdPropTx, &RF_cmdPropTx, sizeof(rfc_CMD_PROP_TX_t));
}
else
{
if (busyMutex != NULL)
{
Semaphore_post(busyMutex);
}
return EasyLink_Status_Param_Error;
}

if (rfModeMultiClient)
{
EasyLink_RF_prop.rfMode = RF_MODE_MULTIPLE;
}
/* Initialize TX_ADV command from TX command */
initializeTxAdvCmdFromTxCmd(&RF_cmdPropTxAdv, &EasyLink_cmdPropTx);
/* Customize the CMD_PROP_TX command for this application */
RF_cmdNop.startTrigger.triggerType = TRIG_NOW;
RF_cmdNop.startTrigger.pastTrig = 1;

/* Set up the next pointers for the command chain */
RF_cmdNop.pNextOp = (rfc_radioOp_t*)&RF_cmdPropCs;
RF_cmdPropCs.pNextOp = (rfc_radioOp_t*)&RF_cmdCountBranch;
RF_cmdCountBranch.pNextOp = (rfc_radioOp_t*)&EasyLink_cmdPropTx;
RF_cmdCountBranch.pNextOpIfOk = (rfc_radioOp_t*)&RF_cmdPropCs;

/* Customize the API commands with application specific defines */
RF_cmdPropCs.rssiThr = RSSI_THRESHOLD_DBM;
RF_cmdPropCs.csEndTime = (IDLE_TIME_US + 150) * 4; /* Add some margin */
RF_cmdCountBranch.counter = CS_RETRIES_WHEN_BUSY;


/* Request access to the radio */
rfHandle = RF_open(&rfObject, &EasyLink_RF_prop, (RF_RadioSetup*)&EasyLink_cmdPropRadioSetup.setup, &rfParams);

//Set Rx packet size, taking into account addr which is not in the hdr
//(only length can be)
EasyLink_cmdPropRxAdv.maxPktLen = EASYLINK_MAX_DATA_LENGTH + EASYLINK_MAX_ADDR_SIZE;
EasyLink_cmdPropRxAdv.pAddr = addrFilterTable;

EasyLink_cmdPropRxAdv.addrConf.addrSize = addrSize; //Set addr size to the
//default
EasyLink_cmdPropRxAdv.pktConf.filterOp = 1; // Disable Addr filter by
//default
EasyLink_cmdPropRxAdv.pQueue = &dataQueue; // Set the Data Entity queue
// for received data
EasyLink_cmdPropRxAdv.pOutput = (uint8_t*)&rxStatistics;

// WOR
memcpy(&EasyLink_cmdPropRxSniff, &EasyLink_cmdPropRxAdv, sizeof(rfc_CMD_PROP_RX_ADV_t));


/* Calculate datarate from prescaler and rate word */
uint32_t datarate = calculateSymbolRate(EasyLink_cmdPropRadioSetup.divSetup.symbolRate.preScale,
EasyLink_cmdPropRadioSetup.divSetup.symbolRate.rateWord);

/* Configure Sniff-mode part of the RX_SNIFF command */
configureSniffCmd(WOR_MODE, datarate, WOR_WAKEUPS_PER_SECOND);
// e/o WOR

//Set the frequency
RF_runCmd(rfHandle, (RF_Op*)&EasyLink_cmdFs, RF_PriorityNormal, 0, //asyncCmdCallback,
EASYLINK_RF_EVENT_MASK);

//set default asyncRxTimeOut to 0
asyncRxTimeOut = 0;

//Create a semaphore for blocking commands
Semaphore_Params params;
Error_Block eb;

// init params
Semaphore_Params_init(&params);
Error_init(&eb);

// create semaphore instance if not already created
if (busyMutex == NULL)
{
busyMutex = Semaphore_create(0, &params, &eb);
if (busyMutex == NULL)
{
return EasyLink_Status_Mem_Error;
}

Semaphore_post(busyMutex);
}
else
{
//already configured and taken busyMutex, so release it
Semaphore_post(busyMutex);
}

configured = 1;

return EasyLink_Status_Success;
}

2.4 Configuration:

SimpleBeacon_Status SimpleBeacon_init(bool multiClient)
{
if(multiClient)
{
//set mode to multimode
RF_pModeBle->rfMode = RF_MODE_MULTIPLE;
}

if(!configured)
{
RF_Params_init(&BlerfParams);
//set inactivity timeout to 4000u seconds
BlerfParams.nInactivityTimeout = 4000;
bleRfHandle = RF_open(&bleRfObject, RF_pModeBle, (RF_RadioSetup*)RF_ble_pCmdRadioSetup, &BlerfParams);

if(bleRfHandle < 0)
{
return SimpleBeacon_Status_Config_Error;
}

configured = true;
}

return SimpleBeacon_Status_Success;
}

Thanks,

YTE

  • Hi,

    YTE said:
    Sometimes after transmitting a BLE advertisement, when transmitting a 433Mhz packet, the signal is very weak (assumption is that it is being sent with wrong rf configuration).

    If you see a transmission on 433 Mhz, but the signal strength not being good, then the PHY configuration seems to be (almost) correct. There are now two possibilities:

    • The antenna switch is not correctly configured and the wrong antenna is used
    • The analog part of the RF core is not correctly configured.

    Because you said that the signal is only sometimes "weak", I would tend to option 2. When the RF driver performs a PHY switch, then the RF core is reconfigured, but there are certain shortcuts that the RF driver takes if the RF core has not been powered down.

    May I ask you to test the following procedure instead of re-running EasyLink_init():

    • insert RF_yield(), you would need to get an RF driver handle from somewhere. It does not matter on which driver you call RF_yield()
    • add Task_sleep(200000) afterwards to wait for 2 ms so that the power down can complete.

    Does that already solve the problem?

  • Hi Richard,

    Thanks for the prompt response.

    After replacing init with yield and sleep, issue still occurs:

    // /* Initialize EasyLink */
    // if (EasyLink_init(RADIO_EASYLINK_MODULATION) != EasyLink_Status_Success)
    // {
    // System_abort("4 failed");
    // }

    RF_yield(rfHandle);
    Task_sleep(200000);

    according to bellow, the sleep is 200000*1000/4000000 = 50ms, i tried also Task_sleep(8000) for 2 ms, and got the same results.

    #define delay_ms(i) Task_sleep( ((i) * 1000) / Clock_tickPeriod )

    thanks,

    YTE.

  • Hi,

    the time is not critical. I just used 2 ms to make sure that the power-down procedure of the RF core has finished. I don't know how RF_yield() works when multiple clients are active. Could you please check the number of power dependencies after Task_sleep() to check whether the RF core has really powered down?

    #include <ti/drivers/power/PowerCC26XX.h>
    
    uint32_t dependencies = Power_getDependencyCount(PowerCC26XX_DOMAIN_RFCORE);
    

    The number is 0 only when the RF core has been powered down.

  • Hi Richard,

    I get dependencies == 0, both when problem occurs and when it doesn't occur.

    When signal is sent OK, i get RSSi of 21, when it is not OK i get RSSI of 50.
    I tried changing the Frontend configuration so that the 433 will get the 2.4 path, and i saw a similar RSSI.

    Seems like the driver doesn't change the fronend when moving from 2.4 ro 433 sometimes, it fits with your assumprion that: "the PHY configuration seems to be (almost) correct".
  • YTE said:
    I get dependencies == 0, both when problem occurs and when it doesn't occur.

    OK, good to know. Then we can most probably rule out RF settings and patches.

    YTE said:
    Seems like the driver doesn't change the frontend when moving from 2.4 ro 433 sometimes, it fits with your assumprion that: "the PHY configuration seems to be (almost) correct".

    Are you talking about the antenna switch?

  • We have no rf switch, two single ended (based on CC1350STK).
    I am refering to the frontrfmode on the divSetup:

    The configuration is as follows:

    .config.frontEndMode = 0x2 --> for RFN pin - 433Mhz (smartrfsettings.c)
    .config.frontEndMode = 0x1,-->For RFP pin - 2.4Ghz (smartrfsettingBle.c)

    When i changed the frontEndMode in smartrfsettings.c (433Mhz) to 0x1 instead of 0x2, i got similar poor results to
    as i see when problem occurs.
  • Can you send me the whole project?

  • Sent in a private message,

    Thanks!
    YTE
  • Hi,
    thanks for sending me the project. I had finally some time to look into it. We identified a bug in the RF driver. The analog front-end configuration of the RF core is not properly updated in some cases when performing a PHY switch. This will not be fixed in the next SDK release in January. Your work-around to re-initialize EasyLink is OK.