5 Classic vs Low Energy (BLE)

In 60 Seconds

Classic Bluetooth and BLE share only the 2.4 GHz band and the Bluetooth brand – they are not backward compatible. Classic handles continuous streaming (audio, files) at milliamp power levels, while BLE is optimized for intermittent sensor data at microamp levels, enabling months-to-years battery life on a coin cell.

Key Concepts

BR/EDR (Basic Rate/Enhanced Data Rate): Classic Bluetooth physical layer modes; BR = 1 Mbps (GFSK), EDR = 2–3 Mbps (π/4-DQPSK, 8DPSK)
LE (Low Energy): BLE physical layer using GFSK with 1 Mbps (LE 1M), 2 Mbps (LE 2M, BT5.0+), or 125/500 kbps coded PHY for extended range
Scatternet vs BLE Star: Classic Bluetooth forms scatternets of overlapping piconets; BLE uses a star topology with one central and multiple peripherals
Dual-Mode Chip: Bluetooth IC supporting both Classic (BR/EDR) and BLE simultaneously; common in smartphones and laptops
Single-Mode Chip: BLE-only IC for IoT sensors; lower cost and power than dual-mode but cannot connect to Classic-only devices
Sniff Mode: Classic Bluetooth power-saving mode where slaves check for master traffic only at negotiated intervals (analogous to BLE connection intervals)
Page/Inquiry: Classic Bluetooth device discovery procedure (inquiry = scan for devices; page = connect to known device)
LE Coded PHY: BLE 5.0 physical layer using Forward Error Correction (FEC) at 125 kbps or 500 kbps, quadrupling range to ~400 m

Minimum Viable Understanding

Classic Bluetooth and BLE are fundamentally different protocols that share only the 2.4 GHz band and the Bluetooth brand – they are NOT backward compatible. Classic is designed for continuous streaming (audio, file transfer) at milliamp power levels, while BLE is optimized for intermittent sensor data at microamp levels, enabling months-to-years battery life on a coin cell. Choosing the right variant – and understanding BLE power pitfalls like radio startup time and MTU negotiation – is essential for any IoT design.

5.1 Learning Objectives

By the end of this chapter, you will be able to:

Distinguish the fundamental differences between Classic Bluetooth (BR/EDR) and Bluetooth Low Energy (BLE), including incompatible PHY layers and protocol stacks
Calculate power consumption for different advertising and connection configurations using duty cycle analysis
Select the right Bluetooth variant based on application requirements such as data rate, battery life, and topology
Diagnose common pitfalls when designing BLE-based IoT devices, including radio startup overhead and MTU negotiation failures

For Beginners: Classic Bluetooth vs BLE

Classic Bluetooth is like a phone call – it maintains a continuous connection for streaming audio or transferring files. BLE (Bluetooth Low Energy) is like sending a quick text – it wakes up briefly to exchange small amounts of data, then goes back to sleep. BLE was designed specifically for IoT devices that need to run on tiny batteries for months or years.

Sensor Squad: The Great Power Showdown!

“Let me tell you about the biggest difference between Classic Bluetooth and BLE,” Sammy the Sensor began. “Classic Bluetooth is like leaving the tap running all day – it keeps the connection flowing constantly. Great for music streaming, but terrible for my little sensor friends who only need to send a temperature reading once a minute!”

“Think of it this way,” Lila the LED suggested. “Classic Bluetooth is like a spotlight that stays on during an entire concert – bright and powerful but uses lots of energy. BLE is like a camera flash – it lights up for just a tiny moment, does its job, and then turns off. That quick flash is all we need to send sensor data!”

Max the Microcontroller leaned in. “Here is the technical secret: BLE was designed from scratch as a completely different protocol. It is not just Classic Bluetooth on a diet. The connection setup is faster, the packets are smaller, and the radio sleeps most of the time. I can manage dozens of BLE sensors with barely any processing power.”

“And the results speak for themselves!” Bella the Battery said proudly. “Classic Bluetooth drains me in hours, but BLE lets me power a sensor for months or even years on a single coin cell battery. That is the difference between milliamps and microamps – and in the IoT world, every microamp counts!”

