Prop to Prop with Xbee Questions

mhamen3

Hi guys,

I've got a few questions about xbee performance. I'm in the process of designing a prop powered quadruped robot that I want to control with a prop based controller through xbee modules. I plan on having something like eleven 10 bit outputs. At 9600buad does this mean that I will be able to send and read these outputs around 87, [9700/(11 x 10bit)]=87.27, times per second? From you experienced folk, is there a noticeable delay between, say, moving a stick and seeing a response?

Any feedback on this would be greatly appreciated.

Thanks,
Marc

Mike G

You can think of the xBee is like a drop in replacement for a serial connection up to 250kbs.

Mike Green

The xBee doesn't work like that. On one hand, you can communicate with an xBee much faster than 9600 Baud (like 115KBaud). On the other hand, the xBee buffers the information in an internal buffer and, when that buffer is full or when a configurable timeout occurs, the xBee sends the whole packet to the receiving xBee, checks it for errors, asks the transmitting xBee for a retransmission if there was an error, and eventually begins parcelling out the received packet to the receiving controller. Under good conditions, you may get throughputs over 115KBaud which would certainly satisfy your goals. If there's interference from other 2.4GHz devices or if the distance involved is near the limits of the devices or if there's 2.4GHz absorbent material between the two devices (like walls or rain or lots of moisture or a lot of metal), the xBees will have to repeatedly retransmit the data which will slow things down. You can reconfigure the timeouts, but you have to be careful because there's some overhead in transmitting and receiving a packet. If a packet is transmitted too soon, that will reduce the overall throughput.

Use a higher Baud and reduce the effective packet size. I believe you can force the xBee to transmit its current buffer contents. You might do that each update cycle.

JoeLucia

Mike Green wrote: »

The xBee doesn't work like that. On one hand, you can communicate with an xBee much faster than 9600 Baud (like 115KBaud). On the other hand, the xBee buffers the information in an internal buffer and, when that buffer is full or when a configurable timeout occurs, the xBee sends the whole packet to the receiving xBee, checks it for errors, asks the transmitting xBee for a retransmission if there was an error, and eventually begins parcelling out the received packet to the receiving controller. Under good conditions, you may get throughputs over 115KBaud which would certainly satisfy your goals. If there's interference from other 2.4GHz devices or if the distance involved is near the limits of the devices or if there's 2.4GHz absorbent material between the two devices (like walls or rain or lots of moisture or a lot of metal), the xBees will have to repeatedly retransmit the data which will slow things down. You can reconfigure the timeouts, but you have to be careful because there's some overhead in transmitting and receiving a packet. If a packet is transmitted too soon, that will reduce the overall throughput.

Use a higher Baud and reduce the effective packet size. I believe you can force the xBee to transmit its current buffer contents. You might do that each update cycle.

Set RO - Packetization Timeout to 0 to send data byte for byte as they enter the serial port.
Set DL - Destination Address to FFFF for Broadcast to eliminate the need for each packet to be ACK'd by the recipient(s).

The sender is not waiting for an ACK so it just keeps transmitting bytes as fast as the come in on the serial port. The recipients I presume are doing some sort of checksum on the received packet (since is IS still a packet) before delivering it to the serial port so I would expect dropped packets more then corrupted data due to range limits or interference.

I've streamed data and video at 57600 this way without any problems. Since I'm only pumping out at 57600, I expect ALL of my data to be transmitted without delay or latency since the radio communication is ALWAYS happening at 115200 +/- where the extra speed covers my packet overhead, I think.

mhamen3

I also wonder if there are any advantages or disadvantages with the chip antenna vs the wire antenna?

Mike Green

The chip antenna is smaller. The wire antenna puts out a better signal. That's always the tradeoff between a compact and a full-sized (for the wavelength) antenna.

SRLM

In my environment, I found that 57600 baud works best with the fewest corruptions or missed packets. Anything higher and the output just became unusable. I set up the xbees as a remote control system using two props on either end, and there wasn't any noticeable lag when controlling the robot.

johnfos

SRLM wrote: »

In my environment, I found that 57600 baud works best with the fewest corruptions or missed packets. Anything higher and the output just became unusable. I set up the xbees as a remote control system using two props on either end, and there wasn't any noticeable lag when controlling the robot.

The nearest a Series 1 XBee can get to 115,200 baud is actually 111,111 baud, which is a consequence of its system clock rate. If you're connecting an XBee to a PC, the PC will run at exactly 115,200 and that's not generally close enough for reliable communication. With an XBee connected to a prop, as you have at each end, setting the props to communicate at 111,111 should work fine. With the prop's 80MHz clock you should be able to get pretty close to 111,111. A similar argument applies to communication at 230,400 baud (where connection to a PC is out of the question even if the PC can do that speed).

Since your system works, I assume you won't feel the need to do this - I just thought it might be worth mentioning in general.

BTW, I can bang on for hours about this sort of issue... :-(

Duane Degn

I've found using the XBees clear to send (CTS) feature useful.

My concern was making sure all information was transmitted not necessarily how fast it was transmitted.

One of my modified versions of Tim Moore's pcFullDuplexSerial4FC uses an increased tx buffer. It can also detect acknowledgments from within the driver cog. I think It's pretty cool, maybe it would be useful to you.

The driver and demo is attached to post #12 of this thread. (This is the first time I've tried linking to an individual post so I also linked to the thread.)

The demo uses two XBees attached to one board. The serial numbers will need to be changed to the numbers corresponding your XBees. My XBees are series 2.5 so I'm not sure what other changes will need to be made.

I doubt the driver will help with the speed of communication (possibly a little if you're using acknowledgments). I do think it makes it easier not to have to wait while you tx buffer is emptied.

If you try the driver out and need some help, let me know.

Duane