The XBee is a Pro, 900Mhz, and it I found it isn't the baud rate that is most important like some have suggested. At first I attempted to use the Xbee like a RC TX/RX sending channel updates at 50HZ and the result was 'latency'. This was caused by the buffers of the XBees filling faster then they were emptied, so what I was seeing was data up to a half a second old.
What does work is to send the least amount of data needed at a rate the Xbee can both process the incoming stream and output the stream. My latest version only sends channel changes to the airborne XBee and the airborne xbee sends channel positions at 20hz. Even when moving the sticks rapidly, the channel changes move the servos good resolution and no latency. The channel positions and expected positions are compare in the GCS and differences result in the GCS resending a servo position. So far I haven't recorded a single instance where the resend was needed.
To keep the xbee workload down (and latency to a minimum) all data is transmitted in binary. The largest packet of data that is sent from the airborne xbee is only 26 bytes big. Since the xbee's PAN ID handle the interference I only have a short preamble (!!!), a one byte Unit ID (for multiple airborne units), and a one byte packet id. The airborne xbee sends 2 types of packets, fast changing data (channel+attitude ) at 20hz, and slow changing data (way point changes+battery voltage+GPS Fix type+GPS Satelites) . This simple protocol seems to work and pose minimal overhead to the Palm and Arduino's. The Palm development software is nice in that the serial stream reader is type specific so once a preamble is detected, reading the packet data into variable is as easy as:
ss.read aMode
ss.read aRoll
ss.read aPitch
ss.read aThrottle
ss.read aLatitude
ss.read aLongitude
ss.read aAltitude
ss.read aRollAttitude
ss.read aPitchAttitude
ss.read aGroundSpeed
ss.read aAirSpeed
ss.read aCourse
ss.read aClimbRate
ss.read aRSSI
ss.read aFuel
Comments