USERNAME PASSWORD LOST PASSWORD? REGISTER
"A Complete Mobile Application Development Environment"
Advertisement

Downloads
Documentation
Forums
Blog
Press
Bug Tracking
Creator IDs
Contact Us
Bluetooth PDF Print E-mail

The ACCESS Linux Platform Bluetooth components are based on open-source BlueZ stack and OpenOBEX stack. The BlueZ stack supports the latest Bluetooth specifications:

  • Bluetooth 2.0
  • Enhanced Data Rate (EDR)
  • Advanced Frequency Hopping (AFH) for Wi-Fi cohabitation
  • Extended Synchronous Connection-Oriented (eSCO)
  • Different device transport support (UART, USB, etc.)
NOTE: As of this writing, ACCESS Linux Platform's Bluetooth support is based on BlueZ release 3.7. BlueZ relies on DBus, an LGPL component, in order to comply with the GPL.

Bluetooth Architecture ^TOP^

Figure 5.1  Bluetooth Framework

The Bluetooth Panel is the user interface for the management of Bluetooth power, discoverability, device name, known devices (connected once, paired or not).

The Bluetooth daemon (hcid) is provided by BlueZ and performs Bluetooth device initialization (name, discoverability), security (pairing), and other initializations.

The Bluetooth Hardware Management daemon provides functionality not provided by the BlueZ daemon: it manages the Bluetooth radio (starting, stopping, and initializing) through BlueZ and radio-specific code, including HW Management and Wi-Fi separation.

The Bluetooth ACCESS Linux Platform daemon displays the authentication dialog as necessary, and keeps Bluetooth ACCESS Linux Platform settings updated.

Bluetooth services are provided as a Linux daemon or as a BlueZ service.

ACCESS Linux Platform Bluetooth Library ^TOP^

The Bluetooth library that is part of ACCESS Linux Platform provides APIs to application developers, including functions that allow developers to:

  • Check Bluetooth availability: alp_bluetooth_check(). If Bluetooth is off and not currently disabled under Flight Mode, application developers can use the Bluetooth library to create a dialog that gives the device user an option to start Bluetooth.
  • Get a list of remote devices whose information has been stored on the user's device. Device information includes class of device, friendly name, last connection date, and pairing details.
  • Get or remove device information for a specific device
  • Get the friendly name of a remote device
  • Create a dialog to discover and select one or more devices: alp_bluetooth_discovery_dialog_new()

Prepare a channels map for AFH support (Wi-Fi coexistence): alp_bluetooth_prepare_afh_channels() See the Doxygen-generated reference documentation included in the product for more information about these functions.

Bluetooth Features ^TOP^

ACCESS Linux Platform Bluetooth provides a number of features, including a settings (or preferences) panel for end users, a configurable discovery widget, and a number of Bluetooth profiles.

Bluetooth Settings Panel ^TOP^

The Bluetooth Settings panel allows users to manage a Bluetooth configuration on their device. Using the panel, a user can perform the following tasks:

  • Start and stop Bluetooth
  • Set device discoverability (On - discoverable, or Off - hidden)
  • Set the friendly name of the device
  • Pair with other devices
  • Manage a list of "known" devices (devices that have successfully connected via Bluetooth at least once)

This panel also displays a list of devices currently connected to the user's device.

User preferences for Bluetooth are stored as ACCESS Linux Platform Settings.

Bluetooth Discovery Widget ^TOP^

The Bluetooth Discovery widget is a dialog that can be configured programmatically. The widget is intended for use by application developers who want to ask a user to select one or more Bluetooth devices. Developers can configure the widget to suit their application's needs. See the ACCESS Linux Platform User Interface Widget Reference for more information.

Bluetooth Profiles ^TOP^

ACCESS Linux Platform Bluetooth support enables the use of different Bluetooth profiles. Some of the Bluetooth profiles are included in ACCESS Linux Platform. The ACCESS Linux Platform Bluetooth library API is provided to aid development and UI consistency for custom profiles.

Some of the profiles provided with ACCESS Linux Platform include:

