• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 54 subscribers
  • Views 660 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.

CC1352P: How to sync time between collector and sensor nodes in TI 15.4 stack with frequency hopping mode enabled?

Zhiyong Li (FT)
Expert 2450 points
Part Number: CC1352P

Hi,

Time synchronization has been discussed for proprietary physical layer in this page, but it seems more challenging in 15.4 stack with FH enabled. 

My plan is to piggy back on MAC data poll. Upon receiving data poll indication, collector sends out some sort of instruction to tell the current time on collector. In theory this should work. The part I am not sure are:

1) What if there are asynchronous data request pending? Will collector push the time synchronization instruction to queue? 

2) Is the pollIndCB() and processDataRetry() in collector example code right place to add time synchronization instruction? 

Thanks in advance.

ZL

/*!
 * @brief      Process the MAC Poll Indication Callback
 *
 * @param      pPollInd - poll indication
 */
static void pollIndCB(ApiMac_mlmePollInd_t *pPollInd)
{
    ApiMac_sAddr_t addr;

    addr.addrMode = ApiMac_addrType_short;
    if (pPollInd->srcAddr.addrMode == ApiMac_addrType_short)
    {
        addr.addr.shortAddr = pPollInd->srcAddr.addr.shortAddr;
    }
    else
    {
        addr.addr.shortAddr = Csf_getDeviceShort(
                        &pPollInd->srcAddr.addr.extAddr);
    }

    processDataRetry(&addr);
}

/*!
 * @brief      Process retries for config and tracking messages
 *
 * @param      addr - MAC address structure */
static void processDataRetry(ApiMac_sAddr_t *pAddr)
{
    if(pAddr->addr.shortAddr != CSF_INVALID_SHORT_ADDR)
    {
        Cllc_associated_devices_t *pItem;
        pItem = findDevice(pAddr);
        if(pItem)
        {
            /* Set device status to alive */
            pItem->status |= CLLC_ASSOC_STATUS_ALIVE;

            /* Check to see if we need to send it a config */
            if((pItem->status & (ASSOC_CONFIG_RSP | ASSOC_CONFIG_SENT)) == 0)
            {
                processConfigRetry();
            }
            /* Check to see if we need to send it a tracking message */
            if((pItem->status & (ASSOC_TRACKING_SENT| ASSOC_TRACKING_RETRY)) == 0)
            {
                /* Make sure we aren't already doing a tracking message */
                if(((Collector_events & COLLECTOR_TRACKING_TIMEOUT_EVT) == 0)
                    && (Csf_isTrackingTimerActive() == false)
                    && (findDeviceStatusBit(ASSOC_TRACKING_MASK,
                                            ASSOC_TRACKING_SENT) == NULL))
                {
                    /* Setup for next tracking */
                    Csf_setTrackingClock(TRACKING_DELAY_TIME);
                }
            }
           
        // Add data request for time synchronization here?

        }
    }
}

  • 0
    TI__Guru* 79271 points

    I will assign someone to help you. However, when using the TI.15.4, the syncing should be taken hand of by the stack,hiding the complexities of maintaining synchronization from the application and easing the task of developing applications with frequency hopping feature.

    Siri

  • 0 in reply to Siri
    Expert 2450 points

    It would be nice if this is handled by the stack itself. Any ETA on this?

    In the interim, I would still like to know if the idea to piggy back on data poll will work though. We need something to get our application up and running.

  • 0 in reply to Zhiyong Li (FT)
    TI__Guru 73301 points

    Hi Zhiyong,

    As Elin says, if you are using the TI 15.4-Stack the collector and nodes will sync each time a packet is sent and received between them.

    Is this what you're planning to implement?

  • 0 in reply to Marie H
    Expert 2450 points

    I meant to ask about synchronization of RTC time between collector and sensor nodes. I don't see any reference to RTC related function like Seconds_set(), Seconds_get() in the SDK folder, so I believe this part has not been implemented yet. But I could be wrong.

  • 0 in reply to Zhiyong Li (FT)
    TI__Guru 73301 points

    Hi Zhiyong, 

    As you say, the RTC is not automatically synchronized between the collector and nodes. I'm not really sure what the use-case would be, since the main reason for these clocks to be synchronized is for the devices to be able to transmit/receive on a synchronized schedule.

  • 0 in reply to Marie H
    Expert 2450 points

    Hi Marie,

    We need to keep track of UTC time on each sensor node in case collector node goes down/absent for long period of time. This scenario rarely but does happen for all sorts of reasons.

    With that goal in mind, could you comment on the idea to piggy back on data poll request? What is the delay between getting RTC on collector side and then sending it to sensor node when that sensor node polls for data? The challenge is if we just mindlessly send RTC time on collector to sensor, there will be a delay up to a polling interval, which we intend to set as 30 or 60 seconds. But if we can manage the delay down to 1 or 2 seconds, it will be acceptable. 

    Update: or if you could point me the current time synchronization code, I will see if use that part. I believe it will be much more precise. The essence is to get RTC time on collector right before it is sent out by MAC layer. In this regard, this is probably best handled in MAC layer.

    Thanks.

  • 0 in reply to Zhiyong Li (FT)
    TI__Guru 73301 points

    Hi Zhiyong,

    I think the safest method would be to add a GPS chip on your equipment to keep track of the time. Obviously this is a more costly solution.

    Please keep in mind that if your device stays disconnected for an extended time period it will drift compared to other devices. 

    Let me check bout the synchronization code. I'm not sure whether this is open source or not. I'll get back to you.

  • 0 in reply to Marie H
    Expert 2450 points

    Hi Marie,

    I think adding a GPS chip is a bit excessive. We don't have the battery budget and deployment location of those devices usually don't have GPS signals as well. The RTC on sensor nodes is backup source of UTC timestamp, if we can reduce the delay between the moment RTC on collector is read and the moment sensor nodes receives that time down to 1 or 2 seconds, it will be acceptable.

    I briefly went through source code of SDK. I think a straightforward way is to tag each packet sent out from collector with timestamp. A 4 byte timestamp is not too much overhead. Alternatively we can probably define a new time sync message. Can this be done?

    I am looking at the following function:

    //<SDK installation folder>\source\ti\ble5stack\icall\src\inc\icall.h

uint32_t icall_directAPI( uint8_t service, icall_lite_id_t id, ... );

    Is this the right place to start?

  • 0 in reply to Zhiyong Li (FT)
    TI__Guru 73301 points

    Hi Zhiyong,

    I'm sorry, this code is not publicly released so I cannot post it here. 

    I think you will need to make your own packet format with a time stamp as you say, and handle it in the application. 

    icall is not really related in this case.

  • 0 in reply to Marie H
    Expert 2450 points

    Hi Marie,

    We are able to control the timing of time sync packet and ensure they reach sensor nodes in less than 1 second of inaccuracy, so this problem is solved. Thanks for your input.