Controlling the Bluetooth Radio

  Update 10/3/05
Is radio control really even needed!???
We recently did more testing with radio control and found some very surprising results - even when you use the Bluetooth Manager to turn the bluetooth "off", you can still use our BTAccess library just fine! You can connect to the stack. You can search for and find devices. You can connect and disconnect from those devices. You can set security options.

In other words, it looks like you don't NEED a way to turn the radio on if it's off - BTAccess will work anyway. Maybe the radio really is off, but our use of the internal functions makes it turn on (though it doesn't change the icon state on the Today screen); or maybe when you turn it off with Bluetooth Manager it doesn't really go off. In any case, I can use BTAccess and StackDemo just fine regardless of the radio state.
 		  
Posted 11/1/04
The Sad History of Radio Control
When the very first bluetooth-enabled iPAQs came out they used the Widcomm bluetooth stack v1.2.  These models offered an API interface for radio control - IsRadioOn, RadioOn, RadioOff, - as well as letting you receiving notification when the user turned the radio off, removed the old bluetooth sleeve, or powered-on the PDA.  These features were all made available through the use of the original user-interface and underlying security manager which was created by Philips Electronics on contract to Compaq/HP.  This was the state of affairs right up to the iPAQ 39xx models.  

With the introduction of the 5xxx iPAQ models HP executives chose to use a newer version of the Widcomm stack (v1.3) and also began using Widcomm's own user interface and underlying security manager.  Unfortunately the Widcomm software did not offer all these very useful functions and notifications.  BTAccess was therefore no longer able to support them.

Current Functionality
Currently we still offer methods called RadioOn and RadioOff in .Net (BTRadioOn and BTRadioOff in C++, as well as BTIsRadioOn).  But all these can really do any more is set a registry value that relates to how the radio is controlled when the unit is reboot.  Our "RadioOff" just sets this special registry value, so next time the user does a soft-reset, the radio will not come on.  Likewise with RadioOn, we can only set a registry value to be used upon soft-reset.  It's not good.  But it's better than nothing for some users

What about iPAQUtil.dll?
This is another mess, this time courtesy of HP.  At some point HP released a free utility dll called iPAQUtil.dll and an accompanying iPAQUtil.h header file.  It purported to offer functions for getting at hardware information, including bluetooth-related functions like RadioOn and RadioOff.  Unfortunately these original bluetooth functions never worked. Even worse, they were only offered for some models of iPAQ.  

As a public service to our customers we would like to summarize what they contain here. 

Note - the header files and help files are no longer free from HP.  To obtain them you need to sign up with HP's Developer program at www.ipaqdeveloper.com

iPAQUtil SDK Contents (as of 11/1/04):

h5400 SDK No iPAQUtil.dll.  
Contains only an iPAQUtil.h of 11,170 bytes from 11/11/02.   
Contains a helpfile showing how to access the library via LoadLibrary and GetProcAddress (no iPAQUtil.lib file ships in this package).
Anecdotal information that the Bluetooth functions do not work.
h1900 SDK Contains an iPAQUtil.dll of 7,168 bytes from 12/3/03.  
Contains an iPAQUtil.h file contains 2,448 bytes from 11/19/03. 
However it has NO sections relating to bluetooth!  
A dumpbin of the dll also shows no Bluetooth related functions.
h2200 SDK No iPAQUtil.dll. 
Contains only an iPAQUtil.h of 7,854 bytes from 9/30/03.  
Not tested.
General SDK Bluetooth functions only apply to h3100, h3700, h4700, and h6700 series of iPAQs No iPAQUtil.dll, but has numerous files including complete C++ sample code.
Contains an iPAQUtil.h of 21,147 bytes (lots of enums!) from 10/13/04. 
Also contains an iPAQUtil.lib so presumably you can link to it and not have to do LoadLibrary and GetProcAddress any more on the models this is for (sounds like they're finalizing standardizing on this library).
Not tested.

In all cases (except in the h1900 SDK) the following Bluetooth functions are present (and some others dealing with version info):

IPAQUTIL_API BOOL iPAQSetBlueToothRadio(DWORD *lpdwValue);
IPAQUTIL_API BOOL iPAQGetBlueToothRadioStatus(DWORD *lpdwValue);
IPAQUTIL_API BOOL iPAQGetBlueToothRadioPresent(DWORD *lpdwValue);

In the case of the General SDK there is also another interesting-sounding function, but we have not tried using it:

IPAQUTIL_API BOOL iPAQSetBlueToothReset();

What's BTAccess Going To Do About It?
We will make an attempt to test all the various iPAQUtil functions on the various models in the coming weeks.  One option is to offer the functions but return NOT_SUPPORTED in those cases where there is no dll, or the dll exists but bluetooth functions aren't there, or the functions are there but they are known to not work.  But our feeling is it will be only marginally useful to our customers to do all that because:
a) you can try this yourself with the above information
b) it will only apply to iPAQs since this is an HP-specific mechanism
c) even if it does turn the radio on/off physically, it's not clear that the Widcomm stack will operate correctly afterwards.

In our humble opinion what really needs to happen is for Widcomm, whose stack is in all these PDAs, to put back in all the proper radio control and events that developers demand.  When and if that will happen, now that they've been bought out by BroadCom and hardly ever answer their tech support lines, is anybody's guess! :)