900 Classic Bluetooth vs Bluetooth Low Energy
900.1 Learning Objectives
By the end of this chapter, you will be able to:
- Understand the fundamental differences between Classic Bluetooth (BR/EDR) and Bluetooth Low Energy (BLE)
- Calculate power consumption for different advertising and connection configurations
- Choose the right Bluetooth variant based on application requirements
- Avoid common pitfalls when designing BLE-based IoT devices
900.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
900.3 The Evolution of Bluetooth
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.
900.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, primarily for voice headsets and file transfer
- 2004: Bluetooth 2.0 + EDR (Enhanced Data Rate) boosted speeds to 3 Mbps
- 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, different packet formats, and different connection procedures
- 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 |
900.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)
900.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!
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.
900.5 Detailed Technical Comparison
900.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 |
900.7 Common Pitfalls
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());
}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.
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 dataThe 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)900.8 BLE vs Wi-Fi vs Zigbee: Choosing the Right Protocol
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.
900.9 BLE PHY Modes (Bluetooth 5.0+)
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 |
900.10 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
900.11 What’s Next
The next chapter, Bluetooth Topologies, explores the different network configurations available in Bluetooth—from simple star topologies and broadcast beacons to complex mesh networks for building automation.