Sometimes Blind node does NOT rejoin network unless reset

What version of the stack are you using, 1.4.3? You will have to add nwkNeighborTableInit() to the ZDO_SyncIndicationCB function, or otherwise, over time the neighbor table will fill up and not cause the ZDO state machine to trigger a rejoin. I would also suggest increasing the size of the neighbor table from 4 to something like 20, or as large as you can make it.

Mr. Zed,

Thanks! I'm trying to implement this into my project code. I will update the result once done.

Henry

hi,

I think the problem is NV_RESTORE option. in my tests i realise that if you want to use NV_RESTORE option , you should apply this to all devices including coordinator also..

kuyuk:

Thanks for reply. I've tested it in all devices have NV_RESTORE option, but still got same result.

"Z",

Unfortunately, your code doesn't work, even both ways are applied. 

So, I let my end-devices force reset every 10 minutes, it works fine, but I expect the correct way.

Henry

What do you mean by my code doesn't work? It works? Without this workaround you will see end devices not even rejoin if they have too many neighbors. So you definitely need that line of code in there.
All devices must have NV_RESTORE turned on.

Force reset blind nodes timely can "solve" this issue.

Even add nwkNeighborInitTable() to the ZDO_SyncIndicationCB function as below, the blind nodes still cannot trigger rejoin when its parent was gone.

 void ZDO_SyncIndicationCB( byte type, uint16 shortAddr )
{

#if !defined ( RTR_NWK )
    if ( type == 1 )
    {

     nwkNeighborInitTable();
      ZDApp_SendMsg( ZDAppTaskID, ZDO_NWK_JOIN_REQ, sizeof(osal_event_hdr_t), NULL );
    }
#endif
  return;
}

increasing the size of the neighbor table from 4 to 20 doesn't make difference.

The blind node has NV_RESTORE, but ref node has not.

Hi Z,

I'd like to declare the issue more clearly. Actually, the blind node does not aware (or take action to rejoin) its parent has gone when it sent the data to parent router without any response. It continue to send next data frame to the dispeared parent router unless reset it. So, I guess the issue isn't caused by the neighbor capacity.

Thanks

Henry

Hi Henry,

This is what must happen normally: The End-device, node in your case, sends data to its parent and listens for an ACK from the parent. If it does not receive an ACK after a timeout it tries to resend the same data and waits for an ACK. This procedure is repeated a few times; i believe 8 times (you can use the sniffer to figure this out), and if ACK is still not received the node gives up and informs your App via the AF_DATA_CONFIRM event.

Now, the question is this, is your node waiting for an ACK from the parent after sending some data? The option to enable waiting for an ACK is supplied to AF_DATA_REQUEST. My hunch is that your node is not waiting for an ACK from its parent. So it just pumps data after data assuming that the parent is 'alive' when the parent has actually been turned off.

Please check this.

Hi Fox366631,

Your hunch seems to be not right. In Z-stack Samples Applications F8W-2006-0023. There is this paragraph:

This is an indication of the OTA result for each data request that is successfully initiated by invoking AF_DataRequest(). ZSuccess confirms that the data request was successfully transmitted OTA. If the data request was made with the AF_ACK_REQUEST flag set, then the ZSuccess confirms that the message was successfully received at the final destination. Otherwise, the ZSuccess only confirms that the message was successfully transmitted to the next hop.

That means even if you do not send with AF_ACK_REQUEST, you will still get an acknowledgement whether the next hop (i.e. the parent for an end device) has successfully received the data or not.

Yuan Jian