6 Bluetooth Profiles: Classic and GATT

6.5.1 Architecture

To see what “wireless serial cable” really adds, follow Figure 6.2 across the full endpoint path. The diagram matters because the familiar UART interface can hide radio setup, RFCOMM state, and host-side port creation that have no equivalent in a passive copper cable.

Read Figure 6.2 from the MCU’s UART into RFCOMM, through the Bluetooth link, and out to the host’s virtual serial port. Application bytes retain stream semantics, while pairing, framing, retransmission, supervision, and reconnect behavior sit underneath. That ordered path explains both SPP’s value for legacy equipment and the need to test disconnection, buffering, and timeout behavior before approving it.

Use Cases:

• Serial debugging
• Sensor data transmission
• Wireless UART for embedded systems
• Legacy device communication

6.5.2 Implementation

SPP uses RFCOMM (Radio Frequency Communication) to create virtual serial ports:

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. 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. A receiver service listens with a BluetoothServerSocket, accepts a connection, then reads framed messages from the resulting BluetoothSocket; a remote app scans or selects the peer, opens its own BluetoothSocket, and writes the command bytes. For an IoT remote-control demo, keep the proof at the application boundary: which button produced which message, how the receiver parsed it, which GPIO or actuator action followed, and what timeout or disconnect rule leaves the device in a known state.

# Python example using PyBluez
import bluetooth

# Server (peripheral device)
server_sock = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
server_sock.bind(("", bluetooth.PORT_ANY))
server_sock.listen(1)

# Advertise SPP service
uuid = "00001101-0000-1000-8000-00805F9B34FB"  # SPP UUID
bluetooth.advertise_service(server_sock, "SensorData",
                           service_id=uuid,
                           service_classes=[uuid, bluetooth.SERIAL_PORT_CLASS],
                           profiles=[bluetooth.SERIAL_PORT_PROFILE])

print("Waiting for connection...")
client_sock, client_info = server_sock.accept()
print(f"Connected: {client_info}")

# Send/receive data like a serial port
while True:
    data = read_sensor()
    client_sock.send(f"{data}\n")

6.5.3 Arduino Example

#include <SoftwareSerial.h>

// HC-05 Bluetooth module on pins 10, 11
SoftwareSerial bluetooth(10, 11);  // RX, TX

void setup() {
    Serial.begin(9600);
    bluetooth.begin(9600);
    Serial.println("Bluetooth SPP Ready");
}

void loop() {
    // Send sensor data over Bluetooth
    int sensorValue = analogRead(A0);
    bluetooth.println(sensorValue);

    // Receive commands from phone
    if (bluetooth.available()) {
        char cmd = bluetooth.read();
        processCommand(cmd);
    }

    delay(100);
}

6.5.4 SPP Limitations

• No BLE support: SPP will not work with BLE-only devices; use a BLE UART-style GATT service instead.
• Discovery required: Users normally pair manually; NFC or QR-assisted pairing can reduce setup friction.
• Power consumption: Classic Bluetooth draws more current than BLE; reserve SPP for continuous streams or powered devices.
• No standard data format: SPP transports bytes, not semantics; define a simple application protocol.

6.6.1 HID over Classic Bluetooth

Used by most wireless keyboards and mice:

Characteristics:

• Low latency (8-11 ms typical)
• Report-based data structure
• Boot protocol for BIOS compatibility
• Encryption required

For a keyboard, the practical path is: key press becomes a HID scan code, the profile wraps it into a report carried by the Bluetooth stack, and the host converts the recovered scan code back into an operating-system input event. That is why HID interoperability depends on the report descriptor and security state, not only on a successful Bluetooth connection.

6.6.2 HID over GATT (BLE)

BLE version for lower power devices:

Service UUID: 0x1812

Inspect Figure 6.3 to see how a BLE keyboard or mouse exposes more than one “input value.” Inspecting the service structure first makes the later UUID list meaningful and shows which metadata lets a host interpret reports correctly.

Read Figure 6.3 from the HID service into HID Information and the Report Map, which establish device metadata and report format. Then follow Control Point and Protocol Mode for host control before reaching the Report characteristics that carry input, output, or feature data. 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.

Characteristics:

