Bluetooth in C#, Which stack, Which SDK?

Question

We've got an application which needs to be able to use bluetooth for the following requirements:

1. Receive files from bluetooth devices (up to 2 devices at the same time)
2. Display all bluetooth devices in range
3. Send files to bluetooth devices
4. Scan for bluetooth devices and transfer files at the same time

We're running on Windows XP.

I've done some looking around and there seems to be 3 main stacks:

BlueSoleil

On the BlueSoleil website, in their SDK section, it seems to mention only 1 connection is supported, which is obviously no good.

Windows

Only seems to support 1 bluetooth dongle, which will probably mean we can't meet all our requirements.

Widcomm

Expensive and potentially overkill? More complex API? Thoughts?

In terms of SDK for C#, was looking at Franson Bluetools, anyone used this API?

Thanks

Answer 1

Try this: 32feet.NET. Starting from version 2.4, they support Widcomm stack in addition to Windows stack.

BTW: Why you need to work with two dongles at the same time? Usually single dongle can handle up to 7 devices connected simultaneously.

Answer 2

Firstly the disclaimer, I'm the maintainer of the 32feet.NET library. :-)

I've just checked, and on XP with the Microsoft stack (using one dongle) I can concurrently be receiving two OBEX PUTs and also discovering devices. That's using 32feet.NET's ObexListener class and the BluetoothClient.DiscoverDevices method. To send the OBEX PUTs one can use its ObexWebRequest class. To do multiple parallel connections with ObexListener I just had multiple threads calling its GetContext() method.

So that's maybe simpler than we thought...

I've also tested it with Andy Hume's OBEX Server using his Brecham.Obex library and the concurrent receive works fine there too. Its available from http://32feet.net/files/folders/objectexchange/entry6511.aspx.

On our Widcomm support. Hopefully it doesn't seem too "incomplete" on the client side... Inquiry (device discovery) and connections all work. The server-side still needs a little work however and there are some things the Widcomm API simply doesn't support eg. (programmatic authentication handling).

What was the issue with the samples? Compile-time or run-time? On MSFT stack or Widcomm? Follow-up at http://32feet.net/forums/37.aspx if you prefer.

Answer 3

Time to explain exactly what we ended up doing...

2 dongles why?

1. If a dongle is doing a scan the transfer rate is massively slowed down
2. A dongle can only support 7 concurrent transfers, if you are doing a scan, this drops to 6. If you want to send, receive and scan all at the same time, everything slows down, badly, and you are very limited in channels.

So, the idea is to run one dongle continuously scanning (so devices appear as quickly as possible) and the other dongle reserved for transfers, and since it's not scanning, transfers are nice and quick.

Library we used

After much testing and thought, we ended up opting for WirelessCommunicationLibrary from BT framework.

It supports Widcomm, Windows, BlueSoleil and the Toshiba stack. It supports all the server side stuff we need, is a well supported commercial product, which works perfectly without error.

Which stack?

Well, this is a complex one. NONE of the stacks support 2 dongles at the same time. So the only option is to run one dongle on one stack and the other dongle on another. This is where the WCL library comes in handy!

Microsoft - If an error occurs during a scan, it's common for the whole stack to crash out. This is not ideal! You have to close and restart radio device, it takes time and is fault prone. But... the Microsoft stack does handle file transfers very nicely.

Widcomm - Widcomm stack isn't great for file transfers. There is pesky little apps which install with Widcomm which keep trying to take control from your app. You can kill the bttray.exe, which helps, but you still get some strange behaviour from the stack during transfers. I'm sure this can be resolved, but since Windows is poor for scans, makes sense to use Widcomm for scans.

So... we've got one dongle set to Widcomm to scan over and over, and one dongle set to Microsoft set to handle only file transfers (in and out).

Getting 2 dongles to work

We went for using 2 of the same dongles, we can order them in bulk and stock them all the same reducing confusion. Each device shipped just needs 2 bluetooth dongles, simple.

The only problem is, these are widcomm dongles and we need one dongle on the Windows stack. Windows doesn't recognise these as Windows dongles, so won't register them for the Windows stack. So... the is a hack you can make to the bt.inf file to make it recognise the dongle for Windows. Then you need to switch the drivers for one of the dongles to run on the Windows drivers and you're all done.

Summary

So... we've got one dongle scanning all the time, one handling transfers, each on separate stacks and it all works nicely. This is the only way I have found to get 2 dongles working smoothly on Windows. If you've got a better suggestion, please post it!