5.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Bluetooth Overview: Basic understanding of Bluetooth technology and its role in IoT
Networking Fundamentals: Basic understanding of wireless communication concepts

How It Works: BLE Power Savings Through Duty Cycle

How does a BLE sensor last 2 years on a coin cell while Classic Bluetooth drains the same battery in days?

Advertising Mode (disconnected): BLE sensor broadcasts 31-byte packet on channels 37, 38, 39 every 1 second
- Radio active: 3 x 1.2 ms = 3.6 ms per cycle
- Radio sleeping: 996.4 ms per cycle
- Duty cycle: 3.6 / 1000 = 0.36%
Radio Events: Each 1.2 ms event consumes ~15 mA (startup + TX + settling)
- Energy per event: 15 mA x 1.2 ms = 18 µAs
- Energy per cycle (3 channels): 3 x 18 = 54 µAs
Sleep Mode: MCU + radio in deep sleep consuming 2 µA
- Energy during 996.4 ms sleep: 2 µA x 996.4 ms = 1,993 µAs
Average Current Calculation:
- Total per 1-second cycle: 54 + 1,993 = 2,047 µAs = 2.047 mA-ms
- Average current: 2,047 µAs / 1,000 ms = 2.05 µA (mostly sleep)
Battery Life (CR2032 = 220 mAh):
- Runtime: 220,000 µAh / 2.05 µA = 107,317 hours = 12.2 years
Accounting for sensor + MCU overhead (~50 µA): Total ~52 µA → 5.9 months realistic

Classic Bluetooth comparison: Maintains connection even when idle → 25-35 mA continuous → CR2032 lasts 6-9 hours. The 1,000x difference comes from sleeping 99.6% of the time.

Putting Numbers to It

The power difference between Classic and BLE for a temperature sensor reporting once per minute is dramatic.

\[\text{Battery Life} = \frac{\text{Battery Capacity (mAh)}}{\text{Average Current (mA)}}\]

For Classic Bluetooth maintaining an idle connection: Average current ≈ 30mA.

\[\frac{220\text{mAh}}{30\text{mA}} = 7.3 \text{ hours}\]

For BLE with 1-second advertising: Average current ≈ 0.052mA (52µA).

\[\frac{220\text{mAh}}{0.052\text{mA}} \approx 4{,}231 \text{ hours} = 176 \text{ days}\]

The 580× battery life improvement makes BLE viable for coin cell IoT sensors.

Try It: Classic vs BLE Power Comparison

Adjust the advertising interval and see how BLE’s duty cycle approach compares to Classic Bluetooth’s always-on connection.

Show code

viewof advInterval = Inputs.range([20, 10000], {step: 10, value: 1000, label: "BLE Advertising Interval (ms)"})
viewof battCapBle = Inputs.range([50, 500], {step: 5, value: 220, label: "Battery Capacity (mAh)"})

Show code

