Hi,
we use the Z-Stack version 2.3.1-1.4.0 on CC2530. We changed a lot of code within the ZDApp.c to implement a certain network agility. This way we build end devices which are able to join any network with the correct stack profile and the join permission flag set. Basically this is working fine, but sometimes there are problems occurring during the network join process.
The end device sends a beacon request, gets a bunch of beacon frames returned by the surrounding routers and the ZDO_NetworkDiscoveryConfirmCB is called by the network layer. For the purpose of debugging every discovered network is written to a non-volatile log file. Anyway some devices need a lot of attempts to join a PAN even though the flags within the beacon frames are set correctly (checked with packet sniffer). Some devices never join after a time. I located the problem within the network layer. Sometimes beacon frames of the correct PAN are not passed through the network layer. In other cases the PAN is detected correctly and presented to the callback, but the device capacity flag (join permission) seems not to be set, even though it is in the received beacon frame.
To analyze this behavior I added a counter to the event handler for MAC_MLME_BEACON_NOTIFY_IND, which counts the number of beacon frames received and forwarded to the network layer between two calls of the ZDO_NetworkDiscoveryConfirmCB. This way I get the number of received beacon frames and recognized PANs. In my opinion the number of PANs should be less or equal than the number of beacons. But in several cases the network layer discovered e.g. three PANs from just one beacon frame received during one network scan. Faced with this, I assume the network discovery procedure to have a memory of past scans. Is it possible to clean this up? For this application the network discovery seems to be not reliable. Thus my question is, whether I can get more information about this part of the network layer? Are there some parameters to tune? Or is this a known issue of version 2.3 and is solved with the latest release? If so, changing to the latest version could be worth the effort of porting the code. Or do you have any suggestions to solve this problem?
Thank you!
Dave
