Transmit request in an explicit RX indicator

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.

Header values
7E
01 10
91
00 13 A2 00 41 49 70 41
F7 21
E8
E8
00 11
C1 05
01

Payload
34 3B 32

Transmit Request Packet
7E 01 0C 10 00 00 13 A2 00 41 49 70 26 C1 12 00 00 34 3B 30 3B 35 3B 31 3B 31 36 3B 33 30 38 31 38 37 30 32 34 31 32 31 36 39 64 36 32 61 39 30 34 39 36 35 66 33 37 62 30 33 30 30 30 61 66 64 38 39 37 35 66 30 66 33 39 61 38 34 37 31 30 30 33 32 30 30 36 32 31 32 37 33 36 30 31 37 62 38 39 36 30 61 63 37 39 61 38 37 36 32 35 32 39 63 32 38 32 64 65 36 31 66 30 64 65 37 35 36 30 61 37 32 31 33 63 63 65 34 62 63 39 37 31 33 63 33 35 37 38 37 36 36 37 62 34 32 34 36 65 38 39 39 36 30 34 34 62 66 33 35 30 32 34 32 30 31 32 30 63 33 30 33 35 61 64 32 30 31 63 34 35 62 61 65 65 35 32 61 65 31 30 38 36 38 30 36 35 39 33 64 39 63 31 38 64 38 39 38 61 64 32 30 65 31 34 37 39 31 61 30 64 32 65 32 34 64 31 66 30 35 64 35 63 32 63 64 30 33 32 35 63 35 31

Explicit RX Indicator Checksum
A9

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;

uint8_t sendBytes[nOfSendBytes];

uint8_t start[]={0x7E};
uint8_t frameType[]={0x10};
uint8_t frameID[]= {0x00};
uint8_t numJump[]={0x00};
uint8_t options[]={0x00};

sendBytes[0] = start[0];
sendBytes[1] = (length & 0x0000ff00) >> 8;
sendBytes[2] = (length & 0x000000ff);

sendBytes[3] = frameType[0];
sendBytes[4] = frameID[0];

for(int i=0; i<8; i++)
    sendBytes[i+5] = routes_64[targetIndex][i];

sendBytes[13] = routes_16[targetIndex][0];
sendBytes[14] = routes_16[targetIndex][1];
sendBytes[15] = numJump[0];
sendBytes[16] = options[0];

for(int i=0; i

7E 01 10 91 00 13 A2 00 41 49 70 41 F7 21 E8 E8 00 11 C1 05 01 34 3B 32 7E 01 0C 10 00 00 13 A2 00 41 49 70 26 C1 12 00 00 34 3B 30 3B 35 3B 31 3B 31 36 3B 33 30 38 31 38 37 30 32 34 31 32 31 36 39 64 36 32 61 39 30 34 39 36 35 66 33 37 62 30 33 30 30 30 61 66 64 38 39 37 35 66 30 66 33 39 61 38 34 37 31 30 30 33 32 30 30 36 32 31 32 37 33 36 30 31 37 62 38 39 36 30 61 63 37 39 61 38 37 36 32 35 32 39 63 32 38 32 64 65 36 31 66 30 64 65 37 35 36 30 61 37 32 31 33 63 63 65 34 62 63 39 37 31 33 63 33 35 37 38 37 36 36 37 62 34 32 34 36 65 38 39 39 36 30 34 34 62 66 33 35 30 32 34 32 30 31 32 30 63 33 30 33 35 61 64 32 30 31 63 34 35 62 61 65 65 35 32 61 65 31 30 38 36 38 30 36 35 39 33 64 39 63 31 38 64 38 39 38 61 64 32 30 65 31 34 37 39 31 61 30 64 32 65 32 34 64 31 66 30 35 64 35 63 32 63 64 30 33 32 35 63 35 31 A9

Is a Valid frame with 255 bytes of data and an overall packet size of 272 bytes including ALL API bytes.

That’s correct, but it shouldn’t be in an API output packet, should it? Because I found it in an Explicit RX Indicator+Unsup ZDO API output.

Yes this is an output or an Explicit RX packet. It breaks down as follows:

7E
01 10
91
00 13 A2 00 41 49 70 41
F7 21
E8
E8
00 11
C1 05
01
Data payload:
34 3B 32 7E 01 0C 10 00 00 13 A2 00 41 49 70 26 C1 12 00 00 34 3B 30 3B 35 3B 31 3B 31 36 3B 33 30 38 31 38 37 30 32 34 31 32 31 36 39 64 36 32 61 39 30 34 39 36 35 66 33 37 62 30 33 30 30 30 61 66 64 38 39 37 35 66 30 66 33 39 61 38 34 37 31 30 30 33 32 30 30 36 32 31 32 37 33 36 30 31 37 62 38 39 36 30 61 63 37 39 61 38 37 36 32 35 32 39 63 32 38 32 64 65 36 31 66 30 64 65 37 35 36 30 61 37 32 31 33 63 63 65 34 62 63 39 37 31 33 63 33 35 37 38 37 36 36 37 62 34 32 34 36 65 38 39 39 36 30 34 34 62 66 33 35 30 32 34 32 30 31 32 30 63 33 30 33 35 61 64 32 30 31 63 34 35 62 61 65 65 35 32 61 65 31 30 38 36 38 30 36 35 39 33 64 39 63 31 38 64 38 39 38 61 64 32 30 65 31 34 37 39 31 61 30 64 32 65 32 34 64 31 66 30 35 64 35 63 32 63 64 30 33 32 35 63 35 31

A9

Now if you are referring to 7E 01 0C 10 00 00 13 A2 00 41 49 70 26 C1 12 00 00 34 3B 30 3B 35 3B 31 3B 31 36 3B 33 30 38 31 38 37 30 32 34 31 32 31 36 39 64 36 32 61 39 30 34 39 36 35 66 33 37 62 30 33 30 30 30 61 66 64 38 39 37 35 66 30 66 33 39 61 38 34 37 31 30 30 33 32 30 30 36 32 31 32 37 33 36 30 31 37 62 38 39 36 30 61 63 37 39 61 38 37 36 32 35 32 39 63 32 38 32 64 65 36 31 66 30 64 65 37 35 36 30 61 37 32 31 33 63 63 65 34 62 63 39 37 31 33 63 33 35 37 38 37 36 36 37 62 34 32 34 36 65 38 39 39 36 30 34 34 62 66 33 35 30 32 34 32 30 31 32 30 63 33 30 33 35 61 64 32 30 31 63 34 35 62 61 65 65 35 32 61 65 31 30 38 36 38 30 36 35 39 33 64 39 63 31 38 64 38 39 38 61 64 32 30 65 31 34 37 39 31 61 30 64 32 65 32 34 64 31 66 30 35 64 35 63 32 63 64 30 33 32 35 63 35 31 as being a valid frame, it is not. The length bytes and checksum are incorrect for it to be a valid frame.

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.