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.


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 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.



  1. Compile the SeparateBlueSoleil project — the code will be included in the main assembly eventually.
  2. 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" ?>
        <sectionGroup name="InTheHand.Net.Personal">
          <section name="BluetoothFactory"
              type="InTheHand.Net.Bluetooth.BluetoothFactorySection, InTheHand.Net.Personal"
              requirePermission="false" />
      <!-- -->
        <BluetoothFactory reportAllErrors="false" oneStackOnly="false">
            <add name="InTheHand.Net.Bluetooth.BlueSoleil.BluesoleilFactory, SeparateBlueSoleil" />
      <!-- -->
        <trace autoflush="true" indentsize="4">
            <add name="myListener"
               initializeData="trace.log" />
  3. Check that the support has loaded.
    1. Check whether BluetoothRadio.PrimaryRadio and/or BluetoothRadio.AllRadios are non-empty, and that one has SoftwareManufacter containing a BlueSoleil value.
    2. 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
  4. See below for what is and isn’t supported.