3  Bluetooth Overview

3.1 Learning Objectives

After completing this chapter series, you should be able to:

• Distinguish between Bluetooth Classic and Bluetooth Low Energy (BLE) in terms of architecture, power consumption, and target applications
• Describe the BLE protocol stack including GAP, GATT, ATT, and L2CAP layers
• Explain BLE advertising modes, connection parameters, and data transfer mechanisms
• Evaluate when to use Bluetooth Classic versus BLE for specific IoT scenarios
• Apply BLE concepts through hands-on ESP32 simulation exercises
• Calculate battery life estimates for BLE devices using duty-cycle power models
• Select the appropriate Bluetooth profile for a given IoT application requirement

In 60 Seconds

Bluetooth is a short-range wireless technology with two variants: Classic Bluetooth for continuous streaming (audio, file transfer) and BLE for low-power intermittent communication (sensors, beacons, wearables). BLE is built into all modern smartphones, making it the most accessible wireless protocol for IoT device connectivity.

Key Concepts

• Bluetooth SIG: The standards body managing Bluetooth specifications, profiles, and the qualification/certification program for commercial products
• 2.4 GHz ISM Band: Unlicensed radio band (2.400–2.4835 GHz) used by Bluetooth; shared with Wi-Fi and Zigbee, requiring coexistence mechanisms
• Classic Bluetooth (BR/EDR): Original Bluetooth variant for continuous data streaming; uses 79 × 1 MHz channels with FHSS at 1600 hops/second
• BLE (Bluetooth Low Energy): IoT-optimized Bluetooth variant using 40 × 2 MHz channels; can operate on coin-cell batteries for years with µA sleep currents
• Advertising Channels: Three dedicated BLE channels (37, 38, 39) at 2402, 2426, 2480 MHz, placed to minimize overlap with Wi-Fi channels 1, 6, 11
• GATT (Generic Attribute Profile): BLE application-layer protocol organizing device data into services (collections) and characteristics (typed values)
• Central/Peripheral: BLE connection roles; central (smartphone/gateway) initiates connections; peripheral (sensor/beacon) advertises and accepts connections
• Connection Interval: BLE parameter defining how frequently master and slave exchange packets; ranges from 7.5 ms to 4 s

Minimum Viable Understanding

Bluetooth is a short-range wireless technology with two main variants: Classic Bluetooth for continuous streaming (audio, file transfer) and Bluetooth Low Energy (BLE) for intermittent, low-power communication (sensors, beacons, wearables). BLE is built into all modern smartphones, making it the most accessible wireless protocol for IoT device connectivity. They are separate protocols and are not backward compatible with each other.

3.2 Introduction

Bluetooth is one of the most ubiquitous wireless technologies in IoT, powering everything from fitness trackers and smart locks to industrial sensors and building automation systems. This chapter series provides a comprehensive guide to Bluetooth technology, covering both Classic Bluetooth and Bluetooth Low Energy (BLE).

For Beginners: What is Bluetooth?

Think of Bluetooth like a wireless conversation between two devices that are close together. Just like how you can talk to a friend standing next to you without needing a phone line, Bluetooth lets devices “talk” to each other without wires.

Simple analogy: Bluetooth is like a short-distance walkie-talkie for your devices. Your phone can “talk” to your headphones, your fitness tracker, or your smart lock—all without any cables!

Two types of Bluetooth:

• Classic Bluetooth: Like a phone call—good for long conversations (music streaming)
• BLE (Bluetooth Low Energy): Like text messages—quick updates, then the device goes back to sleep (fitness trackers, sensors)

Sensor Squad: The Wireless Whisperers!

“Have you ever wondered how your phone talks to your headphones without any wires?” Sammy the Sensor asked, tapping his antenna excitedly. “That is Bluetooth! It is like having a secret walkie-talkie built into every device.”

“I use Bluetooth all the time!” Lila the LED chimed in. “When someone connects their phone to a smart light bulb, Bluetooth carries the message telling me what color to glow and how bright to shine. The best part is that it only works over short distances, like across a room, so your neighbor cannot accidentally change my color!”

