7 Bluetooth Profiles: Selection and Implementation

7.1 Start With the Situation

This section: Start With the Situation — The profile families are understood, but a product still needs one interoperable choice.

The profile families are understood, but a product still needs one interoperable choice. The team must compare use cases, test both ends, and record discovery and recovery behavior before release.

7.2 Overview

This section: Overview — This route turns profile knowledge into a tested selection and implementation record.

This route turns profile knowledge into a tested selection and implementation record.

This is part 2 of 2. Review Bluetooth Profiles: Classic and GATT when you need the first route.

7.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• compare Bluetooth profiles by use case
• select a compatible profile set
• test discovery, interoperability, and recovery

7.4 Technology Comparison

This section: Technology Comparison — Choosing the right profile starts by inspecting Figure 7.1 for the workload split: sustained streams belong on the Classic side, while small structured values and duty-cycled exchanges belong on the BLE GATT side.

Choosing the right profile starts by inspecting Figure 7.1 for the workload split: sustained streams belong on the Classic side, while small structured values and duty-cycled exchanges belong on the BLE GATT side.

+

Read Figure 7.1 from Classic audio, voice, serial replacement, and richer continuous HID traffic to BLE sensor readings, commands, battery levels, and alerts. Then apply the decision rule to the product’s actual data shape, latency, power, and peer ecosystem. Mesh remains a separate many-node control choice. The comparison guides selection; its example ranges and rates still require device and site measurement rather than being treated as acceptance guarantees.

• Classic Bluetooth: Around 100 m range, 1-3 Mbps data rate, medium power, about 100 ms typical latency, 7 active devices per piconet, pairing-based setup, best for audio and file-style streams.
• BLE: Around 50 m range, 125 kbps to 2 Mbps data rate, very low power, 7.5 ms minimum connection interval, many devices over time, advertising-based discovery, best for sensors.
• BLE Mesh: Multi-hop range, low data rate, mains-powered relays and low-power sleeping endpoints, variable latency, an address space with 32,767 unicast element addresses, provisioning-based setup, best for building-wide control. The element-address limit is not a guaranteed node capacity.

7.5 Case Study: Wireless Earbuds

This section: Case Study: Wireless Earbuds — Modern earbuds use Classic Bluetooth for A2DP audio streaming and BLE for low-power status updates (battery level, configuration).

Modern wireless earbuds demonstrate multi-profile integration:

Profiles Used:

1. A2DP - Stereo music streaming
2. AVRCP - Play/pause/skip control
3. HFP - Voice calls
4. BLE GATT - Battery level, custom settings

Dual-Mode Operation:

Modern earbuds use Classic Bluetooth for A2DP audio streaming and BLE for low-power status updates (battery level, configuration). The dual-mode radio switches between protocols automatically based on the active profile.

Power Optimization:

• A2DP codec selection affects battery life
• BLE for low-power status updates
• Sleep mode when not playing
• Active noise cancellation power budget

7.6 Start With the Story

This section: Start With the Story — Two Bluetooth devices can pair and still fail to understand each other.

Two Bluetooth devices can pair and still fail to understand each other. A profile is the shared agreement that says which services exist, what the data means, and how a standard client should behave.

Use this chapter from interoperability backward. Ask what another device must already know, which profile supplies that contract, where a custom service is justified, and how the implementation will prove it did not invent a private dialect by accident.

7.7 Deep Dive: Attribute Tables, Handles, and UUID Evidence

This section: Deep Dive: Attribute Tables, Handles, and UUID Evidence — BLE profile conformance is proved by the discovered attribute table, not by a screenshot of one value arriving.

BLE profile conformance is proved by the discovered attribute table, not by a screenshot of one value arriving. Inspect Figure 7.2 to establish the service-to-characteristic hierarchy before following individual handles. The table should expose access properties, notification descriptors, and the boundary between a standard profile and product-specific semantics.

+

Read Figure 7.2 from the BLE node into each service, then descend to the characteristic values and their access contracts. Standard services give generic clients shared meaning; configuration and firmware branches can use vendor UUIDs. That hierarchy is the map for the handle, CCCD, caching, and reconnect evidence below.

When a client connects, it performs service discovery by walking the server’s attributes by handle and reading the UUIDs that live at those handles. A standard Heart Rate profile server has an attribute sequence like this:

Because this measurement is Notify, the client cannot simply read it once and be done. It must write 0x0001 to the CCCD at handle 0x002B; after that, the server pushes each new reading from the value handle. A good profile test records the UUID discovered, the handle used for the CCCD write, whether the characteristic property is Notify or Indicate, and what happens after reconnect.

