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

LAUNCHXL-CC1312R1: Sensor Nodes Rejoin Issue

Yue Zhang65
Intellectual 500 points
Part Number: LAUNCHXL-CC1312R1

Hi,

I have a network with 25 nodes, running SimpleLink CC1312 SDK 3.10. there is no problem  to build the connections, but sensor nodes have troble to rejoin after turn off/on the collector. Not all of them have the problem, I will say randomly some of them were unable to rejoin. Our collector running in a mode that will be off for a while then start up again.

Sensor node is CC1312 and CoProcessor is also CC1312 with ti154stack_linux_x64_2_09_00_09. I went through some threads mentioned to adjust some settings, here is my questions,

1. what does tickle timer do?how it affect rejoin process? my setting is #define TRICKLE_TIMEOUT_VALUE       30000

2.Does this setting matters? #define FH_NUM_NON_SLEEPY_FIXED_CHANNEL_NEIGHBORS  2, we have 25 nodes...do i have to set it to 25?

3. if sensor not rejoin, what state its' in?

4. will increase  association attempts help? #define CONFIG_FH_MAX_ASSOCIATION_ATTEMPTS    10

5.  Do i need to change scan interval? #define CONFIG_SCAN_BACKOFF_INTERVAL  5000

6. anything in the collector end need to changes...what are the following settings do? what is 'PAS/CS MIN timer'?

    ; The maximum trickle timer window for PAN Advertisement
    ; and PAN Configuration frame transmissions.
    ; Recommended value is half of the PAS/CS MIN timer.
    config-trickle-max-clk-duration = 6000

    ; The minimum trickle timer window for PAN Advertisement,
    ; and PAN Configuration frame transmissions.
    config-trickle-min-clk-duration =  3000

what else should i look into?

thank you very much!