{
  const advActiveMs = 3.6; // 3 channels x 1.2ms per channel
  const advCurrentMA = 15; // mA during advertising
  const sleepCurrentUA = 2; // uA
  const classicCurrentMA = 30; // always-on connection

  const dutyCycle = advActiveMs / advInterval;
  const bleAvgUA = (advCurrentMA * 1000 * dutyCycle) + (sleepCurrentUA * (1 - dutyCycle));
  const bleAvgMA = bleAvgUA / 1000;
  const bleLifeHours = battCapBle / bleAvgMA;
  const bleLifeDays = bleLifeHours / 24;

  const classicLifeHours = battCapBle / classicCurrentMA;
  const classicLifeDays = classicLifeHours / 24;

  const ratio = Math.round(bleLifeDays / classicLifeDays);

  let bleStr;
  if (bleLifeDays < 30) bleStr = `${bleLifeDays.toFixed(1)} days`;
  else if (bleLifeDays < 365) bleStr = `${(bleLifeDays/30).toFixed(1)} months`;
  else bleStr = `${(bleLifeDays/365).toFixed(1)} years`;

  return html`<div style="border:1px solid #E0E0E0;border-radius:8px;padding:16px;background:#FAFAFA;font-family:Arial,sans-serif;">
    <div style="display:flex;flex-wrap:wrap;gap:16px;margin-bottom:12px;">
      <div style="flex:1;min-width:200px;background:#E74C3C11;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#7F8C8D;font-size:0.85em;">Classic Bluetooth</div>
        <div style="color:#E74C3C;font-size:1.4em;font-weight:bold;">${classicLifeHours.toFixed(1)} hours</div>
        <div style="color:#7F8C8D;font-size:0.8em;">${classicCurrentMA} mA always-on</div>
      </div>
      <div style="flex:1;min-width:200px;background:#16A08511;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#7F8C8D;font-size:0.85em;">BLE (${advInterval}ms interval)</div>
        <div style="color:#16A085;font-size:1.4em;font-weight:bold;">${bleStr}</div>
        <div style="color:#7F8C8D;font-size:0.8em;">${bleAvgUA.toFixed(1)} uA average</div>
      </div>
      <div style="flex:1;min-width:200px;background:#2C3E5011;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#7F8C8D;font-size:0.85em;">BLE Advantage</div>
        <div style="color:#2C3E50;font-size:1.4em;font-weight:bold;">${ratio}x longer</div>
        <div style="color:#7F8C8D;font-size:0.8em;">Duty cycle: ${(dutyCycle * 100).toFixed(3)}%</div>
      </div>
    </div>
  </div>`;
}

5.3 The Evolution of Bluetooth

The Challenge: Low-Power Wireless for Wearables

The Problem: Classic Bluetooth wasn’t designed for IoT:

Connection setup: 100ms+ (too slow for brief sensor interactions)
Always-on connection: Drains coin cell batteries in hours, not months
Complex profiles: Designed for audio streaming, not simple sensor data
Power consumption: 30-100mW continuous (smartphone-class, not sensor-class)

Why It’s Hard:

Wearables and beacons need coin cell batteries lasting months to years
Beacons must broadcast continuously without requiring pairing
Sensors send small data bursts (50-200 bytes) infrequently (once per minute)
Must work with every smartphone (iOS, Android) without special hardware

The Solution: Bluetooth Low Energy (BLE) - a low-power Bluetooth mode with its own protocol stack, GATT-based data model, and aggressive power management.

5.3.1 Historical Context

Understanding Bluetooth’s 30-year evolution helps explain why BLE is fundamentally different from Classic Bluetooth—not just a “low power mode,” but an entirely new protocol stack designed from scratch for IoT.

Original Problem (1994): Ericsson engineers wanted to eliminate the tangle of cables connecting mobile phones to accessories. The “MC-Link” project aimed to replace RS-232 serial cables with a short-range wireless link that could handle voice and data.

First Generation (1998-2004): Bluetooth 1.0-2.0 focused on cable replacement:

1998: Bluetooth 1.0 released (named after Harald “Bluetooth” Gormsson, a 10th-century Viking king who united Denmark)
1 Mbps data rate (BR — Basic Rate), primarily for voice headsets and file transfer
Classic Bluetooth operates at 2.4 GHz using 79 channels (2402–2480 MHz, 1 MHz spacing) with FHSS (Frequency-Hopping Spread Spectrum) at up to 1,600 hops/second for interference resistance
2004: Bluetooth 2.0 + EDR (Enhanced Data Rate) boosted speeds to 3 Mbps (2 Mbps with π/4-DQPSK, 3 Mbps with 8DPSK modulation)
Enabled stereo audio streaming (A2DP profile) and faster syncing

The Low Energy Revolution (2010): Bluetooth 4.0 introduced BLE as a completely new protocol:

Why “new”? BLE is not backward compatible with Classic—it uses different modulation (GFSK), different packet formats, and different connection procedures
BLE radio: Also operates at 2.4 GHz but uses 40 channels (2 MHz spacing), with 3 dedicated advertising channels (ch. 37: 2402 MHz, ch. 38: 2426 MHz, ch. 39: 2480 MHz) chosen to avoid Wi-Fi overlap, and 37 data channels for connections
Data rate: BLE 4.x supports 1 Mbps (with ~270 kbps effective throughput); BLE 5.0 adds a 2 Mbps PHY mode
Coin cell operation: Designed for low-duty-cycle devices targeting multi-month to multi-year battery life
Connection setup: Optimized for short exchanges, but discovery/connection time still depends on advertising/scan intervals
Sleep current: Can be in the single-digit microamp range depending on the radio and MCU
Key enabler: Apple’s iBeacon (2013) triggered the retail beacon explosion

