926  Bluetooth Review: Visual Gallery and Assessment

NoteSeries Navigation

This is Part 4 of the Bluetooth Comprehensive Review series:

  1. Overview and Visualizations - Protocol stacks, state machines, initial scenarios
  2. Advanced Scenarios - Medical security, battery drain, smart locks
  3. GATT Pitfalls - Common implementation mistakes
  4. Assessment (this chapter) - Visual gallery and understanding checks

926.1 Summary

This comprehensive review synthesized Bluetooth Classic and BLE concepts for IoT applications:

  • Protocol Stack Architecture: Bluetooth operates on 2.4 GHz ISM band with frequency hopping, supporting both Classic (audio streaming, file transfer) and BLE (sensors, wearables) modes with distinct power profiles
  • BLE Power Efficiency: BLE supports low-duty-cycle operation (advertising, notifications, configurable connection intervals) that can enable long battery life for sensors and wearables
  • GATT Services: Generic Attribute Profile provides standardized data organization through services and characteristics, with profiles like Heart Rate, Battery Service, and Device Information ensuring cross-vendor interoperability
  • Bluetooth Mesh: Extends BLE for building automation with managed flooding and built-in security; practical scale depends on traffic patterns, relay density, and the physical environment
  • Security Levels: Four security modes from no security (Mode 1, Level 1) to authenticated pairing with AES-128 encryption (Mode 1, Level 4), with LE Secure Connections providing ECDH key exchange
  • IoT Applications: BLE is widely used for wearables, beacons, smart home devices, and medical monitoring because it balances range, throughput, ecosystem support, and power consumption

926.2 What’s Next

Continue to IEEE 802.15.4 to explore the low-power wireless standard that serves as the foundation for mesh protocols like Zigbee and Thread used in IoT networks.

926.3 Understanding Check: Bluetooth Technology Selection

Apply your Bluetooth knowledge to understand real-world design decisions:

Situation: You’re designing a fitness tracker that must last 6 months on a CR2032 coin cell battery (240mAh) while continuously monitoring heart rate and syncing with a smartphone.

Technology options: - Classic Bluetooth: Continuous connection, reliable audio support - BLE (Bluetooth Low Energy): Intermittent connection, optimized for sensors

Think about: 1. How much power does maintaining a continuous Bluetooth connection consume? 2. How do BLE intermittent connections compare to Classic continuous connections in terms of power and responsiveness? 3. Why does “faster pairing” translate to longer battery life?

Key Insight:

Classic Bluetooth power profile:

Idle (connected): 30-60mA continuous
Active transmission: 40-80mA
Connection setup: 6 seconds @ 60mA per connection
Daily consumption: ~1440mAh (continuous connection)
Battery life: 240mAh / 1440mAh = 4 hours!

BLE power profile:

Active (transmitting): 8-15mA for 2ms bursts
Idle (between transmissions): 1-15µA sleep mode
Connection setup: overhead varies by configuration
Heart rate measurement (1/second):
  - Wake: 0.5ms
  - Measure: 1ms @ 10mA
  - Transmit: 2ms @ 15mA
  - Sleep: 996.5ms @ 10µA
Average consumption: ~200µA
Daily: ~4.8mAh
Battery life: 240mAh / 4.8mAh = 50 days → 6+ months with optimization!

Why BLE wins for fitness trackers: - Large power reductions are possible through aggressive sleep/duty-cycling - Intermittent connections and short radio bursts enable frequent sleep/wake cycles - Optimized protocol: Smaller packets, less overhead per transmission - Asymmetric data flow: Sensor mostly transmits TO phone (BLE optimized for this)

Verify Your Understanding: - Can you calculate the power difference between transmitting every 1 second vs every 10 seconds? - What happens to battery life if you need to maintain a continuous connection for audio (e.g., Bluetooth headset)? - Why can’t you use Classic Bluetooth for a coin cell device?

Situation: Your smart home hub (Bluetooth master) controls 12 devices: 8 smart bulbs, 3 door sensors, and 1 thermostat. Suddenly, only 7 devices respond while the other 5 show “disconnected” even though they’re powered and in range.

