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.
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"?
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.
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
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