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

This is a post I've been meaning to do for a couple of years and just never got around to it. The table below is an attempt to document the Bluetooth profiles supported on various flavours of Windows. Because Windows CE is modular don't expect every CE device to support all the possible profiles, this table gives an indication of what the platform creators had available to them. In order to conserve space I've made copious use of acronyms (and initialisations), the current release versions of all of these profiles are documented on the public Bluetooth website.

What I haven't attempted to do is compare the profiles available on 3rd Party stacks, that would be a little more complex

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 several witnesses), 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.

Windows XP supports a much smaller number of socket options for Bluetooth than Windows CE, although it generally provides alternative ways to get/set those properties. The table below shows those that are supported on XP and how they relate to their Windows CE equivalent. Notice that the only one which behaves the same on both platforms is SO_BTH_ENCRYPT

The current version of the Bluetooth.NET library doesn't include the XP versions in the BluetoothSocketOptionName enumeration, but I have added these for the next release.

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.

Today I've completed the v1.3 release of Bluetooth. This pulls together the latest binaries, source code, samples and help documentation into a single package. There are few differences in the public interface from previous releases, notably the BluetoothSerialPort class has been fixed and re-introduced, also the BondedDevices property for retrieving previously bonded devices from the registry.

I've also prepared a class-library diagram to accompany this release:-

OpenNETCF.Net.Bluetooth.1.3.50525.png (136.1 KB)

You can download the installation package from here.

With the Microsoft Bluetooth stack a single outbound virtual COM port is supported, to set this up you have to bond with the device. If you want to switch between several devices at different times this is awkward. You can however alter the registry settings between connections to switch devices.

1. Setup an Outbound COM port for the first device

2. Bond with the other device(s) you wish to use

3. Make a note of the bluetooth IDs of these bonded devices - see the subkeys of [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Device] for details

4. Before switching devices ensure you do not have the outbound virtual COM port opened (often COM 5 but check on your device).

5. Replace the value of "OBBDaddr" in the key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\SerialPort] with the bluetooth address of your required device.

6. Open the COM port - now connects to the device specified in the above registry key.

Now that the dust has settled on MEDC, I'm thinking about how to move forward with the Bluetooth library. I had essentially put development on hold when I first heard that Microsoft were preparing their own source package prior to MEDC. When it was released, I was a little disappointed in their functionality (and compatibility) so I've decided to press on improving the Bluetooth.NET library. It's going to take a few weeks to put together the next version, one key aim is to synchronise the source, samples, documentation and binaries with this next release, some of the previous releases have been binary only.

In the meantime here is a comparison of the functionality available today in the widely available Bluetooth libraries/SDKs:-

Obviously your feedback will help shape the library, so what are the key features you'd like to see added or improved?

To facilitate using the library in Visual Studio 2005 Betas I have made a few minor updates to the managed Bluetooth library, new/fixed in this release:-

• Now works under .NETCF 1.0, .NETCF 2.0, .NET 1.1 .NET 2.0 (Not tested under the .NET 1.0 desktop framework but should work).
• On Windows CE remote name lookups are performed "on-demand" rather than during device discovery to reduce discovery time.
• Reintroduced the BluetoothSocket helper class which provides a shortcut to create a Socket for working with Bluetooth independently of the existing BluetoothClient / BluetoothListener classes.
• Removed OpenNETCF.dll dependency, cures deployment problems on desktop machines.

Download the latest version here:-

Downloads

Mike Hall posted a link on his blog to a channel9 interview with Anil Dhawan from the Windows Mobile team discussing Bluetooth programming, which I recommend you check out. Anil gave a demo of a native code application to remote control PowerPoint on a desktop PC. This inspired me to put some finishing touches to a test application I built for the Bluetooth .NETCF library - It is by no means finished but it works (with the wind blowing in the right direction!).

There are two components, on the Smartphone an application which you first select Search from the menu and it will do a lookup of local discoverable devices, then select one and select the Connect menu option. Once connected any d-pad or number keys are captured and sent over bluetooth. As I said it was an unfinished project, key items missing are:-

• Store desktop address in the registry so we only have to search once
• More intuitive interface
• Support for key mapping - map the device keys to application specific commands e.g. for media player etc

On the desktop a simple listener which listens on a custom service, incoming data is received as keycodes which are broadcast on the system using the SendKeys.Send method.

On an unrelated note, thanks to Sergey Bogdanov who has contributed an implementation of the SendKeys class to be included in the upcoming SDF v1.3 release.

With the listener application running and the Smartphone client connected you can automate (within reason) whatever app has the focus. It works great for Powerpoint browsing between slides using the d-pad on the phone. The usual disclaimer applies - this works only with the Microsoft Bluetooth stack on both device and desktop, I tested with an Orange SPV C500.

The two projects are available to download here.

Not a huge amount of change since last months release but I just wanted to post the latest update. The download includes the same Chat application samples along with the complete solution for the library itself.

Downloads

The main changes in this release are:-

