CC1352P: Enabling High PA for 2.4 GHz

The E2E thread linked to are still valid. 

I don't have any HW available at the moment (working from a remote location) and therefore unable to test. But could you post your current code implementation? In particular, have you check that the switch is set to the correct path? 

Since you ask about SmartRF Studio, does that mean you use a relatively old SDK version without syscfg? I got the impression from previous posts that you are aiming to use the newest SDK? 

Sorry for this lengthy answer, but maybe I should make clear what I did and what I'm trying to do in the future.

Currently I'm just starting on the development of my software. As a start, I played with various example projects, just to see what the hardware and the SDKs are capable of. The main examples I worked with are the rfEasyLinkEcho and the rfAudio examples.

• From the rfEasyLinkEcho, I like the SysConfig tool for comfortably adding and changing the drivers and especially the PHY configuration. This is great since we are currently evaluating how to implement an audio application with multiple participants. The easy configuration via SysConfig will allow us to evaluate our options (frequency band, data rates, tx power etc.) for a later product implementation of the CC1352P. Why using EasyLink? Well, because it comes with some nice features, like CCA, asynchronous transmission and reception, as I said in my previous reply to you.
• the rfAudio example is great since it already implements an audio compression codec. 

So this is my longer answer to your last question and this maybe makes my previous posts a little clearer. So, in a nutshell, yes, I want to use SysConfig, but the problem is that the rfAudio example doesn't have it implemented. My first trial of putting those two projects together was not very successful and resulted in many compilation and linking errors, but that is another issue.

Now before I continued trying to merge these projects, I wanted to test the range with different PHY configuration, using the rfAudioTx/Rx example for a simple audio transmission. So for this issue, I only used this project. I used SmartRF Studio and the Code Export Tool, just as you suggested here. I configured three different PHY configs (915, 868 and 2400 MHz) which are all working fine. The high PA settings for the Sub-GHz frequencies also seem to work fine. Enabling High PA for the 2400 MHz band is the issue. 

Below, you find three pOverrideTx20 definitions that I tried: two from CC2652P (BLE and IEEE) and one where I naively used the pOverrideTx20 from the CC1352P of a Sub-GHz PHY (868 MHz). All of them were exported from SmartRF Studio. None of them work. In all cases, the transmission power drops, so that the measured RSSI from a receiver board is at about -70 dBm, even though the boards are right next to each other. I didn't change anything other in the example (except for some settings for the audio codec, so that shouldn't be relevant for now).

// 20 dBm override from CC2652P, IEEE 802.15.4
// does not work
// Overrides for CMD_PROP_RADIO_DIV_SETUP_PA
uint32_t pOverridesTx20[] =
{
    // The TX Power element should always be the first in the list
    TX20_POWER_OVERRIDE(0x003F75F5),
    // The ANADIV radio parameter based on the LO divider (0) and front-end (0) settings
    (uint32_t)0x01C20703,
    // override_tx20_settings.xml
    // Set RTIM offset to 3 for high power PA
    (uint32_t)0x00038783,
    // Set synth mux for high power PA
    (uint32_t)0x010206C3,
    // Set TXRX pin to 0 in RX/TX and high impedance in idle.
    HW_REG_OVERRIDE(0x60A8,0x0001),
    (uint32_t)0xFFFFFFFF
};

// 20 dBm override from CC2652P, BLE
// does not work
// Overrides for CMD_BLE5_RADIO_SETUP_PA
uint32_t pOverridesTx20[] =
{
    // The TX Power element should always be the first in the list
    TX20_POWER_OVERRIDE(0x003F75F5),
    // The ANADIV radio parameter based on the LO divider (0) and front-end (0) settings
    (uint32_t)0x01C20703,
    // override_tx20_settings.xml
    // Bluetooth 5: Set RTIM offset to 3 for high power PA
    (uint32_t)0x00030783,
    // Bluetooth 5: Set synth mux for high power PA
    (uint32_t)0x010206C3,
    // Set TXRX pin to 0 in RX/TX and high impedance in idle.
    HW_REG_OVERRIDE(0x60A8,0x0001),
    // Bluetooth 5: Turn off DTX gain adjustment
    (uint32_t)0x000007E3,
    // Bluetooth 5: Set default TX shape
    (uint32_t)0x00008C73,
    (uint32_t)0xFFFFFFFF
};

