Home/Support/Support Forum/Xbee S2 randomly disassociated

Xbee S2 randomly disassociated

0 votes
Dear all,

We are facing a strange situation by using the XBEE S2 RF Module.

We had set up a network topology using:
- 1 Coordinator in API=2
- 10 Routers in API=1
- 12 End Devices in API=2

Everything are established normally and working properly by communicating custom messaging through network (We have testing the topology for at least one week without having issues).

However, there are times (randomly) that we get the a disassociation packet (apiId=MODEM_STATUS_RESPONSE (0x8a),error=false,status=DISASSOCIATED) and the whole network is stacked. The coordinator is not hard Reseted and is not send any command regarding disassociation.

Our first question is when else a disassociation is occurred (except from hard Reset or Disassociation Command) because the network is stacked and any communication is working from coordinator to Routers or End Devices.

Our second thoughts are regarding coordinator as in that state the coordinator seems that he can receive messages but cannot send. Is this associated with the first issue?

Please for your help.

Thank you.
asked Sep 28, 2015 in IEEE 802.15.4 by p.andriopoulos New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
Before this can be answered, we would need to know which node this command is coming from.
answered Sep 29, 2015 by mvut Veteran of the Digi Community (11,302 points)
Hi mvut,

Thank you for your reply. The command is coming from Coordinator as he is responsible for the whole network. I log this response in one of the Actuators.
Can you provide the 4 API frames going in and out of the UART just before the disassociation occurs? Make sure to include that packet as well.
As I mentioned before this occurs randomly and without any standard patterns so its very difficult to reproduce and record those 4 frames that going in and out.

It will be helpful too if you can inform me if there is any other reason (except the hard reset or association command) that occurs a disassociation.
Other than a hardware reset, watchdog reset or one of the network commands such as  NR or ID change, the module should not be resetting.
The only commands that remains to check more extensively is the watchdog. I have placed the NW=1 only to Routers.
This is why it is even more important to see the full frame and one or two before.
I will try to make a logging script in order to log every frame. I think this is the only solution.
...