• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 58 subscribers
  • Views 1013 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.

Z-Stack Lighting - Joining Issue in Large Network

Sjef de Krijger
Expert 1405 points

Other Parts Discussed in Thread: Z-STACK, CC2530

Hi,


During tests with a large network (> 120 nodes) with stack parameters tuned according to AN123 (breaking the 400 node barrier). This works fine except for the fact that there is always a handful (< 5) nodes that do not show up in any other node's neighbor tables. They do respond to broadcasts. When power-cycling the node, it does become a neighbor and I can get a device announce (the latter only sometimes).

Could this have something to do with EXTENDED_JOINING_RANDOM_MASK and/or BEACON_REQ_DELAY_MASK? I don't understand  the comments in f8wConfig.cfg. How to both influence the "This value is masked with
 * the return from osal_rand() to get a random delay time for
 * each joining cycle." ?

Thanks,

Sjef.

  • 0
    TI__Genius 10650 points
    Hello Sjef,

    EXTENDED_JOINING_RANDOM_MASK is only masking the return value of osal_rand() function see file ZDApp.c function ZDOInitDevice() to understand this. Similarly for BEACON_REQ_DELAY_MASK in function ZDApp_ProcessOSALMsg(). They only configure the delay to the function ZDApp_NetworkInit() after which time the device will attempt to join the newtork.
    If this delay is too large and the network permit join is closed then these devices will not be able be able to join the network. And may not appear in the neighbor table of the nearby routers.
    To be sure of the issue I want to ask a few basic questions,
    How are you checking that the devices are present in the neighbor table of at least one neighbor?
    Have you ensured that these devices that have joined the network successfully? Is is possible after reset they are able to join the network successfully and in the first time they were not?
    Do you reset only these devices which do not appear in the neighbor table or all network devices after which you see these device appear in the neighbor table?
    Are the neighbor table of the nearby routers full?

    Regards
  • 0 in reply to Suyash Jain
    Expert 1405 points
    Hi Suyash,

    Thanks for your answer. It's possible I don't understand the terminology correctly. The network is already existing and all devices are on the network. By 'on the network' I mean they all respond to a broadcast command. Does this mean the devices have all joined?

    When I study the code in ZDOInitDevice, to me it seems that when the NFN device is powered on it re-joins the network (ZDApp_NetworkInit() is called, which joins a network, according to the comments). Or does, in Z-Stack code, the word 'join' have a different meaning?

    I see now that EXTENDED_JOINING_RANDOM_MASK is not used when restoring network state, so it's no use to change this, I guess. Assuming the device has already 'joined' the network.

    What I want to do is this: Imagine 100 nodes (NFN, already on the network) are powered up at once. I want to spread the messages.

    > How are you checking that the devices are present in the neighbor table of at least one neighbor?
    Use a recursive algorithm to get all devices' neighbor tables (ZDO_LQI_REQ).

    > Have you ensured that these devices that have joined the network successfully?
    If 'join' means 'on the network' (i.e. responding to a broadcast, that's how I confirm this) then YES.

    > Do you reset only these devices which do not appear in the neighbor table
    Yes.

    > Are the neighbor table of the nearby routers full?
    Yes. Maybe this is a problem. I increased the neighbor table size to 48 (cf. AN123). Maybe I should increase it more? But on other hand, many neighbors with very low LQI could be replaced by the stronger one. Does Z-Stack do this?


    Thanks,
    Sjef.
  • 0 in reply to Sjef de Krijger
    Expert 1405 points
    A reply to this would be welcomed.
  • 0 in reply to Sjef de Krijger
    Expert 1405 points
    Bump again? Suaysh, do you see this message or is there a reason you wish to not reply???????
  • 0 in reply to Sjef de Krijger
    TI__Genius 10650 points
    Hi Sjef,

    Sorry for the delay on my reply.

    For your questions above please see my response below:

    Thanks for your answer. It's possible I don't understand the terminology correctly. The network is already existing and all devices are on the network. By 'on the network' I mean they all respond to a broadcast command. Does this mean the devices have all joined?

    [S] Yes, if the devices are responding to broadcast command messages for the network. The devices are on the network.


    When I study the code in ZDOInitDevice, to me it seems that when the NFN device is powered on it re-joins the network (ZDApp_NetworkInit() is called, which joins a network, according to the comments). Or does, in Z-Stack code, the word 'join' have a different meaning?

    [S] You are correct, the ZDOInitDevice() is called start the device in network, it initiates either the new network join, rejoin, or resume of the device based on the device's state. If the device is factory new, the stack will then attempt to start the network if the device is coordinator, join a network in case of router or end device. If the devices had joined the network before and this function is called for example after a power cycle, the device will then resume its state in the network as before the power cycle.

    I see now that EXTENDED_JOINING_RANDOM_MASK is not used when restoring network state, so it's no use to change this, I guess. Assuming the device has already 'joined' the network.

    What I want to do is this: Imagine 100 nodes (NFN, already on the network) are powered up at once. I want to spread the messages.

    > How are you checking that the devices are present in the neighbor table of at least one neighbor?
    Use a recursive algorithm to get all devices' neighbor tables (ZDO_LQI_REQ).

    > Have you ensured that these devices that have joined the network successfully?
    If 'join' means 'on the network' (i.e. responding to a broadcast, that's how I confirm this) then YES.

    > Do you reset only these devices which do not appear in the neighbor table
    Yes.

    > Are the neighbor table of the nearby routers full?
    Yes. Maybe this is a problem. I increased the neighbor table size to 48 (cf. AN123). Maybe I should increase it more? But on other hand, many neighbors with very low LQI could be replaced by the stronger one. Does Z-Stack do this?

    [S] Z-Stack will replace the neighbors to which a router has a broken link. If the two routers can still hear each other’s link status messages and send messages to each other but the LQI is not better than other say for example a potential neighbor with a better LQI value, Z-Stack will not replace a neighbor will lower LQI value.
    Also, all the routers should show up in the ZDO_LQI_REQ if all the routers that were part of the network when the missing routers joined the network are powered on. The reason is when routers respond to the zdo_lqi_req, they send the information from both the association table and neighbor table. So the parent of missing routers should report the missing routers as part of the zdo_mgmt_resp message. Is it possible that the parent of the missing are turned off when you are doing the network scan using zdo_lqi_req.
    Also, there is a parameter “startIndex” see the API 3.1.6.3 ZDP_MgmtLqiReq() in the Z-Stack API document for description. Are you getting all the neighbors from a router before asking for information from the next one?

    Regards
  • 0 in reply to Suyash Jain
    Expert 1405 points
    Hi Suyash,

    Thanks for your reply, it does clear up my confusion about when a device is supposed to be joined or not. As for the issue with neighbor tables, I verified that the startIndex parameter is used correctly. I did notice that it's always the same nodes that don't seem to be in neighbor tables, so now I'm looking at a possible hardware issue.

    Thanks,
    Sjef
  • 0 in reply to Suyash Jain
    Intellectual 645 points

    Hi Sjef,

    I am facing the same problem:

    "What I want to do is this: Imagine 100 nodes (NFN, already on the network) are powered up at once. I want to spread the messages. "

    I see my co-ordinator (CC2530) is not even able to respond to 18 nodes when all turned on at the same time and trying to send messages at the same time. co-ordinator seems to be dropping packets. How do I ensure they start sending data at random intervals?

    May be I should use random function to decide timer interval in all of these nodes..It is needed only the first time I guess. 

    -Dhaval

  • 0 in reply to Dh Sh
    Guru 735695 points
    Basically, Zigbee device would do collision detection so they won't send message at the same time. I would suggest you to use Ubiqua Packet Analyzer to check what happens.