• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 570 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.

Using RF Timer for packet duration calculation

Leonid A.
Expert 1630 points

HI, I am using RF timer time stamp for calculation of the received packet duration as following:

preamble length : 4 bytes

sync                 : 4 bytes 

length               :  1 byte                 

data                  :  17 byte

CRC                 : 2 bytes

#define RADIO_TIME_2_MCS(radioTime) (radioTime /4)

/* Enter RX mode and stay forever in RX */
RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRx, RF_PriorityNormal, &callback, IRQ_RX_ENTRY_DONE);

...

void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
{

if (e & RF_EventRxEntryDone)
{

TxTS = m_rxStatistics.timeStamp;

RxTS = RF_getCurrentTime();   //taken in callback()              

                        Duration = RADIO_TIME_2_MCS(RxTS - TxTS); 

....

}

}

Data Rate:50 kb/sec

the result:5040-5060 mcs

packet length = Duration/160 = 31.625

but actual length is 28 bytes

Q: what is the right way to use Rf timer time stamps?

  • 0
    TI__Genius 14860 points

    [EDIT] Corrected the meaning of the appended timestamp.

    Hi Lenoid,

    are you implementing a time synchronization mechanism? Here I have described an approach where you don't need to measure anything beforehand. I've included a more detailed explanation in the new SDK documentation (docs/proprietary-rf-documentation). You can use the two-way approach to measure the offset between starting a TX command and sending the first preamble byte. This is a value that cannot be measured directly and is RF settings-specific. Once you have it, you can implement a one-way synchronization application (as long as you use the same RF settings).

    For getting RX timestamps, you could also just append the timestamp to the packet. It is then put behind the payload:

    RF_cmdPropRx.rxConf.bAppendTimestamp = 1;

    Anyway, the timestamp is the time of the first preamble bit on the air. The receiver extrapolates this information from the time when the syncword was found and the settings specified via the setup command.

    Richard

  • 0 in reply to Richard W.
    Expert 1630 points
    Hi Richard,
    Thanks once again for the time synchronization mechanism explanation.

    Here is the Siri's answer(31/10/2016):
    The built in timestamp is calculated by taking the local time of when the receiver got the internal sync found signal, and then deducts an estimate of the time it took to send preamble and sync word. It also includes an estimate of the RX and TX delay. This is important because the time when the internal sync found signal is triggered will actually include these delays. This is all done is such a way that the timestamp on the RX side will closely approximate the start of the preamble on the TX side.

    I try to understand what's wrong in our the packet duration calculation.

    BR
    Leonid
  • 0 in reply to Leonid A.
    Expert 1630 points
    May be it is the latency between the pCb calling and RF driver?
    see : RF_runCmd(RF_Handle h, RF_Op* pOp, RF_Priority ePri, RF_Callback pCb, RF_EventMask bmEvent);
  • 0 in reply to Leonid A.
    TI__Genius 14860 points

    Leonid,

    1. I was wrong about the appended timestamp and corrected the explanation in my previous post.
    2. Callbacks from the RF driver have a certain undeterministic delay and are not recommended for actions which need a high time precision.

    Q: How do you deduce TxTS in your above code? Is it included into the packet payload? Is it the same as the transmitter uses as start trigger for the TX command?

  • 0 in reply to Richard W.
    Expert 1630 points

    Hi Richard,

    1.

    here the code:

    TxTS = m_rxStatistics.timeStamp;

    RxTS = RF_getCurrentTime();   //taken in callback()    

    I see, that accordance to your and Siri explanation  m_rxStatistics.timeStamp is the Time Stamp of the receiving the 1st bit of preamble( after all interpolations and etc...) .

    So it looks looks like the  latency of the switch from the RF driver code to the callback is about 480 mcsec(3 bytes duration).

    2. We use only the m_rxStatistics.timeStamp in our calculations

    3. I take into account context switch duration from callback to the application (50-60m mcs) and RF_close(rfHandle) command duration (~160 mcs).

     BR

    Leonid