SparkFun Forums

[jdias]

Hi,

I am transmitting continuously at 9600 bps using the default configurations for both my XBees XB24-B.
The communication is one way only, the transmitter is connected to the ATMega328 UART and the receiver is connected to the PC via USB (FTDI).
Here is the actual data rate for a given program:

Wired connection (no XBee) : 7694 bps
from the ZNET 2.5 Router/End Device AT to ZNET 2.5 Coordinator AT: 6800 bps (some lost packets)
from the ZNET 2.5 Coordinator AT to ZNET 2.5 Router/End Device AT: 0356 bps (many lost packets)
from the Zigbee Router/End Device AT to Zigbee Coordinator AT : 0000 bps (doesn't work)
from the Zigbee Coordinator AT to Zigbee Router/End Device AT : 0328 bps (many lost packets)

For higher baud rates (115200) I get even worse packet drop rates:

Wired connection (no XBee) : 94200 bps
using XBee XB24-B ZNet 2.5 : 27900 bps

Why is that? Is there anything I can do to improve these rates?

[waltr]

At what distances?
With what antennas?

Are you using the RTS/CTS to prevent buffer overflow?
Are there re-transmissions?
Are there other 2.4GHz equipment near the receiver? There could be receiver de-sense and/or interference.

I run XBees with ZigBee firmware at 38.4kBaud from a PIC to the PC without any packet or data lose.

[jdias]

At what distances?

Very close, about 1 inch.

With what antennas?

Chip antenna http://www.seeedstudio.com/depot/xbee%C ... ml?cPath=2

Are you using the RTS/CTS to prevent buffer overflow?

In the receiver those pins are connected to the FT232R (UART USB chip).
But in the transmitter those pins are floating.
Since my MCU (ATMega328) doesn't have those pins, so I'll have to understand how they work and I'll have to implement them programatically, right?

Are there re-transmissions?

Rarely, transmitting sequential numbers at 1200 bps I saw only one repetition in minutes.

Are there other 2.4GHz equipment near the receiver? There could be receiver de-sense and/or interference.

There was many 2.4GHz devices within meters from the receiver. I turned them all off, and it didn't solve my problem. The actual transmission rate didn't improve at all.

[theridane]

One inch is too close, you might be saturating your receiver. Move them apart at least about a foot.

[waltr]

One inch is too close, you might be saturating your receiver. Move them apart at least about a foot.

I agree.
This could also cause the receiver/transmitter (coordinator/end device) to operate on different RF channels. Try with a greater separation and have the coordinator re-form the network and the end/router re-assoocate to the network to reset the RF channel and PAN .

But in the transmitter those pins are floating.

Ensure that the input to the XBee is not floating, either drive it, terminate it or disabled it in the parameters.

What are the Power Levels set to?

Quote:
Are there re-transmissions?

Rarely, transmitting sequential numbers at 1200 bps I saw only one repetition in minutes.

I'm asking about re-transmissions inside the XBee's protocol not what you'll see in the serial (DIN/DOUT).

Have you set the DH & DL parameters in the sending units to the SH & SL of the receiving unit or are you trying to use 'Broadcast"?

[jdias]

What are the Power Levels set to?

Every parameter is set to default.
In this case the default is PL = 4 (highest) for both devices.

I'm asking about re-transmissions inside the XBee's protocol not what you'll see in the serial (DIN/DOUT).

Is there any way to verify this?

Have you set the DH & DL parameters in the sending units to the SH & SL of the receiving unit or are you trying to use 'Broadcast"?

Every parameter is set to default,
so I am using broadcast. Does it deteriorate the transfer rate?

[stevech]

Without any mesh network software, e.g., wireless serial port extension, and with the proper RTS/CTS flow control, and with no RF interference due to a busy WiFi network on a channel that overlaps, you should expect 80,000 bits/sec net yield. Or more. I've achieved that.

On WiFi coexistence: WiFi is a 20MHz wide signal, with centers at WiFi channel 1, 6 and 11. The channel numbering for 802.15.4 is different - so look at frequency chart showing both.

Of course, also ensure that the received signal strength is good, like -85dBm or less negative; -75 is ideal.

If you are using broadcast, the MAC layer error correction is disabled. that's OK if you can tolerate errors (bit errors or dropped packets). Also OK if you have an application layer protocol to do error detection and correction. As a general rule, sending to the broadcast address (all ones) is never used for reliable datagram service.

[jdias]

One inch is too close, you might be saturating your receiver. Move them apart at least about a foot.

I agree.
This could also cause the receiver/transmitter (coordinator/end device) to operate on different RF channels. Try with a greater separation and have the coordinator re-form the network and the end/router re-assoocate to the network to reset the RF channel and PAN .

I didn't matter in my case. I set them many feet apart and the drop rates didn't change

[jdias]

Have you set the DH & DL parameters in the sending units to the SH & SL of the receiving unit or are you trying to use 'Broadcast"?

Every parameter is set to default,
so I am using broadcast. Does it deteriorate the transfer rate?

If you are using broadcast, the MAC layer error correction is disabled. that's OK if you can tolerate errors (bit errors or dropped packets). Also OK if you have an application layer protocol to do error detection and correction. As a general rule, sending to the broadcast address (all ones) is never used for reliable datagram service.

I set the destination address and the transfer rate didn't change in the End Device => Coordinator scenario.
But the reverse scenario improved achieved the same performance as in the former one. Thanks