• 0x2A4A - HID Information: Read-only metadata about the HID device.
• 0x2A4B - Report Map: Read-only descriptor that tells the host how to interpret reports.
• 0x2A4C - HID Control Point: Write Without Response for suspend/exit-suspend commands.
• 0x2A4D - Report: Read, Write, and Notify for input, output, and feature reports.
• 0x2A4E - Protocol Mode: Read and Write Without Response for Boot vs Report protocol selection.

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.

6.6.3 HID Report Types

• Input reports: Device to host; keystrokes, button presses, mouse movement, joystick axes.
• Output reports: Host to device; LED state such as Caps Lock or controller rumble commands.
• Feature reports: Bidirectional; configuration and device-specific settings.

6.6.4 Example: BLE Keyboard

#include <BleKeyboard.h>

BleKeyboard bleKeyboard("ESP32 Keyboard");

void setup() {
    bleKeyboard.begin();
}

void loop() {
    if (bleKeyboard.isConnected()) {
        // Type a message
        bleKeyboard.print("Hello from ESP32!");

        // Special keys
        bleKeyboard.press(KEY_LEFT_CTRL);
        bleKeyboard.press('c');
        bleKeyboard.releaseAll();

        delay(1000);
    }
}

6.6.5 Game Controller Support

Modern game controllers use HID:

• Xbox Series controllers: Bluetooth HID, typically around 8 ms.
• PlayStation 5 controllers: Bluetooth HID, typically around 10 ms.
• Nintendo Switch controllers: Bluetooth HID, typically around 15 ms.

6.7.1 Architecture

Before comparing codecs, locate the two A2DP roles in Figure 6.4. The role boundary determines which endpoint produces the encoded media stream and which endpoint receives and renders it, so it belongs ahead of any bitrate or latency choice.

Follow Figure 6.4 from the source application through encoding and the Bluetooth media path to the sink’s decoder and audio output. Control and capability negotiation establish a mutually supported configuration before streaming begins. This direction of travel connects the abstract source/sink names to product responsibilities and sets up the codec discussion: end-to-end quality and delay depend on both endpoints, not on a codec label alone.

6.7.2 Audio Codecs

• SBC: 328 kbps, around 200 ms latency, good quality, mandatory and free for A2DP.
• AAC: 256 kbps, around 100 ms latency, very good quality, licensed and widely used by Apple devices.
• aptX: 352 kbps, around 70 ms latency, excellent quality, licensed and useful for video sync.
• aptX HD: 576 kbps, around 100 ms latency, near-CD quality, licensed.
• LDAC: 990 kbps, around 200 ms latency, high-resolution audio, licensed and power-hungry.
• LC3: Variable bitrate, around 20 ms latency, excellent quality, used by BLE Audio rather than classic A2DP.

6.7.3 Codec Selection

During A2DP setup, the source and sink exchange supported codec capabilities and select the best mutually supported option. Always expect fallback to SBC because it is mandatory, then prefer lower-latency codecs when video or gaming sync matters.

6.7.4 A2DP Latency Considerations

Audio latency affects user experience:

• Music listening: Less than 200 ms is usually acceptable; any supported codec can work.
• Video watching: Aim below 100 ms; aptX is preferred, with AAC often acceptable.
• Gaming: Aim below 50 ms; aptX Low Latency is the classic Bluetooth target.
• Live performance: Aim below 20 ms; use wired audio or LE Audio with LC3 rather than classic A2DP.

6.9.1 HFP vs HSP

• Call control: HFP supports full call control; HSP only supports basic headset behavior.
• Voice dial: HFP supports voice dialing; HSP does not.
• Caller ID: HFP can expose caller ID; HSP does not include it.
• Three-way calling: HFP supports it; HSP does not.
• Audio codec: HFP supports CVSD and mSBC; HSP is limited to CVSD.
• Use case: Choose HFP for modern devices and HSP only for legacy compatibility.

6.9.2 Voice Call Audio Quality

Hands-free calling is bidirectional, so inspect Figure 6.5 to inspect both the downlink heard by the user and the microphone return path before judging quality. The processing blocks reveal why a connected call may still suffer echo, noise, or intelligibility failures.

Read Figure 6.5 first from the phone across the Bluetooth link to the hands-free loudspeaker. Then trace the microphone path back, paying attention to echo cancellation and noise reduction before the signal returns to the phone network. That loop connects HFP’s call-control features to acoustic performance: codec support, microphone placement, cabin noise, and echo processing must be tested together in the intended environment.