• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 56 subscribers
  • Views 726 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352P7: CC1352 not enough TX power - Override not working? (Single-Ended, Internal Bias)

Rene Arts
Prodigy 10 points
Part Number: CC1352P7

Hi there,

Requesting some assistance with a custom board that I'm trying to get to work up to our spec. Generally this system needs to work in the 430-480MHz range with 4-GFSK modulation.

We're using a CC1352P7 with an external RF LNA for RX and an external RF amplifier for TX, all with internal bias.

RX is designed to be input from the RFn pin, whereas TX is designed to be output from RFp (all on the Sub_1GHz pins and Single-Ended). 

According to SWRA640 (rev H) section 2.2 (configuring Front-End Mode) we have set Config.frontEndMode to 0x02 to select Single-Ended mode RX on RFN. In addition, we have also set the override as advised with setting x=1. Note that the datasheet mentions ADI_HALFREG_OVERRIDES(0, 16, 0x7, x) where the S has to be removed to satisfy the compiler as there is no such macro defined. 

I have tried to use these settings with both our own application software (based on TI-rtos) as well as with Smart-RF Studio 7, but I am getting unsatisfactory results. When measuring directly on the RFp output with a spectrum analyser, I would expect a signal around roughly 0-3dBm, but I am measuring 25-30dB less. I am suspecting that I am measuring the parasitic coupled resultant of the transmitted signal on the RXn pin and traces. 

However when I set .config.frontEndMode to 0x1 (Single-Ended on RFp), the output power is rougly 0dBm as expected, but -naturally-  my RX sensitivity drops with ~30dB as RX is now configured on the RFp pin as well. This leads me to believe that the override setting to assign TX to the RFp pin is not working correctly in our configuration. 

I have included our smartrf_settings.c as generated with SmartRF Studio 7. Please let me know if/what additional information you need!

My questions:

  1. Generally: what can I do to improve the TX performance while maintaining the RX sensitivity? - preferably in software ;-) 
  2. Am I missing any other setting, did I configure something in a wrong way? 
  3. Is the override applied correctly the way I have done it? Does it matter where in the overrides block this line is inserted?

Thanks in advance! 

//*********************************************************************************
// Generated by SmartRF Studio version 2.30.0 (build#397)
// The applied template is compatible with cc13x2_26x2 SDK version 2.30.xx.xx or newer.
// Device: CC1352P7 Rev. B (1.1). Only supported by CC26x2 SDK version 5.10.xx.xx or newer
//
//*********************************************************************************


//*********************************************************************************
// Parameter summary
// RX Address0: 0xAA 
// RX Address1: 0xBB 
// RX Address Mode: No address check 
// Frequency: 459.30000 MHz
// Data Format: Serial mode disable 
// Deviation: 0.797 kHz
// Packet Length Config: Variable 
// Max Packet Length: 255 
// Packet Length: 20 
// Packet Data: 255 
// Preamble Count: 4 Bytes 
// Preamble Mode: Send 0 as the first preamble bit 
// RX Filter BW: 9.7 kHz
// Symbol Rate: 4.80042 kBaud
// Sync Word: 0x930b51de 
// Sync Word Length: 32 Bits 
// TX Power: 3 dBm 
// Enable high output power PA: false 
// Whitening: No whitening 

#include "smartrf_settings_NGT.h"

#include DeviceFamily_constructPath(rf_patches/rf_patch_cpe_prop.h)

// TI-RTOS RF Mode Object
RF_Mode RF_prop =
{
    .rfMode = RF_MODE_AUTO,
    .cpePatchFxn = &rf_patch_cpe_prop,
    .mcePatchFxn = 0,
    .rfePatchFxn = 0
};