Max the Microcontroller nodded thoughtfully. “There are actually two types of Bluetooth. Classic Bluetooth is like having a long phone call – great for streaming music to headphones. But BLE, or Bluetooth Low Energy, is like sending quick text messages – perfect for sensors that only need to share a little data now and then, like a temperature reading once per minute.”

“And that is where I come in!” Bella the Battery added proudly. “BLE was designed specially so devices like fitness trackers can run on a tiny coin cell battery for months or even years. Instead of staying connected all the time, BLE devices wake up, send their message, and go right back to sleep. It is the ultimate power-saving trick!”

Putting Numbers to It

The duty cycle determines how long a BLE device remains active versus sleeping. Battery life can be estimated as:

\[\text{Battery Life (hours)} = \frac{C_{battery}}{I_{active} \times DC + I_{sleep} \times (1 - DC)}\]

where \(C_{battery}\) is battery capacity, \(I_{active}\) is active current, \(I_{sleep}\) is sleep current, and \(DC\) is the duty cycle (fraction of time active).

Example: A fitness tracker with a CR2032 battery (220mAh) transmitting heart rate every 60 seconds: - Active: 15mA for 5ms (BLE transmission) - Sleep: 2µA (deep sleep mode) - Duty cycle: \(DC = \frac{5\text{ms}}{60000\text{ms}} = 0.0000833\)

\[\text{Battery Life} = \frac{220}{15 \times 0.0000833 + 0.002 \times 0.9999} \approx \frac{220}{0.0032} \approx 68,750 \text{ hours} \approx 7.8 \text{ years}\]

This shows why BLE can achieve multi-year battery life with ultra-low duty cycles.

Try It: BLE vs Classic Power Comparison

Select a device type to see how BLE’s sleep-dominated power profile compares to Classic Bluetooth’s always-on connection.

viewof deviceType = Inputs.select(
  ["Fitness Tracker", "Door Sensor", "Beacon", "Temperature Logger"],
  {label: "Device Type", value: "Fitness Tracker"}
)

{
  const profiles = {
    "Fitness Tracker": {interval: 1000, payload: 8, battery: 220, desc: "Heart rate every 1 second"},
    "Door Sensor": {interval: 86400000/40, payload: 4, battery: 225, desc: "~40 events/day average"},
    "Beacon": {interval: 1000, payload: 31, battery: 620, desc: "Advertising every 1 second"},
    "Temperature Logger": {interval: 60000, payload: 4, battery: 220, desc: "Reading every 60 seconds"}
  };
  const p = profiles[deviceType];
  const activeMs = 3.6;
  const txMA = 12;
  const sleepUA = 2;
  const classicMA = 30;

  const dutyCycle = activeMs / p.interval;
  const bleUA = (txMA * 1000 * dutyCycle) + (sleepUA * (1 - dutyCycle));
  const bleMA = bleUA / 1000;
  const bleDays = (p.battery / bleMA) / 24;
  const classicDays = (p.battery / classicMA) / 24;

  let bleStr = bleDays < 30 ? `${bleDays.toFixed(1)} days` : bleDays < 365 ? `${(bleDays/30).toFixed(1)} months` : `${(bleDays/365).toFixed(1)} years`;

  return html`<div style="border:1px solid #E0E0E0;border-radius:8px;padding:16px;background:#FAFAFA;font-family:Arial,sans-serif;">
    <p style="margin:0 0 10px;color:#2C3E50;"><strong>${deviceType}</strong>: ${p.desc} | Battery: ${p.battery} mAh</p>
    <div style="display:flex;flex-wrap:wrap;gap:16px;">
      <div style="flex:1;min-width:180px;background:#E74C3C11;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#E74C3C;font-weight:bold;">Classic Bluetooth</div>
        <div style="color:#2C3E50;font-size:1.3em;font-weight:bold;">${classicDays.toFixed(1)} days</div>
      </div>
      <div style="flex:1;min-width:180px;background:#16A08511;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#16A085;font-weight:bold;">BLE</div>
        <div style="color:#2C3E50;font-size:1.3em;font-weight:bold;">${bleStr}</div>
      </div>
      <div style="flex:1;min-width:180px;background:#3498DB11;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#3498DB;font-weight:bold;">BLE Sleep Time</div>
        <div style="color:#2C3E50;font-size:1.3em;font-weight:bold;">${((1 - dutyCycle) * 100).toFixed(3)}%</div>
      </div>
    </div>
  </div>`;
}