Think about: 1. Why exactly 7 devices work while 5 fail? 2. Is this a hardware failure or protocol limitation? 3. How could you connect all 12 devices?

Key Insight:

Piconet architecture limitation:

Classic Bluetooth piconet = 1 master + 7 active slaves (maximum)

Why 7?
- 3-bit address field in packet header
- Addresses: 001-111 (7 values)
- 000 reserved for broadcast
- Total active devices: 7

Additional devices:
- Can be "parked" (up to 255 total)
- Parked devices cannot transmit
- Must be "unparked" to communicate
- Only 7 can be active simultaneously

Your 12-device problem:

Devices 1-7: Active, working normally
Devices 8-12: Disconnected or parked (cannot communicate)

This is NOT a bug - it's the protocol specification!

Solutions for >7 devices:

Option 1: Use BLE instead

BLE doesn't have the 7-device piconet limitation
Many BLE stacks support more than 7 concurrent connections (implementation-dependent)

Option 2: Multiple piconets

Deploy 2 hubs (each supporting 7 devices)
Hub 1: 7 devices
Hub 2: 5 devices
Operational trade-off: extra hardware and integration complexity

Option 3: Bluetooth Mesh

Best for large deployments
Each node can relay messages (no central master limitation)
Practical scale depends on traffic patterns, relay density, and environment
Common in building automation

Verify Your Understanding: - Can you explain why the 7-device limit exists (hint: packet header design)? - If you needed to connect 50 smart lights, which Bluetooth technology would you use? - Why is the piconet limitation NOT an issue for most consumer Bluetooth devices (headphones, keyboards)?

Situation: Your office has a busy 2.4 GHz Wi-Fi environment and you’re deploying BLE sensors. Users report intermittent sensor disconnections, but most people still perceive Wi-Fi as “working fine.”

Think about: 1. Why do Bluetooth and Wi-Fi interfere with each other? 2. What frequency band do they both use? 3. How does Bluetooth handle this interference?

Key Insight:

Wi-Fi and Bluetooth share the 2.4 GHz ISM band. Wi-Fi uses relatively wide channels, while Bluetooth uses narrower channels and adapts its channel usage over time. In a busy environment, Bluetooth links may see more retries, higher latency, and occasional disconnects even when Wi-Fi still feels “fine” to most users.

How Bluetooth mitigates interference: - Classic (BR/EDR): uses Adaptive Frequency Hopping (AFH) to avoid persistently bad channels. - BLE: uses an adaptive channel map (channel classification) plus retransmissions; most stacks enable this by default. - Both benefit from better link margin (placement, antenna orientation, fewer obstructions).

Practical mitigations for your deployment: - Move high-bandwidth clients/APs to 5 GHz/6 GHz where possible to reduce 2.4 GHz congestion. - Ensure adaptive channel selection/AFH is enabled (it is sometimes disabled in test modes). - Improve RF conditions: gateway placement, antenna orientation, avoid metal enclosures, reduce obstructions. - Tune BLE parameters for robustness (scan windows, connection interval/timeout), and keep transmit power within local regulatory limits.

Verify Your Understanding: - Why can Wi-Fi appear “okay” while BLE sensors disconnect? - Which mitigations reduce congestion vs improve link margin? - When would you consider switching to a different radio technology entirely?

Situation: You’re building a continuous glucose monitor (CGM) that transmits patient blood sugar data via BLE to a smartphone app. This is sensitive health data, so you need strong security and careful session management.

Think about: 1. What happens if an attacker can eavesdrop on readings (confidentiality)? 2. What happens if an attacker can inject or replay commands/readings (integrity)? 3. What user verification is realistic during pairing for your device’s UI constraints?

Suggested approach (high level): - Prefer LE Secure Connections and require an encrypted link for sensitive characteristics. - Use an authenticated pairing method when possible (Numeric Comparison or OOB are strongest; Passkey Entry can work when only one side has UI). - Add application-layer authorization and a session timeout (e.g., “unlock” in the app before reading/exporting data). - Plan for bond revocation (lost phone) and secure firmware updates.

