Stonestreet One Bluetopia

Stonestreet One Bluetopia

I have now implemented support for the Bluetopia stack from Stonestreet One. Many thanks to Aton Spa (Italy) http://www.aton.eu for commissioning and funding this work,

I tested on a Mobile Compia M3Sky, and have had reports of successful usage on a Symbol MC70.

General

This is a summary see below for the details of each classes supported methods and properties.

There is good support for BluetoothRadio, BluetoothDeviceInfo (including RSSI), and device discovery including ‘live’ discovery. There is preliminary support for BluetoothListener, see below. BluetoothSecurity is also well supported both PairRequest and RemoveDevice, and also SetPin both there and on BluetoothClient. There is only good support for SDP querying.

BluetoothClient.Connect is supported for all RFCOMM/SPP connections. BluetoothClient.Authenticate and Encrypt are not supported (haven't looked), and as noted above we do support SetPin.

Data transfer (for BluetoothClient and BluetoothListener) seems fine.

The current BluetoothListener support is preliminary. It isn't clear from the API how to support multiple connections to the same port number, or even whether multiple concurrent connections to the same port number are supportable. In 3.4 and later the listener will successfully accept one connection. There is however good support for SDP records, including custom records.

ObexWebRequest and ObexListener both work — listener operation of course limited as above.

BluetoothSerialPort is not supported, mainly due to the 'one at a time' restriction, see below, which means that the virtual COM port could not be used when the current application is active. (BTExplorer will only run when your application is exited (or the stack usage exited via BluetoothFactory.HackShutdownAll)).

To check if Stonestreet One Bluetopia support is being loaded, check whether BluetoothRadio.PrimaryRadio or AllRadios returns a radio and whether it's SoftwareManufacturer is an enum value of StonestreetOne.

Unlike all the other stacks Bluetopia does not provide the Device Names for the discovered device as part of the Inquiry process (the other stacks raise an event when a device is found and another event once its name is found). So we would have to do that ourselves. However when we did so we found that that broke various things, firstly aborting the Inquiry process and secondly interfering with connections. Maybe that's just how Bluetooth works? Anyway we thus don't automatically look-up device names during inquiry, but will query for them when the application accesses the DeviceName property.

Please let me have any feedback.

Bluetopia one at a time, and coexistence with the MSFT stack

The first thing to note is that the Stonestreet One Bluetopia stack only allows one application at a time to use the stack; this includes the control-panel application provided by Stonestreet One called BTExplorer.exe. So if we can’t load the stack then check that no other Bluetooth application is active. At start-up we look for the BTExplorer.exe application and kill it if it is running. (Note one can tell whether any application is using Bluetooth from the Windows Mobile UI: if the Wireless Manager Bluetooth state is “On” and the Bluetooth icon at the bottom right of the Today screen does not have a yellow/black exclamation mark overlay).

It is also common on recent devices for the Microsoft stack to be installed alongside the Stonestreet One Bluetopia stack to allow the user a choice of which stack to use. The device I’m using currently has a control-panel called “BT Select” (Settings: System) which allows one to select “StoneStreetOne” or “Microsoft” and reboot. However it doesn't actually change what API is useable. The “BT Select” setting only selects which stack’s Control Panels are active. If no other application is using Bluetooth (and when Microsoft is selected if its mode is ‘Off’) then an application can choose which API to use by using it first. 32feet.NET tries to load the Stonestreet One Bluetopia stack first.

Multi-stack

It is not possible to use the Stonestreet One Bluetopia stack along with any other stack. As noted above is not even possible for two applications to use the stack together.

BluetoothRadio

The ‘one application at a time limitation’ also means that the radio is apparently powered-down when no application is using the stack (third-party or BTExplorer.exe). It also means that the radio Mode (connectable/discoverable), Name and ClassOfDevice are not persistent — at each stack open, they default respectively to non-connectable/non-discoverable (so can make client connections), a system specific value e.g. “mobile compia” and zero . 32feet.NET currently does not persist any of these values across sessions currently.

Radio settings (e.g. Mode and Name) are also lost when the devices goes into standby even when the stack connection stay open. We aim to look at this sometime in the future storing any settings made by the application and reapplying them on power resume.

Bluetopia SDK SSP version breaking change

When I added the support I found that there was apparently a breaking change in the Bluetopia SDK. When support for Bluetooth v2.1 Secure Simple Pairing (SSP) was added new fields were created in some of the structs (actual in unions in the structs) and this changed the alignment of existing fields. Yikes! I've added code to handle this situation, but I've only tested on the new SDK. However this only affects pairing, so simple connect, discovery, etc won't be affected.

Details

See my full test notes in the repository e.g. at https://32feet.svn.codeplex.com/svn/InTheHand.Net.Personal/Testing/32feet%20Bluetopia%20Test.html It contain information on what error codes are produced in various cases in BluetoothClient.Connect for instance.

Diagnostics

This stack allows one to get diagnostics access to the packets that are being sent and received from the Bluetooth controller (over the HCI connection). We support logging these packets to a file on the device and they can then be viewed in Wireshark for instance. If there is a file called "DoPacketDebug.txt" in the same folder as the application then the packets will be logged to a new file called "packets.pcap" in the root folder of the device. This file can then be loaded in Wireshark for analysis, see http://wiki.wireshark.org/Bluetooth. (The file is in libpcap format with protocol id {"LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR"}).

Things that could be improved

Store and Load Remembered/Authentication devices to Registry.

Find a way to stop Name Lookup interfering with Inquiry and Connect

Name Lookup faster by using Inquiry Result’s Clock-offset info in HCI call.

Check if HCI Name Lookup (with clock) doesn’t interrupt Inquiry.

Re-set radio Mode and Name after power-resume.

Block any API use too soon after power-resume.

See if we can store LinkKeys on the controller.

Have Auth handler send negative response when have no device info. (We currently only send negative when LinkKey is requested but we have only the PIN). — In Connecting case: Should just close/abort the connection, as LkNegRsp causes remote stack to prompt for a PIN.

Improve connect speed in two ways: by using Clock Offset, and stop the stack from closing the connection after SDP, just as we’re about to open the RFCOMM connection. Perhaps:

Manually open HCI connection, that also uses Clock-offset etc. Need also to close it and thus do reference counting...

Use manual SDP disconnect mode, so manually keep SDP session open until we've called RFCOMM/SPP connect. But maybe some devices can't handle a connect when SDP is still open.

When Connecting to service requiring authentication when have been given no LK nor PC, should a) fail quickly and b) have BtCli.Connect (??and BtLsnr.Accept) return a better error code.

Find if there's a way to have a listener remain active when its has already accepted a connection.