Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 233 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.

CC2674P10: Commissioning process - processing time

Geoffrey Ficara
Intellectual 2480 points
Part Number: CC2674P10

Tool/software:

Hi, 

I have a question regarding the provisioning process on Zigbee using the Network Steering command. When this commands is executed the application is completely blocked and all application tasks are no longer executed for a period varying between 350 and 550ms. The goal is to reduce this time. 

During the analysis we found out that : 

  • When a commissioning request is made periodically and no controller is present, the Zigbee stack still consumes the same initialization time each time, without any real exchange with a controller.
  • The initialization phase is systematically repeated for each request.

it leads me to 3 questions : 

  1. Is 400 ms the expected processing time for commissioning using the Network Steering command, even without a controller ? 
  2. In a scenario where the application launch that command periodically, is there a way to reduce the time spent in this routine (init once then skipped ?) or do all the steps have to be repeated ?
  3. Finally, based on the documentation > 12.5 Network Steering Procedure for a Node not on a Network, 
    (https://software-dl.ti.com/simplelink/esd/plugins/simplelink_zigbee_sdk_plugin/1.60.00.14/docs/zigbee_user_guide/html/zigbee/developing_zigbee_applications/z_stack_developers_guide/z-stack-overview.html#commissioning) there are some configurable parameters. One idea to reduce the processing time would be to disable the secondary channels (searching only on the primary channel). Would you recommend that? 

Thank you,

Geoffrey 

  • 0
    TI__Guru**** 208417 points

    Hi Geoffrey,

    Please reference the correct documentation, here is the most recent Z-Stack User's Guide from TI Resource Explorer.  You should certainly remove the secondary channel set, reduce the number of channels scanned in your primary channel set, and possibly reduce the BDB_DEFAULT_SCAN_DURATION (untested).  Please note that these changes will reduce the possibility of identifying open Zigbee networks nearby.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Intellectual 2480 points

    Hi Ryan, 

    Thanks for your feedback, I have a bit more information now. 

    • Removing the secondary channels doesn't have much influence on the commissioning time.
    • Figure 37. Network Steering Procedure for a Node Not on a Network would make you think a longer time is needed to to exchange keys etc... when you find a network. However the commissioning time is similar whether a network is found or not when the network steering command is used.

    We tried the following too : 

    • networkStateNV == ZDO_INITDEV_RESTORED_NETWORK_STATE : in this case ZDApp_RestoreNetworkState() is called to restore the previous network 
      • ZDOInitDeviceEx() (368 ms)
      • zgInitItems() (210 ms)
      • zgInitItems() (155 ms)
    • networkStateNV != ZDO_INITDEV_RESTORED_NETWORK_STATE : network parameters set by default 
      • ZDOInitDeviceEx() (401 ms)
      • zgInitItems() (210 ms)
      • NLME_InitNV() (80 ,71 ms)
      • NLME_SetDefaultNV() (92,5 ms

    As you can see ZDOInitDeviceEx() function is the main cause of the latency observed when calling the Zstackapi_bdbStartCommissioningReq() function. More particularly, it is mainly due to the execution of certain sub-functions such as zgInitItems(), ZDApp_RestoreNetworkState(), NLME_InitNV(), and NLME_SetDefaultNV().

    These functions seem to be executed systematically during commissioning, even when no open network is detected. This raises several questions:

    1. Why are these operations performed even if no network is available? For example, why do we need to restore or reset network settings if the device is not yet connected to a network? This seems to introduce unnecessary latency when we try to scan for open networks.

    2. Is it possible to optimize the execution of these functions in the context of commissioning? (they are located in bdb.c)

                    For example by adding ourselves conditions of executions (to run them only when restoring an existing network or initializing a new one) ?               By modifying the delay argument inside ZDOInitDeviceEx(delay, x))

    Regards

    Geoffrey 

  • 0 in reply to Geoffrey Ficara
    TI__Guru**** 208417 points
    1. This is done to restore NV settings that may have changed since the last Network Steering was performed, such as channel and PanID.
    2. The customer could possibly reduce the amount of times that zgInitItems is called to once at startup if they are confident that NV items will not be updated.  They could also further evaluate changes to the extendedDelay length and determine whether it affects the ZR's ability to properly join a network.  The NV sub-functions are the only APIs listed which cannot be modified by the customer as they reside inside of source code.

        // Only delay if joining network - not restoring network state
    extendedDelay = (uint16_t)((NWK_START_DELAY + startDelay)
              + (OsalPort_rand() & EXTENDED_JOINING_RANDOM_MASK));

    Regards,
    Ryan