3.3 Chapter Series Overview

This topic has been split into focused chapters for easier learning. Each chapter builds on the previous one:

3.3.1 Core Chapters

1. Classic Bluetooth vs BLE
   • Evolution of Bluetooth from 1994 to present
   • Key differences between Classic and BLE
   • Power consumption and battery life calculations
   • When to choose each technology
2. Bluetooth Topologies
   • Star, broadcast, and mesh network configurations
   • BLE advertising modes for beacons
   • Bluetooth Mesh for building-scale deployments
   • Power optimization for different topologies
3. Bluetooth Piconet Architecture
   • Central/peripheral (master/slave) roles
   • The 7-device active limit in Classic Bluetooth
   • Scatternet formation for extended networks
   • Workarounds for connection limits
4. Bluetooth Connection Establishment
   • Classic Bluetooth discovery (inquiry and paging)
   • BLE advertising and scanning
   • Connection parameters (interval, latency, timeout)
   • Bonding and pairing methods
5. Bluetooth Protocol Stack
   • Classic vs BLE protocol layers
   • GATT architecture (services, characteristics, descriptors)
   • Notification vs indication for data delivery
   • Adaptive Frequency Hopping (AFH)
6. Bluetooth Profiles
   • Serial Port Profile (SPP) for wireless UART
   • Human Interface Device (HID) for input devices
   • Advanced Audio Distribution Profile (A2DP)
   • Choosing the right profile for your application

3.3.2 Hands-On Learning

7. Bluetooth Hands-On Lab
   • Build a BLE sensor beacon using Wokwi simulator
   • Implement GATT services and characteristics
   • Handle connections and send notifications
   • No hardware required—browser-based simulation

3.4 Quick Reference

3.4.1 Classic Bluetooth vs BLE at a Glance

Aspect	Classic Bluetooth	BLE
Purpose	Audio streaming, file transfer	Sensors, beacons, wearables
Power	Medium (mA range)	Very low (uA range)
Battery Life	Days to weeks	Months to years
Data Rate	1–3 Mbps (EDR)	125 kbps–2 Mbps (LE Coded–LE 2M)
Connection	Persistent	Can be transient
Profiles	A2DP, HFP, SPP	GATT services

3.4.2 Bluetooth Version History at a Glance

Version	Year	Key Feature
1.0 / 1.2	1999 / 2003	Basic Rate (BR) 1 Mbps, piconet
2.0 + EDR	2004	Enhanced Data Rate (EDR) up to 3 Mbps
3.0 + HS	2009	High-Speed mode via 802.11 co-radio (24 Mbps burst)
4.0	2010	BLE introduced; sub-milliwatt sleep operation
4.2	2014	IPv6/6LoWPAN support, improved privacy, larger PDU
5.0	2016	LE 2M PHY (2 Mbps), LE Coded PHY (4× range), 8× advertising broadcast capacity
5.1	2019	Direction Finding (AoA/AoD for ~cm accuracy)
5.2	2020	LE Audio (LC3 codec), Isochronous Channels, Audio Sharing
5.3 / 5.4	2021–2023	Connection subrating, EATT enhancements, PAwR for large device sets

3.4.3 When to Use Bluetooth

Choose Bluetooth when:

• Smartphone connectivity is required (BLE built into all phones)
• Short-range communication (10–100 m typical; up to ~400 m with BLE 5.0 LE Coded PHY) is sufficient
• Battery life is important (BLE)
• Audio streaming is needed (Classic A2DP or BLE LE Audio with Bluetooth 5.2+)

Consider alternatives when:

• Internet connectivity required (use Wi-Fi)
• Large mesh network needed (consider Zigbee, Thread)
• Very long range required (use LoRa, cellular)

3.4.4 Knowledge Check: Bluetooth Version Milestones

3.5 Learning Path

3.5.1 Beginner Path (2-3 hours)

1. Read Classic Bluetooth vs BLE for foundational understanding
2. Skim Bluetooth Topologies for network concepts
3. Complete Bluetooth Hands-On Lab for practical experience

