3 How Bluetooth Works: Classic vs BLE
Understanding Bluetooth Classic vs BLE for IoT Applications
bluetooth, ble, bluetooth low energy, wireless, iot, frequency hopping, 2.4ghz, piconet
3.1 Start With the Story
A small sensor can behave like a chatty audio link, a sleepy beacon, or a connected GATT device. Those are not cosmetic choices; they decide battery life, latency, throughput, discovery, and what a gateway can trust.
Use this chapter to slow Bluetooth down into its moving parts. Follow advertising, scanning, roles, channels, connections, and services until the design choice can be explained as an operating tradeoff rather than a checkbox.
Phoebe’s Why
A radio wave’s speed, frequency, and wavelength are locked together: \(c = f\lambda\). Pick a frequency and the wavelength – and the antenna length that resonates with it – is fixed. That matters for a frequency-hopping radio because Classic Bluetooth retunes its carrier roughly 1,600 times a second across 79 channels, and BLE hops across 37 data channels after connecting. If wavelength shifted meaningfully hop to hop, the antenna would need to retune with it. It does not, because the whole 2.4 GHz ISM band this chapter’s radio hops across is a narrow sliver next to its own center frequency – so one fixed chip or PCB antenna covers every channel, and the free-space loss barely changes hop to hop either. That is why Adaptive Frequency Hopping exists to dodge busy channels, not lossy ones: physics does not hand AFH a systematically clearer channel to hop to.
The Derivation
The speed lock:
\[\lambda = \frac{c}{f}\]
Quarter-wave resonant length, the common chip/PCB antenna target:
\[\ell_{\lambda/4} = \frac{\lambda}{4}\]
Free-space path loss at a fixed distance \(d\) (spherical spreading into an aperture, as derived for the wave-fundamentals chapter):
\[\mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
Comparing two channels at the same distance, the distance cancels and only the frequency ratio survives:
\[\Delta\mathrm{FSPL}_{dB} = 20\log_{10}\frac{f_{high}}{f_{low}}\]
Worked Numbers: This Chapter’s Own Hopping Map
- Band edges, from this chapter’s own channel plan (Classic 79 \(\times\) 1 MHz spanning 2402-2480 MHz): \(\lambda_{2402} = 3.00\times10^{8}/2.402\times10^{9} = 124.9\) mm; \(\lambda_{2480} = 120.97\) mm – the whole hopping map spans only \(3.20\%\) of the 2440 MHz center frequency.
- Antenna length across the hop set: quarter-wave at 2402 MHz is \(124.9/4 = 31.2\) mm; at 2480 MHz it is \(120.97/4 = 30.2\) mm – a \(0.982\) mm difference across all 79 Classic channels, well inside the bandwidth of any real chip antenna, which is why one fixed antenna serves every hop without retuning.
- Path-loss delta across the same 78 MHz span, at a 10 m BLE-range check: \(\mathrm{FSPL}_{2402}=20\log_{10}(4\pi\times10/0.1249) = 60.05\) dB; \(\mathrm{FSPL}_{2480}=60.33\) dB – a difference of only \(0.278\) dB, matching \(20\log_{10}(2480/2402)=0.278\) dB from the ratio form.
- What that confirms: 0.278 dB is far below what a receiver can even distinguish from noise-floor jitter, so hopping across this chapter’s 79 (or BLE’s 40) channels never trades meaningful range for a “better” channel – it only trades exposure to whatever Wi-Fi, Zigbee, or microwave energy happens to be sitting on that 1-2 MHz slice right now, which is exactly the busy-channel-avoidance job this chapter assigns to AFH.
3.2 Bluetooth Fundamentals for IoT
Bluetooth fundamentals start with a choice between behaviors, not with a logo. Classic Bluetooth is usually reviewed for sustained streams and established compatibility profiles. Bluetooth Low Energy is usually reviewed for short, duty-cycled exchanges such as sensor reports, beacons, phone-based setup, and small control messages. Bluetooth Mesh is reviewed as a managed many-node control pattern, not as a simple extension of one phone connection.
The important beginner idea is that “Bluetooth works” is not one claim. Discovery, pairing, connection setup, GATT service behavior, notification timing, power draw, privacy, phone compatibility, and recovery after failure are separate pieces of evidence.
Radio Remi
“Range, power, and data-rate is a triangle — pick two honestly, then measure the third in the real room.”
Through this chapter, Remi tags each Bluetooth behavior with its band, its trade, and the room measurement that proves it.
Worked example: a reusable shipping logger needs to wake every few minutes, advertise that it is nearby, let a phone read the last temperature excursion, and then sleep again. That job points toward BLE because the exchanged values are small and the radio can be scheduled around short discovery and GATT transactions. The evidence record still needs the actual service, characteristic, read or notification behavior, phone permission state, sleep behavior, and failed-setup recovery. A headset audio stream, by contrast, is a different Bluetooth behavior with different profile, timing, and power evidence.
The same product might use more than one boundary. During warehouse commissioning, a phone may connect as a central and write configuration. During transport, gateways may only observe advertisements. During service, a technician may connect and read diagnostics. Calling all three cases “BLE support” hides the review questions. A useful fundamentals review names which behavior is being approved, what peer is involved, what data moves, and what retest trigger would make the evidence stale.
If you only need the intuition, this layer is enough: use Classic Bluetooth for sustained compatibility streams, BLE for small local IoT exchanges that can sleep between radio events, and mesh only when the provisioning, relay, security, and operations model are explicitly reviewed.
3.2.1 The Fundamental Choice
Review continuous connection behavior, audio or legacy profile fit, controller support, and whether the product can tolerate the active-link power model.
Review advertising, scanning, connection intervals, GATT services, characteristics, notifications, writes, and sleep behavior for the real device.
Profiles, services, permissions, characteristic properties, and app or gateway mapping define what the bytes mean.
Approve only the tested phones, firmware, enclosure, radio environment, security flow, battery target, and recovery behavior.
3.2.2 Common Beginner Distinctions
- Advertising proves visibility; it does not prove connected data exchange.
- A connection proves link setup; it does not prove the correct service, characteristic, permission, or application value.
- A BLE label suggests low-power design potential; it does not prove the actual duty cycle or battery life.
- A phone demo is useful evidence, but it should stay bounded to the tested phone, operating system, app permissions, firmware, and recovery path.
3.2.3 Overview Knowledge Check
3.3 Build the Bluetooth Fundamentals Record
A practical Bluetooth fundamentals record explains why the chosen Bluetooth behavior fits the IoT job. It should show the device role, traffic pattern, receiver population, service model, timing, security ceremony, power expectation, and retest trigger. This keeps design review from sliding between Classic, BLE, advertising, connection, GATT, mesh, and gateway claims.
Use this record early. Before writing firmware, it catches mismatches such as selecting BLE for sustained high-rate traffic, using a beacon when the app needs acknowledged commands, or assuming a phone setup flow works across every phone and permission state.
3.3.1 Worked Review: BLE Sensor Reporting
A battery sensor sends a small reading to a phone app. The record should approve only the tested reporting workflow: the device is a BLE peripheral, the phone acts as central, the service and characteristic are known, the value format is documented, notification or read behavior is tested, pairing or authorization is defined, and reconnection after phone absence is observed.
Power approval needs its own evidence. The review should record the advertising schedule, connection behavior, payload size, sleep state, failed-connection recovery, and the device conditions that require retest.
3.3.2 Worked Review: Setup-Only BLE
A product may use BLE only for commissioning before it joins Wi-Fi, Thread, cellular, or another network. That is a setup workflow, not proof that BLE is the product data network. Review who can discover the setup mode, how the product proves ownership, how credentials are protected, what timeout ends setup mode, and how the device recovers from a failed or interrupted setup.
3.3.3 Practitioner Knowledge Check
3.4 Radio, Link, GATT, and Operations Boundaries
Bluetooth behavior moves through several evidence boundaries. A device may be visible during advertising, connect as the expected role, expose services through GATT, exchange an application value, and then recover after disconnection. Each boundary can pass or fail independently.
That separation matters because the fix changes by boundary. A scan problem may involve advertising interval, phone permissions, or RF placement. A read problem may involve pairing, service discovery, characteristic properties, or app mapping. A power problem may involve connection interval, retry behavior, sleep state, or a failed reconnection loop.
3.4.1 Diagnosis Pattern
- Keep the symptom narrow. Decide whether the failure is discovery, connection, pairing, GATT access, notification timing, application meaning, power, or recovery.
- Preserve known-good lower evidence. If the phone can discover the device, do not erase that evidence while debugging GATT access.
- Change one boundary at a time. Phone OS, app permission, firmware, enclosure, antenna, connection schedule, and service schema changes should be tested separately.
- Record what remains unproven. A lab phone and one firmware build do not prove all phones, all sites, all batteries, or all ownership transitions.
3.4.2 Under-the-Hood Knowledge Check
3.5 BLE Advertising & Scanning Game
3.6 How Bluetooth Works: Radio, Channels, and Piconets
Behind the discovery-and-GATT behavior above sits a specific radio design. The title’s promise — how Bluetooth actually works — comes down to three ideas: the 2.4 GHz band, frequency hopping, and the piconet.
The 2.4 GHz ISM band, split into channels. Classic and BLE share the crowded 2.4 GHz band with Wi-Fi, Zigbee, and microwaves. Classic Bluetooth divides it into 79 channels of 1 MHz; BLE uses 40 channels of 2 MHz — of which 3 are advertising channels (37, 38, 39, deliberately spaced to dodge the busiest Wi-Fi channels) and 37 are data channels.
Frequency hopping spread spectrum (FHSS). Rather than sitting on one channel, Bluetooth hops. Classic hops ~1,600 times per second across its 79 channels, following a sequence derived from the master’s clock and address. A burst of interference on one channel only corrupts the packets that happened to land there, and the link continues on the next hop. Modern devices use Adaptive Frequency Hopping (AFH), which detects busy channels (an active Wi-Fi network, say) and drops them from the hopping map — this is why Bluetooth and Wi-Fi coexist on the same band. BLE hops across its 37 data channels once connected, using a hop increment agreed at connection setup.
Remi’s Signal Check
- Band: 2.4 GHz ISM — Classic: 79 × 1 MHz channels; BLE: 40 × 2 MHz, three for advertising.
- Trade: ~1,600 hops a second ride out interference bursts; AFH drops Wi-Fi-busy channels.
- Room test: map the site’s active Wi-Fi channels — AFH needs clean channels left to hop to.
Classic Bluetooth’s physical layer uses Gaussian frequency-shift keying at the basic 1 Mbps rate, with enhanced data-rate modes using phase-shift keying for 2 and 3 Mbps payloads. The carrier does not hop during one frame; packets occupy one, three, or five 625 microsecond slots before the link moves on in the hopping sequence. A basic-rate packet carries an access code and header before the payload, with CRC and whitening used to detect errors and avoid long runs of identical bits.
Classic packet review can count those fields before making a throughput claim. The access code is built from a short preamble, a 64-bit sync word, and sometimes a trailer; channel, device, and inquiry access codes tell the receiver whether the packet belongs to the piconet, a specific device exchange, or inquiry behavior. The sync word is derived from the lower address part, with the general inquiry LAP 0x9E8B33 reserved for discovery. The basic-rate header carries the active-member address, packet type, flow, acknowledgment, sequence, and header-error-check fields; it is protected separately from the payload. Forward error correction may repeat or encode bits to improve robustness, but it also consumes airtime, so a payload that looks small in bytes can take extra slots, polls, and retransmissions on a 625 microsecond schedule.
The piconet. A Bluetooth connection is organized as a piconet: one device is the master (BLE calls it the central) and owns the clock and hopping sequence; up to seven active slaves (BLE: peripherals) synchronize to it and hop in lockstep. In BLE, a peripheral first advertises on the three advertising channels; a scanning central hears it and opens the connection, after which both follow the shared data-channel hop sequence.
In Classic scatternets, a bridge device can participate in more than one piconet by taking different roles at different times, such as slave in one piconet and master in another. That does not create arbitrary peer-to-peer traffic. Each piconet still has its own clock, hop sequence, polling behavior, and active-member limit, so bridge behavior belongs in the capacity and latency evidence.
Stack and version landmarks. Baseband handles physical channels, hop selection, packets, paging, inquiry, and synchronous or asynchronous links. L2CAP sits above it for logical-channel multiplexing, segmentation and reassembly, and group abstractions; RFCOMM builds a reliable virtual serial stream over that stack for Classic serial-style profiles. Historically, Bluetooth v1.2 established the stable early Classic baseline, v2.1 + EDR added Secure Simple Pairing and higher practical rates, v3.0 + HS used Bluetooth for setup while routing high-speed data over 802.11 when the +HS feature was actually present, and v4.0 separated Classic, high-speed, and Bluetooth Low Energy behavior.
BLE changes the link setup vocabulary. A peripheral advertises periodically, often somewhere between tens of milliseconds and several seconds depending on power and discovery needs. The common advertising packet types are ADV_IND for general connectable advertising, ADV_DIRECT_IND for a directed connection attempt, ADV_NONCONN_IND for broadcast-only information, and ADV_SCAN_IND when scan responses may add more data. Once connected, the peers agree on an access address, hop increment, channel map, and connection timing; private addressing and identity keys can keep the product from being tracked by a fixed radio address.
Bluetooth 5 added PHY choices that should be named in design evidence: LE 1M, LE 2M, and LE Coded. LE Coded uses redundancy for range, commonly described as S=2 around 500 kbit/s or S=8 around 125 kbit/s, while leaving the preamble and access-address handling visible as lower-layer evidence. The trade is deliberate: coded packets can survive weaker links, but the extra symbols stretch airtime and can reduce throughput or battery life if the product only needed a short-range link.
Remi’s Signal Check
- Band: same 2.4 GHz band, three BLE PHYs — LE 1M, LE 2M, LE Coded.
- Trade: Coded redundancy buys range — S=2 ~500 kbit/s, S=8 ~125 — and pays in airtime and battery.
- Room test: measure throughput and battery at the real mounting distance before approving Coded.
LE Coded packets still start with the ordinary synchronization evidence, but their coded portion adds a coding indicator and terminator fields so the receiver knows whether the remaining packet uses the S=2 or S=8 pattern. Bluetooth 5.1 added a different kind of physical-layer evidence for positioning: direction finding can use a Constant Tone Extension after the CRC so an antenna array can compare phase across antennas. That can support angle-of-arrival or angle-of-departure estimates, but it needs controlled antenna switching, calibration, and interference review; a raw phase or range claim is not enough release evidence.
Why BLE is low-power. The advertise-then-connect model, tiny packets, and long sleep intervals mean the radio is off most of the time — the battery-life evidence the review sections above check is a direct consequence of this radio design.
Remi’s Signal Check
- Band: advertising uses three of 40 channels, repeating between tens of milliseconds and several seconds.
- Trade: tiny packets and long sleeps keep the radio off — battery bought with discovery latency.
- Room test: log the real advertising interval and sleep state; that is the battery evidence.
3.7 Summary
- Bluetooth fundamentals review starts by naming the behavior: Classic stream, BLE advertising, BLE connection, GATT exchange, setup workflow, gateway handoff, or mesh control.
- BLE supports low-power IoT designs when the actual advertising, connection, payload, sleep, retry, and recovery behavior fit the product goal.
- Discovery, connection, GATT access, application meaning, security, power, and operations are separate evidence boundaries.
- A useful design record names the role, receiver population, service model, timing, trust flow, recovery path, and retest trigger.
- Approvals should stay bounded to the tested phones, firmware, enclosure, radio environment, application version, and ownership workflow.
3.8 Key Takeaway
Choose Bluetooth for IoT only when the reviewed mode, role, service model, timing, trust flow, power behavior, receiver scope, and recovery path match the product job.
3.9 See Also
Review the broader Bluetooth fit decision across Classic, BLE, roles, profiles, security, and operations.
Follow services, characteristics, permissions, notifications, indications, and GATT evidence in detail.
Review advertising, scanning, connection setup, pairing, bonding, parameters, and reconnection behavior.
Connect Bluetooth profile and service choices to interoperability, application meaning, and evidence records.