AT vs. API mode on XBee Pro Series 2

Wireless & IoT
1

When in transparent (AT) mode, do the XBee modules do anything to ensure that packets aren’t dropped? Or is that only possible if you use API mode and ensure that each packet you send is received correctly by looking for an acknowledgement?

I am using two XBee Pro Series 2 modules to transfer some data in AT mode. Sometimes the data comes through fine, but other times it is corrupted, or things that were sent on one end are not received on the other. Is this to be expected, what is the best approach to ensuring that there are no dropped packets? I presume it requires using API mode, but perhaps not?

The data I am trying to send is a set of measurements which total 24 bytes and are being measured every 10ms (100hZ). I don’t need to act on the data in realtime, but I do want to make the most effective use of the XBee and minimize packet drops. How frequently should I be sending packets data wirelessly? Should I try to transmit each set of 24 bytes as its own packet, or is it generally better to maximize the payload? For instance, I could send 3 measurements (72 bytes) at a time instead of only 1 measurement (24 bytes).

Thanks,

~Luke

2

There are parameter settings in the XBees to disable ACKs and retransmissions, check that they are not set.

Are there any other 2.4GHz devices (WiFi) running near by?

24bytes x 10 bits x 100per second = 24000 bits per second (baud). What is the serial baud rate set to? Are you using the CTS/RTS handshaking lines to prevent XBee serial buffer overflow?

I’ve used the series 2 XBees at 57.5kbaud in AT mode without lost data but my total data rate is lower. 24kbaud should be easily doable one way. How much data is going in the other direction?

There are also parameters for when data in packetized to the RF layer. Check them.

Getting 72 bytes packetized at a time may help as it will reduce the overhead on the RF link layer.

As for data errors, you could wrap your data in your own packet with error checking (checksum at minimum). Then the receiving end could determine if the data is corrupt.

API mode adds many more bytes of overhead on the serial interface (look at what is in an API frame). Since you are only going point to point you don’t need the additional information such as the source device address.

3

if the data is sent in bursts at 100 bursts per second, the setting for the transparent mode’s de-queuing time is key. This says “transmit what’s queued so far, since no bytes have come in on the serial port in the last x miliseconds”. When sending does begin, it will take time to transmit then receive an ACK.

IMO, 100 packets of data per second is too high of a packet rate. If you can can assure these collected in to larger groups, to keep the transmissions per second down, and have more radio link packets fill out the 100 byte (approx) capacity, this will work better.

4

There is a wireless 802.11b/g router about 20 feet from my desk that is running, other than that there aren’t any other wireless devices in the same room (but there are plenty in our building with decent enough signal strength for me to connect via my laptop.). One thing I remember reading about is the channel – maybe we should experiment with different channels to find the one with the least amount of noise?

I have both XBee’s configured to 115200 baud, so we should definitely be well within our transmission capabilities. I’ve also set the baud rate on the Arduino and on the PC to 115200.

We are primarily sending data one way – the Arduino has several sensor connected to it, which it samples every 10ms, then sends out via Serial.write() commands. Currently we have this structured such that we have a byte array of length 24, and we use the 8-bit timer2 to trigger an interrupt which indicates we should sample all our sensors. We then do:

Serial.write(out, 24);

where out is the byte array.

Perhaps I should instead use a byte array of length 72, and call:

Serial.write(out, 72);

every third sample? So instead of 24 bytes every 10ms, we would send 72 bytes every 30ms.

This seems like it would maximize the packet payload and give more time for the XBee to perform retries if needed. If I am reading the documentation correctly, 72 bytes is the max payload for the Series 2 devices, while Series 1 devices have a max payload of 100 bytes. Presumably the difference is taken up by the extra overhead that the Zigbee protocol imposes.

Also, would it be worth trying to force the buffer to be sent immediately after we perform our Serial.write()? From what I have read, you can enter command mode, then send the AT commands GT + CC + GT to cause the buffer to be packetized. But perhaps this wouldn’t happen any faster if we just set the packetization timeout to something smaller (default is 3 character times, so at 115200 buad, I think this is 3/(115200/8) = 0.000208 s ~= 0.21ms). Entering command mode takes lot of time because of the guard times that must be observed before and after ‘+++’ is sent, so this is probably a bad idea.

In the Series 1 devices, there is a setting which allows you to control how many ‘XBee retries’ are conducted, and it can be up to 6. I don’t see anything similar for the Series 2 devices, but there is a way?

Also, with transparent mode, is the XBee just taking care of building the API frame for you with some defaults? It seems like it must be because the packet payload size is the same as when you use API mode.

Thanks,

~Luke

5

I have both XBee’s configured to 115200 baud, so we should definitely be well within our transmission capabilities.

This is worth reading:

http://www.digi.com/support/forum/viewt … hread,7255

It could be part of your problem in addtion to what steve said.

6

re UART speed to XBee.

You should use 56K or less. Unrelated to wireless, 115K has little margin for baud rate error mismatch. Because the XBee buffers, the baud rate on the UART is unrelated to the wireless speed. It’s not like a dial-up modem which does not buffer.

The air link bit rate of 802.15.4 in 2.4GHz is 250Kbps. But the net yield, as in any half-duplex wireless system, is 20-40% less. And with competition for airtime due to WiFi falling on the same channel, the speed can be a bit less, but only if the WiFi is highly active. Very highly active, like streaming video. WiFi is 20MHz wide whereas '15.4 is 2MHz. You can see the channel numbers of '15.4 versus WiFi, and frequencies, in graphics on the web. Typically, WiFi rarely uses half the available airtime, allowing plenty of time to share the same spectrum with '15.4.

7

hazelnusse:
Also, with transparent mode, is the XBee just taking care of building the API frame for you with some defaults? It seems like it must be because the packet payload size is the same as when you use API mode.

Thanks,

~Luke

In transparent mode, Digi prepends 2 or so bytes to your data, and removes it on reception. Conversely, the Digi API mode's frame starting with 7E and so on is used ONLY on the UART link. The payload from that API frame on the UART is extracted and sent via a different frame format (per IEEE) on the '15.4 link.