Bluetooth & BLE · Study deck
Bluetooth Profiles: Selection and Implementation
The profile families are understood, but a product still needs one interoperable choice.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The error: A developer building a custom BLE game controller implements HID over GATT (HOGP) but hardcodes a simple report descriptor, assuming "it's just button states and joystick positions.".
- Explain: 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.
- Explain: Full frames per second: 100 samples/sec ÷ 165 = 0.606 frames/sec, requiring 1.65 s of batching; a 10-50 ms latency target needs smaller, more frequent frames.
- select a compatible profile set
Major section
Technology Comparison
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.
- The element-address limit is not a guaranteed node capacity.
- Wireless earbuds: A2DP + AVRCP + HFP for music, media controls, and calls.
Major section
Common Pitfalls in Bluetooth Profile Implementation
Solution: HID requires authentication and encryption; always enable security features.
- Impact: 150-200 ms audio delay causes noticeable lip-sync issues.
- Impact: Incompatibility with operating systems and need for custom apps.
- Mistake: Assuming all Bluetooth devices support the same profiles.
- Impact: Connection failures between devices (e.g., BLE-only phone can't use SPP).
Major section
Connection: BLE GATT Profiles meet CoAP Resource Model
BLE's GATT (Generic Attribute Profile) and CoAP share a strikingly similar resource-oriented architecture.
- Both organize functionality into hierarchical resources: GATT uses Services > Characteristics > Descriptors, while CoAP uses URI paths like /sensors/temperature/current.
- Both support read/write/notify operations, and both use UUIDs or URIs as resource identifiers.
- The key difference: GATT operates at the link layer (single-hop BLE), while CoAP operates at the application layer (multi-hop IP).
Major 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.
- The table should expose access properties, notification descriptors, and the boundary between a standard profile and product-specific semantics.
- Standard services give generic clients shared meaning; configuration and firmware branches can use vendor UUIDs.
Major section
Deep Dive: Attribute Tables, Handles, and UUID Evidence (continued)
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.
- It must write 0x0001 to the CCCD at handle 0x002B; after that, the server pushes each new reading from the value handle.
- The client uses handles as local addresses and UUIDs as meaning.
Major section
Deep Dive: Attribute Tables, Handles, and UUID Evidence (continued)
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.
- 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.
Major section
Worked Example: SPP Throughput vs BLE GATT for Sensor Data Streaming
Active power: 30-50 mA continuously because the connection is maintained.
- Illustrative RFCOMM payload: 990 bytes per frame if negotiated and supported; batching reduces overhead but adds buffering delay.
- Full frames per second: 100 samples/sec ÷ 165 = 0.606 frames/sec, requiring 1.65 s of batching; a 10-50 ms latency target needs smaller, more frequent frames.
- A separate microcontroller and Bluetooth stack would implement either transport.
Major section
Worked Example: SPP Throughput vs BLE GATT for Sensor Data Streaming (continued)
Illustrative framing budget: RFCOMM (5 bytes) + L2CAP (4 bytes) + assumed baseband overhead (18 bytes) = 27 bytes; actual packet framing and retransmissions vary.
- Connection interval: 7.5 ms minimum, allowing about 133 connection events per second; an event may carry multiple packets.
- Maximum samples fitting in a notification: 182 ÷ 6 = 30, but filling 30 samples at 100 samples/sec takes 300 ms, violating a 30 ms update target.
- For a ≤30 ms batching target, send at most 3 samples (18 bytes) per notification, or send partially filled frames sooner; 100 ÷ 3 rounds up to 34 notifications/sec.
Major section
Worked Example: SPP Throughput vs BLE GATT for Sensor Data Streaming (continued)
Throughput: Both meet the 4,800 bps requirement, but SPP has much more margin (around 1 Mbps practical vs 10 kbps BLE GATT in this conservative example).
- Battery life under the stated active-use and powered-off assumptions: 46.8 days versus 3.1 days.
- Setup complexity: SPP is simpler because it behaves like a serial port; BLE requires GATT service design.
- Hardware boundary: Bosch BNO055 is an IMU with I2C, UART, and HID-I2C interfaces, not an SPP or BLE radio.
Major section
Common Mistake: Using BLE HID Without Understanding Report Descriptor Complexity
The error: A developer building a custom BLE game controller implements HID over GATT (HOGP) but hardcodes a simple report descriptor, assuming "it's just button states and joystick positions.".
- A minimal game controller descriptor is 60-100 bytes of carefully structured data.
- Tested on Android: Worked (Android is lenient with HID descriptors).
- Tested on iOS: Worked (iOS auto-detects based on UUIDs).
- Lesson: HID descriptors are deceptively complex.
Deck summary
Key takeaways
Mesh remains a separate many-node control choice.
- Solution: HID requires authentication and encryption; always enable security features.
- BLE's GATT (Generic Attribute Profile) and CoAP share a strikingly similar resource-oriented architecture.
- BLE profile conformance is proved by the discovered attribute table, not by a screenshot of one value arriving.
- That hierarchy is the map for the handle, CCCD, caching, and reconnect evidence below.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1A smart-home hub must (1) stream music to existing Classic A2DP-only speakers, (2) receive readings from BLE-only temperature sensors, and (3) control Bluetooth Mesh lights. Which Bluetooth implementation strategy covers all three?
Show answer
Answer: C This scenario requires Classic A2DP for the specified speakers, BLE collection for the sensors, and Bluetooth Mesh support for the lights.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2What provides a reusable Bluetooth transport or object-exchange contract for profiles?
Show answer
Answer: B RFCOMM and GOEP supply reusable transport or object-exchange contracts.
Q3Complete the code to connect to a BLE device and read a GATT characteristic:
Show answer
Answer: A BleakClient uses an async context manager for connection management.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q4A firmware update moves a sensor value to a new GATT handle. What should a compatible client do after reconnecting?
Show answer
Answer: C Handles can move while the UUID still names the data.
Print reference
Answers
Answer key.
- C · This scenario requires Classic A2DP for the specified speakers, BLE collection for the sensors, and Bluetooth Mesh support for the lights.
- B · RFCOMM and GOEP supply reusable transport or object-exchange contracts.
- A · BleakClient uses an async context manager for connection management.
- C · Handles can move while the UUID still names the data.