Problem with transmission of large blocks of data

Hello,

I am using XBee-PRO DigiMesh 900MHz modules in my application, but I can't transmit large blocks of data reliably.

I can transmit small quantity of data at once without problem (~750 bytes), but when I try to transmit a lot of data at once (more than 15 or 20 packets of 100 bytes), I begin to lose a lot of packets. When I send the packets with a delay of 100ms between them, the transmission is ok. The problem is that with this delay the transmission rate became very low to me, less than 1KB/seg.

At first I thought it was some problem with the modules transmission or reception buffer, but I have investigated it and I think that the problem isn't there. I checked the serial flow control and it appears to be working, and the serial baud rate in the modules shouldn't limit the reception (I am using 115200bps and I have tested 230400bps, but the rate that I can transmit is much less than it).

I will investigate a little more to eliminate the possibility of the problem be something with the buffers, but I found one thing that may be wrong. As I need to send large blocks of data, I want to use unicast to avoid the multicast automatic retransmission (3 retransmissions). So, I am using the API mode with escaped characters to interface with the modules. What I found is that the transmission status, which modules sends after each packet sent, says that even when I send a unicast packet, it is retransmited 3 times. It happens for every packet, even if I send only one packet. Below is one example:

Packet sent:
0x7E 0x00 0x18 0x7D 0x31 0x01 0x00 0x7D 0x33 0xA2 0x00 0x40 0x53 0x88 0xB2 0xFF 0xFE 0x01 0x01 0x00 0x7D 0x31 0xC1 0x05 0x00 0x00 …

Transmission status received (just payload):
0x8B 0x01 0xFF 0xFE 0x03 0x00 0x00

Packet received in the other module (just payload):
0x91 0x00 0x13 0xA2 0x00 0x40 0x53 0x88 0xDF 0xFF 0xFE 0x01 0x01 0x00 0x11 0xC1 0x05 0x01 …

The "Options byte", in the transmission packet, is set to zero, so the transmission should be unicast. And in the received packet, the "Options byte" is 0x01, so it should be an unicast packet. I don´t think I am losing packets on RF transmission, and I get always 3 retransmission, even when I send just one packet. If I had some problem with the RF transmission  the retransmission should change, and I should lose packets, but I lose packets just when I try to send large blocks of data. Shouldn't the retransmission be zero or at least be 1 or 2 some times? It is always three, like happens in multicast transmission.

The Mesh Retries (MR) in the module is set to 1. If the module is retransmitting 3 times every packet that I send, could it cause the loses of packets that I am seeing? Someone have some tip?

Thank you.

Tiago Prado Lone

Quick note, the baud rate only pertains to the data rate between your hardware and the Xbee. The baud rate,“RF data rate”,between Xbees is 156.25 kbps.

I 've found the problem. The RF transmission is OK, the problem was with the UART’s reception buffer in PC. The terminal software that I was using, and the program that I developed weren’t reading the serial data at the needed speed and the serial buffer in PC was becoming full after some time. I changed the way that my program read the serial data and the problem was solved. Now I can achieve a transmission rate of ~4KB/sec without losing any packet. I saw in another forum that the 250kbps modules real throughput was 80kbps in function of the additional overhead associated with 802.15.4. As this module is a little slower, I think this rate is normal, isn’t it?

The data rate you are seeing could very well be accurate. The DigiMesh protocol has much more protocol overhead than the 802.15.4 module because of the routing, acknoledments, and if you were uisng broadcast or unicast etc. The addressing that you are using and the netowrk topology that you have configured could effect this, but at this point we cannot say for certain what your actualy throughput should be, so for the time being, the data rate you are seeing is probably OK.

Thank you for the answers…