Made for iPhone hearing aids & CI’s: Android catches up with Bluetooth 4.0 Low Energy support

Part and parcel for direct iPhone communications to hearing aids & CI’s is support for the Bluetooth 4.0 Low Energy (“BLE”) protocol: Apple has had it in iOS for over a year; and now finally Google’s Android operating system has caught up with BLE support.

Although Bluetooth “classic” has been around for over a decade, it suffers from power consumption problems while streaming audio. Back in 2005 Starkey tried it with their “Eli” transceiver, but basically due to drain was only really effective on 675-powered hearing aids (and 3-cell CI’s from Med-El and Cochlear). Part of the specification for Bluetooth 4.0 is the Low Energy (BLE) protocol, engineered so that a device can operate for a year on a coin-cell battery. There will still be an issue of about 3.0 mA of battery drain when 2.45 gHz analog radio is used; however that will drop considerably once 14-16 nM fab lines get up to speed early next year, as all-digital Moore’s Law radios on ASIC SoC’s will cut the drain to the point where BLE-enabled hearing aids can be reliably powered by a #312 battery.

From the Bluetooth Low Energy page on the Android developer website:

Bluetooth Low Energy:

Android 4.3 (API Level 18) introduces built-in platform support for Bluetooth Low Energy in the central role and provides APIs that apps can use to discover devices, query for services, and read/write characteristics. In contrast to Classic Bluetooth, Bluetooth Low Energy (BLE) is designed to provide significantly lower power consumption. This allows Android apps to communicate with BLE devices that have low power requirements, such as proximity sensors, heart rate monitors, fitness devices, and so on.

Key Terms and Concepts:

Here is a summary of key BLE terms and concepts:

• Generic Attribute Profile (GATT): The GATT profile is a general specification for sending and receiving short pieces of data known as “attributes” over a BLE link. All current Low Energy application profiles are based on GATT.

The Bluetooth SIG defines many profiles for Low Energy devices. A profile is a specification for how a device works in a particular application. Note that a device can implement more than one profile. For example, a device could contain a heart rate monitor and a battery level detector.

• Attribute Protocol (ATT): GATT is built on top of the Attribute Protocol (ATT). This is also referred to as GATT/ATT. ATT is optimized to run on BLE devices. To this end, it uses as few bytes as possible. Each attribute is uniquely identified by a Universally Unique Identifier (UUID), which is a standardized 128-bit format for a string ID used to uniquely identify information. The attributes transported by ATT are formatted as characteristics and services.

• Characteristic: A characteristic contains a single value and 0-n descriptors that describe the characteristic’s value. A characteristic can be thought of as a type, analogous to a class.

• Descriptor: Descriptors are defined attributes that describe a characteristic value. For example, a descriptor might specify a human-readable description, an acceptable range for a characteristic’s value, or a unit of measure that is specific to a characteristic’s value.Service: A service is a collection of characteristics. For example, you could have a service called “Heart Rate Monitor” that includes characteristics such as “heart rate measurement.” You can find a list of existing GATT-based profiles and services on

Roles and Responsibilities:

Here are the roles and responsibilities that apply when an Android device interacts with a BLE device:
• Central vs. peripheral. This applies to the BLE connection itself. The device in the central role scans, looking for advertisement, and the device in the peripheral role makes the advertisement.
• GATT server vs. GATT client. This determines how two devices talk to each other once they’ve established the connection.

To understand the distinction, imagine that you have an Android phone and an activity tracker that is a BLE device. The phone supports the central role; the activity tracker supports the peripheral role (to establish a BLE connection you need one of each—two things that only support peripheral couldn’t talk to each other, nor could two things that only support central).

Once the phone and the activity tracker have established a connection, they start transferring GATT metadata to one another. Depending on the kind of data they transfer, one or the other might act as the server. For example, if the activity tracker wants to report sensor data to the phone, it might make sense for the activity tracker to act as the server. If the activity tracker wants to receive updates from the phone, then it might make sense for the phone to act as the server.

In the example used in this document, the Android app (running on an Android device) is the GATT client. The app gets data from the GATT server, which is a BLE heart rate monitor that supports the Heart Rate Profile. But you could alternatively design your Android app to play the GATT server role. See BluetoothGattServer for more information.


In this DevBytes Fred Chung gives a brief overview of the technology, and how Android supports it at the platform level:

▬▬► Importantly, another section of the Bluetooth 4.0 specification is for long distance transmission, up to 200 yards at 1.0 mW (0 dBm) and a half mile at 10 mW (10 dBm), in addition to the 30 feet at the 100 µW (-10 dBm) power level in Classic Bluetooth — More on this in an upcoming article as these high power extensions is key to sticking a fork in troublesome baseband induction “hearing” loops for venues~


Comment problems: Read before posting
It’s been brought to our attention from several of our readers that they were having their comments rejected by the Akismet plug-in for WordPress as spam. This is unacceptable to us; and we are soliciting suggestions for a replacement. Unfortunately, we have to use something to screen for spam, as we were receiving over 100 spam comments per day at its’ peak. In the interim, to save retyping, we recommend selecting & copying all of your text to the clipboard: If your comment is accidentally rejected, simply paste it into an e-mail message, put “Rejected Comment” in the subject line, and send it to us at Dan@Snip.Net and we’ll manually post it for you~

Print Friendly

← Viscosity vs Hardness of Ear Impression Materials The Free App-Based Acceptable Noise Level Hearing Test Everyone Can Use →

About the author

Dan Schwartz

Electrical Engineer, via Georgia Tech


  1. Dan Schwartz
    July 29, 2013 at 3:02 pm

    Grant Beattie wrote the following comment:

    I think they should have considered ANT.

    • Dan Schwartz
      July 29, 2013 at 3:21 pm

      Grant, the problem with ANT, Zigbee, and others is that they are not really IEEE standards, like IEEE 802.11 “WiFi” & 802.15.4 “Bluetooth” — This may be OK for a manufacturer-specific proprietary method, as hearing aid industry standardization is like herding cats. It took Apple to (helpfully!) herd the hearing aid industry all in one direction on a standardized platform for direct-to-hearing aid communication. The fact that now Android 4.3 supports BLE is A Good Thing.

  2. JOHN
    September 12, 2013 at 12:40 pm

    Can the author throw some light on the BLE product launched in indiegogo

  3. Alex
    March 23, 2014 at 11:57 pm

    I wonder, when the manufacturers of hearing aids will abandon NOAH protocol for programming hearing aids. It is clear, that you can program the hearing aids through Bluetooth

Leave A Reply


%d bloggers like this: