The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

CC2530: coordinator not receiving periodic packets from the router

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK


We have several networks deployed, that consists of one znp coordinator and ~100 routers each.
All router are programmed to send a periodic heartbeat msg (report attribute) to coordinator every 5 mins.

Some times these heartbeat does not reach the coordinator for 4 to 5 consequent heartbeats.
However, when ping is done from the coordinator(read attribute) to node, it receives the response
and also the heartbeat message are delivered to coordinator from next time onwards.

Here is the data from a smaller network ~38  nodes ( channel id 16) no other networks in this channel.
In this network also we observe missed heart beat once in a while.
This is the Wireshark capture from that network 

You can see from above image, that the packets of sequence id 36 and 37 are missing.

The correlation we have observed are, 
1) more heartbeats per node are lost when the network size(router count) is bigger 
2) when ping is done from the coordinator the route is restored, and heartbeat messages are received from the nodes that were failing earlier

Q1) what may be the cause of above mentioned correlations?

Q2) why the packets are missing so much?

  • Hi Aviral,

    Which version of Z-Stack are you using?  Are all products using TI CC2530 devices?  Provided Link Status messages, Z-Stack defines NWK_LINK_STATUS_PERIOD for each device.  This value must typically be agreed upon by all devices in the network (standard value of 15 seconds) and after NWK_ROUTE_AGE_LIMIT missed link status frames (default 3 in Z-Stack) the route between associated devices will be marked as bad/faulty.  It could then be restored after receiving a message from the associated device.  Packets may not be sent out on the network if the channel is too noisy (controlled by CSMA/CA feature) and this issue can propagate with more devices on a network.  Also, the limited RAM on the CC2530 requires caution when deploying large networks, as a ZC/ZNP node type requires more RAM to manage communication with so many nodes.  It would not be surprising if the ZC failed to ACK some Report Attribute messages, possibly causing a bad/faulty route indication on the ZR, while attempting to process messages for several devices.