• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 947 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.

Original question:

LAUNCHXL-CC1352P: LAUNCHXL-CC1352P

LAUNCHXL-CC1352P: Interpreting reported time in the ApiMac_mcpsDataInd_t structure

jonathan bondzie
Intellectual 260 points

Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: CC2538

Hi,

I recently got help from one of your colleagues in getting the time reported for tx/rx in the ApiMac_mcpsDataInd_t structure.

However the documentation states that it's the received/transmitted time in backoffs or MAC timer

units. I checked the technical-reference-manual.html and rxConfig.bAppendTimeStamp

reference doesn't explicitly say how to interpret the times.

1. Is the backoff time supposed to be in units of 16uS slots? (uint32_t timestamp)

2. The ratio of the MAC timer units (uint16_t timestamp2) and backoffs (timestamp) isn't consistent; which suggests

they are not the same measurement of received/transmitted times. (please see output below from a test)

3. What are the units for timestamp2? is it the same as Clock_tickPeriod

You can see from the numbers below that the ratio of timestamp/timestamp2 is not consistent,

I would imagine that if these two times are both reporting the time it took to receive/transmit the

packet then the ratio of the two numbers should be approximately the same number for each

set.

Below is an output from a run:

Sensor 0x1
rtt(Us) = 29062
rcvd backoffs (timestamp) = 3949
rcvd MAC units(timestamp2) = 33
Sensor 0x1
rtt(Us) = 29362
rcvd backoffs(timestamp) = 4675
rcvd MAC units(timestamp2) = 16
Sensor 0x1
rtt(Us) = 28752
rcvd backoffs(timestamp) = 5344
rcvd MAC units(timestamp2) = 47
Sensor 0x1
rtt(Us) = 29032
rcvd backoffs(timestamp) = 6074
rcvd MAC units(timestamp2) = 20
Sensor 0x1
rtt(Us) = 28572
rcvd backoffs(timestamp) = 6780
rcvd MAC units(timestamp2) = 5
Sensor 0x1

Thanks

  • 0
    TI__Mastermind 23776 points

    Timestamp is in symbols = 16us for 2.4G/20us for 50kbps SubG

    Timestamp 2 is in RAT clicks (250ns)

  • 0 in reply to AB
    Intellectual 260 points

    That unfortunately doesn't add up because the two numbers from my understanding are supposed to

    be a measure of the same thing either how long it took to receive or transmit.

    Using these two readings

    rcvd backoffs(timestamp) = 6074      ----->> 97814uS
    rcvd MAC units(timestamp2) = 20     ----->> 5000nS

    These numbers don't match but they are both supposed to be how long it took to either read/transmit. How come?

  • 0 in reply to jonathan bondzie
    TI__Mastermind 23776 points

    Hello Jonathan,

    I believe those are timestamps and not deltas. 

  • 0 in reply to AB
    Intellectual 260 points

    Unfortunately I'm getting conflicting answers because the initial solution was that timestamp was in backoffs of 16uS and timestamp2 was in slots of 20nS.

    The current suggestion is that these are not Deltas but rather timestamps.

    For it not to be Delta's it's gotta be relative to something. What's it relative to?

  • 0 in reply to jonathan bondzie
    TI__Mastermind 23776 points

    The MAC internal timer.

  • 0 in reply to AB
    Intellectual 260 points

    Thanks, that's fair. But is timestamp the MAC timer at the start and timestamp2 is the duration?

    Can you please give a complete explanation of how to interpret the two numbers relative to the MAC timer.

    Thanks

  • 0 in reply to jonathan bondzie
    TI__Mastermind 23776 points

    Hello, 

    Those timers start at the beginning of the code, when the stack is initialized.

    Timestamp 1 will let you know at what point was that messaged receive/sent/ack/nack/etc. relative to the start of the MAC

    Timestamp 2 will let you know at what point was that messaged receive/sent/ack/nack/etc. relative to a more precise timer, called the RAT timer internal to the radio of the device.

    Regards,

    AB

  • 0 in reply to AB
    Intellectual 260 points

    Hi AB,

    Perhaps I should ask my question differently.

    I initiated the meaning of those timers because my actual intention

    is to calculate how long a packet is taking to be transmitted.

    Example:

    Assume I send packet 1 and the receiver gets packet 1. How can I calculate

    how long it took from transmit to receive? Is there a way to calculate this using

    the api provided by TI?

    The timestamps in the packets suggest I can use the HAL interface of the radio doorbell

    described in section 25.2 of the technical reference manual, but I don't see the api available

    for getting access using those commands. When I grep any of those commands listed it always

    shows up in a binary object; which implies the api isn't external.

    That said can you suggest a way for me to calculate the time it takes to transmit a packet?

    If it were constant then this would be straight forward but it varies.

    Thanks

  • 0 in reply to jonathan bondzie
    Intellectual 260 points

    After some digging around I found a link to the RAT timer

    dev.ti.com/tirex/content/simplelink_cc13x0_sdk_2_40_00_20/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/rf-core-index.html

    Which gives me access to the interface for the RAT timer.  I also found documentation on the MAC timer from the CC2538 manual. The only drawback

    with that is access is directly via the registers. Do you know of an API for getting access to the MAC timer? I'll look around and see what I can find.

    Thanks

  • 0 in reply to jonathan bondzie
    TI__Mastermind 23776 points

    You can see the latest time by looking at the timestamp. Another way is to access the PIBs directly through memory.