Mesh Networking Era (2017): Bluetooth Mesh extended BLE to building-scale deployments:

Supports up to 32,767 nodes in a single network
Enables smart lighting, HVAC, and sensor networks across entire buildings
Uses managed flooding for message relay (no routing tables needed)

Modern Evolution (2020-Present): Bluetooth 5.x continues enhancing IoT capabilities:

Version	Year	Key Features	IoT Impact
5.0	2016	2x speed, 4x range, 8x advertising	Long-range industrial sensors
5.1	2019	Direction finding (AoA/AoD)	Indoor positioning to <1m accuracy
5.2	2020	LE Audio, LC3 codec, EATT	Hearing aids, multi-stream earbuds
5.3	2021	Connection subrating, periodic advertising	Reduced power, better coexistence
5.4	2023	PAwR (Periodic Advertising with Responses)	Electronic shelf labels at scale
Auracast	2022	Broadcast audio sharing	Public venues, accessibility

5.4 Classic Bluetooth vs BLE: Core Differences

Bluetooth comes in two main types, designed for different purposes:

Aspect	Classic Bluetooth	Bluetooth Low Energy (BLE)
Purpose	Streaming data (like music)	Sending small bits of data
Power Use	Higher (constant connection)	Very low (sleep most of the time)
Battery Life	Days to weeks	Months to years
Discovery/Setup	Often slower and more user-driven	Often faster, but depends on advertising/scan settings
Best Analogy	Phone call (continuous)	Text messages (quick bursts)
IoT Use	Audio devices	Sensors, beacons, wearables

Analogy: Phone Call vs. Text Message

Classic Bluetooth is like a phone call — you establish a connection and keep talking continuously (streaming music)
BLE is like texting — you send a quick message and then your phone goes back to sleep (fitness tracker sending heart rate)

5.4.1 Why BLE Changed Everything for IoT

Before BLE, battery-powered sensors were impractical because Bluetooth drained batteries too fast. BLE solved this:

Battery Impact:

Classic Bluetooth: Always on -> Battery lasts days/weeks
BLE: Wake briefly, then sleep -> Battery lasts months/years!

Real-World Impact:

Coin cell battery (like in a watch): ~230 mAh capacity
Classic Bluetooth: Would drain it in 1-2 weeks
BLE sensor: Can run for 2-5 years!

Common Misconception: “BLE is Just Low-Power Bluetooth”

The Misconception: Bluetooth Low Energy is Classic Bluetooth with power optimizations.

Why It’s Wrong:

BLE is a completely different protocol (incompatible PHY and stack)
Classic: Continuous connection, streaming audio
BLE: Burst transmission, attribute-based data model
Different radio characteristics (channels, modulation)
A Classic-only device CANNOT communicate with BLE-only device

Real-World Example:

Classic Bluetooth headphones: Continuous audio stream, hours of battery
BLE heart rate monitor: 1-second updates, months of battery
Trying to stream audio over BLE: Impossible (no A2DP profile)
Trying to read heart rate from Classic: Impossible (no GATT)

The Correct Understanding:

Feature	Classic Bluetooth	BLE
Connection	Persistent	Burst
Data model	Profiles (SPP, A2DP)	GATT attributes
Latency	Higher	Lower (ms)
Throughput	Higher (Mbps)	Lower (kbps)
Power	Higher	Much lower
Use case	Audio, file transfer	Sensors, beacons

BLE is a different technology that shares only the Bluetooth brand.

Knowledge Check: BLE Advertising Channels

5.5 Detailed Technical Comparison

5.6 Wireless Technology Comparison

Bluetooth Classic

