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.

CC1310: CC1310 :TI 15.4 used with PA(Skyworks Sky66115) Demo?

Part Number: CC1310
Other Parts Discussed in Thread: CC1190, , CSD

Hi Tis,

We used Sky66115 as our product's PA at 433Mhz. We test it on SmartRF successfully , but  we use the CC1190 demo to control sky66115 , we met errors. We also read the datasheet and config the param,but we failed. Would you pls  provide the control demo for Sky66115?

Thanks a lot.

  • Are you here referring to a 15.4 example that uses CC1190 and you want to change this to a 15.4 example that uses CC1310 + SKY66115?
  • Hi Ter,
    Yes,we need the example that uses CC1310+SKY66115.
    Thanks a lot.
  • I have to ask around for this one. Most likely I have to wait until next week since people is currently out of office
  • Hi Ter,
    Ok, Thanks a lot.
  • Currently the stack only supports CC1190. You can look into if it's possible to derive the control signals you need from the PA_EN and LNA_EN signals given from the stack.
  • I have not tested this and I don't know how it would interact with the stack but you can look at the callback functions in the board files relater to the RF driver:

    /*
     *  =============================== RF Driver ===============================
     */
    #include <ti/drivers/rf/RF.h>
    
    /*
     *  Board-specific callback function to set the correct antenna path.
     *
     *  This function is called by the RF driver on global driver events.
     *  It contains a default implementation to set the correct antenna path.
     *  This function is defined in the file CC1352R1_LAUNCHXL_fxns.c
     */
    extern void rfDriverCallback(RF_Handle client, RF_GlobalEvent events, void *arg);
    
    const RFCC26XX_HWAttrsV2 RFCC26XX_hwAttrs = {
        .hwiPriority        = ~0,     /* Lowest HWI priority */
        .swiPriority        = 0,      /* Lowest SWI priority */
        .xoscHfAlwaysNeeded = true,   /* Keep XOSC dependency while in stanby */
    
        /* Register the board specific callback */
        .globalCallback     = &rfDriverCallback,
    
        /* Subscribe the callback to both events */
        .globalEventMask    = RF_GlobalEventRadioSetup | RF_GlobalEventRadioPowerDown
    };

  • Hi Ter,

    Thanks for your reply.We failed about changing RF driver. Because we could not estimate the RF TX/RX status,so couldn't configure the params.

    would you pls find the SmartRF 's code example  to control  Sky66115?

    In SmartRF the setup is as follow:

    2.4.1 DIO Configuration

    Based on the truth table of the SKY66115-11 shown in Table 1, SmartRF Studio should have the DIO

    configured as shown in Figure 5.

    Table 1. SKY66115-11 Truth Table

    DIO_1 (CTX) : LOW & DIO_30 (CSD) : HIGH ----> Rx

    DIO_1 (CTX) : HIGH & DIO_30 (CSD) : HIGH ----> Tx

    DIO_1 (CTX) : X & DIO_30 (CSD) : LOW ----> Sleep

    2.4.2 RF Front-End Configuration

    Figure 6 and Figure 7 show the configuration of Tx and Rx modes separately. This is configured in the

    CMD_PROP_RADIO_DIV_SE radio operation commands.

    For the Tx path configuration shown in Figure 6, RF_P is set to single-end option. The txpower

    parameters should also be configured based on Table 3.

    For the Rx path shown in Figure 7, RF_N is set to single-end option.

  • Is this still in the context of the 15.4 stack?

    What do you mean by "SmartRF 's code example" since your latest post details how to do this in SmartRF Studio?
  • Hi Ter,
    Sorry,I didn't tell the correct details.
    Yes, it is still in 15.4 stack.Because We can control Sky66115 in SmartRF, We want tranfer smartRf code example into 15.4 stack.
  • As I wrote: Currently the stack only supports CC1190. This coding is done in files that are not available for customers hence you can't easily add support for a different FEM.

    Could you elaborate some on "We failed about changing RF driver. Because we could not estimate the RF TX/RX status,so couldn't configure the params"?
  • It looks like I didn't get all the relevant information about this when I asked around this summer:

    If you look in the application -> PALNA folder in the 15.4 examples you will find:

    void Board_Palna_initialize(uint32_t hgm)
    {
    	if (hgm)
    	{
    	    CC13x0_LAUNCHXL_rfDisableCallback();
    
    		if (!palnaPinHandle)
    		{
    			/* Open PA/LNA PIN driver */
    			palnaPinHandle = PIN_open(&palnaPinState, palnaPinTable);
    			
    			/* Set IO muxing for RFC GPOs */
    			PINCC26XX_setMux(palnaPinHandle, Board_CC1190_LNA, IOC_PORT_RFC_GPO0);
    			PINCC26XX_setMux(palnaPinHandle, Board_CC1190_PA, IOC_PORT_RFC_GPO1);
    		}
    		
    		PIN_setOutputValue(palnaPinHandle, Board_CC1190_HGM, (hgm & 1));
    			
    	}
    }

    which should be possible to modify to cover your needs. The power table should also be updated to reflect that you are using a different frontend.