CC2650EMK: NLME_NetworkDiscoveryRequest specification

You can refer to section 3.4.1.1 NLME_NetworkDiscoveryRequest() in Z-Stack API.pdf under folder C:\Texas Instruments\Z-Stack Home 1.2.2a.44539\Documents\API

Thank you for your reply.

I cannot find the Z-Stack API.pdf.
Could you please attach it?

Best Regards,

You can refer to Z-Stack API.pdf

Hi, 
I have an additional question.
Is the source code for this function publicly available?

Best regards,
Yuya Murata

Hi Yuya,

The NLME layer and functions are part of the Z-Stack source code which is not made publicly available.

Regards,
Ryan

Thank you for your reply.

Yuya

Hi,

I found the following article.
https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/390470/in-what-condition-function-nlme_networkdiscoveryrequest-will-return-znwkinvalidrequest

It was noted that error code 0xC2 occurs when calling a function when it is already connected.
Do you know what the other conditions are that give you that error code?

Best regards,
Yuya

ZNwkInvalidRequest should be sufficiently explanatory, it will be returned when the parameters supplied do not match the expectations of the command.  Can you please provide an example of the command used with parameters included which returns this error?  Here also are more E2E threads for your reference.

Regards,
Ryan

Thank you for your reply.

What are the conditions under which other error codes occur?

Best regards,
Yuya Murata

For example, NLME_NetworkDiscoveryRequest returns ZNwkInvalidRequest if the local device is already part of a network.

ZStatus_t NLME_NetworkDiscoveryRequest( uint32 ScanChannels, uint8 ScanDuration )
{
  ZMacScanReq_t scanReq;

  // If device is already on a network, use ZDO_MGMT_NWK_Discovery.
  // Or else, leave the network first, then initiate the scan
  if ( ( _NIB.nwkState == NWK_ENDDEVICE ) || ( _NIB.nwkState == NWK_ROUTER ) )
    return (ZNwkInvalidRequest);

Regards,
Ryan

Hi,

ZNwkInvalidRequest was happend my ZED when ZED does not send Orphan Notification and Beacon Request.
Please see the attaced log file.

6305.log.zip

savedState is ZStack state(App get ZStack state using zclport_getDeviceInfo() )
and Beacon Request ret is NLME_NetworkDiscoveryRequest return value.

Do I need to restart the ZED to fix this problem?

Best regards,
Yuya Murata

Thank you for providing the sniffer log.  The ZC is not responding to any ZED Data Requests even after a successful Rejoin and Device Announcement (albeit with many superfluous packets).  The ZED then goes silent 30 seconds later and never shows more activity.  Device reset or otherwise, you need to repair the communication between these Zigbee nodes.

Regards,
Ryan

Hi, 

What does NLME_NetworkDiscoveryRequest output in the error codes defined in ZComdef.h?
Are all error codes likely to be output?

Best Regards,
Yuya Murata

Hi, 
Thank you for early reply.

Please tell us the following two things about ZNwkInvalidRequest error.

1. What is the source code that changes to _NIB.nwkState = NWK_ENDDEVICE?
    I cannot find it.
2. What is the callback function for the disconnection?
    For example, the function that is called when there is no response from ZC due to radio power weak.

Best regards,
Yuya Murata

Hi,

Is what you are describing how to know about the disconnect in the application (SampleSwitch code)?
What I want to know is the callback function when z-stack detects a disconnect, not the application.
I am assuming there is a function that is called when the z-stack detects a disconnect, for example, the ZDO_NetworkDiscoveryConfirmCB function is set as the callback function for the NLME_NetworkDiscoveryRequest function.
Do you have any information on this?

Best Regards,
Yuya Murata

Switch_processZStackMsgs (using SampleSwitch as example) is the callback for disconnect and other network state.

Hi,

I have a question about the previous log.
In the previous log, I got DEV_ANNCE on the packet, but the devState of the z-stack obtained by zclport_getDeviceInfo was not DEV_END_DEVICE.
Are there any conditions that would cause this kind of logging?

To, YK

I am waiting for the defect to reproduce itself using the following new logging method.
When it reproduces, I will post that log.

In Sensor_process(Tempsensor.c)

System_printf("ICall_wait start\r\n\0");
/* Wait for response message */
ICallerrNo = ICall_wait(ICALL_TIMEOUT_FOREVER);
System_printf("In ICALL_WAIT\r\n\0");
System_printf("ICallErrNo = %d \r\n\0", ICallerrNo);
if(ICallerrNo == ICALL_ERRNO_SUCCESS)
{
    System_printf("In ICALL_WAIT\r\n\0");
    pzDevInfo = zclport_getDeviceInfo(ztsEntity);
    dDevState = pzDevInfo->devState;	
    outputDevState(dDevState);	
    if(ICall_fetchServiceMsg(&stackid, &dest, (void **)&pMsg)
         == ICALL_ERRNO_SUCCESS)
    {
		System_printf("In fetchServiceMsg\r\n\0");
        if( (stackid == ICALL_SERVICE_CLASS_ZSTACK) &&
           (dest == ztsEntity) )
        {
          if(pMsg)
          {
            TempSensor_processZStackMsgs(pMsg);
            
            // Free any separately allocated memory
            Zstackapi_freeIndMsg(pMsg);
          }
        }
    }
    ~~processing for TEMPSENSOR_DATA_SEND_EVENT)~~
}

