Bluetooth & BLE · Study deck

Bluetooth Profiles: Classic and GATT

This first route builds a profile, a shared rule for how Bluetooth devices use a service.

Radio Remi is your guide for this deck.

profiles

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain the role of Bluetooth profiles in enabling interoperability across devices from different manufacturers
Implement Serial Port Profile (SPP) for wireless UART communication in embedded systems
Configure Human Interface Device (HID) profile for keyboards, mice, and game controllers
Apply Advanced Audio Distribution Profile (A2DP) for high-quality audio streaming with appropriate codec selection

Major section

In 60 Seconds

Bluetooth SIG adopted profiles standardize behavior for specific uses; a custom GATT profile can define a device-specific contract but does not by itself guarantee interoperability.

Bluetooth Low Energy, or BLE, is the low-power Bluetooth family used by many sensors.
Firmware means the software stored on a device.
Choosing the right profile determines your entire implementation approach.

Major section

Key Concepts

A 328 kbps SBC stream is one possible setting, not an A2DP maximum.

Bluetooth Profile: A standardized specification defining how two or more Bluetooth devices implement a specific use case (e.g., hands-free calling, heart rate monitoring).
GATT-Based Profile: Modern BLE profile built on the Generic Attribute Profile; defines specific service and characteristic UUIDs, mandatory operations, and data formats.
Both peers must still implement compatible behavior.

Major section

Key Concepts (continued)

A2DP (Advanced Audio Distribution Profile): Classic Bluetooth profile for stereo audio streaming over ACL; SBC is mandatory, while codecs such as AAC and aptX are optional.

HFP (Hands-Free Profile): Classic Bluetooth profile for phone calls via headsets; uses a synchronous SCO or eSCO audio link for the call.
Battery Service (BAS): BLE service (UUID 0x180F) with Battery Level characteristic (0x2A19, 0–100%); clients can interpret it when both devices support the service (Bluetooth Core Specification).
Adopted vs Custom Profile: SIG-adopted profiles specify interoperable behavior and often use adopted 16-bit service UUIDs; custom services commonly use vendor-specific 128-bit UUIDs.

Major section

What Are Bluetooth Profiles?

Bluetooth profiles define how devices should behave for specific use cases.

Audio: A2DP, HFP, HSP, and AVRCP use Classic Bluetooth for continuous audio and call-control streams.
Input: HID can run over Classic Bluetooth or BLE, depending on latency and battery-life requirements.
Health: HRS, BLP, and GLS are BLE GATT profiles for structured sensor measurements.

Bluetooth profile ecosystem overview

Major section

Serial Port Profile (SPP)

The useful mental model is still a cable replacement, but the review should remember the layers.

RFCOMM emulates EIA-232 style control and binary data transport over the Bluetooth baseband through L2CAP, so a terminal sees a simple reliable stream while the controller still handles hopping, framing, retransmission, and link supervision.

Serial Port Profile (SPP) Architecture

Major section

Serial Port Profile (SPP) (continued)

Discovery required: Users normally pair manually; NFC or QR-assisted pairing can reduce setup friction.

That makes SPP a good fit for powered debug consoles and legacy UART bridges, but a weak fit for coin-cell sensors that only need occasional structured values.
Android Bluetooth examples use the same role split.
No BLE support: SPP will not work with BLE-only devices; use a BLE UART-style GATT service instead.

Major section

Human Interface Device (HID)

The hierarchy connects GATT discovery to actual operating-system events: a link can be connected yet unusable if its report map, permissions, or subscriptions are wrong.

The Report characteristic (0x2A4D) uses a Client Characteristic Configuration Descriptor (CCCD, UUID 0x2902) — a central writes 0x0001 to this descriptor to enable Input Report notifications from the peripheral.

Major section

Advanced Audio Distribution Profile (A2DP)

The source encodes the sound and sends it on the Bluetooth media path.

This makes the role names useful: the source owns the send side, while the sink owns the play side.
The bitrates and delays below are illustrative device configurations, not codec requirements or guaranteed end-to-end latency.

Major section

Hands-Free Profile (HFP)

Voice dial: HFP supports voice dialing; HSP does not.

Three-way calling: HFP supports it; HSP does not.
Audio codec: HFP supports CVSD and mSBC; HSP is limited to CVSD.
The processing blocks reveal why a connected call may still suffer echo, noise, or intelligibility failures.

