Replies to This Discussion

JDronesPermalink Reply by Jani Hirvinen on May 22, 2011 at 6:46am

Answer is simple 57600 used to work a lot better on earlier xbees. Also it really depeneds on what type of protocol you using to writr your telemetry things.

More faster you go more you will get errors. If you dont have good error correction on protocol your gcs will work badly.

Also distance is one issue that affects on speed. Sure we can go even 20 megabytes over 20 kilometers but then quatiom is wha tis the price for the modems. There are njce tdma modems than do life hd feed slong other thing and for long distances but problem is that they cost aboit 800usd each.

9600 might be a bit too low for proper data feed. 57k then again lets us to put a lot of messages trough. 115k is good if we dont have interference.

• ▶ Reply

Permalink Reply by Martin Seven on May 22, 2011 at 7:20am

I've been testing 802.11a modules by UBNT (XR5). Live HD from the air is not nearly as impossible as people think.

• ▶ Reply

JDronesPermalink Reply by Jani Hirvinen on May 22, 2011 at 7:22am

Jmd45, yes we know those but they are a bit heavyish.

• ▶ Reply

Permalink Reply by Sebastian Gralla on May 23, 2011 at 8:15am

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)

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on May 22, 2011 at 7:30am

It came about from a lot of testing. We got too many lost packets on the standard 900Mhz Xbees at 115200, and the telemetry team said they didn't need any faster speed than 57600, which is more reliable. We used to run them even slower at 38k, but after a lot of field trialing felt comfortable enough to raise that.

• ▶ Reply

Permalink Reply by Darren on May 22, 2011 at 7:47am

HK was doing some testing with his 2.4 xbee's and his GCS and came to the conclusion 57.6 was max when doing xctu range tests.

http://diydrones.com/forum/topics/happy-killmore-gcs?commentId=7058...

• ▶ Reply

Permalink Reply by phillip.anthony.smith on May 23, 2011 at 1:08am

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.

 

Phillip

• ▶ Reply

Permalink Reply by MikeInFrance on May 23, 2011 at 8:21am

History has it's part to play also:
depending on the device you hook on serial, 9600 is about the entry point nowadays (think of serial GPS )
When speed and datavolume are kept slow and small, all devices can communicate without having to use complex error correction routines.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on May 23, 2011 at 9:21am

 

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.

• ▶ Reply

Permalink Reply by Paul Mather on May 26, 2011 at 8:17pm

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.

 

• ▶ Reply

Permalink Reply by Bob Anderson on May 26, 2011 at 8:42pm

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.

• ▶ Reply

Permalink Reply by Nigel on May 27, 2011 at 12:59am

Bob,

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?

Nigel

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page