• BluetoothRadio class which handles the radio state on a single or multiple radio device. Multiple radios are only supported on XP, Windows CE supports a single radio device.
• BluetoothSecurity class which has a couple of methods to automate the pairing (bonding) process between devices. Using SetPin and RevokePin you can specify the PIN to use with a particular remote device. Using PairRequest you can force the device to intiate a connection and bond with the remote device with the specified PIN code. Currently the BluetoothSecurity class is built for Windows CE only, in a future update this functionality will be extended to run on the desktop too.
• General housekeeping - P/Invokes have been moved into a single NativeMethods class and a few new ones added, though not all are used by the library yet.

Online documentation for this build can be browsed here.

Since it's such a frequently asked question I've documented it here with some images which should hopefully clear up any confusion. The following screenshots show how to identify the Bluetooth stack on your Pocket Pc without writing any code or delving into the registry or system files.

Finally a quick reminder, the Bluetooth.NET library only works currently with the Microsoft stack, so if you have Widcomm/Broadcom or any other you'll have to look at third-party APIs.

I've posted an updated build of the Bluetooth library here. It adds full support for the desktop, improved class-of-device and other properties.

The sample app is now supplied in Pocket Pc, Smartphone and Desktop versions which all talk to each other.

I've uploaded a new release of the Bluetooth library which adds the key feature of hosting services over bluetooth. This now allows two-way communications between devices and to demonstrate how this works I've included a sample Bluetooth Chat application. This registers a custom bluetooth profile and listens for incoming connections, and creates outgoing connections using this service identifier to other devices. In this way it only communicates with other devices exposing this service and wont interfere with any other applications using Bluetooth.

Thanks go out to Wei-Meng Lee for giving permission to base the sample on his previous IrDA chat application available with this MSDN article. The Bluetooth version works in a very similar way, with the exception of doing a device discovery when it first loads. An enhancement yet to be added is the ability to periodically discover in a background thread. From the app screen select the target device which must also be running the software and Bluetooth must be Discoverable. Then type your message and click send and it will appear onscreen on the other device. In the below example I had a brief conversation with Santa who was half-way up a chimney at the time - such is the versatility of Bluetooth :)

The ZIP file below includes the Bluetooth library project and compiled output, and the BTChat sample project. As I get time to do more work on the library I'll post some other examples, and include versions for other platforms e.g. Smartphone and XP.

Known issues:-

• Hosting services doesn't yet work on XP (some of the structures are slightly different so this requires a little more work)
• BluetoothClient.RemoteDeviceName doesn't work so you can't retrieve the device name from an open connection (Device names work correctly during discovery on both Windows CE and XP)
• BluetoothSerialPort (For emulating a COM port) is not fully tested and probably doesn't work - SerialPortProfile connections work great using sockets (BluetoothClient).

Requirements:-

• SDF v1.2
• Windows CE Device or Windows XP computer using the Microsoft Bluetooth stack (Sorry but Widcomm is not supported).

Download:-

Downloads

If you have any comments or questions please drop me an email. For now all that remains is for me to wish you a Very Merry Christmas!

There were some recent enquries on the OpenNETCF Forums about the current Bluetooth code. It seems I had refreshed the website with some development code which would only work if a couple of items were commented out. This is because these classes (Sdp related) are still under development and require COM interop and are currently built against InTheHand.Interop.dll which does COM interop with no native DLL required, and is used in my PocketOutlook and ADOCE products.

So I've updated the code online and attached a .zip of the project below which will build successfully against the v1.2 SDF (and the compiled dll is included in the bin folder). Documentation is in the online library at http://32feet.net/library/

I'm working on a sample application to accompany the library, but it's been tested with a Bluetooth GPS unit and a Jabra headset successfully (Before you ask it only uses the control functionality of the headset, not the audio stream). But you can programmatically make the headset ring and capture the event when the user presses the answer button. Not terribly exciting but an interesting start, I guess I need some more unusual Bluetooth devices to test against.

What isn't working in this release is the ability to host a service and allow other devices to discover it, since this requires some of the ongoing Sdp work. Once this is in place you will be able to do data transfer between devices which is when the fun will really begin!

Also bear in mind this is designed to work only with devices with the Microsoft Bluetooth stack, for example HTC Phone Edition devices and most Smartphone 2003 models.

Downloads

We can already enable and disable Bluetooth on devices equipped with Microsoft's Bluetooth stack. In the case of iPaq devices, which use the Widcomm stack, it is possible to toggle the radio state using an API provided in HP's iPAQUtil.dll. This can be P/Invoked from a .NETCF project like so:-

[DllImport("iPAQUtil.dll", SetLastError=true)]

public static extern bool iPAQSetBlueToothRadio(ref int lpdwValue);

Which you can then call with:-

For devices which use the Microsoft Bluetooth stack in Pocket PC 2003 and Smartphone 2003 (e.g. O2 XDA2 and Orange SPV E200) you can toggle the Bluetooth state from code using the BthGetMode and BthSetMode functions. This allows you to set the Bluetooth radio Off, On and Discoverable. Full source project here:-

http://www.opennetcf.org/public/OpenNETCF.Net.Bluetooth.zip

Expect this to be incorporated into a future library release from OpenNETCF. Note that this wont work on devices using the WidComm stack (iPaq models etc).