• State Not Answered
  • Replies 5 replies
  • Subscribers 74 subscribers
  • Views 749 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 270569
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ZigBee End Devices Leaving nRF52840 Coordinator

WestCoastDaz

We have had our nRF52840 based Zigbee Coordinator in production since September of 2020 with great customer feedback.  Unfortunately, we have recently had several instances of third party ZigBee end devices leaving the network and requiring repairing by our customers which is a headache when the user isn't close to our device.

Most of the sensors that have this issue seem to be ZigBee 3.0 devices.  I have the following questions:

  1. Is there a method to determine why a sensor left the network from the ZBOSS stack?
    1. Is there method to determine if the coordinator caused the device to leave or if the device did it?
  2. Is there a defines process for handling ZigBee 30 devices leaving the coordinator?
    1. I noticed in the new nRF Connect SDK there where a lot of flow charts for handling the ZigBee signals including rejoining.
  3. Is there any other methods for diagnosing these kinds of lost connection issues?

This project is using nRF SDK for Thread and ZigBee v4.0.0.

Thanks,

Parents
  • 0

    Hi again

    Marte is right, the rejoining should be enabled by default. As this is occurring on your customer's devices, I understand that this might not be doable, but is it possible to get a traffic dump (.pcap) file so we can take a look at what's going on over the air. A suggestion by one of our Zigbee developers: Have you tried enabling the legacy device support on the coordinator (adding zb_bdb_set_legacy_device_support(1) in the ZB_BDB_SIGNAL_STEERING signal handler)?

    Best regards,

    Simon

  • 0 in reply to Simonr

    Yes, I have zb_bdb_set_legacy_device_support(1) enabled in the ZB_BEB_SIGNAL_STEERING handler.  Unfortunately I haven't been able to get a trace yet.  I have tried to get the NRF 802.15.4 sniffer to work on a rPI for long duration traces but  the interface doesn't seem to show up in Wireshark.

    Any other thoughts or tests?  Is there any error stats that the ZBOSS stack collects that would be helpful to review?

Reply
  • 0 in reply to Simonr

    Yes, I have zb_bdb_set_legacy_device_support(1) enabled in the ZB_BEB_SIGNAL_STEERING handler.  Unfortunately I haven't been able to get a trace yet.  I have tried to get the NRF 802.15.4 sniffer to work on a rPI for long duration traces but  the interface doesn't seem to show up in Wireshark.

    Any other thoughts or tests?  Is there any error stats that the ZBOSS stack collects that would be helpful to review?

Children
Related
Terms of service