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

CC1310: Deviation of time sync

Viki Shi
Expert 3130 points
Part Number: CC1310


Hi,

A customer tested rf_EchoTx & rf_EchoRx on CC1310-LaunchPad, he set the send interval to 30ms, and turned off power policy, which would exclude the impact of automatically sleeping.

Test procedure: get the time from a TX board sending data to the RX board receiving it and running the callback function. Compared these data and printed them out via UART. The result showed that the deviation was up to 13-15us. How to narrow it down to below 5us?

BR,

Viki Shi

  • 0
    TI__Guru 58425 points

    Hi Viki, 

    Could you clarify what all numbers mean exactly? As for deviation, this is likely due to TI-RTOS deviation in the Swi's and this is something you should expect. You could play around with increasing the Swi priority of the RF Driver but it might or might not give you less jitter.

    Is the TX / RX timestamps as such consistent?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Expert 3130 points

    Hi,

    Explanation of the above figure:

    Printing the data every 3 seconds, which means send/receive 100 packets and print out. From left to right【us as unit】, the first one is the time from sending to receiving of every 100th packet; The second one is the minimum time from sending to receiving of a packet[including the other 99 packets]; The third one is the maximum time. From which we can see the deviation of maximum and minimum value is 21us.

    According to your suggestion, he then changed the strategy to avoid task delay. So now the testing is non RTOS------read the clock of RF core[M0] in receiving callback, get the difference value between two adjacent timestamps and compare them. The deviation is still about 11us-12us, not within 5us. Anything else we can do?

    BR,

    Viki Shi

  • 0 in reply to Viki Shi
    TI__Guru 58425 points

    Hi Viki,

    Could you share how he gets the timestamp? It does not sound like he is using the timestamp that the RF Core could (if told to) to attach to the packet in question?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Expert 3130 points

    Hi,

    He got the time via RF_getCurrentTime(). When in TX mode,he obtained the time via the same API and gave it to TX.startTime. Then added 30ms to startTime, and trigger the RF core to send when the time was reached.

    BR,

    Viki

  • 0 in reply to Viki Shi
    TI__Guru 58425 points

    Hi Viki,

    When it comes to RF synchronization I would advice he use the built in RX timestamp feature to get a proper RX timestamp to relate to. RF_getCurrentTime() only gives you the current time which would not correlate to the time when the packet was actually started to be received/sent out (depending on how you choose to look at it). 

    Using the RF_getCurrentTime(). API from the callback will include all jitter that might be in the system up until that point while the RX timestamp will be the RAT value at the point where the packet was first detected on air (it is actually from the time of "sync found" that is then later adjusted for length of preamble).