In TempSensor_processZStackMsgs(Tempsensor.c)

case zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND:
    {
      // The ZStack Thread is indicating a state change
	  System_printf("msg=DEV_STATE_CHANGE_IND\r\n\0");
      zstackmsg_devStateChangeInd_t *pInd
        = (zstackmsg_devStateChangeInd_t *)pMsg;
      
      // Only process the state change if it actually changed.
      if(savedState != pInd->req.state)
      {
        savedState = pInd->req.state;
      	outputDevState(savedState);  
        if((pInd->req.state == zstack_DevState_DEV_ZB_COORD)
           || (pInd->req.state == zstack_DevState_DEV_ROUTER)
             || (pInd->req.state == zstack_DevState_DEV_END_DEVICE))
        {
          // The device is part of a network, get the device's
          // network parameters.
          //pNwkInfo = zclport_getDeviceInfo(ztsEntity);
          
          
          if(pInd->req.state != zstack_DevState_DEV_END_DEVICE)
          {
            
            
          }
          else
          {
            // Change the default poll rate from 1 second to
            // the config setting in znwk_config.h
            TempSensor_setPollRate(1000);
          }
          
#if defined (ZCL_EZMODE)
          zcl_EZModeAction(EZMODE_ACTION_NETWORK_STARTED, NULL);
#endif
        }
      }
    }
    break;

Best Regards,
Yuya

Please provide the contents of the DEV_ANNCE packet and zclport_getDeviceInfo values.  It is difficult to provide further insight without specific details.

Regards,
Ryan

Hi Ryan,

Please see the attaced file.

0211.log.zip

ED send Device Announce Packet.( Please see packet No. 224033)
But, saved state did not change from NWK_DISC to DEV_END_DEVICE(please see log file Line 435 ~ 452)
Log file line 442, I think it is actually savedState = DEV_NWK_SEC_REJOIN_ALL_CHANNEL.
My coding mistake was to show savedState of the App before the update.

Best Regards,
Yuya Murata

According to my experiences, you shouldn't see so many device announcement when ZED rejoins network and also fast/continuously data request. If you run default example without your modifications in Z-Stack source code, do you still see such behavior?

Hi, YK
Thank you for your reply.

Please see the attached log and packet sniffer log.
I used sample codes except for the transmit power.(I used ZMacSetTransmitPower(TX_PWR_MINUS22); )
Sometimes, device announcement  see fast/continuously in packet sniffer log.
(packet No. 1627-1639, 1740-1792, 4751-4760, 5577-5588)

log_1018.zip

I would like to see your opinion.
Best Regards,
Yuya Murata

My opinion is why you set TX_PWR_MINUS22 when doing your test? If you use normal TX power, do you still see the same issue?

Hi, YK
Thank you for your reply.

Please see the attached packet sniffer log.
Below is the log when transmission power is not reduced.
Sometimes, device announcement  see fast/continuously in packet sniffer log.
(packet no. 443562-443605, 443805 - 443816)
0526.zip

The product I am developing needs to be reconnected even if the distance between ZED and ZC is far.
For this reason, I am testing the product with reduced transmit power.

Best Regards,
Yuya

The sniffer log looks much better. I remember Z-Stack would check if signal strength is good enough for rejoin. You can try to revise "uint8 gMIN_TREE_LQI = MIN_LQI_COST_3;" in nwk_globals.c  to "uint8 gMIN_TREE_LQI = MIN_LQI_COST_7;" to see if rejoin works better when signal is poor.

Hi, YK
Thank you for your reply.

Your help has been very helpful.
I will try your answer.
But, my question to you now is the following.

I have a question about the previous log.
In the previous log, I got DEV_ANNCE on the packet, but the devState of the z-stack obtained by zclport_getDeviceInfo was not DEV_END_DEVICE.
Are there any conditions that would cause this kind of logging?

