• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 1570 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/CC1310: The trigger mode for TX and Rx modes of CC1310

weihan.ji
Intellectual 580 points
Part Number: CC1310

Tool/software: TI-RTOS

Hi all，

I use absolute start triggers (TRIG_ABSTIME)in TX modle，and  i use RF_getCurrentTime() to get the timestamp I need to use.when I complete the TX mode and switch to RX mode,do I need to reset the trigger?

And do i need to get the timestamp  by use RF_getCurrentTime() again.

  • 0
    TI__Genius 14860 points

    Hi,

    this is how I interpret your question:

    • You want to send a packet with an absolute start time
    • After TX has completed, you want to switch to RX and you also want to use an absolute start time.
    • You want to know whether you need to call RF_getCurrentTime() again after the TX command has completed to calculate a valid start trigger for the RX command.

    Is this interpretation correct? In that case, the answer is no. You do not need to call RF_getCurrentTime() again because the the time when TX completes is predictable and the radio timer is constantly counting up. The time for TX is 50 us for command parsing + 384 RAT ticks (96 us)  between start trigger and the first bit on air + the time needed to send n preamble bytes + sync word + payload + CRC. The latter depends on the configured symbol rate.

    So you only need to make sure that the calculated start time for the RX command is really after the TX command has completed. You could also chain the RX command to the TX command then program a start trigger relative to the TX command if you want.

    I hope that this answers your question.

  • 0 in reply to Richard W.
    Intellectual 580 points
    Hi, Richard
    Thanks for your answer，now I understand how absolute time works.And i have a new question, i try to use a endtime to control the RX's time，and my configuration and operation of Rx are approximately as follows:

    RF_cmdRxHS.pQueue = &RX_dataQueue;
    RF_cmdRxHS.maxPktLen = RX_MAX_LENGTH;
    RF_cmdRxHS.pktConf.bRepeatOk = 0;
    RF_cmdRxHS.pktConf.bRepeatNok = 0;
    RF_cmdRxHS.rxConf.bAutoFlushCrcErr = 0; //
    RF_cmdRxHS.startTrigger.triggerType = TRIG_ABSTIME;
    RF_cmdRxHS.startTrigger.pastTrig = 1;
    RF_cmdRxHS.endTrigger.triggerType = TRIG_ABSTIME;
    RF_cmdRxHS.endTrigger.pastTrig = 1;*/


    rfHandle = RF_open();

    RF_pCmdRxHS->endTime = RX_Cmd_EndTime; //the end time is a future time stamps


    rxCommandHandle = RF_runCmd();




    But I always feel that RX has stopped accepting the data and not stopped at the endtime I set.

    Thanks again
  • 0 in reply to weihan.ji
    Expert 2050 points
    well with bRepeat = 0, RX will finish after the first received packet, which may be before your configured endtime.

    Set these to 1 if you want it to receive multiple packets with one RX command and have it wait until your end time to finish.

    Also check your pktConf.endType setting - this determines what happens if your end trigger occurs *while* receiving a packet - choose between aborting reception and finishing immediately, or waiting until the packet is fully received before finishing.

    If you're intending to transmit afterwards, filterOp is important too - this determines whether RX will completely receive but discard packets with wrong address or other bogus header data, or simply return to sync search or finish while the bad packet is still on the air.

    If you chain commands together using pNextOp before handing the first one to RF_runCmd or RF_postCmd, you need to set up all the trigger times first and the radio will execute them as commanded. This is the recommended way. Note that you can mix different trigger types from one command to the next depending on your timing requirements, this can reduce the number of commands you have to change each loop by making subsequent commands relative to their start, or to first start or whatever you like.

    If you issue each command individually with RF_runCmd, the timing will vary and you may have to adjust each command before posting it.