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: Different power emission with different settings - all don't make sense

Part Number: CC1310


With the TI CC1310-LaunchPad connected to SmartStudioRF, I read on my power sensor tool:

868MHz, 50kbps, 14dbm: 11.15dbm
868MHz, 500kbps, 14dbm: 11.15dbm
915MHz, 50kbps, 14dbm: 8.95dbm
915MHz, 500kbps, 14dbm: 8.95dbm

So, if the frequency goes away from 868MHz, the power emitted at the antenna is less. My analysis is that the passive network is super optimized for 868MHz so there is greater loss when going away from that frequency.

With my custom board which has the Johanson Balun, I read on my power sensor tool:

915MHz, 50kbps, 14dbm: 12.3dbm
868MHz, 50kbps, 14dbm: 12.3dbm
868MHz, 500kbps, 14dbm: 7.99dbm
915MHz, 500kbps, 14dbm: 7.96dbm

My analysis is that the balun doesn't change the outgoing power across the supported frequency range. Good.

But I have a 4dbm loss when I increase the symbol rate. I suspect a software problem. Why is that? How can I avoid that?

To run and get those numbers, I have exported the c-code from the SmartRF Studio with the relevant settings of each test (nothing else changed) and I'm using the demo EasylinkRFTX and transmit all the time.

  • Hi Gregoire,

    The difference between 868 MHz and 915 MHz is not that large, you can refer to section 5.20 in the datasheet for details. The only way to measure this accurately is through a conducted setup or radiated in an anechoic chamber. Simply measuring RSSI from a receiver device on your desk will not give accurate performance numbers.

    Regards,
    Fredrik
  • Thank you for trying to help, but unfortunately, that's not helping. I can reproduce those numbers and they are not "random" because it's on my desk. If I could repeat in a nuclear plant with 20-feet concrete around, I really doubt it's going to give me something completely different especially as the power is measured with cables out of the CC1310 chip. It's not spying in the air by measuring RSSI...

    The difference between 868 and 915 doesn't bother to me. But the difference in the second test does bother me and it's very likely software related.
  • Hi Gregoire,

    Can you share a photo of your setup? Your results are not aligned with the expected performance, so I suspect there is an issue with how you are measuring.

    I did not catch that in the second case the measured power varies with symbol rate. Do you see the same if you control your device directly from SmartRF Studio? What power levels do you measure if you use a CW output instead of a modulated signal.

    Also, what is your "power sensing tool"? Is it a proper RF power meter, or something else?

    Regards,
    Fredrik
  • Yes, the RF power meter is a wired power sensor: www.minicircuits.com/.../dashboard.html. It's not a sniffer.

    For the first case, Windows 10 -> SmartRF Studio -> CC1310 LaunchPad -> Power sensor. In any case, I don't care about the variance over the frequency when not using a balun.

    For the second case, I cannot link my board to the SmartRFStudio. The point is that at 50kbps, output power is around 12dbm which makes sense. there is going to be a loss in the balun. The output power diminishes if I increase the symbol baud rate. That's my problem as I want to be at 500kbps.

    I have tried to play with the c-code settings but it's not changing the output power. there is a glass ceiling of 8dbm at 500kbps. The output power seems be linear from 8 to 12dbm for 500 to 50kpbs. That's the issue.
  • Settings at 915@500:

    //*********************************************************************************
    // Generated by SmartRF Studio version 2.13.1 (build#180)
    // The applied template is compatible with CC13x0 SDK version 2.10.xx.xx or newer.
    // Device: CC1310 Rev. B (2.1)
    //
    //*********************************************************************************
    
    
    //*********************************************************************************
    // Parameter summary
    // RX Address0: 0xAA 
    // RX Address1: 0xBB 
    // RX Address Mode: No address check 
    // Frequency: 915.00000 MHz
    // Data Format: Serial mode disable 
    // Deviation: 175.000 kHz
    // Packet Length Config: Variable 
    // Max Packet Length: 255 
    // Packet Length: 20 
    // Packet Data: 255 
    // RX Filter BW: 1243 kHz
    // Symbol Rate: 500.00000 kBaud
    // Sync Word Length: 32 Bits 
    // TX Power: 14 dBm (requires define CCFG_FORCE_VDDR_HH = 1 in ccfg.c, see CC13xx/CC26xx Technical Reference Manual)
    // Whitening: No whitening 
    
    #include <ti/devices/DeviceFamily.h>
    #include DeviceFamily_constructPath(driverlib/rf_mailbox.h)
    #include DeviceFamily_constructPath(driverlib/rf_common_cmd.h)
    #include DeviceFamily_constructPath(driverlib/rf_prop_cmd.h)
    #include <ti/drivers/rf/RF.h>
    #include DeviceFamily_constructPath(rf_patches/rf_patch_cpe_genfsk.h)
    #include DeviceFamily_constructPath(rf_patches/rf_patch_rfe_genfsk.h)
    #include "915-500.h"
    
    
    // TI-RTOS RF Mode Object
    RF_Mode RF_prop =
    {
        .rfMode = RF_MODE_PROPRIETARY_SUB_1,
        .cpePatchFxn = &rf_patch_cpe_genfsk,
        .mcePatchFxn = 0,
        .rfePatchFxn = &rf_patch_rfe_genfsk
    };
    
    
    // Overrides for CMD_PROP_RADIO_DIV_SETUP
    uint32_t pOverrides[] =
    {
        // override_use_patch_prop_genfsk.xml
        // PHY: Use MCE ROM bank 4, RFE RAM patch
        MCE_RFE_OVERRIDE(0,4,0,1,0,0),
        // override_synth_prop_863_930_div5.xml
        // Synth: Set recommended RTRIM to 7
        HW_REG_OVERRIDE(0x4038,0x0037),
        // Synth: Set Fref to 4 MHz
        (uint32_t)0x000684A3,
        // Synth: Configure fine calibration setting
        HW_REG_OVERRIDE(0x4020,0x7F00),
        // Synth: Configure fine calibration setting
        HW_REG_OVERRIDE(0x4064,0x0040),
        // Synth: Configure fine calibration setting
        (uint32_t)0xB1070503,
        // Synth: Configure fine calibration setting
        (uint32_t)0x05330523,
        // Synth: Set loop bandwidth after lock to 20 kHz
        (uint32_t)0x0A480583,
        // Synth: Set loop bandwidth after lock to 20 kHz
        (uint32_t)0x7AB80603,
        // Synth: Configure VCO LDO (in ADI1, set VCOLDOCFG=0x9F to use voltage input reference)
        ADI_REG_OVERRIDE(1,4,0x9F),
        // Synth: Configure synth LDO (in ADI1, set SLDOCTL0.COMP_CAP=1)
        ADI_HALFREG_OVERRIDE(1,7,0x4,0x4),
        // Synth: Use 24 MHz XOSC as synth clock, enable extra PLL filtering
        (uint32_t)0x02010403,
        // Synth: Configure extra PLL filtering
        (uint32_t)0x00108463,
        // Synth: Increase synth programming timeout (0x04B0 RAT ticks = 300 us)
        (uint32_t)0x04B00243,
        // override_synth_disable_bias_div5.xml
        // Synth: Set divider bias to disabled
        HW32_ARRAY_OVERRIDE(0x405C,1),
        // Synth: Set divider bias to disabled (specific for loDivider=5)
        (uint32_t)0x18000200,
        // override_phy_rx_aaf_bw_0x0.xml
        // Rx: Set anti-aliasing filter bandwidth to 0x0 (in ADI0, set IFAMPCTL3[7:4]=0x0)
        ADI_HALFREG_OVERRIDE(0,61,0xF,0x0),
        // override_phy_gfsk_rx.xml
        // Rx: Set LNA bias current trim offset to 3
        (uint32_t)0x00038883,
        // Rx: Freeze RSSI on sync found event
        HW_REG_OVERRIDE(0x6084,0x35F1),
        // override_phy_gfsk_pa_ramp_5us_agc_reflevel_0x24.xml
        // Tx: Configure PA ramping setting (0x10) for approximately 5 us PA ramp time. Rx: Set AGC reference level to 0x24.
        HW_REG_OVERRIDE(0x6088,0x1024),
        // Tx: Configure PA ramping setting (0x08) for approximately 5 us PA ramp time
        HW_REG_OVERRIDE(0x608C,0x0813),
        // override_phy_rx_rssi_offset_5db.xml
        // Rx: Set RSSI offset to adjust reported RSSI by +5 dB (default: 0), trimmed for external bias and differential configuration
        (uint32_t)0x00FB88A3,
        // TX power override
        // Tx: Set PA trim to max (in ADI0, set PACTL0=0xF8)
        ADI_REG_OVERRIDE(0,12,0xF8),
        (uint32_t)0xFFFFFFFF
    };
    
    
    // CMD_PROP_RADIO_DIV_SETUP
    // Proprietary Mode Radio Setup Command for All Frequency Bands
    rfc_CMD_PROP_RADIO_DIV_SETUP_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 = 0x2BC,
        .symbolRate.preScale = 0x6,
        .symbolRate.rateWord = 0x20000,
        .symbolRate.decimMode = 0x0,
        .rxBw = 0x2F,
        .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,
        .txPower = 0xA73F,
        .pRegOverride = pOverrides,
        .centerFreq = 0x0393,
        .intFreq = 0x8000,
        .loDivider = 0x05
    };
    
    
    // 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 = 0x0393,
        .fractFreq = 0x0000,
        .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
    };
    

  • Hi Gregoire,

    Can you replicate your measurements with a spectrum analyzer?

    Why are you not able to control your custom board from SmartRF Studio?

    Regards,
    Fredrik
  • Yes, I can see it on a spectrum analyzer.

    SmartRF Studio isn't going to change anything here. The final code should run on my board, my product is not to use SmartRF Studio. SmartRF Studio flashes its own firmware, it's not the firmware my product is going to use.
  • Hi Gregoir,

    Can you post some screen captures from the spectrum analyzer as well as a photo of your HW and how it is connected to the instrument?

    I would like to see how SmartRF Studio by itself performs to rule out, or conclude on, SW being the source of the problem.

    Regards,
    Fredrik
  • How couldn't it be a software problem?

    LaunchPad, 868MHz, 50kbps, 14dbm: 11.15dbm

    LaunchPad, 868MHz, 500kbps, 14dbm: 11.15dbm

    Custom board, 868MHz, 50kbps, 14dbm: 12.3dbm

    Custom board, 868MHz, 500kbps, 14dbm: 7.99dbm

    http://gentil.com/tmp/setup.jpg

    http://gentil.com/tmp/868-500.png

  • What happens if you switch from "modulated" to "unmodulated"?
  • Does it make any difference if you enter the operating frequency in the power meter GUI?
  • Interesting question: the same.

    If I play with the settings of SmartRF Studio, the output power doesn't change except for a variation of the frequency which I attribute to the fact that the passive network (balun equivalent) is more optimized for 868MHz. But that doesn't worry me and doesn't matter to me.

    For my own custom board problem, I'm doing a loop of EasyLink_transmit(&txPacket); with the c-code settings exported from SmartRF Studio and (posted above). The baudrate influences the maximum power output which doesn't make sense at least for a 33% loss.

    The tool does measure the peaks of output power.

    Perhaps because 500kbps goes faster than 50kbps, the chip goes in some kind of low power mode between each transmit though I have no sleep. In the continuous TX of SmartRFStudio, it seems that a command is sent to the radio to send continuously, so it's a total different approach that is not suitable in a "real life" product.

    I still believe that there is a wrong (or un-optimized) setting somewhere for 500kbps and the different readings I'm seeing is not something due to the measuring tool itself.
  • This is a very expensive, high-quality tool. No changing the operating frequency doesn't change anything.
  • Hi Gregoire,

    I ran some measurements with a CC1310 LaunchPad controlled by SmartRF Studio. On a spectrum analyzer I could not see any difference in output power between 50 kbps and 500 kbps at any frequency.

    Did you try to reproduce your measurements on a spectrum analyzer instead of the power meter? Did you try controlling your custom HW directly from SmartRF Studio?

    Regards,
    Fredrik
  • Hy Gregoire,
    Have you checked your custom Board with SmartRF Studio?
    Try accessing the custom Board with SmartRF studio and do the measurement and see if there will be any variation?
  • I am closing this thread due to inactivity.