• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 54 subscribers
  • Views 710 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.

CC1352P: Radio command chain for TDMA

Mike Snyder
Intellectual 285 points
Part Number: CC1352P

Could chaining/counting be used to implement a TDMA network? 

For instance, could the TDMA master TX in slot 0, RX in slots 1-n, then back to TX? 

    if (isMaster()) {
        /* Set up the next pointers for the command chain */
        /* 1: Nop->TX (no condition) */
       rf_ctx.RF_cmdNop->startTrigger.triggerType = TRIG_ABSTIME;
       rf_ctx.RF_cmdNop->startTrigger.pastTrig = 1;
       rf_ctx.RF_cmdNop->pNextOp = (rfc_radioOp_t*)rf_ctx.RF_cmdPropTx;
       rf_ctx.RF_cmdNop->condition.rule = COND_ALWAYS;

       /* 2: TX->Branch (no condition)*/
       rf_ctx.RF_cmdPropTx->condition.rule = COND_ALWAYS;
       rf_ctx.RF_cmdPropTx->pNextOp = (rfc_radioOp_t*)rf_ctx.RF_cmdCountBranch;

       /*3: Branch->Rx (when count !=0)
        *   Branch->Tx (when count ==0) */
       rf_ctx.RF_cmdCountBranch->condition.rule = COND_SKIP_ON_FALSE;  /* If count==0 return FALSE */
       rf_ctx.RF_cmdCountBranch->pNextOp = (rfc_radioOp_t*)rf_ctx.RF_cmdPropRx;
       rf_ctx.RF_cmdCountBranch->pNextOpIfOk = (rfc_radioOp_t*)rf_ctx.RF_cmdPropTx;
       rf_ctx.RF_cmdCountBranch->counter = radio_cfg.numSlots - 1;
    }

If so, how could you set up triggers for that? Is it technically TRIG_NOW when firing chained events? 

    rf_ctx.RF_cmdPropRx->startTrigger.triggerType = TRIG_NOW; // executes 'now' in chain context?
    rf_ctx.RF_cmdPropRx->endTrigger.triggerType = TRIG_REL_START;
    rf_ctx.RF_cmdPropRx->endTime = PACKET_INTERVAL_US;

  • 0
    TI__Mastermind 25255 points

    Hi Mike,

    TRIG_NOW, in chain context, means the command will be executed immediately after the previous command is done.

    As you want to implement TDMA, you might want to configure CMD_PROP_TX and CMD_PROP_RX to have endTriggers set to TRIG_REL_START.

    That way, you could have fixed duration slots, and in your case, using CMD_COUNT_BRANCH, you could branch to CMD_PROP_RX a certain amount of times before branching out to CMD_PROP_TX/CMD_NOP.

    Regards,

    Arthur

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    Thanks Arthur. 

    Does CMD_COUNT_BRANCH treat CMD_PROP_RX like CMD_PROP_CS? 

    I was having problems getting the counter to work with CMD_PROP_RX and was thinking the API might differ between CS/RX. 
    I was using the above configuration. 

  • 0 in reply to Mike Snyder
    TI__Mastermind 25255 points

    They should not be treated differently by CMD_COUNT_BRANCH.

    I think that you should not have the COND_SKIP_ON_FALSE rule on your CMD_COUNT_BRANCH, but COND_ALWAYS instead.

    Indeed, as it is now it will skip CMD_PROP_RX when the counter reaches 0. This could be your issue.

    Regards,

    Arthur

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    very helpful thank you. 

    would a 'listen before TX' approach work for the slave devices on the TDMA? 
    Instead of using CMD_PROP_CS, can it be done with CMD_PROP_RX? 

    The timing and triggering make sense to me, but would we need to verify a packet was actually received. 
    I know how to manage that logic in the callbacks, but not with the chaining. 

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    Arthur, what if I wanted to continuously listen for multiple packets without stopping the receiver between TDMA slots? 
    This would be without the counter I would presume. 

    Could I do a TRIG_NEVER with a TRIG_COMMAND to shut it down at the end of frame? 
    How do you restart RX when you receive a packet before end of frame? In the callback? 

    On the master, 
    It would be cool to chain RX 'constant' until end of frame, then immediately TX on TRIG_COMMAND. 

    On the slave,
    It would be cool to continuously RX until its time to TX (master slot < n < numslots - 1), then continously RX again

  • +1 in reply to Mike Snyder
    TI__Mastermind 25255 points

    Mike,

    There are options to do just what you described:

    • CMD_PROP_RX: bRepeakOk/bRepeakNok: when enabled, it allows you to carry on with RX when having received a backed correctly/incorrectly.
    • Abort when received TRIG_COMMAND

    This is explained on table 15-172 of the aforementioned TRM.

    Have you tried aborting RX with TRIG_COMMAND?=

    Regards,

    Arthur

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    Thanks Arthur. Yeah I'm aborting RX with TRIG_COMMAND right now. its working great.. 

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    Hi Arthur. 

    Dumb question - when using RX with bRepeatOk, my Rx Queue needs to accommodate 1 slot per packet that could be received. 
    I was thinking I could process these one at a time as RF_pendCmd occurs after each RX event. 

    I was getting a hard fault until I added a real queue. 

  • 0 in reply to Mike Snyder
    TI__Mastermind 25255 points

    Hi Mike,

    You indeed need a real queue, and what you describe is actually implemented in the rfPacketRx example already.

    Regards,

    Arthur

  • 0 in reply to Arthur R☑️
    Intellectual 285 points

    Thanks again Arthur

    Last question for this thread. 
    if I wanted to chain a few differently configured CMD_PROP_RX, can I just copy the struct and have them point to each other in the chain? 

    for instance 

    cmdFs[0] 
    cmdRx[0]
    cmdFs[1]
    cmdRx[1]

  • +1 in reply to Mike Snyder
    TI__Mastermind 25255 points

    Hi Mike, you can indeed do so.

    As you described, you can have a cmdRx1 pointing to a cmdRx2 with different parameters.

    Regards,

    Arthur