• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 1065 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.

CCS/LAUNCHXL-CC1310: Real Time Clock in Collector and Sensor TI 15.4 Stack

Ricardo Arjona
Prodigy 110 points
Part Number: LAUNCHXL-CC1310

Tool/software: Code Composer Studio

Hi,

I am trying to measure the latency when sensor data is generated, transmitted and received by the collector. For this purpose, I have implemented an interrupt (in board_key.h and board. key.c files) at the sensor to trigger the sensor data transmission event SENSOR_READING_TIMEOUT_EVT  in order to transmit at will regardless the timeout. So I am collecting the timestamps when the ISR is attending the interrupt and when the sensor is effectively transmitting the packet (indicated externally by the green LED pin DIO7) . Using a scope, I am measuring the time from my trigger signal to schedule a transmission at the sensor and the final transmission time. I am getting a difference between the delay calculated using the timestamps and the value red by the scope about 100ms.

To get the timestamps I am using  ICall_getTicks() but I have also used Clock_getTick() and the result it is the same, any idea about what this is happenning?

Second, what is the difference between these two functions to get the timestamps?

Is the RTC running all the time or is frozen when the sensor is sleeping?

  • 0
    TI__Expert 4440 points
    Hi Ricardo,

    I cannot comment on the 100 ms discrepancy you are seeing. I can however recommend you to implement a new timer instance dedicated to be your time stamp provider.

    Icall_getTicks() will just call Clock_getTick() indirectly. By default, the "Clock Tick' increments every 10 uS (set in app.cfg). The SYS/BIOS kernel will use a hardware instance of the RTC to initialize the Clock instance. The kernel clock will by default use "RunMode_DYNAMIC". Essentially, the RTC will not generate an interrupt unless it absolutely needs to. This allows the device to go into a low power state.

    Derrick
  • 0 in reply to Darius Williams
    Prodigy 110 points
    Hi Derrick,
    Thanks for your reply.

    I have solved the problem. Since my interrupt to trigger the sensor data transmission event was implemented in the board_key files, the debounce timer was affecting my timestamps, so I just set to zero this time since my trigger signal is purely electronic. Thanks.