Standard: IEEE 802.15.1
Frequency: 2.4 GHz
Raw Rate: 1-3 Mbps
Typical Throughput: 0.7-2.1 Mbps
Outdoor Range: 10 m class 2, 100 m class 1
Power / Battery: Medium power; days on small batteries
Network Size: 7 active devices

Bluetooth Low Energy

Standard: IEEE 802.15.1
Frequency: 2.4 GHz
Raw Rate: 1 Mbps in BLE 4.x
Typical Throughput: ~0.27 Mbps for sensor payloads
Outdoor Range: ~50 m, longer with coded PHY
Power / Battery: Very low power; months to years
Network Size: Implementation-dependent

Zigbee

Standard: IEEE 802.15.4
Frequency: 868 MHz, 915 MHz, 2.4 GHz
Raw Rate: 250 kbps at 2.4 GHz
Typical Throughput: ~0.2 Mbps
Outdoor Range: 10-100 m per hop
Power / Battery: Very low power; months to years
Network Size: 64,000+ theoretical nodes

Wi-Fi

Standard: IEEE 802.11 a/b/g/n
Frequency: 2.4 GHz and 5 GHz
Raw Rate: 11-600 Mbps
Typical Throughput: 7-150 Mbps
Outdoor Range: 100-250 m
Power / Battery: High power; hours on small batteries
Network Size: ~255 clients per network

Feature	Classic Bluetooth (BR/EDR)	Bluetooth Low Energy (LE)
Power profile	Higher average for continuous streams	Lower average for low-duty-cycle sensors
Range	Environment-dependent (often tens of meters)	Similar; coded PHY can extend range at lower data rates
Data rate	Higher application throughput (audio-friendly)	Lower effective throughput (sensor-friendly)
Discovery/setup	Often more user-driven	Advertising-based; timing depends on intervals
Best for	Audio streaming, peripherals	Sensors, beacons, wearables

5.7 Common Pitfalls

Pitfall: Assuming BLE Connection Interval Equals Update Rate

The Mistake: Setting the BLE connection interval to match your desired sensor update rate (e.g., 5-second connection interval for 5-second sensor readings), then wondering why the connection is unstable or data is missed.

Why It Happens: Developers confuse “connection interval” (radio scheduling parameter, 7.5ms to 4s max) with “application update rate” (how often your code sends data). The BLE specification limits connection intervals to 4 seconds maximum, so you cannot have a “5-minute connection interval.”

The Fix: Use a reasonable connection interval (100-500ms for sensors) combined with peripheral latency to skip connection events when there’s no data. Send sensor readings via notifications at your desired application rate, independent of the connection timing:

Implementation pattern:

Use a 100-200 ms connection interval so the link remains responsive.
Set peripheral latency so the sensor can skip idle radio events.
Keep the supervision timeout safely longer than the skipped-event window.
Send readings with application timers, for example every 5 minutes, instead of trying to make the BLE connection interval equal the sensor reporting interval.

Pitfall: Not Accounting for BLE Radio Startup Time in Power Calculations

The Mistake: Calculating battery life based only on TX current and transmission duration, ignoring the significant power consumed during radio startup, calibration, and post-TX settling.

Why It Happens: Datasheets highlight peak TX current (8-15mA), but the radio requires 1-3ms of startup time at similar current before transmitting. For short packets, startup overhead can exceed actual TX time, doubling power consumption.

The Fix: Include the full radio event duration in power calculations, not just packet airtime:

Correct power budget for one BLE radio event:

Startup/calibration: 1.5 ms at 12 mA = 18 uAs
TX packet: 0.3 ms at 15 mA = 4.5 uAs
RX window if connected: 1.0 ms at 12 mA = 12 uAs
Post-processing: 0.5 ms at 5 mA = 2.5 uAs
Real total: about 37 uAs, not the 4.5 uAs predicted by TX airtime alone
For 1-second advertising on 3 channels, that difference is roughly 111 uAs/s vs 13.5 uAs/s, about an 8x underestimate

Always measure actual current with an oscilloscope or power analyzer, or use vendor-provided power profiling tools.

Pitfall: Not Negotiating MTU Size Before Transferring Large Payloads