Verify Your Understanding: - Can you explain the difference between pairing (key exchange) and bonding (key storage)? - Why is numeric comparison stronger than passkey entry for user verification? - What additional security would you implement at the application layer (hint: end-to-end encryption)?

Situation: You’re developing a wireless keyboard for tablets. It needs to send keypresses, support multiple operating systems (Windows, Mac, iOS, Android), and have <10ms latency for responsive typing.

Think about: 1. Why use the HID (Human Interface Device) profile instead of creating a custom GATT service? 2. What does “profile” mean in Bluetooth terminology? 3. How does using a standard profile enable cross-platform compatibility?

Key Insight:

Bluetooth Profiles = Application-specific Behavior

Profile: Pre-defined services, characteristics, and protocols for specific use cases
Benefit: Interoperability without custom drivers

HID Profile specification:
- Based on: USB HID (Human Interface Device) spec
- Services: HID Service (0x1812)
- Characteristics: HID Report (0x2A4D), HID Report Map (0x2A4B)
- Data format: HID descriptor defines keyboard layout, keycodes

Why HID for keyboards:

1. OS Support (built-in drivers):

Windows: Recognizes HID keyboards automatically (since Windows 7)
Mac: Native HID support (no pairing for some devices)
iOS: Supports HID keyboards via Bluetooth
Android: HID keyboard support since Android 4.0

Custom GATT service:
❌ Requires custom driver for each OS
❌ App must be installed before keyboard works
❌ Security restrictions (iOS doesn't allow custom BLE keyboard drivers)

2. Standard Keycode Mapping:

HID Usage Tables define keycodes:
- Letter 'A' = 0x04
- Enter = 0x28
- Ctrl = 0xE0

All operating systems interpret these codes identically
No need for platform-specific mapping

3. Low Latency Requirements:

HID Profile parameters:
- Connection interval: 7.5-15ms (optimized for input devices)
- Slave latency: 0 (no skipped intervals - immediate response)
- Supervision timeout: 500ms
- Report rate: Typically 125 Hz (8ms interval)

Result: <10ms latency from keypress to character on screen

Alternative (custom GATT service):

Create custom service: UUID 0x1234-5678-...
Custom characteristic: Keypress data format
Problems:
❌ Requires app on every device (can't work at BIOS/boot level)
❌ Connection pairing issues (not recognized as keyboard)
❌ No OS-level keyboard shortcuts (Ctrl+C, Alt+Tab won't work)

Verify Your Understanding: - Can you explain why a Bluetooth keyboard works immediately after pairing without installing drivers? - What other profiles exist for common devices (hint: headphones, fitness trackers, heart rate monitors)? - Why can’t you use HID profile for a sensor sending temperature data?

926.4 Further Reading

926.5 Next Chapter

Continue to CoAP Protocol - another lightweight IoT protocol.

BLE Advertising Best Practices: - Discovery vs battery: Shorter intervals improve discovery, longer intervals extend battery life - Beacon Formats: iBeacon (Apple), Eddystone (Google), AltBeacon (open source) - Extended Advertising (BT 5.x): Up to 255 bytes payload vs 31 bytes legacy - Power: Non-connectable advertising is often lower power than maintaining a connection, but depends on interval and duty cycle

GATT Performance Tips: - Negotiate MTU: Request the largest MTU both sides support to reduce per-packet overhead (platform-dependent) - Batch writes: Use Write Without Response for bulk, non-critical data (logs, sensor readings) - Notify vs Indicate: Notify is lower overhead; Indicate provides acknowledgement when you need delivery confirmation - Cache GATT DB: Store service/characteristic UUIDs after first discovery

Bluetooth Mesh Use Cases: - Smart lighting: From tens to thousands of nodes (deployment-dependent), group addressing, scene control - Sensor Networks: Temperature, occupancy, environmental monitoring - Asset Tracking: Warehouse, hospital equipment tracking with beacons - Building Automation: HVAC, access control, security integration - Provisioning: Smartphone app adds/removes nodes from mesh network