-yue

  • 0
    TI__Mastermind 23556 points

    Hello Yue,

    The rejoining of sensors will depend on the network mode. Ideally after some time all sensors must have re joined the network.

    In what mode are you operating?

    1.All asynchronous frames are transmitted based on a trickle timer [RFC 6206]. Asynchronous messages are sent back-to-back over a specified channel list. This action enables a receiver to receive such frames with high probability, irrespective of the hopping sequence.THIS IS ONLY FOR FH ENABLED NETWORKS.

    2.No, this setting is to be able to allocate space on the routing table of the device, since these networks do not have multi hop functionality enabled, this is not going to affect it.

    3.orphaned, it is best to dissassociate and then re join

    4. That could help, if the root of the problem is that it gives up on association

    5. Not really, 5 seconds is good, you can decrease it to 2 or 3 seconds to make them scan faster and potentially join faster. but after they reach orphan mode the interval you will need to modify is the orphan otification interval which will determine how often does the orphan notify the collector of its state. By default its 30sec

    6.If using FH mode, then yes you can potentially modify these settings if you understand what each do, I recommend reading our user guide: http://dev.ti.com/tirex/explore/node?node=APeHcG.A0wniaym22zAYKw__pTTHBmu__LATEST

    As far as what else to change, we need to understand what the problem is firtst, the best way to do this is to download packet sniffer and see what is going on in the network and understand if the sensors are even attempting to reconnect. To download the packet sniffer go here: http://www.ti.com/tool/PACKET-SNIFFER

    You are welcome,

    AB

  • 0 in reply to AB
    Intellectual 500 points

    Thank you so much, AB!  I understand better now, but still have some questions, see below..

    In what mode are you operating?

    >>>>>>>FH mode

    1.All asynchronous frames are transmitted based on a trickle timer [RFC 6206]. Asynchronous messages are sent back-to-back over a specified channel list. This action enables a receiver to receive such frames with high probability, irrespective of the hopping sequence.THIS IS ONLY FOR FH ENABLED NETWORKS.

    >>>>>>>understand !

    2.No, this setting is to be able to allocate space on the routing table of the device, since these networks do not have multi hop functionality enabled, this is not going to affect it.

    >>>>>>>got it!

    3.orphaned, it is best to dissassociate and then re join

    >>>>>>>we were using non-beacon mode previously, so I know if I turn off collector(actually reset the CoP) sensor will be in state 5(orphan), but in no-beacon mode, sensor will execute 'orphan scan' based on  CONFIG_ORPHAN_BACKOFF_INTERVAL, but in HF mode, seems sensor keeps getting JDLLC_PCS_EVT events and try to reconnect the collector based on CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION. Is my understanding correct? and CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION is also used in initial join process, I know it maybe a trade-off, I don't want the sensor keeps sending sendAsyncReq() while in 'orphan mode, but if i increase CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION, will it slow down the initial join?

    4. That could help, if the root of the problem is that it gives up on association

    >>>>>>> got it!

    5. Not really, 5 seconds is good, you can decrease it to 2 or 3 seconds to make them scan faster and potentially join faster. but after they reach orphan mode the interval you will need to modify is the orphan otification interval which will determine how often does the orphan notify the collector of its state. By default its 30sec

    >>>>>>> Is 'orphan notification interval'  the same as CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION?

    6.If using FH mode, then yes you can potentially modify these settings if you understand what each do, I recommend reading our user guide: http://dev.ti.com/tirex/explore/node?node=APeHcG.A0wniaym22zAYKw__pTTHBmu__LATEST

    >>>>>>>Still a little bit confused about the relationship between sensor settings and collector settings, are they related? from the comments my understanding is config-trickle-max-clk-duration should be half of the value of the smaller value of  CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION or CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION. am i right? what is PAS/CS MIN timer? advertisement/config  solicit trickle timers?

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

        ; The maximum trickle timer window for PAN Advertisement
        ; and PAN Configuration frame transmissions.
        ; Recommended value is half of the PAS/CS MIN timer.
        config-trickle-max-clk-duration = 6000

        ; The minimum trickle timer window for PAN Advertisement,
        ; and PAN Configuration frame transmissions.
        config-trickle-min-clk-duration =  3000

    As far as what else to change, we need to understand what the problem is firtst, the best way to do this is to download packet sniffer and see what is going on in the network and understand if the sensors are even attempting to reconnect. To download the packet sniffer go here: http://www.ti.com/tool/PACKET-SNIFFER

    >>>>>>I changed some of the values above, if I just turn on/off collector, all the sensors will eventually join(i do found some bad boards!) another test I did is that I keep the collector on, and power up all the sensors together, i still see some sensors having trouble. my understanding is that these two tests should be the same, am i right?

    Thank you again!

    -Yue

  • 0 in reply to Yue Zhang65
    TI__Mastermind 23556 points

    Hello Yue,

    You are correct, we need to first understand the problem before we start changing values.

    Now that I know you are in FH mode, I can say that you can ignore all of the orphan state information I said above, it does not apply to FH mode.

    If your devices are sleepy end devices, then your Collector needs to have the permit join enabled (open network). This is a scenario that we are looking into internaly in our development team.

    If you go to that link I provided, I have created a section that describes in detail what each of those packets and timer do. (ADV/Config solicit packets/frames)

    I recommend you look into that, since it is a great read.

    Regards,

    AB 

  • 0 in reply to AB
    Intellectual 500 points

    Hi AB,

    Thank you!

    I made some progress but not fully understand it yet. I do read the document in you link(I've been reading it several times). now I have a question regarding the doc ( I read the one almost the same doc from the SDK package). In the following section. how the 10min and 25 min defined? the reason I am asking is that in non-beacon mode, I was monitoring the tracking msg from coordinator and the tracking interval is defined in collector...

    ; Time interval in ms between tracking message intervals
        config-tracking-delay-time = 60000

    so in FH mode, I saw the tracking msg coming, but the interval is randomly 7min ~9min.

    Maintaining a Connection for End Nodes

    In a typical star network, the devices have to keep track of unicast and broadcast timing of Coordinator’s hopping sequences while the coordinator has to do for the unicast timing information of all the connected devices.

    The timing information of the unicast and broadcast sequence of a device is carried in unicast timing and frame type information element (UTT-IE) and broadcast timing Information element (BT-IE), respectively. All data frames with destination address mode set to extended or None shall carry UTT-IE and BT-IE. The ACK frames from PAN-Coordinator will contain both the UTT-IE and BT-IE irrespective of address mode, while those from other non-sleepy end devices will carry UTT-IE alone. The timing information corresponding to the source of the received Data/ACK frame is updated based on received frames.

    The lifetime of a neighbor table is based on the last time the entry was updated. As long as a frame is received from a neighbor once every neighbor valid time, it is kept active. The neighbor valid time for a hopping neighbor is set to 2 hours by default. Neighbor valid time can be changed using the MAC_FHPIB_NEIGHBOR_VALID_TIME PIB attribute. After that period the entry is considered as expired. Any neighbor table entry is deleted if it is not updated within the last 10 hours.

    The period within which at least one data frame should be exchanged to maintain reliable communication depends on the dwell time value used by the PAN coordinator. TI recommends keeping this period for at most 10 minutes or 25 minutes, for a PAN coordinator dwell time of 100 ms and 250 ms respectively.

  • 0 in reply to Yue Zhang65
    Intellectual 500 points

    BTW, I am still testing, the tracking msg interval can be as long as ~26 minutes...

  • 0 in reply to Yue Zhang65
    TI__Mastermind 23556 points

    In FH those messages are asynchronous and are controlled by trickle timers. These get triggered randomly, which is why you are seeing that range of values.

  • 0 in reply to AB
    Intellectual 500 points

    Thanks!

    -Yue