Since Bluetooth APIs were introduced into Windows (we are talking about the desktop OS here, not Windows CE / Windows Mobile / Windows Phone) there have been numerous updates and changes. Confusingly not all of these have been in Major updates or service packs but some changes are implemented in OEM only packages. We have been working on the 32feet.NET library to ensure we continue to support the new features in the Microsoft Bluetooth stack. There are a number of useful resources which describe the changes. Firstly Alan McFarlane, who has done a lot of really great work on the 32feet.NET library, has put together a detailed description of the changes in Windows 7 including a dive into the native header files. As you'll see one of the main area of changes is the support for Bluetooth 2.1 which introduces new authentication methods. You should read Alan's full article.

I also noticed that Microsoft have published a new FAQ on Bluetooth support in Windows. Interestingly this covers the entire history of Bluetooth on desktop Windows showing which releases implemented which Bluetooth versions. It goes into some depth on developing drivers for Bluetooth devices too - for example if you implement the Device ID profile you are able to integrate into the new Device Stage UI in Windows 7. The Download is a Microsoft Word 2007 document:-

http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Bth_FAQ.docx

John Penman has written an article in the March edition of Delphi Magazine entitled "Simple Wireless Networking with Delphi for .NET" which describes using the 32feet.NET library from Delphi code. It walks the user through each of the areas of functionality in the library: IrDA, Bluetooth and Object Exchange. Its written for the v1.6 version, but the object model in the latest v2.1 version is a superset so the code will work with the latest version.

Yesterday I released the latest update to the personal area networking library to the 32feet.NET site. This release focussed on bug fixes and improved compatibility and error handling. This release supports device discovery on the latest WM5.0 AKU3 devices and beyond where the registry layout has undergone a few undocumented changes. You can view the full list of closed work items for this release on the CodePlex workspace.

The code also now has unit testing (not yet covering all functionality) and a new sample application for using IrDA on desktop Windows versions.

By chance I was looking through the Windows CE 6.0 documentation and cam across a new Bluetooth method - BthReadRSSI. My interest was heightened when reading the Requirements section. Apparently the method is supported on Windows Mobile 5.0 as well as CE 6.0. Without further ado I added the P/Invoke definition to the 32feet source and did some quick tests on my iMate JasJar. The method was present, however it returned the error code 0x00000490 which according to the error lookup tool represents "Element not found". So thats where I leave it for now, but I'd be interested to hear from you if you have another device or a Bluetooth equipped CE 6.0 device. You can download the latest 32feet source from the CodePlex project which has this functionality - see the BluetoothDeviceInfo.Rssi property.

While there have been some improvements to Bluetooth support through the version - like the addition of A2DP (Wireless Stereo) and most recently PAN in AKU3, at the same time the Dial Up Networking profile has been removed. This is a very widely supported profile for connectivity sharing. If you previously used your Windows Mobile device to share your GPRS connection you'll no longer be able to do this with newer devices running AKU3 (or perhaps if any OEMs offer ROM updates to AKU3 for current devices). One scenario I've already encountered where this is a problem is using a TomTom ONE/Go unit - these use Bluetooth to use your phones connectivity to download traffic updates etc, and they support only the DUN profile.

Read a discussion about these changes here on Smartphone Thoughts.

The Bluetooth functionality (and related APIs) are fundamentally unchanged between XP and Vista, however additional profile support has been added for Audio devices. Based on testing with the RC2 build Vista now supports:-

• Handsfree
• Headset
• A2DP (Wireless Stereo)

When Vista detects a new audio device it doesn't automatically install support for the audio services, but it does recognise hands free devices based on their Class-of-Device:-

If you select the device properties, and view the Services tag you can see and select the supported audio profiles and when you apply the settings a new Audio device will be installed.

You can set these programmatically using 32feet.NET with the BluetoothDeviceInfo.SetServiceState method passing in either BluetoothService.Headset or Handsfree. The audio device appears in the Sounds control panel applet, but doesn't override the default system audio. You are unlikely to want to do this with a headset anyway, although it's more likely you'll want to do this with stereo headphones. You can however select this audio device to use with audio conferencing software such as Skype or Windows Messenger or with Vista's speech recognition.

