I have bought a few 900 MHz S3B modules for evaluation. I’m using them in transparent UART mode using point-to-point addressing.
I’m trying to send a stream of 5-byte packets every 33 milliseconds.
Unfortunately, it seems that sometimes, these packets get joined and transmitted later.
Sniffing the 900 MHz band with a spectrum analyzer shows no other traffic nearby, so I don’t think this is because of detecting the channel as taken.
I also sometimes (a few times a second) want to send between 2 and 16 bytes the other way.
I thought that I would be able to send this status packet back in response to receiving an incoming 5-byte packet, and there would be enuogh time to turn around the channel, send data back, and then turn around the channel again for the next 33ms interval.
However, it seems that sending the data back, directly in response to an incoming packet, takes the air for about 50 milliseconds. Running at 20 kbps air rate, this seems surprisingly high.
I’m using a packetization timeout setting of 1 character, and a packet-size threshold of 5 bytes.
I’m measuring round-trip times using a logic analyzer on the USART TX/RX for both the transmitting and receiving modules.
Is there some configuration change I can make to get more real-time performance out of this system?
First off, just about all packetizing RF Modems will have some sort of delay. That is they are not going to have the latency of a cable. They are going to have some sort of latency.
Yes, you can send data in both directions with a Half duplex product such as this. Providing that your total overall through put does not exceed the radios streaming limits.
To minimize the latency, set the TO command to 0x40, the RO back to 3, set the DL and DH of each radio to the SL and SH of the other.
Thank you for your answer, but it adds exactly zero value to my question above.
I already know about packetization, and the latency added by an RF modem.
My question is about the specific performance characteristics of the Xbee.
If I were to take you at your word, then “Providing that your total overall through put does not exceed the radios streaming limits” means that I should easily be able to send 5 bytes per packet, 30 times a second, and then between 0 and 16 bytes per packet in response, a handful of times per second. 20 kilobit, with 62% overhead for framing and air turn-around time and whatnot, gives me 1 kilobyte per second in possible throughput. I’m sending a total of 250 bytes per second; 150 from one end and 100 from the other.
But that’s not what’s happening, as described above. It’s squishing separate packets together and delaying more than 50 milliseconds on top of the scheduled send rate.
Thus, the on-air limitations are controlled by something else, and I’d like to know what that something else is; what kind of control (if any) I have over that something else; and what level of low-latency performance I can actually expect in this kind of situation.
What is the full part number and firmware version of the XBee modules you are working with?
On and depending on what firmware version you are working with, the settings I listed have a great deal with how the radio functions and what the delays can look like.