• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 171 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.

CC1311P3: How to get event callbacks for chained commands

David Paden
Expert 1925 points
Part Number: CC1311P3

Tool/software:

I am implementing a radio with Listen Before Talk.  I based my solution off of the example, and the CCA/LBT is working.  However, I want to get an indication if the CCA failed or not, and go back to Rx immediately upon CCA failure.  I use RF_postCmd() on RF_cmdPropCs to start the process, but the callback only triggers RF_EventLastCmdDone when the transmission is successful.  How can I get read the status of RF_cmdPropCs and/or RF_cmdCountBranch from the callback if the CCA check fails?

The RF_postCmd call I use is:

RF_postCmd(RF_ObjPtr, (RF_Op*)&RF_cmdPropCs, RF_PriorityNormal, &RF_CmdCallback, 0);
  • +1
    TI__Guru* 86131 points

    I am not sure I understand what you want. 

    When you say you want to go back to RX after CCA failure, I assume that you want the chain to finish before going back to RX?

    If not, why do you set up a chain that you do not want to run to completion?

    When you run the chain from the LBT example, you will get a callback when the chain is done. At this point, either the packet has been sent or it has not been sent. Now you can choose to call run the chain again, or you can run for example an RX command.

    If you want to know the status after each of the commands in the chain, you can off course subscribe to RF_EventCmdDone event (will happen after each commands int he chain), and then, in your callback, you can check status of the individual command every time RF_EventCmdDone is asserted.

    However, the purpose of a chain is to let the radio operate without MCU intervention, so I would suggest that you instead alter your chain if it is not doing what you want.

    Siri

  • 0 in reply to Siri
    Expert 1925 points

    Hello Siri,

    I think the missing item was subscribing to the RF_EventCmdDone.  I was under the impression this was implicit since RF_EventLasCmdDone is implicit and I was getting some RF_EventCmdDone calls, but I found this was not the case for command chains.  In the end, I needed enough information to determine WHICH command was the last command and I didn't want to store every command's ID/handle.

    The LBT example uses retries, and so on LBT failure, cmdCountBranch is the last command.  If you do not use retries (as in our original radio implementation), then cmdPropCs is the last command.  If LBT succeeds, then cmdPropTx is the last command.  I wanted my event handler to be able to check all of these cases...not just one.

    Anyway, the issue is not that I wanted to intervene in the command chain, but I needed to know the final state of the command chain (did it transmit or not, did the whole chain succeed or did it stop at one of the earlier commands).  After subscribing to RF_EventCmdDone, I was able to get enough information in the callback to detect all the cases I needed.

  • 0 in reply to David Paden
    TI__Guru* 86131 points

    Glad to hear you were able to find a solution that worked for your use/case.

    BR

    Siri