• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 2053 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.

CMD_PROP_CS to report BUSY or IDLE only

Mark Barr38
Prodigy 60 points

Other Parts Discussed in Thread: SIMPLICITI

I am trying to use CMD_PROP_CS command to tell me IDLE or BUSY after a reasonable amount of time (e.g. 8 symbols worth).
Here is my current understanding of how I need to fill in rfc_CMD_PROP_CS_t (using rfListenBeforeTalk example as a starting place):

rfc_CMD_PROP_CS_t RF_cmdPropCs =
{
.commandNo = CMD_PROP_CS,
.status    = 0x0000,
.pNextOp   = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = TRIG_NOW,
.startTrigger.bEnaCmd   = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig  = 0x0,
.condition.rule = COND_NEVER, // Do not run a next command
      // End causes for the CMD_PROP_CS command:
      // Observed channel state Busy with csConf.busyOp = 1:                PROP_DONE_BUSY TRUE
      // 0bserved channel state Idle with csConf.idleOp = 1:                PROP_DONE_IDLE FALSE
      // Timeout trigger observed with channel state Busy:                  PROP_DONE_BUSY TRUE
      // Timeout trigger observed with channel state Idle:                  PROP_DONE_IDLE FALSE
      // Timeout trigger observed with channel state Invalid and csConf.timeoutRes = 0:
      //                                                                    PROP_DONE_BUSYTIMEOUT TRUE
      // Received CMD_STOP after command started: PROP_DONE_STOPPED FALSE
.condition.nSkip     = 0x0, // Not used (rule does not involve skipping)
.csFsConf.bFsOffIdle = 0x0, // Keep synthesizer running if command ends with channel Idle
.csFsConf.bFsOffBusy = 0x0, // Keep synthesizer running if command ends with Busy
.__dummy0 = 0x00,
.csConf.bEnaRssi  = 0x1, // Enable RSSI as a criterion
.csConf.bEnaCorr  = 0x0, // Disable correlation (PQT) as a criterion
.csConf.operation = 0x0, // Busy if either RSSI or correlation indicates Busy
.csConf.busyOp    = 0x1, // End carrier sense on channel Busy
.csConf.idleOp    = 0x1, // End carrier sense on channel Idle
.csConf.timeoutRes = 0x0, // Timeout with channel state Invalid treated as Busy
.rssiThr          = -90, // Set the RSSI threshold in the application
.numRssiIdle      = 0x4, // Number of consecutive RSSI measurements - 1 below the threshold
                         //   before the channel is Idle
.numRssiBusy      = 0x4, // Number of consecutive RSSI measurements -1 above the threshold
                         //   before the channel is Busy
.corrPeriod       = 0x0000,      // N/A since .csConf.bEnaCorr = 0
.corrConfig.numCorrInv    = 0x0, // N/A since .csConf.bEnaCorr = 0
.corrConfig.numCorrBusy   = 0x0, // N/A since .csConf.bEnaCorr = 0
.csEndTrigger.triggerType = TRIG_REL_START, // Trigs at a time relative to the command started
.csEndTrigger.bEnaCmd     = 0x0,
.csEndTrigger.triggerNo   = 0x0,
.csEndTrigger.pastTrig    = 0x0,
.csEndTime                = <radio-tics>, // Set the CS end time in the application
};

<radio-tics> = microseconds * 4, where microseconds should be the maximum time to wait.

Here is what happens (I think):

  • If 4 consecutive symbols come in above or below the threshold, CMD_PROP_CS will end with PROP_DONE_BUSY or PROP_DONE_IDLE.
  • If 4 consecutive symbols do not occur above or below the threshold within <radio-tics>, CMD_PROP_CS will end with PROP_DONE_BUSYTIMEOUT

Question:

  • Is there a way to get CMD_PROP_CS to report 4 symbols above/below threshold without having to give an csEndTime?
  • If I need to give a csEndTime (otherwise, CMD_PROP_CS could possibly hang), how do I calculate this time for FSK, LRM, and HighSpeed?
    • I want to set the csEndTime to be about 8 symbols worth for FSK, LRM, and HighSpeed. How do I do this?
    • For example, with 2-GFSK@50Kbps waiting 8 symbols for CMD_PROP_CS would be as follows:
      • 1bit/symbol gives 20us/symbol. For 8 symbols, microseconds = 8 * 20 = 160us. Thus, <radio-tics> = 160 * 4. Is this a correct for csEndTime?.  
      • How do I do equivalent calculations for LRM or HighSpeed? What is the bit-encoding?

  • 0
    Prodigy 60 points

    I found another related forum post: How to calculate carrier sense period and sampling time

    https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/p/541261/1980333

    This post says "RSSI update period depends on the configured RX bandwidth"

    For 2-GFSK@50kpbs, the RX Filter BW (RF_cmdPropRadioDivSetup) is 98 kHz from SmartRF Studio.
    From the post, the RSSI update period would be 2*34 us. Correct?

    What about the RSSI update period for LRM.  In SmartRF Studio, it has a RX Filter BW of 39 kHz? There is no RSSI update period listed for this mode?

    Likewise, what about HighSpeed? 

    Again, I am trying to determine how to use carrier sense (over a few symbol times or RSSI updates) to determine if IDLE/BUSY across modes FSK, LRM, HS.

  • 0 in reply to Mark Barr38
    TI__Guru* 87251 points

    Hi

    Unfortunately we do not have any formulas that will calculate this for the different modes so the easiest thing to do is to measure it.

    I took the LBT example and change the CS_RETRIES_WHEN_BUSY to 1. I then output the LNA_PD signal to LED_4. This can be done by adding the following to the code example:

    #include <ti/drivers/pin/PINCC26XX.h>

    PIN_Config ledPinTable[] =

    {

    Board_LED1 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,

    Board_LED0 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,

    PIN_TERMINATE

    };

    /* Route out LNA active pin to LED_4 */

    PINCC26XX_setMux(ledPinHandle, Board_LED0, PINCC26XX_MUX_RFC_GPO0);

    I then measured the time LED_4 was asserted (radio in RX) for different values of numRssiIdle/ numRssiBusy. When numRssiIdle and numRssiBusy is 4, and there are a jammer present, the chip will need around 550 us to determine is the channel is busy or not meaning that the csEndTime should be longer than this.

    This exercise you can do for both LRM and HSM also.

    Siri

  • 0 in reply to Siri
    Prodigy 60 points

    Thanks for the suggestion - I was unaware of this functionaltity from the RF Core.

    I did a different another timing method (albeit more cumbersome):

    • I used a jammer by having SmartRF Studio continuously transmit on a SmartRF06 Board

    • Next, I just called CMD_PROP_CS (using the previous post settings) and just kept shortening csEndTime until the CPE reported PROP_DONE_BUSYTIMEOUT instead of PROP_DONE_BUSY.

    • For FSK@50kbps with numRssiBusy = 4, the csEndTime must be >= 538 * 4 us to get PROP_DONE_BUSY status from the CPE for the CMD_PROP_CS command. Thus, The CPE needs at least 538us to determine if the channel is busy.

    This is close to your results!

  • 0 in reply to Mark Barr38
    Prodigy 175 points
    Hello
    Can you please put up the code for how you called CMD_PROP_CS command?
    I am implementing a similar example and I am confused as to how the command is called.
  • 0 in reply to Chetana Reddy
    TI__Guru* 87251 points

    Look in the LBT example I have reffered to to see how the command can be called

    Siri