The client uses handles as local addresses and UUIDs as meaning. Handles are 16-bit addresses in this server’s attribute table; the same Heart Rate Measurement can sit at handle 0x002A on one device and 0x0015 on another. The UUID 0x2A37, by contrast, is the universal identifier for Heart Rate Measurement. Reusing 16-bit SIG UUIDs for standard data and 128-bit UUIDs for private vendor data keeps generic profile clients interoperable while still leaving space for product-specific features.

Bonded devices may cache handles to avoid rediscovery on every connection, but that cache is conditional evidence, not a portable contract. If firmware changes the attribute database or the server exposes the Service Changed characteristic, the client must invalidate stale handles and rediscover. This is why profile tests should include a reconnect after firmware update or database change: it proves the client relies on UUID meaning and cache invalidation, not on a lucky handle layout from one development board.

7.8 Summary

This section: Summary — The remaining sections put numbers behind two common decisions: whether a sensor stream should use SPP or BLE GATT, and how an A2DP codec choice affects battery life and latency.

This chapter covered Bluetooth profiles for different applications:

• SPP enables wireless UART for embedded systems and debugging
• HID provides standardized input device communication (keyboards, mice, controllers)
• A2DP streams high-quality stereo audio with various codecs
• AVRCP adds media playback control to audio streaming
• HFP enables hands-free voice calls for headsets and car systems
• Profile selection depends on data rate, power, latency, and device compatibility
• Modern devices often combine multiple profiles (A2DP + HFP + BLE GATT)

+Checkpoint: Deep-Dive Readiness

Before using the worked examples, confirm that the evidence loop is complete: profile family selected, standard UUIDs separated from custom UUIDs, CCCD behavior understood, and platform risks listed.

The remaining sections put numbers behind two common decisions: whether a sensor stream should use SPP or BLE GATT, and how an A2DP codec choice affects battery life and latency.

7.9 Worked Example: SPP Throughput vs BLE GATT for Sensor Data Streaming

This section: Worked Example: SPP Throughput vs BLE GATT for Sensor Data Streaming

7.10 Putting Numbers to It

This section: Putting Numbers to It

7.11 Decision Framework: Choosing A2DP Codec for Wireless Earbuds

This section: Decision Framework: Choosing A2DP Codec for Wireless Earbuds

Phone: "I support SBC, AAC, aptX, LDAC"
Earbuds: "I support SBC, AAC, aptX"
Possible result: Connection uses aptX (if both devices select it)

7.12 Putting Numbers to It

This section: Putting Numbers to It

7.13 Common Mistake: Using BLE HID Without Understanding Report Descriptor Complexity

This section: Common Mistake: Using BLE HID Without Understanding Report Descriptor Complexity

Usage Page (Generic Desktop)
Usage (Gamepad)
Collection (Application)
  Usage Page (Button)
  Usage Minimum (Button 1)
  Usage Maximum (Button 12)
  Logical Minimum (0)
  Logical Maximum (1)
  Report Count (12)
  Report Size (1)
  Input (Data, Variable, Absolute)  ← 12 bits for buttons

  Report Count (4)
  Report Size (1)
  Input (Constant)  ← 4 bits padding

  Usage Page (Generic Desktop)
  Usage (X)
  Usage (Y)
  Logical Minimum (-127)
  Logical Maximum (127)
  Report Size (8)
  Report Count (2)
  Input (Data, Variable, Absolute)  ← 2 bytes for joystick
End Collection

7.14 What’s Next

This section: What’s Next — You have now seen how Bluetooth profiles define interoperability across audio, input, data, and health use cases.

You have now seen how Bluetooth profiles define interoperability across audio, input, data, and health use cases. The following chapters build on this foundation by putting profiles into practice and extending your understanding to the full BLE stack.

• Bluetooth Hands-On Lab - Build a BLE sensor beacon from scratch using GATT services, notifications, and connection handling in Wokwi.
• BLE GATT Services and Characteristics - Implement standardized GATT services (HRS, BAS, ESS) and design custom service schemas.
• Bluetooth Security - Configure pairing modes, LE Secure Connections, and encryption to protect BLE profile data.
• Classic Bluetooth vs BLE - Compare protocol stacks, power models, and profile availability to justify technology selection.
• Bluetooth Protocol Stack - Analyze the full stack from PHY to ATT/GATT to understand how profiles are built on lower layers.