Recently I tried a different form of Bluetooth hacking, I purchased a simple car kit and wanted to install it myself. Alongside the kit itself I also purchased the required vehicle specific cable to sit between the vehicle wiring and the radio and connect in the Parrot loom. However I soon realised that it was going to be more difficult than originally anticipated because there wasn't enough space behind the dash to accomodate all the bulky connectors, relaybox and oceans of cables. There were two issues, the adaptor cable passed through every single cable from the vehicle connector even though only a select few were actually used, the inline ISO connectors are rather chunky, the radio itself supports a phone input and mute trigger and so it seemed unnecessary to have the parrot amplify the audio and output it directly to the speakers.

So I set about looking at what was happening before the relay box and was able to determine the pinouts on the Parrot unit itself. The next stage was to simplify the adapter cable to remove unnecessary passthrough wires and remove the inline ISO connectors. I had to directly solder in Power, Earth and Mute wires from the Parrot and connect up the mono phone input to the "raw" output from the Parrot. The only additional wiring required was vehicle specific as there isn't an ignition switched power into the radio as it uses the CAN bus to change state. So I ran the ignition line for the Parrot into the connector with the vehicles cigar ligher socket (on some cars this is permanently powered on mine it's only on with the ignition). I was then able to mount the Parrot box behind the dashboard and route all the wiring behind the vehicle trim. Using this approach has the added benefit of supporting the external volume adjustment through the radio (and hence steering wheel controls). For reference the pin out for the Parrot CK3000 Evolution is as below (Other Parrot models use rather different plugs so I doubt it's transferrable).

Aud-    Earth   Aud+   Mute

White   Black   Red    Blue   Yellow

 X       X       X      X      X

 X       X       X

Red     Yellow  Blue

(used by control panel)

The unused yellow wire is perhaps used by the optional flashing cable. The separate power connector contains three colour coded wires (which are labelled so I wont spell them out here)

Although it took a lot longer than I originally anticipated I've finally put the finishing touches to v2.0 of the 32feet.NET library. v2.0 is a major re-write of the code so that the single codebase can be built into separate dlls for desktop or device. This was primarily to get around the bug in the desktop VB.NET compiler which couldn't cope with redirecting the device System.dll reference to the desktop equivalent. It has had the pleasant side-effect of making the footprint much smaller. The 4 previous dlls are now merged into the single InTheHand.Net.Personal.dll which range from 91kb for the .NETCF v1.0 version to 76kb for the desktop v2.0 version.

You can download the installer which includes the library, documentation and samples from the 32feet website. This release is the first release version to have the full source code available since the project was hosted at CodePlex. You can also use the CodePlex site to download other builds of the code and post bugs/feature requests. If you want to get involved in the project drop me a mail, or join the discussions on the 32feet site.

In an amazing about-face, Broadcom have released their Bluetooth SDK (Both the desktop and Windows CE versions) for free on their website, all you need to do is provide some basic information to register and you'll receive a download link via email. In many ways the Broadcom stack has always been ahead of the Microsoft version in terms of supported profiles, the real stopper has been the need to purchase the SDK to develop for it.

Thanks to forum member Robert83 for the heads-up!

It will be interesting to see how this affects the balance of stacks on new devices, now that both have an accessible programming model, however each stack is not without it's faults - lack of radio control for Broadcom and fewer profiles supported by Microsoft for example.

Among the fairly modest enhancements to the Microsoft Bluetooth stack in Windows Mobile 5.0 is a new unified system for assigning virtual COM ports. Previously this was only exposed to the user via OEM provided plugins. Very often you were limited to a single incoming and outgoing port. The Pairing process on Windows Mobile 5.0 now does a service discovery and allows the user to choose which services they wish to use, when "Serial Port" is ticked in the list you can then use the new interface on the "COM Ports" tab to create a virtual COM port for the device.

All of the settings are stored in the registry so that you can also programmatically query what ports are setup and to which devices they map. The magic happens at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Serial\Ports

This key contains a multi-string value containing all of the available COM ports on the system. This should have been setup by the OEM so that it does not contain reserved COM port identifiers. For example on my iMate K-Jam this value contains:-

COM6

COM7

Below this key there will be a key for each device setup with a virtual COM port, the key will be named with an 8 byte hexadecimal device id (16 characters). This contains values with settings for the port such as Encryption etc. The most useful is "Port", a string value containing the COM port name e.g. "COM6". Each device can have only one virtual COM port assigned, so if you run through the "New Outgoing Port" sequence for the same device it will overwrite your previous settings. The pairing information for the device is stored in a similarly named key under:-

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Device

You can query the values under the device key (again 16 chars for the device id) to retrieve the device name and class of device. When you retrieve paired devices with 32feet.net using BluetoothClient.DiscoverDevices it reads this information for you into a BluetoothDeviceInfo instance.

This new mechanism means that rather than using the awkward RegisterDevice method for registering a virtual COM port (InTheHand.IO.Ports.BluetoothSerialPort in 32feet.net) you can configure the settings through the registry in such a way that they are visible to device user and don't conflict with other ports.

The Bluetooth SIG have introduced a new branding initiative to help clarify what functionality a Bluetooth device supports using a number of simple icons for popular applications of Bluetooth. The current 5 icons are:-

• Print (Hard Copy Replacement Profile, Basic Print Profile)
• Input (Human Input Device Profile)
• Headset (Headset Profile, Handsfree Profile)
• Transfer (Object Push Profile, OBEX FTP)
• Music (Advanced Audio Distribution Profile, Audio Video Remote Control Profile)

Each has specific requirements which must be met for the product to display the icon. It should help to make it possible to identify what functionality a device provides. Windows Mobile 5.0 currently supports the requirements of the Input, Headset and Music icons. It doesn't qualify for Transfer since OBEX FTP is not supported, it is a Windows CE component which is not included in the Windows Mobile platform. And as we know Windows Mobile has no printing support out of the box, however if you have a Bluetooth printer which supports Object Push you can beam Contacts, Appointments and Text/HTML documents to your printer.

One of the features of the Broadcom stack is that when you attempt to connect to a virtual COM port it will show the user the Bluetooth Manager and ask them to select a paired device to connect to. You can suppress this and have it always connect to the last used device. You'll need to write to the registry key:-

HKLM/Software/Widcomm/BTConfig/AutoConnect/0008

Create a DWORD value named BTBrowserEnabled and set the value to 0. If you want to re-enable this feature you can reset the value to 1.

I've posted a Beta build of 32feet.NET to the Files section of the site. Please read the file description for a high-level list of changes. This release is the first to be built against .NET v2.0 and will resolve issues encountered with using the v1.x library from a .NET v2.0 VB project. It also consolidates the previously separate dlls into a single dll (InTheHand.Net.Personal.dll) which reduces the overall footprint to 83kb for Infrared, Bluetooth, Object Exchange and Forms functionality. If you are at MEDC and would like to see this version in action, Nick Landry will be using it as part of his session on Thursday at 11:15 "APP335 Tablet PCs and Smartphones: Working Hand-in-Hand to Enable Your Mobile Workforce".

A user posted an important observation on the Bluetooth COM support in Windows Mobile 5 here on the microsoft.public.pocketpc.developer newsgroup. The problem is that while the system allows you to create virtual COM ports for all your paired devices which support Serial Port Profile, most of the time this will fail because the COM port you pick is already in use, on many devices you can have just 2 virtual COM ports. I've posted a few of my thoughts in the thread linked above, but while there are things that Microsoft can work to improve there are also a few things that developers can do to avoid the problem:-

• Don't rely on the control panel for setting up ports, use the RegisterDevice route (or BluetoothSerialPort in 32Feet.net) to just register a port for the duration you need it (and possibly reuse the same port name). This also allows you to use a different port prefix since few COMx: ports are available out of the box.
• Don't use serial ports. Unless you need your device to be accessible by a legacy app then you can avoid using virtual COM ports altogether and work directly with Sockets (again 32Feet.net will allow you to setup these connections easily). The downside with this approach is it applies only to the Microsoft Bluetooth Stack, as the programming model for the main alternative from Broadcom is essentially based around ports. However based on the first batch of devices released with Windows Mobile 5.0 the Broadcom stack is a lot less common.

In the Windows Mobile 5.0 audio gateway implementation there are a couple of control codes to turn on audio routing through the bluetooth headset/handsfree device. I've only tried this with a couple of devices and had mixed (That's a really bad audio pun sorry!) results but here's a library to allow you to try it yourself. In theory it may work on some 2003 Second Edition devices too. I'd be interested to hear your feedback.

