A general question about baud rates...
I have noticed that there doesn't seem to be any fixed standard for the 'best' baud rate for communicating between any particular device and the APM board. Why don't we just stick to 115200? What is the point in communicating more slowly? For example, why has 57600 been selected as the speed for communicating with the XBee boards? I see that the new ArduStation 'Reborn' project is using 9600...why use an even slower speed? If we always use 115200 wouldn't that save a lot of confusion?
Don't get me wrong, there may well be very good reasons for the different baud rates...I'd just be interested to know what they are.
193g is really heavy for a quad. a normal quad (~40-5cm class) can carry about 200g without problems, so just your transmitter fills out the complete payload, it can carry more but it will get lazy and not fun to fly.
that is not a solution
(just as reference, Xbees doesn't even weight 10g)
Also, my ArduStation code is only at 9600 because I have 900MHZ XSC xbees. They only run at 9600kbps but have very long range. I have some standard xbees in the mail and will revise the ArduStation code once they arrive.
Standard GPS NMEA output is even lower : 4800 bps...
9600 bps is what you get with a GSM modem. Large enough to get a nice command line control.
It is my personal opinion that the data being sent back and forth from the APM to the GCS is well suited for 38400. It's a good mix of 15-20% usage of the bandwidth and the reliability of the slower speed. 9600 is way too slow. 115200 is unnecessarily fast for a single UAV's purposes and I believe the 2.4GHz X-Bee's have a bug in them that will not allow them to work at 115200. The reason to select a slower speed is the slower the data is sent, the less likely the data is to be corrupted.
According to RS232 specifications, the max length of a physical wire connecting two devices running 19200 is 50 ft. At 9600 this number jumps up to 500 ft. http://www.lammertbies.nl/comm/info/RS-232_specs.html The theory behind these distances were for noisy industrial environments, not over air. But the same applies. The faster you send the data, the more likely you are to have errors.
The only real benefit I can see is the potential ability of having multiple UAV's all talking on the same X-Bee channel. In which case, you're going to need the faster bandwidth.... but again, for the single UAV, 38,400 is plenty fast and very reliable.
I run 900mHz Xbee Pros at 200,000 baud (it is possible to use non-standard baud rates). No problems with packet loss. Of course, I'm not doing that with APM. I have another project using an Mbed and I wanted to reduce latency. One way to do that is to get data into the XBee at as high a rate as your serial software/hardware can run.
My understanding is that the over the air bit-rate is not connected to the UART bit-rate. Even if you talk to the Xbee at 1200 baud, it assembles a packet and transmits that packet at a high bit-rate to the remote XBee. In my application, I am giving data to the XBee at a higher bit-rate than the over the air bit-rate can handle. But of course transmissions are in packets followed by waiting, etc.
I was pleased to read your post "My understanding is that the over the air bit-rate is not connected to the UART bit-rate." My suspicion (not based on any knowledge!) is that the speed we communicate with XBees is merely a matter of convenience to us and that the method of transmitting the data over the air was completely unrelated to standard UARTs. Can anyone confirm this one way or the other?