As of revision 78385 the following support is checked-in to our code repository at codeplex and is enabled by default. You can download the code from there and built the “InTheHand.Net.Personal” project to get the main library, the support will also be present in the next release.
We now have support for the BlueSoleil Bluetooth stack on desktop Windows. There is good support for BluetoothRadio, BluetoothDeviceInfo including RSSI, and device discovery including ‘live’ discovery. There is no support for BluetoothListener (there seems to be no BlueSoleil API), and there is only partial support for SDP querying (returns both partial records and partial attributes). BluetoothSecurity.RemoveDevice is supported, but more work is needed for PairRequest.
BluetoothClient.Connect is supported for RFCOMM/SPP connections. However connections can’t be made to profiles that BlueSoleil supports directly, for instance an RFCOMM connection to OBEX Push isn’t possible. Nor is it it possible to make a connection to a specific RFCOMM port number. BluetoothClient.Authenticate, Encrypt are not supported (no API support), and we haven’t looked at support for SetPin.
BluetoothClient’s data transfer is somewhat lacking in comparison with the other stacks as it doesn’t use Sockets nor has it an data transfer API like Widcomm. Instead it creates a virtual COM port for each connection, and that’s what we have to use. It creates a number of problems, firstly when there’s no data in the buffer for Read we would expect Read to block but instead we get an IO error, so we have to workaround that. Then on Write there seems a lack of flow control, we now internally split any any big writes into smaller chunks and in testing that seems to stop data being lost.
Due to the various restrictions above ObexWebRequest and ObexListener are not supported currently. It should be possible at least to support ObexWebRequest by internally using the BlueSoleil OBEX API directly, something for the future, and volunteers welcomed.
To check if BlueSoleil support is being loaded, check whether BluetoothRadio.PrimaryRadio or AllRadios returns a radio and whether its SoftwareManufacturer is a enum value of IvtBlueSoleil.
Please let me have any feedback.
Available from http://32feet.codeplex.com/releases/view/39346
The code is stable, the libraries are Strong-Named, but the Help is not integrated into Visual Studio’s Help.
The main features and bug fixes in this release are as follows. For Bluetooth:
• FIX BluetoothRadio.LocalAddress is all zeros in v2.5 on WM+MSFT (bug 26123) — as broken at version 2.5
• Live discovery — prototype for Widcomm and WM+MSFT (bug 28491) — see the User Guide for more information
• Support setting BluetoothRadio.Name on Win32+MSFT (bug 26149)
• SDP support for 64-bit integers and parsing 128-bit integers (bug 26118, 26119, 28884)
For Bluetooth on Widcomm:
• Support BtRadio.set_Mode (can CE/WM only) (bug 26239)
• BtRadio.Mode reports wrong values when radio has been turned off (bug 26240) — this requires a recent versions of the Widcomm stack
• Fully Widcomm threading compatible including on CE/WM — this is for instance visible to the developer in that Connect can now be called from EndDiscoverDevices etc (bug 26186, 26194, 26195, 26868)
• Close connections on app crash etc (bug 28628)
• Use OnStackStatusChange to close connections when radio turned off (bug 28623)
There are no OBEX or IrDA changes in this release.
For Widcomm, various users have reported that there are problems on desktop Windows with newer versions of the Widcomm stack, with for instance BluetoothClient.Connect failing with a SocketException with it message including the code “PortLookup_NoneRfcomm”. We now supply two versions of 32feetWidcomm.dll for Win32 for this reason. Unfortunately when to use them is complex— I wish Widcomm had been a bit cleverer about how they provided their Vista support. 😦 (Note that Bluecove on Java also has to supply two versions of the DLL presumably for similar reasons ).
- Normal 32feetWidcomm.dll version: Works even when the Microsoft Bluetooth stack is also active, and so allows multi-stack support. But might not work on newer version installations of the Widcomm stack.
- “SDK6” version: May be required on newer version installations of the Widcomm stack, but will not work when the Microsoft Bluetooth stack is active.
We also now include copies of the 32feetWidcomm.dll for x64, let me know if it works for you, it is untested by us.
I have been working on providing support for the BlueSoleil stack on (desktop) Windows. This stack seems a common one to be included with dongles, and people have been asking for it. One good thing about it is that it supports RSSI measurements which the Microsoft stack on Windows does not. (I must write a post sometime of the Microsoft driver engineer’s reasons for not supporting RSSI).
I have checked the code into our code repository at 32feet.codeplex.com and would be pleased to get your feedback.
Download the code from there (whether as a ZIP or as a SVN checkout etc) and compile the main library (InTheHand.Net.Personal.FX2) (actually v3 would likely do) and the SeparateBlueSoleil project. Then follow the instructions below — which are from the “32feet BlueSoleil Test.html” file which is included in the repository.
Radio, DeviceInfo, and Discovery including ‘live discovery’ are working well. BluetoothClient is ok, but there is no support currently(?) for Listener. There’s still work to be done on checking what fails when the radio is disabled, and also on mapping of BlueSoleil’s errors into SocketException etc errors — currently a special BluesoleilException is thrown for any BlueSoleil API error.
Data transfer is less good however. Rather than providing access to the connection to the remote RFCOMM endpoint as a socket or through another API, the access instead is through a virtual COM port, which the stack creates automatically when an RFCOMM connection is made. This causes a number of problem, (no notification of disconnect, error on reading when the buffer is empty, data loss when writing too much), which I should write about elsewhere. I’ve done a lot of work to workaround those problems so things should be ok. Let me know what you find.
- Compile the SeparateBlueSoleil project — the code will be included in the main assembly eventually.
- Tell the library to load the code from there. To do this use a “app.confile” file containing the following, renamed to match your application e.g. to “myapp.exe.config”:
<?xml version="1.0" encoding="utf-8" ?>
<BluetoothFactory reportAllErrors="false" oneStackOnly="false">
<add name="InTheHand.Net.Bluetooth.BlueSoleil.BluesoleilFactory, SeparateBlueSoleil" />
<trace autoflush="true" indentsize="4">
- Check that the support has loaded.
- Check whether
BluetoothRadio.AllRadios are non-empty, and that one has
SoftwareManufacter containing a BlueSoleil value.
- Check what’s in the trace.log file. It should contain something like the following.
BlueSoleil Btsdk_Init: OK=0x0000
BlueSoleil IsBluetoothReady: True, IsBluetoothHardwareExisted: True
BlueSoleil Btsdk_StartBluetooth: OK=0x0000
BlueSoleil IsBluetoothReady: True, IsBluetoothHardwareExisted: True
Num factories: 1, Primary Factory: BluesoleilFactory
BlueSoleil Radio mode: BTSDK_GENERAL_DISCOVERABLE, BTSDK_CONNECTABLE, BTSDK_PAIRABLE
- See below for what is and isn’t supported.