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.

CC1312R7: Can we reduce the Wi-SUN join delay of the nodes that were successfully connected?

Expert 3660 points
Part Number: CC1312R7

Hi Champs,

There is some use cases that the router nodes (RNs) are not powered all the time, but only the Border Router (BR). There are maximum 200 RNs per PAN.

Let's say after the network is completely formed, ie. 100% of the nodes successfully join the network, then the RNs are powered off for some time. So, is there a method to reduce the join delay to a minute or two when all the RNs are powered up again in FAN1.0? If FAN1.1 can do, pls advise too.

Regards,

Kien Nguyen

  • Hi Kien,

    In the upcoming SimpleLink F2 SDK we are adding several features to improve join time, both first time and consecutive joins. The join time will still depend on the number of hops (since hop 2 devices need to wait for hop 1 devices before they can join). Do you have an idea of the network topology?

    This is for FAN 1.0. The SImpleLink F2 SDK 7.40 is planned to be released at the end of February 2024.

    Cheers,

    Marie

  • Hi Marie,

    Thanks for your reply.

    It’s street lighting. Lights are normally in a line (the street) and each of them is about 30-50 meters away from the adjacent ones. With the upcoming SDK 7.40, what is the shortest join delay we can expect for this topology?

    Can the BR and the RNs store necessary parameters after the last successful join so they can use to fasten the next join?

    Regards,

    Kien Nguyen

  • Hi Kien,

    The range will depend on the PHY you choose, but let's assume 1 km range (50 kbps PHY): 1000 m divided by 40 m is 25 devices per hop. 200 devices : 25 devices per hop = 8 hops.

    (Or architecture only supports up to 6 hops but we're just trying to make some simple calculations here.)

    If we say 2 mins join time per hop we're looking at at least 16 mins to get the network up. This is also a simplification since join time can increase for the higher hops.

    Personally I don't think the network topology sounds sustainable with the join time you are looking for. Maybe you can consider adding another BR to reduce the number of hops in the network.

    (BTW you can calculate the range for each PHY with our range estimator:

    https://www.ti.com/tool/RF-RANGE-ESTIMATOR

    Cheers,

    Marie H