Headset/Handsfree Profiles
The Headset profile describes how a Bluetooth-enabled headset should communicate with a computer or other Bluetooth enabled device such as a mobile phone. When connected and configured, the headset can act as the remote device's audio input and output interface, providing full duplex audio.
Advanced Audio Distribution Profile
The Advanced Audio Distribution Profile (A2DP) defines the protocols and procedures that realize distribution of audio content of high-quality in mono or stereo on ACL channels. A typical usage case is the streaming of music content from a stereo music player to headphones or speakers.
Serial Port Profile
This profile defines the requirements for Bluetooth devices necessary for setting up emulated serial cable connections using RFCOMM between two peer devices.
Personal Area Network Profile
The Personal Area Networking (PAN) Profile describes how two or more Bluetooth enabled devices can form an ad-hoc network and how the same mechanism can be used to access a remote network through a network access point.
Dial-Up Networking Profile
The Dial-up Networking Profile defines the protocols and procedures that shall be used by devices implementing the usage model called 'Internet Bridge' (see Bluetooth SIG MRD). The most common examples of such devices are modems and cellular phones.
Object Push Profile
The Object Push profile defines the requirements for the protocols and procedures that shall be used by the applications providing the Object Push usage model. This profile makes use of OBEX to transfer data. The most common devices using these usage models can be notebook PCs, PDAs, and mobile phones.
File Transfer Profile
The File Transfer profile defines the requirements for the protocols and procedures used by the applications providing the File Transfer usage model. This profile is based on the Generic Object Exchange profile (GOEP), which defines the interoperability requirements for the protocols needed by the applications. These usage models are most commonly found in devices such as PCs, laptops, and PDAs.
Human Interface Device Profile
The Human Interface Device profile defines the requirements for the protocols and procedures used by Bluetooth devices such as keyboards, pointing devices, gaming devices, and remote monitoring devices. This specification uses the Universal Serial Bus (USB) definition of Human Interface Device (HID) in order to leverage the existing class drivers for USB HID devices.
SIM Access Profile
The SIM Access profile defines the requirements for the protocols and procedures used to access a GSM SIM card, a UICC card, or a R-UIM card using a Bluetooth link. An example of this profile's use: a user can personalize a car-embedded phone with a subscription module in an external device, which is connected using a Bluetooth wireless link. The external device can either be a simple SIM card holder or a portable phone, which is brought into the car. For ACCESS Linux Platform, the SIM Access profile serves as an interface between the Bluetooth chip and a phone module.
 

Add as favourites (63) | Quote this article on your site | Views: 979

Comments (3)
RSS comments
1. Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 28-03-2008 12:06 - Guest
 
 
Hardware dependancy.
Are Bluetooth profiles hardware dependent, say if I had two could different Bluetooth adaptors both Bluetooth 2.0 +edr. Is there any chance one of them might support a2dp and the other might not support it? (Maybe this can happen with other profiles?)
  
2. Written by jefro on 11-04-2008 10:08 - Registered
 
 
Bluetooth information
As I understand it, Bluetooth profiles are implemented for all potential “users” and “actions”, thus we have profiles for file transfer, headsets, audio distribution, etc. (The profiles we provide are described in these docs.)  
 
The profiles define the path from the Bluetooth daemon to the device’s hardware. In that sense, profiles would not have knowledge of the underlying radio capabilities---that would be the responsibility of the daemon. We require licensees to write their own Bluetooth hardware daemons in order to force them to handle all of the dependencies for whatever hardware they choose. Thus, I think the proper answer to this question is that the profiles we provide are built according to Bluez specs, and that the profile we provide does support a2dp. It is the daemon’s responsibility to cope if the hardware doesn’t support a2dp, perhaps by falling back to a lower audio quality transport method.  
 
It occurs to me that you may be asking the question because you are working on software that depends on a2dp (audio distribution) and want to know what will happen if that feature does not exist on a given device. I think the logical thing to do in that case is to test  
 
It is noteworthy that the underlying hardware is only one point at which a feature must be supported. In the case of a2dp, the headset must also be fully compliant with Bluetooth 2.0+edr. One other potential wrinkle is SCMS-T digital rights management, which precludes using a2dp (according to Wikipedia). 
 
I hope this answers your question! If not, please let me know and I will research further.
  
3. Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 10-05-2008 10:49 - Guest
 
 
Bluetooth information
Hello! 
I have a Bluetooth module but this modul has not GOEP/OPP profile. 
My question is: 
How can I charge a new profile to my module? 
Thank You the answers! 
Sanyi from Hungary :?
  

Only registered users can write comments.
Please login or register.

Powered by AkoComment Tweaked Special Edition v.1.4.6
AkoComment © Copyright 2004 by Arthur Konze - www.mamboportal.com
All right reserved
 


© 2008 ACCESS Developer Network    |    Joomla! is Free Software released under the GNU/GPL License.    |    ACCESS Global Website
Events Support Community Platforms Home