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.

CCS/CC1352P: rfDriverCallbackCustom - Rx/Tx inconsistency rssi

Part Number: CC1352P

Tool/software: Code Composer Studio

We have a custom board based on CC1352 Rev E

As such, we have added rfDriverCallbackCustom().

Using Sub 1Ghz with highPA ( +20dBm).Found inconsistency on Rx/Tx rssi as as dependents on mux configuration 

When using default reference MUX configuration from reference code :

- PINCC26XX_setMux(frontendPins, CONFIG_RF_DIO28, PINCC26XX_MUX_GPIO);

/* Note: RFC_GPO3 is a work-around because the RFC_GPO1 (PA enable signal) is sometimes not
de-asserted on CC1352 Rev A. */
 - PINCC26XX_setMux(frontendPins, CONFIG_RF_DIO29, PINCC26XX_MUX_RFC_GPO3);

- PINCC26XX_setMux(frontendPins, CONFIG_RF_DIO30, PINCC26XX_MUX_RFC_GPO0);

Rx rssi received on our custom board is low ( -55dBm).

However if changing DIO29 mux configuration :

 - PINCC26XX_setMux(frontendPins, CONFIG_RF_DIO29, PINCC26XX_MUX_RFC_GPO0);

Rx rssi received on our board is much higher ( -15dBm) , but than the Tx rssi ( As captured by SmartRF studio RX) is low.

Can you explain why mux configuration is needed, as rfDriverCallbackCustom only used to toggle RF switch IO's . 

  • Hi Amit,

    What version of the SimpleLink CC13x2/CC26x2 SDK are you using?

    Did you base your code on an example project?

    Are you running on a custom board or a LaunchPad? (What LaunchPad?)

  • Hi Marie,

    SDK 3.40.0.02

    Code is based on WakeOnRadio Rx/Tx example.

    Running on a custom board.

    Found that replacing mux index with PINCC26XX_MUX_GPIO  instead PINCC26XX_MUX_RFC_GPO3 for DIO29 ,  everything works fine , but don't really understand why.

    Can you elaborate provide more info about which mux index are selected ?

    PINCC26XX_setMux(frontendPins, CONFIG_RF_DIO29, PINCC26XX_MUX_GPIO /*PINCC26XX_MUX_RFC_GPO3*/);

  • Hi Amit,

    First of all, you should consider what signals you are changing. Assuming default configuration moving from RFC_GPO3 to RFC_GPO0 is changing the control logic A LOT. At default, GPO3 is "TX initiated/ongoing" , GPO0 is LNA enable/disable. This means you basically shift TX control signal for RX control signal.

    Setting it to "PINCC26XX_MUX_GPIO" is simply saying "This GPIO is a normal GPIO" which means it will have the value that is assigned to it.  

    Please see the Proprietary User's Guide -> RF Core chapter for more info on the radio signals http://dev.ti.com/tirex/explore/node?node=AOFmdaK8impnxmEqGU3jkg__pTTHBmu__LATEST

  • Hi,

    This function is used for antenna switch configuration , So I guess should configure all 3 IO's used for switch configuration as PINCC26XX_MUX_GPIO , right ?

    3 signals used for controlling the RF switch .

  • Hi Amit,

    I can't really say that this is correct, it depends on the HW setup. The GPO0 and GPO3 is valid options depending on how you use them. Both of this would result in a actual signal on the IO, it is just that the signal is controller from the RF Modem and not by the user (as in the case of PINCC26XX_MUX_GPIO ). 

    For example, if you have a switch that flip depending on RX/TX, then the LNA signal can be used as this is the radio signaling "in RX" and "not in RX". Same goes for the GPO3, as it could be seen as a "In TX" or "Not in TX" signal. 

    If you rather control all signal yourself manually, then you would need to set them to PINCC26XX_MUX_GPIO and make sure to write the value you expect them to have when going in and out of TX/RX.

  • I'm bit confused :

    It seems the antennas switching callback ( Default function at ti_drivers_config.c , rfDriverCallbackAntennaSwitching) is :

    A. Routing doorbell signals to GPIO pins ( PINCC26XX_setMux())

    AND

    B. Using GPIO's to control RF switch . ( PINCC26XX_setOutputValue())

    In the default function the router signals to GPIO are used also to control RF switch.

    On my custom board I use 3 GIPO's to control RF switches ( More than one ) ; DIO28, DIO29, DIO30.

    So in my custom antennas switching function I do not want to rout doorbell signals to GPIO (B), but control GPIO's directly (B).

    However my tests indicates I still have to rout doorbells signals , and I'm not sure the reason.

  • Amit,

    Yes, both RF Core signals and "normal GPIOs" is used to control the switch used on the LP. If you study the truth table, you should find it being logical.

    Take the "Sub1GHz" case as an example:

    If PA type is "HighPA" (which is the 20 dBm PA, then CONFIG_RF_24GHZ == GPIO == 0 (DIO28). This is what expected as it limits the switch selection to either "Sub1GHz" or "20 dBm PA".

    Now, CONFIG_RF_HIGH_PA is set to the RF Core signal "TX initiated/ongoing" while CONFIG_RF_SUB1GHZ is set to the RF Core LNA signal. This means that the output of these two pins is either:

    CONFIG_RF_SUB1GHZ = 1, CONFIG_RF_HIGH_PA = 0  == Sub1GHx RX

    or

    CONFIG_RF_SUB1GHZ = 0, CONFIG_RF_HIGH_PA = 1  == Sub1GHx TX

    Similarly, you can see that in the case of 2.4GHz, They are all set to GPIO and the CONFIG_RF_24GHZ  is set to one. This as the 2.4 GHz is a single path.

    In short, for the PHY using the high power PA, then you need to use the radio core signals to set the switch correctly when moving between TX/RX. This as there is no callback for this transition, this callback is mainly invoked during a PHy shifting occurrence. 

  • Hi,

    RF switch settings ( On LP its SKY13317-373 )  are identical for  Rx or Tx mode , no ?

    I can understand routing RF core signals when switching PHY ( 2.4Ghz , Sub1Ghz, Sub1Ghz_PA) ,  But should be the when PHy is the same and just switching between Rx and Tx.

     rfDriverCallbackAntennaSwitching is invoked both for Rx mode ( sniff mode)  and Tx mode, right ?

  • Hi Amit,

    The switching settings differ depending on TX/RX and Phy. If you are on the PHy that uses the 20 dBm PA, you need to switch path for RX/TX, when on the PHY that use the normal PA, the path is static. The truth table can be found on the schematic of the LP.

    The RF callback is typically only issued during "radio setup", in other words when you move between PHYs. It is not invoked for moving between RX/TX on the same PHY.