// CC1352P, 868 MHz
// does not work
// Overrides for CMD_PROP_RADIO_DIV_SETUP_PA
uint32_t pOverridesTx20[] =
{
    // The TX Power element should always be the first in the list
    TX20_POWER_OVERRIDE(0x001B8ED2),
    // The ANADIV radio parameter based on the LO divider (0) and front-end (0) settings
    (uint32_t)0x11C10703,
    // override_phy_tx_pa_ramp_genfsk_hpa.xml
    // Tx: Configure PA ramping, set wait time before turning off (0x1F ticks of 16/24 us = 20.3 us).
    HW_REG_OVERRIDE(0x6028,0x001F),
    // Set TXRX pin to 0 in RX/TX and high impedance in idle.
    HW_REG_OVERRIDE(0x60A8,0x0001),
    (uint32_t)0xFFFFFFFF
};


// CMD_PROP_RADIO_DIV_SETUP_PA
// Proprietary Mode Radio Setup Command for All Frequency Bands
rfc_CMD_PROP_RADIO_DIV_SETUP_PA_t RF_cmdPropRadioDivSetup =
{
    .commandNo = 0x3807,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .modulation.modType = 0x1,
    .modulation.deviation = 0x1F4,
    .modulation.deviationStepSz = 0x0,
    .symbolRate.preScale = 0xF,
    .symbolRate.rateWord = 0x28000,
    .symbolRate.decimMode = 0x0,
    .rxBw = 0x5B,
    .preamConf.nPreamBytes = 0x4,
    .preamConf.preamMode = 0x0,
    .formatConf.nSwBits = 0x20,
    .formatConf.bBitReversal = 0x0,
    .formatConf.bMsbFirst = 0x1,
    .formatConf.fecMode = 0x0,
    .formatConf.whitenMode = 0x0,
    .config.frontEndMode = 0x0,
    .config.biasMode = 0x1,
    .config.analogCfgMode = 0x0,
    .config.bNoFsPowerUp = 0x0,
    .config.bSynthNarrowBand = 0x0,
    .txPower = 0xFFFF,
    .pRegOverride = pOverrides,
    .centerFreq = 0x0988,
    .intFreq = 0x0800,
    .loDivider = 0x00,
    .pRegOverrideTxStd = 0,
    .pRegOverrideTx20 = pOverridesTx20
};

Let me know if you need more of my source code.

To cover the basics: I assume you are using this board: LAUNCHXL-CC1352P-2? 

Do you have any RF instruments? It's easier to see if the code works if you are able to measure the output power directly. But in this case it's clear that it doesn't since the measured RSSI is very low. I would require more code than the overrides, the most important to verify is that the correct overrides are actually used. 

If I would set up a check to see if I could get prop 2.4 GHz up and running with 20 dBm I would start with the rfCarrierWave example due to it's simplicity. 

I'm using a LAUNCHXL-CC1352P1.

I'll have to talk to our hardware engineers about our RF instruments. Might take until the beginning of next week. 

Maybe I dont grasp what you mean, I assumed that the overrides are indeed used, since the RF_cmdPropRadioDivSetup includes the Pointer to the override and the setup command is called in the example on startup. According to the reference manual of the CC1352P, section 25.3.3.1.2 on p. 1995:

The txPower parameter is stored and applied every time transmission of a packet starts to set an output power
with temperature compensation. This setting can be changed later with the command CMD_SET_TX_POWER
(see Section 25.3.3.2.16). If txPower is 0xFFFF, the 20 dBm PA is selected instead of the normal one. This
setting is only allowed on a "P" device. If this setting is used, a 20 dBm PA power override as defined in Table
25-22 is mandatory; if missing the setup command will end with error.

As you can see in my code snippet, the txPower field is 0xFFFF and the override pointer is set accordingly. Since the board sends packages (with the wrong power, though), I would thought the radio setup command itself and also the override is executed without an error (according to the manual). The radio setup command is called as shown below (original from the example, not altered by me)

/* Setup radio */
RF_Params rfParams;
RF_Params_init(&rfParams);


/* Request access to the radio */
rfHandle = RF_open(&rfObject, &RF_prop,
                   (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);

RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);

I don't know if the contents of the override for Tx20 are correct or not, though.

Oh. I see. I wasn't aware of the difference to the other boards since I didn't choose the hardware myself. Thank you. I'll consider this thread closed.