Deck summary

Key takeaways

Bluetooth SIG adopted profiles standardize behavior for specific uses; a custom GATT profile can define a device-specific contract but does not by itself guarantee interoperability.

A 328 kbps SBC stream is one possible setting, not an A2DP maximum.
A2DP (Advanced Audio Distribution Profile): Classic Bluetooth profile for stereo audio streaming over ACL; SBC is mandatory, while codecs such as AAC and aptX are optional.
Bluetooth profiles define how devices should behave for specific use cases.
The useful mental model is still a cable replacement, but the review should remember the layers.

Retrieval practice

Recall check 1 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q1An ESP32 debug console must send a continuous UART-like text stream to an existing laptop terminal application that expects a Bluetooth virtual serial port. The hardware supports Classic Bluetooth. Which profile fits?

AA2DP, which carries stereo audio instead of a virtual serial stream.

BHID, which carries input-device reports rather than UART-like text.

CSPP, which emulates a serial port for the existing laptop terminal.

DCustom BLE GATT, requiring an app instead of its expected serial port.

Show answer

Answer: C SPP (Serial Port Profile) is perfect for debug consoles.

Retrieval practice

Recall check 2 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q2A BLE central device has just connected to a peripheral and wants to receive temperature readings automatically without polling. Which sequence of GATT operations correctly sets this up?

ARead the temperature characteristic repeatedly using ATT_READ_REQ at 1-second intervals

BDiscover the temperature characteristic, then write 0x0001 to its CCCD (UUID 0x2902) to enable Notify

CWrite 0x0001 directly to the temperature characteristic value to start streaming

DUse ATT_WRITE_CMD to set the characteristic's Notify property flag to true

Show answer

Answer: B The Client Characteristic Configuration Descriptor (CCCD, UUID 0x2902) controls whether a peripheral sends Notify (0x0001) or Indicate (0x0002) events.

Retrieval practice

Recall check 3 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q3A battery-constrained fitness wearable sends play/pause and skip controls to a phone that supports HID over GATT media keys; no custom phone app is planned. Which implementation fits?

AClassic HID, chosen despite a battery limit and BLE-capable phone.

BBLE HID over GATT, using the phone's supported media-key service.

CA2DP with AVRCP, chosen for audio streaming rather than input keys.

DCustom GATT media control, requiring an app the scenario lacks.

Show answer

Answer: B HID over GATT (service UUID 0x1812) can send standard media controls to a compatible phone without a custom app.

Retrieval practice

Recall check 4 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q4A user complains that audio is out of sync with video on Bluetooth headphones supporting SBC, AAC, and aptX. The source's codec support and end-to-end delays are unknown. Which test plan best diagnoses the problem?

AMeasure SBC bitrate alone, assuming audio quality proves lip-sync delay.

BCheck mutual codec support and measure delay per codec and video compensation.

CMeasure AAC alone, assuming it always has the shortest delay.

DTest LDAC without confirming support on both source and headphones.

Show answer

Answer: B If the source also supports aptX, include it alongside mutually supported SBC and AAC.

Retrieval practice

Recall check 5 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q5A car manufacturer is implementing a Bluetooth hands-free system. The system needs to support voice calls, voice-activated dialing, and display caller ID on the dashboard screen. Which profile should they implement?

AHSP alone, assuming basic headset calling covers dialing and caller ID.

BHFP for hands-free voice calls, voice dialing, and caller identification.

CA2DP with AVRCP for music, assumed to provide call-control features.

DSPP alone, treating a serial data channel as a hands-free call profile.

Show answer

Answer: B HFP supports bidirectional call audio and call controls such as dialing and caller information for a compatible phone and car system.

Print reference

Answers

Answer key.

C · SPP (Serial Port Profile) is perfect for debug consoles.
B · The Client Characteristic Configuration Descriptor (CCCD, UUID 0x2902) controls whether a peripheral sends Notify (0x0001) or Indicate (0x0002) events.
B · HID over GATT (service UUID 0x1812) can send standard media controls to a compatible phone without a custom app.
B · If the source also supports aptX, include it alongside mutually supported SBC and AAC.
B · HFP supports bidirectional call audio and call controls such as dialing and caller information for a compatible phone and car system.