Broadcom

Old Widcomm

Widcomm/Broadcom

See information and features in General below.

Note that starting to use Widcomm is not as easy as the other stacks, as unfortunately a native DLL (or two) is required as well as the normal managed library assembly -- that's because its API is C++ and thus can’t be P/Invoke’d directly. The native library(ies) must be copied to the device for support to work. See XXXX

General

There is good support for BluetoothClient.Connect, BluetoothRadio, BluetoothDeviceInfo (including RSSI), device discovery including ‘live’ discovery, and for BluetoothListener. BluetoothSecurity is supported for PairRequest and RemoveDevice alone. For BluetoothRadio property ClassOfDevice is not supported, nor on Win32 is the Mode property, etc.

BluetoothClient.Connect is supported for all RFCOMM/SPP connections. be aware of the SDP limitations (see below): i.e. one query at a time and multiple results returned. In particular, if the remote service has restarted more that ten times we won't read the last record(s) and the connect will fail it the service's current channel number is not the same as in the last record we read. BluetoothClient.Authenticate and Encrypt are not supported, nor is SetPin.

Data transfer (for BluetoothClient and BluetoothListener) seems fine.

For BluetoothListener note that that stack does not do clean-up if a program exits without clearing its SDP record. That misleads remote client applications that the service is still running. Also when the application next restarts the server can get the same port (SCN) assigned and thus adds the same record, but any incoming connections don't get passed through! Seen on WM at least.

There are a couple of issue with SDP querying. First the API returns ALL the matching records it has ever read from the peer, so expect to get muliple results if you query more than once! Secondly Widcomm provides access only to particular Attributes and not to the whole raw record. The current support is reading the Service Class and Name, and RFCOMM Channel Number attributes only. Finally only one request is supported at a time.

Security: The major issue on Widcomm, apart from the need for the native DLLs, is that there is no support for handling pairing etc, unlike most of the other platforms there is no way to get an event/callback when pairing is required to allow the program to supply a PIN/passphrase/confirmation etc. The only support is API function Bond and UnBond.

ObexWebRequest and ObexListener both work. Of course Widcomm has built in OPP and FTP servers so they will get the incoming requests and not any ObexListener. Either have your application use a different Service Class Id, have it use a specific Service Name, or disable the built-in OBEX servers.

To check if Widcomm/Broadcomm support is being loaded, check whether BluetoothRadio.PrimaryRadio or AllRadios returns a radio and whether it's SoftwareManufacturer is an enum value of Widcomm.

Broadcom detailed support table

(The Broadcom/Widcomm SDKs are at http://www.broadcom.com/support/bluetooth/sdk.php)

Depencies/Installation {anchor:dependencies}

DRAFT DRAFT

As noted above a native DLL is required alongside the managed library DLL (InTheHand.Net.Personal.dll). The native DLL is called 32feetWidcomm.dll.

Windows Mobile

On Windows Mobile just copy the version from the folder to suit your platform (WM5 or PPC2003).

Win32

On desktop Windows things are much less simple. Three native components are required:

32feetWidcomm.dll

Another Widcomm supplied DLL called btwapi.dll.

The Microsoft Visual C++ Runtime libraries.

So you need to copy some DLLs to the same folder as your program (and InTheHand.Net.Personal.dll):

Copy the 32feetWidcomm.dll version from the folder to match your program bit-ness (i.e. either from folder Win32-x86 or Win32-x64).

Copy the btwapi.dll from the child redist folder. (According to the Widcomm documentation: "Note: Only redistribute btwapi.dll if it is not already present on the target system. Overwriting an existing btwapi.dll will cause unpredictable results.")

Ensure you have the necessary Microsoft Visual C++ Runtime libraries. To test this, run the Test32FeetWidcommWin32.exe in the same folder as your DLLs, again using the version folder matching your program bit-ness. The current version of the library can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=26347 "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update".

Some example dependency failure are shown at Example Win32 load errors.

Win32 -- Multi-stack

All stacks on Windows (that I've seen) have the limitation that they only support one Bluetooth Controller/radio/dongle. As a workaround for this there's been the idea that one could install multiple stacks and thus get to use multiple controllers as they each support one radio.

This is possible with Widcomm and Microsoft stacks together. However this is not possible when compiling using the Widcomm version 6 SDK. If you want to use multi-stack, then one must use the 32feetWidcomm.dll from the SDK v5 folder i.e. Win32-x86 SDK5 or Win32-x64 SDK5 folder. Note however that this version might not work on new Widcomm installation. :-(