To set audio routing just call

InTheHand.Net.Handsfree.AudioGateway.RouteAudioToHandsfree = true;

And set to false to return to normal audio use.

Once fully tested and documented this will make it into the 32Feet package.

Some great news from Jason Langridge - not only will AKU 2 introduce the long awaited messaging feature pack, but also introduce the A2DP (Advanced Audio Distribution Profile) Bluetooth profile to support mono and stereo audio devices such as headphones and some advanced car kits. ETA is early 2006 depending on individual OEM schedules for ROM updates.

The agenda for DDD Day II has now been published and for some crazy reason folks voted for my Bluetooth with .NET session :-) I'll be covering both the Bluetooth and Object Exchange components of the 32feet.NET suite, I wont touch on the IrDA part, but the code would be almost exactly the same. We'll walk through discovery, client and server connections and sending/receiving objects, hopefully with some audience participation.

It's a great priviledge to be selected along with such a great selection of excellent speakers so I have a lot to live up to! I now have to attempt to make my demonstration application absolutely bullet proof since it inexplicably failed when I gave a short session at the MVP Summit. But it wasn't my code at fault honestly, it worked fine during lunch afterwards (I had severalwitnesses), obviously a result of the the sinister EM radiation around the Redmond campus... :-)

I was asked how to replace the default Toshiba stack installed on the M200 with the Windows stack (to allow for .NET programmability). Luckily it's easy to do and Toshiba include the necessary bits on the hard disk.

