• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 238 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.

CC2652R: Degrading network status leading to no communication with some devices

Antonio Portaluri
Intellectual 260 points
Part Number: CC2652R
Other Parts Discussed in Thread: CC2592, CC2530, CC2652P, , Z-STACK

Hi,
we are using a CC2652 as a zigbee coordinator (RC-CC2652PA) with the ZNP original firmware v4.30 (with only PA pins adjustment to work with CC2592 and network key).

There are 19 devices connected, all joined:

  • 14 routers with zstack 3.0.2 (CC2530)
  • 2 third parties end devices with Zigbee HA

At some point, the coordinator is not able to communicate with some devices and it does not receive any report from them. I've attached the sniffing trace filtered by only the Link Status messages and it is visible the network degradation. In particular, if you filter for coordinator messages, you can see the Link Status List decreasing.

Also, in most of the other routers messages, the coordinator entry disappear.

  1. What could be the reason of this malfunction? How can we avoid this behavior?
  2. Why the Link Status messages are not sent periodically?
  3. Why the device 0x92D7 (always joined) sends only 2 Link Status messages (the second with excellent communication with the coordinator)?

I've attacched the filtered trace for readability, but I can provide the original trace (about 6300 messages) or a part of it.

Thanks for the help,
Antonio

link_status.zip

  • 0
    TI__Guru**** 207137 points

    Hi Antonio,

    How far apart is each node and have you verified correct TX power output with the CC2592 front end?  Note the CC2652P accomplishes +20 dBm without an external power amplifier.  Where is the sniffer device located?  It could be missing packets based on interference and physical location.  Have you filtered the sniffer log to exclude other channel 11 networks and how noisy is this channel in general?  A few of the ZC's Link Status entries are poor but most have an acceptable incoming/outgoing cost.  Much larger networks have been tested but assume optimized stack settings, feasible report intervals, and minimal interference.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    Hi Ryan,

    All nodes are distributed in the office (grouped by 3-4 devices) and they are 15 meters max away from the ZC (approx at the center) with 2 walls at max to bypass. The power amplifier is ok and the sniffer was located about 1 meter from the ZC. I've not excluded other networks from the sniffer, but no other zigbee networks are showed.

    I have seen the same behavior in another scenario with 18 routers and 1 end device. In this case, the coordinator is not in the middle, the routers are distributed in 3 groups: 1 group very near the coordinator, 1 group at 10 meters with 2 doors to bypass, and 1 device in the middle. No noise and good reachability of the ZC also for the farthest group. In this scenario, the problem affects also some devices very near the coordinator. Another problem is the end device has the parent without a valid Link Status Entry for the coordinator, so it sends the report to the parent, but the router does not redirect the messages.

    We have done some tests. We are able to reproduce this issue by doing these steps: sending an SYS_RESET_REQ, then waiting some minutes before sending the startup_from_app message. In this interval, we have seen in all routers a degrading of Link Status costs regarding the ZC and then removing completely the entry at some point. I think this is acceptable due to the inactivity of the ZC.

    But after resuming the ZC (aka startup message), not all routers are able to restore the route to the ZC and some of them stop reporting data and NWK messages. I think this causes the issue.

    Do you have any observation/suggestion to avoid this behavior?

    The document you have linked is very interesting. We have done similar changes to our old ZC (based on CC2530). Since our scenarios use more ZR wrt your tests, do you suggest to us to apply these changes by default? And what is the number limit of ZR supported by the standard routing after which it is preferable to switch to the MTO routing? In other words: how we can decide which routing fitting better our scenarios?


    Thanks for the support,
    Antonio

  • 0 in reply to Antonio Portaluri
    TI__Guru**** 207137 points

    Hi Antonio,

    It would appear that your network issues are caused by the routing mechanism from the CC2530 routers, not the CC2652R coordinator.  You can refer to the Known Issues E2E discussion page for suggestions on optimizing Z-Stack 3.0.2.  Zigbee routing is self-healing and automatically controlled by the pre-built Z-Stack libraries, however you could force route discovery using NLME_RouteDiscoveryRequest from your application upon detection of a failed route or message delivery.  Of course these will be unsuccessful until your coordinator is active again.

    Many-to-One routing is a special routing scheme that handles the scenario where centralized traffic is involved. It is part of the Zigbee PRO feature set to help minimize traffic particularly when all the devices in the network are sending packets to a gateway or data concentrator.  You can read more about it in the Z-Stack Overview section of the Z-Stack User's Guide.  I recommend that you evaluate it for your use case.

    Regards,
    Ryan