The Mistake: Sending sensor readings, firmware updates, or log files using the default 23-byte ATT MTU (20 bytes usable payload), resulting in excessive fragmentation, 5-10x slower transfers, and significantly higher power consumption due to per-packet overhead.

Why It Happens: The default BLE MTU (Maximum Transmission Unit) is 23 bytes for legacy compatibility. Many developers don’t realize they must explicitly request a larger MTU after connection—it’s not automatic. Without negotiation, a 200-byte sensor reading requires 10+ BLE packets instead of 1.

The Fix: Request MTU exchange immediately after connection establishment. Most modern BLE stacks support 247-512+ byte MTU:

Safe MTU pattern:

Request MTU exchange immediately after connection.
Use the negotiated MTU from the callback; do not assume the requested value was accepted.
Remember that ATT payload is MTU minus 3 bytes.
A 200-byte reading needs about 10 packets with the default 23-byte MTU, but usually 1 packet with MTU 247, cutting radio wake-ups by roughly 7x.

Pitfall: Keeping BLE Radio in Connected Mode When Data Transfer Is Infrequent

The Mistake: Maintaining a persistent BLE connection for a sensor that only sends data every 5-30 minutes, draining battery on connection event overhead when advertising + on-demand reconnection would be more efficient.

Why It Happens: Connection-based communication feels simpler—connect once, send whenever needed. But BLE connections require periodic “keep-alive” exchanges (connection events) at the negotiated interval. Even with 4-second intervals and peripheral latency, a device maintaining connection 24/7 wastes power on events where no data is exchanged.

The Fix: Compare connection maintenance cost vs. advertising + reconnection cost. For infrequent data (>1-2 minute intervals), advertising mode is often more power-efficient:

Power decision rule for infrequent sensors:

Persistent connection at the 4 s limit with latency still creates about 15 idle events every 5 minutes.
If each idle event costs about 25 uAs, the sensor spends roughly 375 uAs before sending useful data.
Advertising plus reconnect can be closer to 109 uAs for the same 5-minute report.
Use persistent connections for data intervals below about 30 seconds.
Test both approaches for 30 seconds to 2 minutes.
Consider advertising or reconnect-on-demand when data arrives less often than 2 minutes or on external triggers.

5.8 BLE vs Wi-Fi vs Zigbee: Choosing the Right Protocol

Protocol Selection Guide

Choose BLE when:

Battery life is critical (years on coin cell)
Smartphone connectivity needed (BLE built into all phones)
Short-range communication (10-50m) is sufficient
Periodic data transmission (every few seconds to minutes)
You can tolerate controller/app limits on concurrent connections (implementation-dependent)
Example: Fitness tracker, smart door lock, medical wearable

Choose Wi-Fi when:

High data rate required (>1 Mbps sustained)
Devices are mains-powered
Internet connectivity essential
Integration with existing network infrastructure
Example: Security camera, smart speaker, video doorbell

Choose Zigbee when:

Mesh networking needed (self-healing, multi-hop)
Large-scale deployment (100s-1000s of nodes)
Low data rate acceptable (250 Kbps max)
Home automation standard (compatibility with hubs)
Example: Smart lighting, building HVAC sensors, industrial monitoring

Trade-off summary: BLE for phone-connected wearables, Wi-Fi for bandwidth-intensive devices, Zigbee for large meshed sensor networks.

5.9 BLE PHY Modes (Bluetooth 5.0+)

Pitfall: Assuming 2M PHY Always Improves Performance

The Mistake: Enabling BLE 5.0 2M PHY (2 Mbps) mode expecting double throughput and half power consumption, then experiencing worse range, more disconnections, and no battery improvement in real deployments.

Why It Happens: The 2M PHY doubles the raw bit rate but uses the same transmit power, resulting in ~6dB less link margin (receiver sensitivity is worse at higher data rates). In marginal RF conditions, this causes more retransmissions and connection failures that offset any throughput gains.

The Fix: Choose PHY mode based on your environment and use case. Test in real conditions before deployment:

PHY selection guide:

Start with 1M PHY as the reliable baseline.
Use 2M PHY for close-range, high-throughput bursts such as OTA updates.
Use Coded PHY S=2 when range matters more than throughput.
Use Coded PHY S=8 for maximum range or difficult building penetration.
Implement fallback: try the faster PHY only when link quality is strong, then fall back to 1M if retransmissions or disconnects rise.

PHY Mode	Data Rate	Range	Power	Use Case
LE 1M	1 Mbps	~50m	Baseline	Default, balanced
LE 2M	2 Mbps	~30m	Slightly higher	High throughput, short range
LE Coded (S=2)	500 kbps	~100m	Lower	Extended range
LE Coded (S=8)	125 kbps	~200m	Lowest	Maximum range

5.9.1 Knowledge Check: Classic vs BLE Compatibility

5.9.2 Knowledge Check: BLE Power Calculation

5.9.3 Knowledge Check: BLE PHY Selection

Concept Check: Connection Interval vs Application Update Rate

Question: You’re designing a BLE temperature sensor that sends readings every 5 minutes. You set the connection interval to 5 minutes (300 seconds) to match the update rate. What will happen?

Choices:

A. The sensor will work perfectly with optimal power efficiency B. The BLE connection will fail because connection intervals are limited to 4 seconds maximum C. The sensor will drain the battery faster due to excessive connection overhead D. The smartphone will disconnect after 30 seconds of inactivity

Correct Answer: B

Explanation: BLE connection intervals are limited by the specification to 7.5 ms minimum and 4 seconds maximum. You cannot have a “5-minute connection interval.” The correct approach is to use a reasonable connection interval (100-500 ms for sensors) combined with peripheral latency (skip connection events when there’s no data) and send your sensor readings via GATT notifications at your desired application rate (5 minutes), independent of the radio’s connection timing. The connection interval is a radio scheduling parameter, not the same as your application’s data rate.

5.10 Worked Example: Hospital Patient Monitoring — Classic vs BLE Decision

Scenario: MedBridge Health equips a 400-bed hospital with wireless patient monitoring. Three device classes need Bluetooth connectivity, each with fundamentally different data patterns.

Device inventory:

Device	Count	Data Pattern	Payload	Interval	Battery Target
Bedside vital signs monitor	400	Continuous waveform (ECG)	250 bytes/packet	8 ms (125 Hz)	Mains powered
Wearable SpO2 sensor	600	Periodic readings	12 bytes	5 seconds	7 days (CR2032)
Asset tracking tag	2,000	Advertising beacon	31 bytes	2 seconds	12 months (CR2450)

Analysis — Device 1: Bedside ECG monitor (Classic Bluetooth)

Data rate: 250 bytes x 125 Hz = 31.25 KB/s continuous = 250 kbps
BLE maximum throughput (BLE 5.0, 2M PHY, DLE): ~1,400 kbps theoretical, ~500 kbps practical
BLE could handle the bandwidth, but continuous streaming at 125 Hz keeps the radio active constantly, negating BLE’s power advantage
Classic BR/EDR profile: SPP (Serial Port Profile) provides a clean serial pipe at 3 Mbps
Power: 35 mA average (irrelevant — device is mains-powered)
Decision: Classic Bluetooth. Continuous high-rate streaming is exactly what Classic was designed for. BLE’s power savings are irrelevant on mains power.

Analysis — Device 2: Wearable SpO2 sensor (BLE)

Data rate: 12 bytes every 5 seconds = 2.4 bytes/sec = 19.2 bps
Power budget for 7-day battery life on CR2032 (230 mAh):
- Available current: 230 mAh / (7 x 24 h) = 1.37 mA average
- Classic Bluetooth: 25-35 mA active (would drain CR2032 in 7-9 hours)
- BLE (connection interval 5 s, 1M PHY): radio on ~2.5 ms per event
- BLE average current: (15 mA x 2.5 ms + 1.5 uA x 4997.5 ms) / 5000 ms = 8.5 uA
- Battery life at 8.5 uA: 230,000 uAh / 8.5 uA = 27,058 hours = 1,127 days
- Add MCU + SpO2 sensor (~150 uA average): total ~158.5 uA = 60 days
Decision: BLE. Battery life is the constraint. Classic would require a 700 mAh rechargeable battery, adding cost, weight, and charging infrastructure for 600 sensors.