First you need to uninstall the Toshiba stack - Go to Add/Remove programs and select "Bluetooth Stack for Windows by Toshiba"

Next run the C:\TOSHIBA\MS_Bluetooth\BtMon2Inst.exe installer to install the BT monitor.

Finally reboot the machine, the system will detect the radio and install the necessary drivers.

From Jason Langridge: "It's using the Microsoft Bluetooth stack".

Excellent, another device added to the growing list.

The Bluetooth.NET library has now reached it's v1.5 milestone and is now part of the 32feet.NET suite. It joins an updated version of my IrDA library for the desktop which now adds some features (borrowed from the Bluetooth developments) so provides a superset of IrDA functionality on either full or compact frameworks. On top of both these libraries sits Object Exchange, this new library makes it easy to programmatically send and receive files and objects over the Object Exchange (OBEX) protocol. This is designed to provide a similar experience to functionality available for .NET for conducting HTTP requests - ObexWebRequest and ObexListener.

The concept of 32feet.NET is to look at personal area networking for the .NET developer whether your platform of choice is .NETCF on Windows CE or full framework on XP, Tablet PC, XP Embedded or Vista (32 Feet is the range of a standard Bluetooth device, that's 10 metres if you prefer metric). The website has been setup with discussion forums for the current libraries and associated technologies, you'll also find all the class library documentation, and of course the download itself which contains assemblies, source, help documentation and samples.

Greg Scott from the Windows CE Networking team has posted an interesting article on how Bluetooth Virtual COM ports are implemented on Windows CE.

Alongside the native code to setup a port, there are some details on the improvements in Windows Mobile 5.0 which now includes UI options to set both incoming and outgoing ports and is integrated into the bonding/pairing process. This means that OEMs no longer need to produce their own individual applets to expose this functionality.

For managed code the Bluetooth.NET library wraps this functionality with the BluetoothSerialPort class.

Today I gave a session at Slide5 on the latest version of the Bluetooth library - v1.4. Key changes for this release were some bug fixes to the samples, increased functionality for the desktop side (ability to bond devices) and service discovery (as yet XP only). I've also tidied up some of the code, in order to have just a single place to determine the platform at runtime. I'll post a version of the OBEX demo I did shortly, but I'll build it as a VS2003 project (the app used for the session demo was built with VS2005 Beta 2)

Downloads

One of our forum members posted about an open source social networking project which uses the Bluetooth.NET library. The project is created by Software Greenhouse which is a joint venture between Microsoft India and Cynapse.

Their initial prototype release and source code can be downloaded by registering at the Software Greenhouse site. The software will allow users of Windows Mobile devices to compare user profiles to look for shared interests and chat with other users. This is an interesting use of the technology and it will be interesting to see how the project evolves. Have you used the Bluetooth library in any projects? if so please leave a comment.