• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 302 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.

CC1310: sensor node in TI-15.4 stack, which of the 3 supported modes(beacon, non-beacon and frequency hopping) has the shortest network joining/rejoining time?

Zhiyong Li (FT)
Expert 2760 points
Part Number: CC1310

Hi,

So far we have been running networks with frequency hopping, sensor nodes typically join network  in 1 ~ 5 minutes with 51 channels selected in the channel mask and 60 seconds polling interval. Although this largely meets our requirements, I am still curious if sensor nodes in the other two modes, either beacon or non-beacon mode, can join/rejoin a network faster, ideally under 10 seconds.

My understanding is that, sensor nodes in frequency hopping mode need so much time to join a network because of the number of channels involved. If we reduce number of channels, down to 25 channels, or event 3 ~ 5 channels, how soon can we expect sensor nodes to join/rejoin a network? Or if we switch to beacon or non-beacon mode, will we see even shorter time to join/rejoin assuming we select the same number of channels in channel mask.

In other words, if we want to optimize the network for shortest possible network joining/rejoining time, how should we go about it?

Please advise, thanks.

ZL

  • 0
    TI__Expert 4486 points

    Hi ZL,

    In order to reduce join in frequency hopping one has to consider the trickle timer based joining process. 

    In order to join a network a device uses asynchronous messages to request an advertisment frame.

    The frequency used to sent these requests (PAS) is set with the help of a trickle timer.

    By reducing the trickle timer interval, which is set within advanced_config.h (CONFIG_TRICKLE_MIN_CLK_DURATION  and CONFIG_TRICKLE_MAX_CLK_DURATION) the frequency.

    As the PAN coordinator is not able to detect devices who joined the FH, there is a procedure implemented to inform the coordinator that a device joined the network. 

    This procedure is influenced by the request interval of the sensor.

    The amount of channels you are using has also an influence, as it increases the time that is used to send an asynchronous message. However, this should have a minor effect.

    To reduce the joining procedure I would recommend you, to change the trickle timer, the report interval and the amount of channels. 

    Regards,

    Alex

  • 0 in reply to Alex Paul
    Expert 2760 points

    Hi Alex,

    Thanks for your quick and very informative response. This definitely helps.

    Alex Paul said:
    By reducing the trickle timer interval, which is set within advanced_config.h (CONFIG_TRICKLE_MIN_CLK_DURATION  and CONFIG_TRICKLE_MAX_CLK_DURATION) the frequency.

    A few related questions:

    1) Do these two knobs control joining time in beacon and non-beacon modes too? I am still trying to figure out the shortest possible joining time in each mode, mostly if beacon/non-beacon mode have shorter joining time, if yes, by how much.

    2) Do we need to take into consideration of polling interval when setting these two knobs? For example, if we set CONFIG_POLLING_INTERVAL at 60000, does it make sense to set the following values to them?

    Fullscreen
    1
    2
    3
    #define CONFIG_TRICKLE_MIN_CLK_DURATION 6000
    #define CONFIG_TRICKLE_MAX_CLK_DURATION 600000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    3) In the example code from SDK v4.20, I found the following knobs related to trickle timer.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    // config.h, sensor project
    /*! Default Polling interval in milliseconds. It will get updated upon reception
    of a config request message */
    #define CONFIG_POLLING_INTERVAL 6000
    /*! PAN Advertisement Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION 6000
    /*! PAN Config Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION 6000
    /*! Default Reporting Interval - in milliseconds. It will get updated upon
    reception of a config request message */
    #define CONFIG_REPORTING_INTERVAL 180000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I assume CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION controls how frequent a sensor node sends out PAS packets, once a sensor node joins network, it won't send out any PAS/PCS packets.

    My questions here are: a) can we set them at different values? b) do we need to take the following knobs in collector project into consideration?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    // config.h, collector project
    /*!
    The minimum trickle timer window for PAN Advertisement,
    and PAN Configuration frame transmissions.
    Recommended to set this to half of PAS/PCS MIN Timer
    */
    #define CONFIG_TRICKLE_MIN_CLK_DURATION 3000
    /*!
    The maximum trickle timer window for PAN Advertisement,
    and PAN Configuration frame transmissions.
    */
    #define CONFIG_TRICKLE_MAX_CLK_DURATION 6000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Sorry for so many questions.

    ZL

  • 0 in reply to Alex Paul
    Expert 2760 points

    Hi Alex,

    I just tested the following settings in sensor node, with CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION changed from previous 60000 to 6000, everything else stayed the same in both sensor node and collector node. Changing CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION alone doesn't seem to speed up joining process. Initial joining after sensor node was flashed with newly built firmware still took 2 minutes.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    /*! Default Polling interval in milliseconds. It will get updated upon reception
    of a config request message */
    #define CONFIG_POLLING_INTERVAL 60000
    /*! PAN Advertisement Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION 6000
    /*! PAN Config Solicit trickle timer duration in milliseconds */
    #define CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION 60000
    /*! Default Reporting Interval - in milliseconds.
    * It will get updated upon reception of a config request message
    * Make sure default is the same as in collector, to minimize writing into NVS
    */
    #define CONFIG_REPORTING_INTERVAL 90000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Does this mean we also need to change other settings such as polling interval or/and CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION ?

    Please advise, thanks.

    ZL

  • +1 in reply to Zhiyong Li (FT)
    TI__Expert 4486 points

    Hi Ziyong, 

    I used the sensor collector example to do some measurement regarding your issue.

    As standard setup I used: 

    SDK:7.10.00.98

    Mode: Frequency Hopping

    Regulation Type: ETSI

    Sub1-Frequency: 863-869

    PHY Type: 50 kbps

    Default Pan Advert solicit and PAN config solicit are 6000 ms 

    On Collector : CONFIG_TRICKLE_MIN_CLK_DURATION is 3000

    and CONFIG_TRICKLE_MAX_CLK_DURATION is 6000

    Report/Poll interval: 60 s

    and did some measurements changing some parameters.

    These were:

    1.) Measurement with standard parameters

    2.) Standard parameters + CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION and CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION changed to 60000 with also changing CONFIG_TRICKLE_MAX_CLK_DURATION to 60000 and CONFIG_TRICKLE_MIN_CLK_DURATION to 30000

    3.)Standard parameters using just channel 1-5

    4.) Standard parameters settinngs + Poll&Report Interval set to 1 s

    My joining timers for all setups were ~20-30 s

    However changing the Trickle timer period increased the join time.

     

    Can you try this at your  table

  • +1 in reply to Alex Paul
    TI__Expert 4486 points

    Regarding the other modes: 

    These will have other procedures to join a network thus the join time will be effected by other settings.

    In beacon enabled mode : 

    This is depending on your implementation. However, the join time  here changed using the beacon interval.

    However the tradeoff here would be higher power consumption.

    To get more information on this I would recommend you to look into the TI15.4 Stack User's Guide Figure 53

    For NON BEACON ENABLED Mode:

    The device performs a broadcast and searches for available PAN-Cordinators. 

    All PAN-Coordinators in range will respond to the request and will be able to request access to the desired PAN-Coordinator.

    I assume this is the mode with the fastest join time.

  • 0 in reply to Alex Paul
    Expert 2760 points

    Hi Alex,

    Thanks for the detailed response. Later yesterday I was able to get joining time in FH mode down to typical 20seconds, by changing both PCS and PAS CLK duration back to default 6s. 20 seconds is more than enough for our purpose so I will settle on FH mode at least for now.

    Our system runs on battery, so we changed polling interval, PCS/PAS clk duration to 60s from default 6s to ensure battery can supply enough power during joining when txPower is set at maxim 26dBm, assuming once a sensor node joins a network, it will stay on and rarely drops off. For reasons that are not clear to me, sensor nodes in some of our early installations will drop off network every couple of hours. Therefore we started to look for ways to reduce network joining time, and your answer helped a lot on that.

    Best,

    ZL