• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 16 subscribers
  • Views 657 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.

CC1352R: RF signals routing for IEEE 802.15.4 at 2.4GHz, sync word detection interrupt

Clement Guillou
Intellectual 430 points
Part Number: CC1352R

Hi,

I am trying to get precise timings for Rx packets in order to synchronize multiple devices. I see in the documentation that the RAT_GPO1 (Sync word detected) is not available for the IEEE 802.15.4 :

http://dev.ti.com/tirex/content/simplelink_cc13x2_sdk_1_60_00_29/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/signal-routing.html#tab-rf-unit-signals

9   RAT_GPO1                       Goes high when sync word is detected and low either when the packet has been received or reception has been aborted. Not available for IEEE 802.15.4 RX commands. Requires an additional override (uint32_t)0x008F88B3
  • Do you have any plans in the near future to enable this signal for the IEEE 802.15.4 standard ? The override wont work in 802.15.4 right ?

Is there any alternative to this missing signal ? I found that mdmsoft might be useful but I wonder :

  • Is there any delay added when using a callback from the event RF_EventMdmSoft ? If so, is this delay consistently the same ?
  • Is there a difference (in time) between RF_EventMdmSoft callback and the interrupt RFHWIFG.MDMSOFT, which is the most precise way to get the sync word detection

Best regards,

Clement

  • 0
    TI__Genius 10955 points
    No, unfortunately this signal is not available in 15.4 mode, and we currently have no plans of changing that. As you suggest, the override won't work in 15.4 mode.

    The interrupt latency is also difficult to predict, as it will depend on what software is running and the priorities in use for different tasks. If the CM4 is idle when the interrupt occurs, the latency should be near constant, but when using an RTOS, there is no way to ensure that the CM4 is idle. This means that there may be several hundred microseconds of latency if there are long critical sections or high-priority interrupts in the system.

    If it is important to have a signal that stays high during the packet, this is probably still your best bet. But if the most important is to have a timing that is known relative to some received packet, you could base it on the time stamp that can be appended on a packet. On the API to the RF core, you can request that a time stamp is appended to each packet in the receive queue. Unfortunately, I am not sure that this time stamp will be available from the stack that you are using. If you are able to get the time stamps, they will give you the radio timer value at the beginning of a packet. You could then create an event controlled by the radio timer to be output at a fixed time after the beginning of the packet.

    Without knowing how you plan to do this synchronization, it is difficult to give a clear suggestion on how to solve your problem.