I have developed an application using Arduino code to connect remote IO devices over a serial protocol. The first Arduino IO device is allocated as the controller and it’s possible to connect other Arduino IO devices as routers.
The Arduino is a 328P MCU and has IO device control of relay outputs and optical inputs. The Xbee is Series 2 ZB series working in API mode 2.
We are using a serial protocol that can be forwarded to other IO devices over the XBee to extend the number of IO that we can control.
The issue is that after sometime the routers appear to go-offline (after many hours).
When they get into this state - the XBee is able to send data via serial to the Arduino - but it appears to ignore all data sent via serial from the Arduino to the XBee.
When it gets into this state - I am able to reset the Arduino but it has no impact on the communications with the XBee. The only way to recover the XBee is a hardware reset of the XBee. I believe this pretty much rules out an issue with the Arduino code.
I am communicating with the XBee without any flow control, and I am using the softwareSerial library. I have no ability to add flow control, or even hardware serial communications - the hardware I have is pretty much fixed. I am communicating with serial at 57600 bps.
I would be fairly confidant that I am overflowing the buffer in the xbee on occasions - but would never have expected that it could cause the XBee to freeze like this.
This is a very critical - hopefully there is a way this can be resolved?
I had a similar issue for several sleeping XBee nodes, described in the Digi forum.
I am also aware of the Stackoverflow case as you referred.
Even if i strongly suspected that the problem was connected to serial buffer overflow, I believe that the real problem is connected to the settings of the parameter ST. After increasing this parameter from 300mS to 2sec. I have not faced any problem with freezing nodes.
On the other hand, I fully agree with you, a serial buffer overflow should not cause the XBee to freeze/crash like this.
Thanks for the details, I have seen this post, but did not think it was applicable.
I am not using end devices, only routers at the moment. The routers never sleep in the current configuration.
I also note that this issue occurs most commonly when the router is having trouble communicating, or where coms will come and go. I believe this is because of the backlog of messages it tries to send through causing the buffer to overflow.
If you are over flowing the buffer, then it is very possible that your API frames are not being received fully resulting in the radio appearing to be lock but in reality, it is waiting for a new valid API frame to be received. To verify this, try using transparent mode since the flow control lines are not an option or reduce the baud rate to 9600 or 2400bps.
Did you find some reliable solution for this problem?
I have the same problem with the xbee S3 pro.
The problem occurs in two situations using API mode:
1 - The sender try to send too much data and some error happens on receiver. In this case, the sender just freeze and I’m not able to send packets until I unplug from the USB and plug it again. In some case, the xbee returns after some minutes (5 -10 min).
2- There are 2 or more node trying to send a lot of data in the same moment. The receiver just freeze. In this case, I believe that the receiver buffer is full and for some reason it keep receiving more packets until freeze.
The baud rate is 230400, I’ve tried to reduce this value but with no success. Moreover, the nodes does not sleep, so ST command does not work as well.
I was wondering if there is some way that I could reset the xbee via code. I’ve already tried the FR command with no success. Maybe some code to force the reset pin.