Analysis — Device 3: Asset tracking tag (BLE advertising only)

No connection needed — tags broadcast location beacons
BLE advertising: 31-byte payload every 2 seconds
Power per advertisement (3 channels, 1M PHY): ~15 mA x 3 x 1.2 ms = 54 uA-s per cycle
Average current: 54 uA-s / 2 s = 27 uA
CR2450 (620 mAh) at 27 uA: 620,000 / 27 = 22,963 hours = 957 days = 2.6 years
Classic Bluetooth inquiry scan: ~25 mA average = CR2450 lasts 25 hours (unusable)
Decision: BLE advertising-only. No connection overhead. Classic cannot beacon without active connections.

System architecture decision:

Device Class	Protocol	Radio	Profile/Service	Smartphone Gateway
ECG monitor	Classic BR/EDR	Dual-mode	SPP	No (bedside hub)
SpO2 sensor	BLE 5.0	Single-mode	Custom GATT	Yes (nurse phone)
Asset tag	BLE 5.0	Single-mode	Advertising only	No (fixed scanners)

Key insight: The hospital needs BOTH Classic and BLE — they are not interchangeable. Choosing the wrong variant for ECG would create unnecessary complexity (BLE connection management for streaming). Choosing Classic for asset tags would make the project physically impossible on coin cells. The 400 bedside hubs use dual-mode Bluetooth chips (EUR 3.20 each) so they can relay both ECG (Classic) and nearby SpO2 data (BLE) to the hospital network.

Interactive Quiz: Match Classic vs BLE Features

Interactive Quiz: Sequence the Bluetooth Variant Selection Process

Label the Diagram

Code Challenge

5.11 Summary

This chapter covered the fundamental differences between Classic Bluetooth and Bluetooth Low Energy:

Classic Bluetooth is designed for continuous streaming (audio, file transfer) with higher power consumption
BLE is optimized for intermittent, low-power sensor data with months to years of battery life
BLE is not backward compatible with Classic Bluetooth—they are separate protocols
Power calculations must account for radio startup time, not just TX current
MTU negotiation is essential for efficient large data transfers
PHY mode selection (1M, 2M, Coded) trades off speed, range, and reliability

Concept Relationships

Core Concept	Builds On	Enables	Common Confusion
BLE Duty Cycle	Radio sleep modes	Months-to-years battery life	Thinking BLE is “Classic on a diet”
Connection Interval (7.5ms-4s)	Link Layer timing	Radio event scheduling	Confusing with application data rate
MTU Negotiation	ATT protocol	Efficient large payload transfer	Assuming 23-byte default is enough
PHY Modes (1M/2M/Coded)	BLE 5.0 physical layer	Range vs throughput tradeoffs	Assuming 2M always improves performance
Advertising vs Connection	GAP roles	Power-optimal communication pattern	Keeping idle connections open wastes power

5.12 See Also

Bluetooth Fundamentals - BLE architecture and protocol overview
BLE Protocol Deep Dive - GATT services and characteristics
Connection Establishment - Connection parameters and intervals
Bluetooth Applications - Real-world BLE use cases
Bluetooth Implementation - ESP32 power optimization examples

5.13 What’s Next

Chapter	Topic	Why It Matters
Bluetooth Topologies	Piconet, scatternet, and Bluetooth Mesh network configurations	Understand how Classic and BLE devices organize into networks beyond point-to-point links
BLE Protocol Deep Dive	GATT services, characteristics, and the ATT protocol	Learn how BLE structures data for sensors and wearables using attribute-based data models
Connection Establishment	Advertising, scanning, and connection parameter negotiation	Master the handshake process that determines power efficiency and latency
Bluetooth Applications	Healthcare, retail beacons, industrial monitoring, and smart home use cases	See how variant selection decisions play out in production IoT deployments
Bluetooth Implementation	ESP32 BLE code, power profiling, and PHY configuration	Apply Classic vs BLE knowledge in firmware with real measurement tools