Prop to Prop with Xbee Questions
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
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
Comments
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.
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... :-(
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