// Overrides for CMD_PROP_RADIO_DIV_SETUP_PA
uint32_t pOverrides[] =
{
    // override_tc706.xml
    ADI_2HALFREG_OVERRIDE(0,16,0x8,0x8,17,0x1,0x1),
    ADI_HALFREG_OVERRIDE(0,16,0x7,1),
    HW_REG_OVERRIDE(0x609C,0x001A),
    (uint32_t)0x000188A3,
    ADI_HALFREG_OVERRIDE(0,61,0xF,0xD),
    // override_prop_common_sub1g.xml
    // TX: Set FSCA divider bias to 1
    HW32_ARRAY_OVERRIDE(0x405C,0x0001),
    // TX: Set FSCA divider bias to 1
    (uint32_t)0x08141131,
    // override_prop_common.xml
    // DC/DC regulator: In Tx with 14 dBm PA setting, use DCDCCTL5[3:0]=0xF (DITHER_EN=1 and IPEAK=7). In Rx, use default settings.
    (uint32_t)0x00F788D3,
    (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 = 0x33,
    .modulation.deviationStepSz = 0x2,
    .symbolRate.preScale = 0xF,
    .symbolRate.rateWord = 0xC4A,
    .symbolRate.decimMode = 0x0,
    .rxBw = 0x45,
    .preamConf.nPreamBytes = 0x4,
    .preamConf.preamMode = 0x0,
    .formatConf.nSwBits = 0x20,
    .formatConf.bBitReversal = 0x0,
    .formatConf.bMsbFirst = 0x1,
    .formatConf.fecMode = 0x9,
    .formatConf.whitenMode = 0x0,
    .config.frontEndMode = 0x2,
    .config.biasMode = 0x0,
    .config.analogCfgMode = 0x0,
    .config.bNoFsPowerUp = 0x0,
    .config.bSynthNarrowBand = 0x0,
    .txPower = 0x40D6,
    .pRegOverride = pOverrides,
    .centerFreq = 0x01CB,
    .intFreq = 0x8000,
    .loDivider = 0x0A,
    .pRegOverrideTxStd = 0,
    .pRegOverrideTx20 = 0
};


// CMD_FS
// Frequency Synthesizer Programming Command
rfc_CMD_FS_t RF_cmdFs =
{
    .commandNo = 0x0803,
    .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,
    .frequency = 0x01CB,
    .fractFreq = 0x4CCD,
    .synthConf.bTxMode = 0x0,
    .synthConf.refFreq = 0x0,
    .__dummy0 = 0x00,
    .__dummy1 = 0x00,
    .__dummy2 = 0x00,
    .__dummy3 = 0x0000
};


// CMD_PROP_TX
// Proprietary Mode Transmit Command
rfc_CMD_PROP_TX_t RF_cmdPropTx =
{
    .commandNo = 0x3801,
    .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,
    .pktConf.bFsOff = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bVarLen = 0x1,
    .pktLen = 0x14,
    .syncWord = 0x930B51DE,
    .pPkt = 0 // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
};


// CMD_PROP_RX
// Proprietary Mode Receive Command
rfc_CMD_PROP_RX_t RF_cmdPropRx =
{
    .commandNo = 0x3802,
    .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,
    .pktConf.bFsOff = 0x0,
    .pktConf.bRepeatOk = 0x0,
    .pktConf.bRepeatNok = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bVarLen = 0x1,
    .pktConf.bChkAddress = 0x0,
    .pktConf.endType = 0x0,
    .pktConf.filterOp = 0x0,
    .rxConf.bAutoFlushIgnored = 0x0,
    .rxConf.bAutoFlushCrcErr = 0x0,
    .rxConf.bIncludeHdr = 0x1,
    .rxConf.bIncludeCrc = 0x0,
    .rxConf.bAppendRssi = 0x0,
    .rxConf.bAppendTimestamp = 0x0,
    .rxConf.bAppendStatus = 0x1,
    .syncWord = 0x930B51DE,
    .maxPktLen = 0xFF,
    .address0 = 0xAA,
    .address1 = 0xBB,
    .endTrigger.triggerType = 0x1,
    .endTrigger.bEnaCmd = 0x0,
    .endTrigger.triggerNo = 0x0,
    .endTrigger.pastTrig = 0x0,
    .endTime = 0x00000000,
    .pQueue = 0, // INSERT APPLICABLE POINTER: (dataQueue_t*)&xxx
    .pOutput = 0 // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
};

  • 0
    TI__Genius 17955 points

    Hi,

    Thank you for pointing out the typo in SWRA640 - we'll get that fixed for the next revision of the document. Using SmartRF Studio to develop the RF settings before moving to your own FW is the recommended flow for this.

    A couple of initial questions:

    • What BOM are you using for this? A BOM for 433 MHz is not yet included in the document.
    • When you state "my RX sensitivity drops with ~30dB as RX is now configured on the RFp pin as well" - if you intend to use an external PA and LNA, what is the concern with the RX Sensitivity on RF_P, given that you will use RF_N for this purpose? I may have misunderstood your question.

    Regards,

    Zack

  • 0 in reply to ZC
    Prodigy 10 points

    Hi Zack, 

    Thank you for your quick response. 

    You are right, the RX sensitivity on RF_p is not a concern at all, I've put in that number to merely support my suspicion that the signal that I am measuring at RF_p with frontEndMode = 0x2 is parasitically coupled from RF_n. 

    In short: 

    1. frontEndMode = 0x2: RX -> RF_n works perfectly fine, TX on RF_p yields barely any output (though it varies according to its setting), irrespective whether and how the override is configured (tried setting 0, 1 and 2)

    2. frontEndMode = 0x1: RX -> RF_n barely works, shows RSSI of 30dB less than with the 0x2 setting, TX on RF_p works perfectly fine (output power of 0dBm and varies according to its setting)

    Our RF LNA is MAX2634, coupled to the CC1352 RF_n with an AC coupling capacitor.

    Or RF PA is GRF5504, coupled to the CC1352 RF_p with an AC coupling capacitor as well. 

    The BOM is, as far as I know, based on the LAUNCHXL-CC1352P-4 evaluation kit but is a custom design -- will check this and report back if different. 

    That said, I'm measuring directly at the filter of RF_p, so the RF PA is not part of the equation here. 

    To me it feels like somehow the override is doing nothing at all in our case, since the output on RF_p works perfectly fine when frontEndMode is set to 0x1. 

  • 0 in reply to Rene Arts
    TI__Genius 17955 points

    I would like to double-check this internally and get back to you with a clear answer. I expect that I will reply mid-next week (Wednesday), but I will reply sooner if I can.

    We are working on releasing a recommended 433 MHz BOM for single-ended configurations (0201 component size), but currently I can't give a timeline for when this will be released. When it is released, it will be added to the next revision of SWRA640.

    I'm adding the additional information below just for clarity (it looks like you have already done this):

    Within SmartRF Studio you can configure the device for the single-ended configurations without having to manually add these overrides.

    Starting with configuring RF_P, this can be done via the following steps:

    • Select the CC1352P7 and Proprietary mode from the main menu
    • Settings (in the top bar) -> Custom Target Configuration
    • In Target Selection create a new configuration (it may be easier to select Create Copy As... to copy over the I/O Configuration and PA Table)
    • Name the target what you like (CC1352P7_IS_RFP for example) and make sure that the CC1352P7 is selected
    • Select the front-end configuration you need (Internal Bias, Single-ended RF on RFP)
    • Save the configuration
    • Check that your new Target Configuration is selected from the drop-down list (RF Design Based On:)

    This should configure the device correctly for RF_P, although you may also need to check that the PA table contains the settings you need. If not then you will need to add them from the Custom Target Configuration window.

    I do not know your layout (I/O configuration, ect.) so it is best if you configure this as needed yourself.

    Regards,

    Zack

  • 0 in reply to ZC
    Prodigy 10 points

    Thanks, that is exactly the procedure that I followed before and have repeated for verification. When I select the front end configuration for Internal Bias, Single-ended RF on RFP, I am indeed getting the 0dBm output power that I am expecting.

    The thing is, and please do correct me if I'm wrong, setting the front end config to SE-RF on RF_p (without any overrides) configures it to expect RX signals on RF_p as well... Our design uses a RX/TX diversity setup and expects RX on RF_n and should use RF_p just for TX. 

    So I would argue that I would need to set the front-end config to SE-RF on RF_n (0x2) with the override (0x1) so TX is routed to RF_p... which unfortunately results in a ~30dB drop in output power with respect to setting frontEnd mode to RF_p (frontEnd mode 0x1).  

    I have included the relevant part of our schematic with the CC1352 and the RF PA and LNA. I am currently measuring at the location indicated with the green arrow in the lower part of the schematic. 

    Schematic

  • 0 in reply to Rene Arts
    Prodigy 10 points

    Hi there,

    Hoping you've been able to discuss this internally! 

    I've also been ploughing through a few more things, trying to get a better grasp of what is happening. I tried starting with various different typical settings within SmartRF Studio, both their 'stock' values as well as changing them to suit our needs. All without a satisfactory result. Mainly tried these as I noticed that some use different override configurations. 

    I have also tried playing around with some undocumented / reserved values for the frontEndMode and override settings, all to no avail. 

    Finally I have measured at the RFp and RFn pins with an oscilloscope, please find the results attached. Channel 1 (yellow) is measured on pin RFp, Channel 2 (green) is measured on pin RFn. All results were obtained using the SmartRF Studio standard setting for 433MHz, 50kbps, 25kHz dev, 2-GFSK, 78kHz RX BW. I have altered the frontEndMode setting and added/altered the override as described in SWRA640 rev. H with setting 0, 1 and 2. 

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 0

    Mode 0: As expected: differential output visible on both RFp and RFn. 

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 1

    Mode 1: As expected:Output on RFp, RFn shows some crosstalk

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 1, override 1

    Mode 1, override 1 on different time scale. As expected and identical to Mode 1 without override. Output signal on RFp, crosstalk on RFn. 

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 1, override 2

    Mode 1, override = 2. Also not as expected: Bias seems enabled on RFn but no visible signal / modulation. 

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 2, no override

    Mode 2, no override: As expected:Output on RFn, RFp shows some crosstalk

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 2, override 0

    Mode 2, override = 0: As expected:Output on RFn, RFp shows some crosstalk

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 2, override 1

    mode 2, override 1 small Vscale

    Mode 2, override = 1: Two plots with different Vscale. Packet structure is visible but has not much signal power.

    ----------------------------------------------------------------------------------------------------------------------------------

    mode 2, override 2

    Mode 2, override = 2: Identical to mode 2, no override, as expected:Output on RFn, RFp shows some crosstalk.

    ----------------------------------------------------------------------------------------------------------------------------------

  • 0 in reply to Rene Arts
    Prodigy 10 points

    Update: Today I have also tested several configuration permutations with the LP-CC1352P7-4 devkit using SmartRF studio. With that setup I observe identical behavior as with our custom boards (we have multiple designs that all suffer from this issue).

    Short recap on what I have tested with the LP-CC1352P7-4 devkit: 

    - Connect the devkit to my PC with and appropriate USB cable

    - Opened the device SmartRF Studio where it was correctly listed as a connected device. 

    - Selected the LP-CC1352P7-4 target configuration and saved it as a new custom design with "Create new copy".

    - Experimented with different Typical Settings (e.g. 431-27MHz 50kbps and 359-430MHz 4.8kbps), also experimented with our custom frequency

    - Experimented with different FrontEndMode settings and override settings (none, 0, 1, 2) for the settings mentioned above. 

    - All 'regular' settings seem to work fine, though both settings using the override (frontEndMode 1, OVR 2 and frontEndMode 2, OVR 1) are not yielding any significant signal on the output. 

    Other factors I have been experimenting with over the last week(s), all without any satisfactory result:

    - Different SmartRF Studio versions (2.30, 2.29, 2.28, 2.27)

    - Different versions of the SimpleLink CC13xx CC26xx SDK (7.10.00.98, 7.10.01.24, 7.10.02.23, 7.40.00.77) on CCS version 12.7.1.00001 

    - Updated TI ARM Clang Complier tools to 3.2.2

    - Different operating systems (Windows 11 Pro, Ubuntu Linux 22.04 based)

    - Different locale settings (NL / Dutch, US / English) - I have previously experienced obscure behavior of software tooling in relation with decimal points and comma's though I could not find any relation here.

  • 0 in reply to Rene Arts
    TI__Genius 17955 points

    Hi Rene,

    I am just replying to note that your issue has not been forgotten, I have reached out to our design team and am still waiting for a response - I am pushing for a reply by the end of this week.

    Regards,

    Zack

  • 0 in reply to ZC
    Prodigy 10 points

    Quick update from our side: we've noticed that TI has released a new version of the SDK 7.41.00.17, we've tested with this as well and have not seen any improvement regarding our issue. 

  • 0 in reply to ZC
    Prodigy 10 points

    Hi Zack,

    Since it's been a few weeks and I haven't heard from you nor from anyone else here; I was wondering if there's any progress on this internally. We're still anxiously waiting for a resolution as we're currently halting our production and are looking into alternative solutions. It'd be great if you would be able to respond and share whether there's been any progress. Thanks! 

  • 0 in reply to Rene Arts
    TI__Genius 17955 points

    Hi Rene,

    This has not been forgotten about, please can you try adding the additional override:

    (uint32_t) 0x30108703

  • 0 in reply to ZC
    Prodigy 10 points

    Awesome and thanks. I still have some more rigorous testing to do, but the first results look very promising. I am cautiously optimistic that this may have resolved the issue I have been battling. 

    I'll get back once I am able to confirm that we're happy with this solution.