Too limited baud rate support

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Set the baud rate in the XBeeZB sample 1 code to anything above 115200.
2. Compile and run.

What is the expected output? What do you see instead?

Expect a successful connection to the XBee module. Instead, libxbee reports 
error -13, invalid parameter.

What version of the product are you using? On what operating system?

Master branch, 3.0.8, linux.

Please provide any additional information below.

The XBee supports both standard and non-standard bitrates up to about one mbps. 
USB serial interfaces usually support up to 921600 bps. It is an unnecessary 
limitation to reject bitrates above 115.2 kbps.

Adding lines to xsys_linux.c such as:

  case 921600: chosenbaud = B921600; break;

appears to work.

Original issue reported on code.google.com by ole.w...@gmail.com on 13 Apr 2013 at 10:36

[GoogleCodeExporter]

Impressive, the fastest I can manage is 460800 baud on an FTDI.

I've make the necessary change and pushed.

Original comment by attie@attie.co.uk on 13 Apr 2013 at 11:59

• Changed state: Fixed

[GoogleCodeExporter]

Wow, that was fast!

My setup actually involves an FTDI chip: I designed a PCB with an FTDI FT230XS, 
a voltage regulator, and the XBee module itself, so the serial line is no more 
than a few centimeters long. This seems to work flawlessly for 921600 bps and 
no additional stop bits.

Thinking about that, the additional stop bit that is practically required for 
115200 bps operation may not be necessary for higher clock rates. The reason 
it's added is that the 115200 bps matches the XBee's clock rather poorly. This 
may not be true for, say, 460800 bps.

Original comment by ole.w...@gmail.com on 13 Apr 2013 at 12:10

[GoogleCodeExporter]

Interesting... I'm using a SparkFun FTDI adapter for that module, but oh well 
:-)

I was considering only using the 2 stop bits for 115200 baud, but as it's just 
a little more 'breathing' room around the data it really won't hurt.
Also, the over-the-air data rate is already swamped by the UART rate, so there 
is little point in removing it.

Original comment by attie@attie.co.uk on 13 Apr 2013 at 12:18

[GoogleCodeExporter]

I agree; if the additional stop bit may be safely removed, it is certainly only 
a minor enhancement that should receive rather low priority.

Original comment by ole.w...@gmail.com on 13 Apr 2013 at 12:25