• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 436 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-CC1312R1: Sensor Nodes Rejoin Issue

LAUNCHXL-CC1352R1: How to reduce re-join network time

Walter Zheng
Prodigy 50 points
Part Number: LAUNCHXL-CC1352R1

Hi, 

I setup the ti demo to use FH using ti154stack_linux_x64_2_08_00_04, simplelink_cc13x2_sdk_2_30_00_45 for the CoP and Sensor since these are rev C boards. Everything connects and talk to each other but is there a way to reduce the time it takes to re-join the network? The PCS_event was triggered after 3 seconds here but often it takes 6 seconds. Then it takes another 16 seconds to trigger the association event. Is this normal?

[2020-06-12 13:23:26.578] TI Sensor
[2020-06-12 13:23:26.580]
[2020-06-12 13:23:26.580] sensor start evt
[2020-06-12 13:23:26.580]
[2020-06-12 13:23:26.580] rejoining
[2020-06-12 13:23:26.583]
[2020-06-12 13:23:26.583] State Changed: 2
[2020-06-12 13:23:26.587]
[2020-06-12 13:23:29.842] PCS_EVT
[2020-06-12 13:23:29.842]
[2020-06-12 13:23:45.733] ASSO_REQ_EVT
[2020-06-12 13:23:45.736]
[2020-06-12 13:23:46.720] association confirmed
[2020-06-12 13:23:46.725]
[2020-06-12 13:23:46.725] ssf_networkupdate
[2020-06-12 13:23:46.725]
[2020-06-12 13:23:46.725] Device Restarted
[2020-06-12 13:23:46.725]
[2020-06-12 13:23:46.725] Frequency Hopping
[2020-06-12 13:23:46.725]
[2020-06-12 13:23:46.725] State Changed: 4

Thanks,

Walter

  • 0
    TI__Prodigy 480 points

    Walter,

    There may be several ways to decrease the time. First off, reduce the number of channels in the FH Channel Mask. This will decrease the time it takes for the sensor to find the network. You can also shorten the trickle timer so that the sensor sends more async messages, thus allowing the collector more of a chance to see the sensor quicker.

  • 0 in reply to Christopher Sickler
    Prodigy 50 points

    Hi Chris,

    Chris S said:
    First off, reduce the number of channels in the FH Channel Mask.

    I thought the PC frame would let the sensor know the frequency the collector is currently on and the sequence so I didn't think the number of channels would matter for re-joining the network but I do see it impacting the transmission of sensor data.

    Chris S said:
    You can also shorten the trickle timer so that the sensor sends more async messages, thus allowing the collector more of a chance to see the sensor quicker.

    This refers to these on the sensor, correct? 

    /*! PAN Advertisement Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION 1000
    /*! PAN Config Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION 1000

    Are there parameters on the collector side that can help reduce the time needed to re-join?

    UPDATE: So I found the delay and it is coming from  Ssf_setFHAssocClock(FH_ASSOC_DELAY + FH_ASSOC_DELAY); Is there a reason for this intentional random delay? What are the trade-offs if this delay is removed?

    Thanks,

    Walter,

  • 0 in reply to Walter Zheng
    TI__Prodigy 480 points

    Walter,

    Please allow me some time to look more into the code for response.

  • 0 in reply to Christopher Sickler
    TI__Prodigy 480 points

    Walter,

    The PA message response by the coordinator does contain the hopping sequence, so yes, your assumption that the sensor would then know what frequency the coordinator would be on. However, before the sensor starts the association sequence, it then sends a PAN Config solicit request to the coordinator. The coordinator then responds in an async PAN config response, meaning it will send up to 129 packets with the PAN config response, 1 for each channel the device is on. Therefore, by nature, decreasing channels will save the sensor some time. As there will be a delay before it can start the association response due to the time the coordinator is sending out all the PAN configs. If you are looking for best speed, we suggest decreasing to 4 channels, however you will need at least 50 channels to get the benefits of max transmission power as per FCC regulation.

    You are correct on assuming the defines are the trickle timers: 

    /*! PAN Advertisement Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION 1000
    /*! PAN Config Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION 1000

    On the collector side, there is no such define. The window of time is set for how long the sensor device will wait to receive a response by this. The window for your define of 1000 ms would be anywhere between .5sec to 1sec. The window minimum is 1/2 that of your clock duration you set in that define.

    Lastly, the delay you found should not be removed. The delay is there for the purpose of waiting for the coordinator to finish its Async transmissions. The second delay found in that function is there only for if the first association request command failed for reasons like channel access failure. It is set to 2 seconds as this is an arbitrary wait time to allow the channels to clear up or for the network to change channels sufficiently. You might be able to decrease the Association delay, but we cannot guarantee it will work.