Windows CE Networking Team WebLog : Author: Greg Scott

More on Extending the Windows CE Bluetooth Hands Free Profile

cenet — Thu, 27 Oct 2005 23:10:00 GMT

In a previous blog article I discussed the basics of extending the Windows CE Bluetooth Hands Free Profile. This included how to plug into the Audio Gateway (AG) in order to send and receive AT commands from a Hands Free (HF) device. In this article I will discuss exactly what commands you might want to add support for and how you can shoot yourself in the foot using the AT command extension interface.

What you cannot do in your AT Command Extension

Some people have asked me questions like:
- Can I override the headset button press to do <X> instead of answering the call?
- Can I make a “double tap” of the headset button do <Y>?

These are interesting ideas but the answer is no. The AG does not receive a generic “button press event”. The HF device will usually have some context and could send a variety of commands based on a button press. For example, outside a call it might send AT+BVRA to do voice dialing. In a call it will send AT+CHUP to end the call. For an incoming call it will likely send ATA and in 3-way call scenarios it might send various other commands. You get the idea. It is probably not possible to accomplish this with the Hands Free Profile.

Bluetooth also defines a Headset Profile which is more basic than Hands Free. In this case, it might be possible to accomplish this. However, this profile is fading away and will likely be deprecated moving forward in favor of Hands Free. If you must there is an AG registry value called “NoHandsFree” to force the AG to use Headset Profile which is documented here.

Why do I want this capability?

So why would anyone ever need to write an AT command extension module? I can think of a few reasons:

1) To support voice dialing (AT+BVRA) which we do not support by default.
2) To support downloading of the phone book which is supported by many car kits and defined in one of the GSM specs.
3) To support extended commands like signal strength, battery notifications and operator name which are supported by many car kits.

None of these things are supported as of today on Windows CE or Windows Mobile.

Don’t shoot yourself in the foot!

Some AT commands can have dependencies on other commands. You can imagine how adding support for one command and letting the AG handle a dependent command could result in problems. Also, there are some commands the AG handles that you don’t want to override. For example, if your extension handled the AT+BRSF command, which reports the HF’s capabilities, the AG would never know what the capabilities are and could cause bad side effects.

The Hands Free AT command extension is a powerful interface. So be careful not to cause bad side effects when using it.

[Author: Greg Scott]

Bluetooth Notifications on Windows Mobile 5

cenet — Wed, 21 Sep 2005 23:28:00 GMT

For Windows Mobile 5.0 we added a new set of APIs for getting notifications from the Windows CE Bluetooth stack.

RequestBluetoothNotifications

StopBluetoothNotifications

There is more information on using these APIs here. Today you can capture notifications related to baseband connection / disconnection, pairing, security, state of the stack (on/off), and various other notifications.

Are there any other events you would like to see exposed through this API?

[Author: Greg Scott]

Bluetooth Virtual COM Ports

cenet — Thu, 18 Aug 2005 19:58:00 GMT

The Windows CE Bluetooth stack has the capability to expose a COM port interface to applications. This allows legacy applications that communicate over serial ports to use the Bluetooth Serial Port Profile. Common applications of this include GPS and printing.

On Windows Mobile 5.0, we now provide user interface to configure BT virtual COM ports. Devices based on WM2003 might have had UI supplied by the OEM to do this. A user can now pair with a GPS device or printer, create a BT COM port from the UI, and configure their applicaton to use that port. In this blog entry I'll talk about how to programmatically set up virtual COM ports.

To create a virtual COM port you need to use the RegisterDevice API. The following code will register the COM port at the specified index to Bluetooth.

PORTEMUPortParams pp;
memset(&pp, 0, sizeof(pp));
pp.device = ba;
pp.channel = channel & 0xff;

HANDLE h = RegisterDevice(L"COM", index, L"btd.dll", (DWORD)&pp);

There are two flavors of BT COM ports: client & server ports. A server port sets pp.flocal to TRUE and does not specify a BT address in pp.device. The purpose of server ports is to wait for incoming connections on the specified RFCOMM channel. The above code creates a client port. When an application calls CreateFile, the BT stack will connect to the remote device specified in pp.device. It will disconnect on CloseHandle.

A client port can specify pp.uuidService instead of pp.channel. This will tell the BT stack to find the RFCOMM channel on the remote device based on the SDP service UUID.

For more info on BT COM port emulation:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50concomportemulationfacility.asp

For more info on the PORTEMUPortParams structure:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50lrfportemuportparams.asp

For applications that are aware they are using Bluetooth, it is recommended that developers use winsock APIs. The purpose of BT virtual COM ports is to enable legacy applications to use Bluetooth.

For more info on using BT winsock APIs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50concreatingconnectionusingwinsockextensions.asp

[Author: Greg Scott]

Extending the Bluetooth Hands Free Profile

cenet — Fri, 12 Aug 2005 23:05:00 GMT

Windows CE supports the Bluetooth Hands Free Profile Audio Gateway (AG). This profile allows you to use a Bluetooth headset or car kit as a hands free (HF) device. This feature is supported on Windows CE 5.0 and Windows Mobile 5.0 (and WM2003 SE). You can find the Hands Free specification at www.bluetooth.org.

On top of routing audio to the HF, this profile allows many other functions like answering/ending/placing a call, redial, memory dial, voice dial, sending DTMF tones, etc. The Windows CE implementation supports all of the mandatory features along with some optional features. For a list of supported features (AT commands):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50conhands-freeprofile.asp

Does this mean that your phone can only take advantage of the features Microsoft has implemented? Of course not! The Hands Free Profile has an extensibility mechanism to allow OEMs to handle AT commands coming from the HF:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50conatcommandextensionmodule.asp

Some optional features of the Hands Free Profile require that the AG modify its “capability” bit mask in order to claim support for the feature (see HFP spec for details). You can override the AG capability to include the new optional feature by using the “capability” registry value:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50conaudiogatewayregistrysettings.asp

So you can handle new AT commands, but what about controlling the audio connection to the HF? The AG service (btagsvc.dll) is a module in services.exe. Applications can send IOControl messages to the service. The AG supports the following IOControl messages:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50conatcommandparser.asp

Using IOCTL_AG_OPEN_AUDIO and IOCTL_AG_CLOSE_AUDIO you can allow all system audio to use your BT HF instead of the default system speaker/mic. Keep in mind that BT audio is routed in hardware between the BT baseband module and cellular modem. Some phones (e.g. HTC Typhoon) will support routing the audio to the OS to enable system sounds and voice dialing over BT, while other phones will only support cellular audio.

Here is a code sample:

HANDLE h = CreateFile(L"BAG0:",0,0,NULL,OPEN_EXISTING,0,NULL);
if (INVALID_HANDLE_VALUE == h) {
// TODO: Handle failure case where AG is not present
}

BOOL fStatus = DeviceIoControl(h,IOCTL_AG_OPEN_AUDIO,NULL,0,NULL,0,NULL,NULL);
if (FALSE == fStatus) {
// Failed to open BT audio!
} else {
// Success!
}

CloseHandle(h);

[Author: Greg Scott]

About Greg...

cenet — Fri, 12 Aug 2005 20:43:00 GMT

Hi, my name is Greg Scott. I have been working as a developer on the Windows CE Networking team since June, 2002. I work on various wireless networking technologies but my primary focus is Bluetooth these days. In the past I've also worked on Wi-Fi, residential gateways, and UPnP.

If there is anything specific you would like me to post to this blog, let me know!