Hi all,

I am writing a Win XP application in C# (using a MS stack BT-stick) to connect to a bluetooth remote device using SPP profile. Everything works fine, I can discover the device and connect with BluetoothClient.Connect(...) using a BluetoothEndPoint with SerialPort service. I can transfer data (files) to the remote device (proprietary protocol) with approx. 50 kbits per second. 

Now I would have expected a faster transmission speed using socket communication but I can not find out from this forum, the MSDN or other docus what determines the speed (or baudrate?) of the socket SPP connection or how to adjust it.

Who knows what determines/limites the bluetooth socket speed (PC Bluetooth-stick, MS stack driver, BT remote device)?

Is it possible to have more than 115200 baud with a Microsoft-stack SPP connection?

Does anybody have measured the transfer-rate of a SPP-based connection with a C# application?

Thanks, 
Tommes

 Hi,

I'm doing something similar. My remote modem is a Firefly bluetooth radio and it has a pin on it that sets the baud rate. High is 9600, low uses the intrernal setting which is 115200 by default. I have connected to this using a SerialPort class in C# and set the baud rate to lots of different things, but the baud is always the same (measured on a logic analyzer) so I believe the radio is setting it for you. Are you having trouble with latency while sending? I'm sending small packets of data (4-8 bytes at a time) and I get huge latency problems, like 10-40 ms per packet which is unacceptable for what I'm designing, any ideas?

Hi David,

 thanks for the reply, no idea why nobody else could give me some feedback !?

 Actually I am seeing a similar behaviour. My remote is an Amber-wireless BT radio which is configured to 230400 baud, so I expected a much higher transmission speed. Due to the limitation of our proprietary protocol the packet size is limited to 255 bytes, this in combination with a latency of approx. 20-40ms ('measured' with DebugView timestamps only) results in this low speed.

In a coming client revision we plan to increase the lenght field in the protocol to be able to cope with at least 1024 bytes per packet. Test transmissions with 1024byte packets showed me a baudrate of about 110 kbit/s.

Any other hint is higly welcome.

 i have exactly the same problem ...

 is there a difference between .write or .beginwrite???

 is an asynchron send better or faster for sending???

 Hi Veit,

What kind of radio/transceiver are you using?

I did some research and it turns out that Bluetooth just has an inherent latency built in, especially for small packets of data. We've figured we can solve our problem by making larger packets, however it's somewhat unrealistic for our project. We'll work on it some more and post what we find. 

 BTW we're using an RN-41 (Fire-Fly) Bluetooth to Serial adapter for our microcontroller.

 Also I dont think there's any speed advantage to using asynch sending. All it does is send in a seperate thread so that the send doesn't block your main application (if it's anything similar to TCP sockets).

 what´s curios is that the answer from the microcontroller is quite fast!

i post a screenshot from the logic-analyser tomorrow

 so here the screenshot ... i send a command to the microcontroller which is really slow!

 it´s only 4 bytes, but huge gaps.

the response is as fast as it should be - 9600bit/s with a rayson btm-222 module

while sending 4 bytes it´s not that problem, but most of the times i´m sending about 80 - 500 bytes and it takes about 2 secondes.

 UPDATE! :

i wrote a simple application for my friend where 1mb of binary data is sent to a device. in this form of transfer there are no gaps !!!!!!!!!

 i can´t wait to get home and check it out ... i will keep you informed 

 here are my results:

with
BlueStream.Writebyte(BT_Array(TX_index))

i get the latency you can see on the screenshot above. 

if i use:

BlueStream.Write(BT_Array, 0, TX_index)

the transmission is about 7 times faster. 

problem solved :)