XBEE Data loss at speeds higher than 9600 baud

Hi all,
I am a new Arduino user. I am using XBEE24, with XBEE shield, ARDUINO UNO board and XBEE EXPLORER. My aim is to send a file from one PC to other faithfully. I have configured both the XBEE radios to work at 115200 baud. One PC uses XBEE explorer with XBEE radio mounted on it. It simply reads ta file (using Processing software) stored on harddisk and transmit it to port for sending to XBEE. I have checked file readin to be ohk.
On the receiving end i have Arduino uno board configured with XBee radio to read the file and store it on computer using processing software.
My problem is when i do the data transfer at 9600 baud rate it works fine though it take more time. But when i try to increase the speed to 115200 baud, then the recieved file shows some data loss. Can any one help me in this regard. I am a new user of these devices.

XBees aren't the best choice for file transfer. They are meant to be low-bandwidth devices, and are aimed at applications that exchange relatively small data packets. They have small buffers that are easily overrun; see the product manual for your particular part. I suppose a person could develop code to packetize file content, send it a piece at a time, wait for acknowledgement, etc. The RF data rate for XBee 802.15.4 and XBee ZB modules is 250kbps. I wouldn't expect to be able to approach half of that as sustained throughput.

If you're using XBees, they're probably only good for about 10m range. XBee Pros will
do more like 100m LOS.

And as Jack mentioned, check the d/s for the size of the internal FIFO of your module,
and gauge the rate of data transmission accordingly. Xbees have a handshake signal
[probably CTS] you can use to throttle data flow.

The other thing is, you cannot connect both the XBee and USB port to the UNO Rx,Tx
pins simultaneously, as the signals will conflict. This is the usual suspect. UNO doesn't
really do XBee very well.

Range specs according to the product manuals. These are probably the limit given good conditions (hence "up to"), but they don't seem terribly unreasonable in my experience. OTOH, 10m is maybe a bit on the pessimistic side.

XBee 802.15.4 modules
Indoor/Urban Range up to 30m
Outdoor LOS Range up to 90m

XBee-PRO 802.15.4 modules
Indoor/Urban Range up to 90m
Outdoor LOS Range up to 1600m

XBee ZB modules
Indoor/Urban Range up to 40m
Outdoor LOS Range up to 120m

XBee-PRO ZB modules
Indoor/Urban Range up to 90m
Outdoor LOS Range up to 3200m

Yeah, my numbers were based on use of the 1/4 wave whip antennas, plus actual on
the ground experience. I treat the advertised range values as a bit on the optimistic
side. I keep seeing these numbers, and thinking - not in my backyard, it doesn't.

Here's an example literally from my backyard. Two XBee ZB low-power modules. One has the wire antenna (XB24-Z7WIT-004) and one has the chip antenna (XB24-Z7CIT-004) which is nowhere near as good (and is no longer made, having been replaced by the PCB antenna, XB24-Z7PIT-004).

They are about 30m or so apart. One is in a backyard shed and the other is in the family room. Pretty much line-of-sight except for two wood frame walls between them. Data is sent once per minute, and it doesn't always make it. When it does, the signal strength is very marginal. I would use different antenna options or maybe even a router as a repeater if it were anything that mattered. But I'm amazed that it works as well as it does, probably 90% or more of the data makes it through!

chart.png

Hey all,
Thanx a lot for ur replies...Just i am curious to know how can i use CTS signal in XBEE to synchronize the data transfer between the XBEEs?

Jack, you get better range than what I get. BTW, you didn't exactly describe what your
graph means. I assume -96 dBm is dropout threshold.

BTW, I've also found that 1-way transmission often works better than 2-way exchanges,
which has to be the proper yardstick.

Eg, try sending a packet to the shed, and having the shed echo it back. For some reason,
with the RFM22s, at 434-Mhz and 50mW xmit power, that I tried a week or so ago, the
remote could receive packets out to about 750' [250m], but the echo back to the host
only worked to about 1/2 that distance.

Surajpaul, the best thing to do is get the datasheet for your particular module, and see
what it says about using handshakes to control data flow into the module.

surajpaul:
Hey all,
Thanx a lot for ur replies...Just i am curious to know how can i use CTS signal in XBEE to synchronize the data transfer between the XBEEs?

Haven't done it myself, but basically the CTS signal would be monitored, and data sent to the XBee only when it's at a low logic level. Each data packet should be less than the size of the XBee's receive buffer. Some configuration (via X-CTU or AT commands) may be required to enable CTS flow control. The product manual is your friend:

Product Manual: XBee / XBee-PRO 802.15.4 RF Modules
http://ftp1.digi.com/support/documentation/90000982_K.pdf

Product Manual: XBee / XBee-PRO ZB RF Modules
http://ftp1.digi.com/support/documentation/90000976_M.pdf

Using CTS in this manner by itself is not sufficient to guarantee error-free data transfer. Some protocol would have to be added to ensure data integrity. API mode would have some advantages, but neither would it be sufficient in and of itself.

oric_dan:
Jack, you get better range than what I get. BTW, you didn't exactly describe what your
graph means. I assume -96 dBm is dropout threshold.

It's the XBee's RSS value. After a packet is received, the receiving node sends a DB command to its XBee to retrieve the RSS value for the last reception. The product manual says that the receiver sensitivity is -102dBm, but I'm not sure I've ever seen anything less than -96dBm. For sure I've never seen three digits. That is getting pretty darned thin.

BTW, I've also found that 1-way transmission often works better than 2-way exchanges,
which has to be the proper yardstick.

I'm not sure why that would be, other than the more transmissions, the more failures will occur. Regardless, the device in the shed has a clock and once an hour it synchronizes with the base station by sending a time request, to which the base station replies with its current time. I just checked it, and in the last 42 hours, it has received 42 syncs.

I also checked the one-way data integrity for the past 24 hours (transmissions once a minute) and 98.8% made it. Quite frankly, I'm amazed given the dismal RSS values.

I actually posted the 2-way transmission bit in a recent thread,

oric_dan:
I actually posted the 2-way transmission bit in a recent thread,

If nothing else, plain old probability works against us. Say that a link is known to be 90% reliable. The round-trip reliability will be only 81%.

I believe that XBees do a certain amount of retries "under the covers" so that is probably a factor as well. There may be a retry count in the API packet header. I've never tried looking at that, but it might be interesting. I'd bet the shed link is doing a few!