I built a ZigBee mesh network out of 20 programmable XBee XB24Cs running ZigBee TH regular 405F firmware. Those XBees are attached to a raspberry pi 3 on which my application is running. The RasPis communicate with the XBee through serial communication, so they are running in API mode. I configured the API output mode as Explicit + unsup ZDO in all XBees.
There is a coordinator in the network to which at every minute all other XBees send 80 packets with 750 ms time intervals, of which 64 packets are full, which means carry 255 bytes payload.
The problem is that 3 of 500 packets includes the original transmit request frame. An example is given below.
I believe the coordinator cannot handle that much frequent data delivery and screwing up the data handling, but I am still not sure. There may be an issue with the firmware.
BTW, at the sender side each XBee sends one packet at a time, and the code is single threaded. For those who may want to see the code that I use to wrap up the payload:
void sendPayload(uint8_t* payloadHEX, int payloadLength){
int length = payloadLength + 14;
int nOfSendBytes = payloadLength + 18;
No, I mean this was in one of RX Indicator frames that I read through serial. This is a part of any of the sender packets. This TX transmit packet was supposed to be parsed, and the payload was supposed to be presented in an Explicit RX Indicator frame in a correct format. Instead, the transmit packet was literally copied into an RX Indicator packet. That’s the problem.
May I suggest you mount these radios in an XBIB board and try to reproduce the issue outside of your hardware? I think you will find that this is most likely an issue with the packet that is being sent to the XBee on the Tx side.