8053.log.zip

I hope to have an answer on this question .

Best Regards,
Yuya

You might need a moment for device to change its state to DEV_END_DEVICE after it joins or rejoins network. If the device joins or rejoins network failure, you might see DEV_ANNCE but the device is actually left the network.

You might need a moment for device to change its state to DEV_END_DEVICE after it joins or rejoins network.

I need more information about the above.
In most cases, the following code works: devState becomes DEV_END_DEVICE, the ZDO_REJOIN_BACKOFF event timer stops, and a device announce packet is sent.
However, the log behavior shows that the device announcement packet is sent, but the devState does not become DEV_END_DEVICE, the ZDO_REJOIN_BACKOFF event timer expires, and the devState becomes DEV_NWK_BACKOFF.
(please see pacekt log No. 224033, and serial log Line 435 ~ 452)

In ZDApp_ProcessNetworkJoin(ZDApp.c, Line1594~1654)

else if ( devState == DEV_NWK_ORPHAN ||
            devState == DEV_NWK_SEC_REJOIN_CURR_CHANNEL ||
            devState == DEV_NWK_TC_REJOIN_CURR_CHANNEL ||
            devState == DEV_NWK_TC_REJOIN_ALL_CHANNEL ||
            devState == DEV_NWK_SEC_REJOIN_ALL_CHANNEL )
  {
    // results of an orphaning attempt by this device
    if (nwkStatus == ZSuccess)
    {
      //When the device has successfully rejoined then reset retryCnt
      retryCnt = 0;

      // Verify NWK key is available before sending Device_annce
      if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey( TRUE ) == false ) )
      {
        // wait for auth from trust center
        ZDApp_ChangeState( DEV_END_DEVICE_UNAUTH );

        // Start the reset timer for MAX UNAUTH time
        ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );
      }
      else
      {
        ZDApp_ChangeState( DEV_END_DEVICE );

        osal_stop_timerEx( ZDAppTaskID, ZDO_REJOIN_BACKOFF );

        // setup Power Manager Device
#if defined ( POWER_SAVING )
        osal_pwrmgr_device( PWRMGR_BATTERY );
#endif

        // The receiver is on, turn network layer polling off.
        if ( ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE )
        {
          // if Child Table Management process is not enabled
          if ( zgChildAgingEnable == FALSE )
          {
            NLME_SetPollRate( 0 );
            NLME_SetQueuedPollRate( 0 );
            NLME_SetResponseRate( 0 );
          }
        }

        if ( ZSTACK_ROUTER_BUILD )
        {
          // NOTE: first two parameters are not used, see NLMEDE.h for details
          if ( ZDO_Config_Node_Descriptor.LogicalType != NODETYPE_DEVICE )
          {
            NLME_StartRouterRequest( 0, 0, false );
          }
        }

        ZDApp_AnnounceNewAddress(); // send device announce packet

        if ( ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE) == 0 )
            || ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE)
              && (zgChildAgingEnable == TRUE) ) )
        {
          NLME_SetPollRate( ZDApp_SavedPollRate );
        }
      }
    }

What condition would be the time-consuming condition you speak of?

Best Regards,
Yuya

Hi, Ryan
Thank you for your reply.

I gave you the wrong information.
The number of lines in the log file is 1882~1908.

You might need a moment for device to change its state to DEV_END_DEVICE after it joins or rejoins network.
I would like the following information regarding the above.
1. Do you know where exactly the process takes time?
   Black box processing(zigbee processing) -> ZDO_JoinConfirmCB -> ZDApp_event_loop -> ZDApp_ProcessOSALMsg
   -> ZDApp_ProcessNetworkJoin -> ZDApp_ChangeState(DEV_END_DEVICE)  -> state = DEV_END_DEVICE
   -> osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT ) -> ZDApp_event_loop -> ZDO_UpdateNwkStatus( status )
   -> zdoSendStateChangeMsg() -> (osal_event_hdr_t *)osal_msg_allocate(sizeof(osal_event_hdr_t)) -> (void)osal_msg_send(taskId, (uint8 *)pMsg);
2. What is the maximum delay?

3. Serial log is output when ICall_wait is released, but please tell me the event when Icall_wait is released.
    I am considering the possibility that the state may have been set to DEV_END_DEVICE, but the ICall_wait wait was not released and could not be taken.

Best Regards,
Yuya Murata

This delay has not been specified.  It typically encapsulates less than a few seconds.  You can measure the time it takes for a device to change states from NWK_DISC to DEV_END_DEVICE with a functional setup and use such instance as a guide.  Your focus should be centered on the fact that the device leaves the network in a short amount of time due to poor connection quality with its parent.