3.5.2 Intermediate Path (4-6 hours)

1. Complete beginner path
2. Study Piconet Architecture for deeper understanding
3. Learn Connection Establishment for optimization
4. Explore Protocol Stack for GATT development

3.5.3 Advanced Path (8+ hours)

1. Complete intermediate path
2. Master Bluetooth Profiles for application development
3. Review case studies and worked examples in each chapter
4. Implement challenge exercises in the hands-on lab

3.6 Concept Relationships

Concept	Relates To	How They Connect
Classic Bluetooth	BLE	Share 2.4 GHz band but different protocols; Classic for streaming, BLE for sensors
Advertising	Connection Establishment	Advertising broadcasts presence; central scans and initiates connection
GATT	Services/Characteristics	GATT organizes data into services (groups) containing characteristics (data points)
Piconet	Mesh	Classic piconet limited to 7 active peripherals; Mesh extends BLE to thousands via managed flooding
Power Consumption	Battery Life	Lower duty cycle = longer battery life; BLE sleeps between events

3.7 Key Takeaways

• BLE is not backward compatible with Classic Bluetooth—they are separate protocols
• Power optimization requires understanding advertising intervals, connection parameters, and sleep modes
• GATT is the foundation of BLE data exchange—services contain characteristics with properties
• Bluetooth Mesh extends BLE to building-scale with managed flooding
• Profile selection depends on your use case (audio, sensors, input devices)
• Bluetooth 5.0 (2016) introduced LE 2M PHY for 2 Mbps throughput, LE Coded PHY for 4× range, and 8× advertising broadcast capacity

3.7.1 Knowledge Check: Classic vs BLE

3.7.2 Knowledge Check: Bluetooth Technology Selection

Worked Example: Calculating Power Consumption for BLE vs Classic Bluetooth Thermostat

Scenario: A smart thermostat needs to maintain a wireless connection to a smartphone for temperature display and user adjustments. You must choose between Classic Bluetooth and BLE.

Requirements:

• Update temperature display every 30 seconds
• Respond to user button presses within 200ms
• Battery powered (4× AA batteries, 3000mAh total capacity)
• Target battery life: 2 years (17,520 hours)

Power Budget Calculation:

Option A: Classic Bluetooth

Idle power (connected): 40mA continuous
Active transmission: 60mA for 50ms per temperature update

Average power calculation:
- Idle: 40mA × 100% = 40.000mA
- Updates: 60mA × (50ms / 30,000ms) = 0.100mA
- Total average: 40.100mA

Battery life: 3000mAh / 40.1mA = 74.8 hours (3.1 days) ❌

Option B: BLE with Connection

Connection interval: 100ms (allows <200ms button response)
Peripheral latency: 299 (respond every 300th event for 30-sec updates)
Active radio: 15mA for 2ms per connection event
Sleep current: 10µA between events

Radio duty cycle when latent:
- Wake every 300 × 100ms = 30 seconds
- Active for 2ms, sleep for 29,998ms
- Duty: 2ms / 30,000ms = 0.0067%

Average power calculation:
- Active: 15mA × 0.000067 = 0.001mA
- Sleep: 0.010mA × 0.999933 = 0.010mA
- MCU + sensors: ~0.050mA average (duty-cycled)
- Total average: 0.061mA

Battery life: 3000mAh / 0.061mA = 49,180 hours (5.6 years) ✓

Option C: BLE Advertising-Only (No Connection)

Advertising interval: 5000ms (5 seconds)
Active radio: 15mA for 1ms per advertisement
Sleep current: 5µA between advertisements

Average power calculation:
- Active: 15mA × (1ms / 5000ms) = 0.003mA
- Sleep: 0.005mA × (4999ms / 5000ms) = 0.005mA
- MCU + sensors: ~0.030mA average
- Total average: 0.038mA

Battery life: 3000mAh / 0.038mA = 78,947 hours (9.0 years) ✓✓

Trade-off: No bidirectional control (phone can only listen, not send commands)

Comparison Table:

Metric	Classic BT	BLE Connected	BLE Advertising-Only
Battery Life	3.1 days	5.6 years	9.0 years
Button Response Latency	<50ms	<200ms	Not applicable (no commands)
Temperature Update Rate	Real-time	30 seconds	5 seconds (phone scans)
Power Consumption	40.1mA	0.061mA	0.038mA
Power Efficiency	1× (baseline)	657× better	1055× better
Use Case Fit	❌ Too high power	✓ Meets all requirements	✓ If no user control needed

Result: Select BLE with connection (Option B) for 5.6 years of battery life while meeting all functional requirements. Classic Bluetooth’s continuous connection would drain batteries in days, making it unsuitable for battery-powered thermostats.

Key Insight: The power difference between Classic and BLE comes from duty cycling, not just radio efficiency. BLE’s ability to sleep for 99.99% of the time (during idle periods) multiplies battery life by 600–1000× compared to Classic’s always-on connection model.

Interactive Quiz: Match Bluetooth Overview Concepts

Interactive Quiz: Sequence the Bluetooth Evolution

3.8 See Also

• Classic Bluetooth vs BLE - Deep dive into protocol differences and use cases
• Bluetooth Protocol Stack - GATT architecture and data exchange
• Bluetooth Topologies - Star, mesh, and broadcast patterns
• Bluetooth Security - Pairing methods and encryption
• Wi-Fi Fundamentals - Higher bandwidth alternative for IoT

Common Pitfalls

1. Treating BLE as a Drop-In Wi-Fi Replacement

BLE is designed for short bursts of small data, not continuous TCP/IP communication. Attempting to stream video frames, JPEG images, or large files over BLE GATT results in throughput of only 0.3–2 Mbps (practical) with high latency. Use BLE for telemetry, commands, and configuration; use Wi-Fi for large data transfers. If both are needed, implement dual-radio designs with BLE for control and Wi-Fi for bulk data.

2. Assuming BLE Range is Always 10 meters

“10 meter range” refers to Class 3 (1 mW / 0 dBm) devices in free space. BLE range varies from <1 m (inside metal enclosures) to ~400 m (BLE 5.0 Coded PHY, outdoor, clear line of sight). Indoor range is typically 10–50 m depending on wall materials. Always conduct site surveys with the actual hardware and enclosure before finalizing network architecture.

3. Not Handling Connection Drop and Reconnection

BLE connections drop regularly due to interference, device movement, or power cycling. Applications that do not implement automatic reconnection logic leave IoT devices in a disconnected state with no data flowing. Implement an exponential backoff reconnection strategy: retry after 1 s, 2 s, 4 s, 8 s, up to a maximum interval. Persist sensor data locally during disconnection and batch-upload on reconnection.

4. Ignoring Smartphone OS BLE Scanning Restrictions

Android 7+ and iOS 10+ impose BLE scan throttling: after 30 seconds of continuous scanning, Android reduces scan frequency to save battery. iOS background scanning imposes 30-second scan windows with gaps. Applications relying on continuous BLE scanning for proximity or real-time updates must account for these OS restrictions and design for intermittent scan delivery, not continuous observation.

3.9 What’s Next

Next Chapter	What You Will Learn
Classic Bluetooth vs BLE	Protocol differences, version history, and power trade-offs
Bluetooth Topologies	Star, broadcast, and mesh network configurations
Bluetooth Piconet Architecture	Master/peripheral roles and the 7-device active limit
Bluetooth Connection Establishment	Advertising, scanning, bonding, and connection parameters
Bluetooth Protocol Stack	GATT services, characteristics, and notifications
Bluetooth Hands-On Lab	Build a BLE sensor beacon in your browser using Wokwi

Related Chapters

Deep Dives:

• Bluetooth Security - Encryption and pairing mechanisms
• Bluetooth Applications - Real-world BLE deployments
• Bluetooth Comprehensive Review - Complete protocol analysis

Comparisons:

• Zigbee Fundamentals - Mesh networking alternative
• Thread Operation - IPv6-based mesh
• LPWAN Comparison - Long-range alternatives

Hubs:

• Simulations Hub - Bluetooth network simulators
• Videos Hub - Visual explanations of BLE concepts

🏷️ Label the Diagram

💻 Code Challenge