5 Classic vs Low Energy (BLE)
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.
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.
5.5 Detailed Technical Comparison
5.6 Wireless Technology Comparison
| Feature | Bluetooth Classic | Bluetooth 4.0 Low Energy (BLE) | Zigbee | Wi-Fi |
|---|---|---|---|---|
| IEEE Standard | 802.15.1 | 802.15.1 | 802.15.4 | 802.11 (a, b, g, n) |
| Frequency (GHz) | 2.4 | 2.4 | 0.868, 0.915, 2.4 | 2.4 and 5 |
| Maximum raw bit rate (Mbps) | 1-3 | 1 | 0.250 | 11 (b), 54 (g), 600 (n) |
| Typical data throughput (Mbps) | 0.7-2.1 | 0.27 | 0.2 | 7 (b), 25 (g), 150 (n) |
| Maximum (Outdoor) Range (Meters) | 10 (class 2), 100 (class 1) | 50 | 10-100 | 100-250 |
| Relative Power Consumption | Medium | Very low | Very low | High |
| Example Battery Life | Days | Months to years | Months to years | Hours |
| Network Size | 7 | Undefined | 64,000+ | 255 |
| 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:
// Correct approach: connection params for power efficiency
ble_gap_conn_params_t conn_params = {
.min_conn_interval = 80, // 100ms (80 * 1.25ms)
.max_conn_interval = 160, // 200ms
.slave_latency = 4, // Skip up to 4 events when idle
.conn_sup_timeout = 400 // 4 second timeout
};
// Application sends data at its own rate
void sensor_timer_callback() {
// Triggered every 5 minutes by app timer
send_temperature_notification(read_sensor());
}
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:
Actual power per BLE event:
- Radio startup/calibration: 1.5ms @ 12mA = 18 uAs
- TX packet (31 bytes): 0.3ms @ 15mA = 4.5 uAs
- RX window (if connected): 1.0ms @ 12mA = 12 uAs
- Post-processing: 0.5ms @ 5mA = 2.5 uAs
----------------------------------------
Total per event: 3.3ms = 37 uAs
Common mistake calculation: 0.3ms TX only = 4.5 uAs
Actual vs estimated: 8x difference!
For 1-second advertising (3 channels):
- Naive estimate: 3 x 4.5 uAs = 13.5 uAs/s = 48.6 uAh
- Real consumption: 3 x 37 uAs = 111 uAs/s = 400 uAhAlways 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:
// Central (phone/gateway) initiates MTU exchange after connection
void on_ble_connected(uint16_t conn_handle) {
// Request maximum MTU supported by this stack (e.g., 247 or 512 bytes)
ble_gattc_mtu_exchange_request(conn_handle, 247);
}
void on_mtu_exchanged(uint16_t conn_handle, uint16_t negotiated_mtu) {
// Both sides agree on minimum of requested MTUs
// Usable payload = negotiated_mtu - 3 (ATT header)
uint16_t max_payload = negotiated_mtu - 3; // e.g., 244 bytes
// Now can send larger chunks efficiently
log_info("MTU negotiated: %d bytes, payload: %d bytes",
negotiated_mtu, max_payload);
}
// Throughput impact example (200-byte sensor reading):
// Default MTU (23): 10 packets x 3.3ms = 33ms, 10x radio events
// MTU 247: 1 packet x 4.5ms = 4.5ms, 1x radio event
// Power savings: ~7x fewer radio wake-ups for same data
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 analysis for 5-minute sensor reporting:
OPTION A: Persistent Connection
- Connection interval: 4s (max allowed)
- Peripheral latency: 4 (skip 4 events when idle)
- Effective event rate: 4s x 5 = every 20s minimum
- Events per 5 minutes: 15 events
- Power per event (idle): ~25 uAs (wake + RX + sleep)
- Total: 15 x 25 = 375 uAs per 5 minutes
OPTION B: Advertising + Reconnect
- Advertising interval: 1000ms
- Advertising power: ~3 uAs average
- Time advertising before reconnect: ~2-3 seconds typical
- Connection + data exchange: ~100 uAs
- Total: 3 uAs x 3s + 100 uAs = ~109 uAs per 5 minutes
Recommendation:
- Data interval < 30 seconds: Use persistent connection
- Data interval 30s - 2 min: Test both approaches
- Data interval > 2 minutes: Consider advertising mode
- Data on external trigger: Use advertising (unpredictable timing)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:
1M PHY (default):
- Sensitivity: -96 dBm typical
- Range: Baseline (10-50m indoor)
- Use case: General purpose, reliable default
2M PHY (speed):
- Sensitivity: -90 dBm typical (6dB worse)
- Range: ~60% of 1M PHY
- Use case: High throughput in good RF (OTA updates, close range)
- Power: Similar per-bit, but transfers complete faster
Coded PHY S=2 (range):
- Sensitivity: -103 dBm typical (7dB better than 1M)
- Range: ~2x of 1M PHY
- Throughput: 500 kbps (half of 1M)
- Use case: Long-range sensors, outdoor deployments
Coded PHY S=8 (maximum range):
- Sensitivity: -107 dBm typical (11dB better than 1M)
- Range: ~4x of 1M PHY
- Throughput: 125 kbps (1/8 of 1M)
- Use case: Extreme range, building penetration
Best practice:
- Start with 1M PHY as baseline
- Use 2M PHY only for short-range, high-throughput scenarios
- Use Coded PHY when range is the priority
- Implement PHY fallback: try 2M, fall back to 1M if connection unstable| 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
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.
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 |