Regards,
Ryan

Hi, Ryan

The packet and serial logs of the problem are summarized in the attached file.
I have questions regarding the following points
I would like to know your opinion.

1. From line 18 to line 55, 9 seconds time has elapsed.
    During this time, the state is not DEV_END_DEVICE on the log.
    Is there any case like this where more than 8 seconds elapse before the state goes
    from DEV_NWK_REJOIN_SEC_ALL_CHANNEL to DEV_END_DEVICE?

2. If you do not know how long it takes to go from DEV_NWK_REJOIN_SEC_ALL_CHANNEL to DEV_END_DEVICE,
    I would try to counteract this problem by performing a soft reset.
    Do you think this countermeasure is OK?

Issues behavior.zip

Best Regards,
Yuya

The time between DEV_NWK_SEC_REJOIN_ALL_CHANNEL and DevState_NWK_BACKOFF can vary based on the number of network rejoin attempts and definitions I previously mentioned as determined by the Z-Stack settings, however it appears you've defined the time based on your current stack build.  Performing a soft reset will not resolve the issue of poor communication between these devices and if you want a different action other than DevState_NWK_BACKOFF in your application then you can make the change in ZDApp.c or decrease the REJOIN_BACKOFF.

Regards,
Ryan

Hi,

I measured the processing time of zclport_getDeviceInfo.
A processing time of about 9 seconds was sometimes required.
Is the processing time of this function so long?
I will provide the logs I took and the source code.

System_printf("ICall_wait start\r\n\0");
/* Wait for response message */
ICallerrNo = ICall_wait(ICALL_TIMEOUT_FOREVER);
System_printf("In ICALL_WAIT\r\n\0");
System_printf("ICallErrNo = %d \r\n\0", ICallerrNo);
if(ICallerrNo == ICALL_ERRNO_SUCCESS)
{
  startTick = Clock_getTicks();
  pzDevInfo = zclport_getDeviceInfo(ztsEntity);
  endTick = Clock_getTicks();
  System_printf("Beacon Request ret = %d\r\n\0", pzDevInfo->nwkAddr);
  System_printf("Send DEV ANNOUNCE ROUTE = %d\r\n\0", pzDevInfo->panId);
  System_printf("DISCONNECT ROUTE = %d\r\n\0", pzDevInfo->parentNwkAddr);
  // zclport_getDeviceInfo tick print start
  System_printf("zclport_getDeviceInfo tick count\r\n\0");
  System_printf("%d\r\n\0", endTick - startTick);
  ------------ ------------------------------------
}
    

logfile.txt

zclport_getDeviceInfo is ultimately serviced by processSysNwkInfoReadReq.  There are no operations in this function which should consume an excessive amount of time.  One caveat is that Zstackapi_sysNwkInfoReadReq is used in-between to establish an ICall message to communicate between the zcl_port and zstacktask layers, so if the ICall queue is busy then this could cause further delay.  However, you really shouldn't need to request the device info as much as your log insinuates.  Monitor the zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND from your application if you need to know when the device state changes and further process accordingly.

Regards,
Ryan

Hi, Ryan

Thank you for your reply.
If ICall is busy, processing zclport_getDeviceInfo takes time.

I have found a way to reproduce this error.
・Set rejoinScanDuration very short.( I set it 1500ms)
This error is caused by a BACKOFF before a rejoin response is received.
Please try it.

I have a few questions I need answered.
・Can the period to send a Beacon Request be calculated using the following formula?
BEACON_REQUEST_DELAY + BEACON_REQ_DELAY_MASK + (zgDefaultStartingScanDuration * runtimeChannel)

・What is the code for the z-stack to send the DEV_STATE_CHANGE_EVENT message to the application via ICall?
ZDApp_ChangeState -> osal_set_event -> ZDO_UpdateNwkStatus -> zdoSendStateChangeMsg -> osal_msg_send
( zstacktask.c) ZStackTaskProcessEvent -> processDevStateChange

Best Regards,
Yuya

TI is no longer investing in the CC2650 as a valid Zigbee solution, so this behavior is not something I will be taking the time to recreate.  The time it takes to actively scan all channels is the scan duration times the number of channels in the channel mask.  BEACON_REQ_DELAY_MASK is a bit mask, not a value in units of time.  The application is notified of device state changes through ZDApp_ChangeState, and this does follow to ZDO_STATE_CHANGE in your application (my original reference was accidentally from the SimpleLink SDK).

Regards,
Ryan