Hi
First off, i really like the form factor and the ability to set the baudrate through a characteristic.

But why is 38400 Baud the max? My understanding is, that the longer the distance for the signal to travel, the higher the error rate gets.
Since the BLEBee fits in a XBee socket, the distance is close to minimal. Is this already a problem?

Are there any obstacels if i want to compile a customized BLEBee frimware by myself? I've read that TI's BLE SDK costs around 2k$, what about BlueGiga's?

Greetz
BBJay

Hi,
even 38400 is much too fast.
If the weather its good and and the antenna of a smartphone is aligned correct to the BLE module you might be able to get a throughput of 12kBit/s. So why is there a need for higher baud rates on the BLEBee.
I'm getting a little tired about the streaming discussion on BLE. If you need to transmit lot of serial data go with the original XBee or a BT Classic module.
BLEBee is a replacement for an XBee module where the transfer rate is not that important.

Bluegiga's SDK is for free. You need a CC-Debugger from TI to program the firmware and a Tag-Connect Adapter, since I decided to go with such a connector to minimise the footprint of the module to a minimum but makes it more difficult to ref lash it yourself.

Cheers,
Michael.

I agree, from a data throughput point of view, there is no need for higher baudrates.

My concern is more about connectivity than transfer rates.
There certainly are devices where a user/developer has no control over the baudrates of the serial port. So even if an application doesn't need high data transfer rates, it won't be able to talk to such a device, if it has a higher baudrate than the ones configurable by BLEBee.

At the moment, i'm developing an iOS App for configuring an Arduino based MultiWii flight controller.
The MultiWii sketch defaults to a 115200 baud serial port, since its main purpose is to be connected to a desktop GUI over an FTDI-USB adapter. While the sketch can be adapted and the GUI configured to use a different baudrate, I still would prefer to suggest a solution with no additional configuration complexity to future users of my app. (I've already evaluated the BLE Mini from ReadBearLab, but its baudrate is hardcoded in the firmware)

Thank you for the infos about the Bluegiga SDK.

Cheers
BBJay


ps: I'm sorry to annoy you with this topic, but a search on the forum didn't show up anything on it.

I am also interested in 115200 baud support. This has nothing to do with throughput, just compatibility.

Dr Kroll, is this something you plan to support?

Hi,
I can change the firmware to support all possible baud rates if you are interested. Moreover this would need the flow control pins to be fully supported on the BLEBee which might involve either some modifications/soldering on the BLEBee itself or another hardware revision.

Do you need all possible baud rates to be supported?

Cheers,
Michael.

I currently need only 115200. However, I would suggest you support all the standard rates supported by XBee (page 34 of datasheet):
1200
2400
4800
9600
19200
38400
57600
115200
From a product design perspective, the BLEbee becomes more 'intuitive': "it's got the same pins as XBee and it also supports the same baud rates"

Non-standard baud rates seem a lower priority, unless you've had demands?

I anticipated that RTS/CTS would also be needed. I am currently writing a reply to your other thread ("Question: Which additional pins should the BLEbee use?") with some thoughts.