Bluetooth & BLE · Study deck

BLE Field Debugging and Internals

Picture a sensor that pairs on the bench but stops sending updates after it is installed behind a cabinet.

Radio Remi is your guide for this deck.

fielddebugging

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: The mathematical gist.: With a 100 ms interval, 500 µs transmit burst at 15 mA, and 5 µA sleep current, the radio averages 0.0800 mA and a 225 mAh cell gives about 117 days.
Explain: The field failure rarely says "Bluetooth is broken." It says notifications stopped, the battery collapsed, the MTU was too small, the connection interval drifted, or the lab trace no longer matches the installed device.
Explain: Each war story ends with the evidence that would have caught it — and the internals section explains what the stack was doing all along.

Major section

When the Lab Meets the Field

A green connection icon does not show where the data stopped.

Bluetooth Low Energy is a short-range radio system designed for small data exchanges and low power; it is shortened to BLE.
Everything in Building BLE Apps on ESP32 works on the bench.
This chapter is about the day it does not: notifications that never arrive, connections that eat the battery, payloads that silently truncate.
Each war story ends with the evidence that would have caught it — and the internals section explains what the stack was doing all along.

Try it: When the Lab Meets the Field in the chapter

Major section

Phoebe's Field Notes: The mAh-to-Runtime Chain, and Where It Sags

The mathematical gist.: With a 100 ms interval, 500 µs transmit burst at 15 mA, and 5 µA sleep current, the radio averages 0.0800 mA and a 225 mAh cell gives about 117 days.

A missed shutdown that leaves 8 mA in “sleep” raises the average to 8.04 mA and cuts that estimate to 1.17 days.

Major section

When It Breaks in the Field

Most BLE bugs are not random.

They come from a mismatch between what the code assumes and what the protocol actually agreed to do.
Problem: Code connects to BLE device but doesn't receive updates.
Cause: Notifications require writing to CCCD descriptor.
Problem: Battery drains quickly or response is too slow.

Major section

Start With the Story

Reproduce one symptom, capture the radio and application evidence, change one variable, and keep the smallest explanation that makes the deployed behavior understandable.

Cause: Default MTU is only 23 bytes (20 payload).
Key Insight: The 23-byte default MTU is a BLE legacy constraint.
ESP32's Bluedroid BLE stack requires ~120 kB RAM; NimBLE requires only ~40 kB.

Major section

Start With the Story (continued)

BLE event handlers (NimBLE ble_hs_cfg.sync_cb, gap_event_cb) run in the NimBLE host task context.

The field failure rarely says "Bluetooth is broken." It says notifications stopped, the battery collapsed, the MTU was too small, the connection interval drifted, or the lab trace no longer matches the installed device.
If you forget, your application will work fine until you exceed 20 bytes, then fail mysteriously.
Not every field failure is a notification, interval, or MTU bug.

Major section

Start With the Story (continued)

This often manifests as "missing bytes" or "corrupted readings" that work fine in testing with short payloads but fail in production with full data.

Developers test with simple sensor values (2-4 bytes) that fit easily, then add more features (timestamps, multiple readings, metadata) pushing total payload to 30-50 bytes without realizing MTU negotiation is required.
For IoT sensor projects that only need BLE (no Classic Bluetooth), using Bluedroid wastes 80 kB of RAM that could be used for application buffers.
Setting BLE_SM_IO_CAP_NO_INPUT_NO_OUTPUT (Just Works pairing) for a device that stores sensitive user data provides zero MITM protection.

Major section

Start With the Story (continued)

Just Works pairing generates an unauthenticated LTK that any BLE central can establish without user confirmation.

For devices handling health, financial, or access-control data, require at minimum Passkey Entry (IO_CAP_DISP_ONLY or IO_CAP_KEYBOARD_ONLY) with MITM protection flag.
When these failures are under control, the build starts looking like a product rather than a lab.
The closing sections keep the same ideas but ask the production questions: power, security, evidence, and what to study next.

Major section

Under the Hood: Parameters, Payloads, and Internals

The connection-interval mistake above is not only a battery problem; it is a parameter-coupling problem.

A demo that connects once does not prove latency, battery, or recovery claims.
The ordered evidence connects radio setup to the timeout bounds calculated next.

BLE connection flow from advertising through scan request, scan response, connection indication, connected GATT data exchange, and connection parameter bounds.

Deck summary

Key takeaways

A green connection icon does not show where the data stopped.

The mathematical gist.: With a 100 ms interval, 500 µs transmit burst at 15 mA, and 5 µA sleep current, the radio averages 0.0800 mA and a 225 mAh cell gives about 117 days.
Most BLE bugs are not random.
Reproduce one symptom, capture the radio and application evidence, change one variable, and keep the smallest explanation that makes the deployed behavior understandable.
BLE event handlers (NimBLE ble_hs_cfg.sync_cb, gap_event_cb) run in the NimBLE host task context.

Retrieval practice

Recall check 1 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q1Per this chapter's 'notifications never arrive' war story, why does calling characteristic.read() once fail to deliver ongoing updates?

ANotifications require writing to the CCCD descriptor (0x2902) to enable them; a single read() only fetches the value once and never turns on the notify stream

BThe characteristic must instead be polled with read() every 100ms in a loop

CBLE peripherals only ever send one value per connection by design

DThe MTU must first be increased to 247 bytes before any notification can arrive

Show answer

Answer: A

Retrieval practice

Recall check 2 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q2Per this chapter's 'connection interval mismatch' war story, why can battery drain quickly or response feel sluggish when a device is left on the default connection interval?

AThe interval wasn't tailored to the application: a short interval such as 7.5-15 ms suits a game controller's fast response needs, while a much longer interval like 1000-4000 ms suits a temperature sensor that reports rarely

BA temperature sensor needs a 7.5-15 ms interval while a game controller can tolerate 1000-4000 ms

CConnection interval only affects how fast the UI updates, not battery consumption

DThe fix is to disable notifications entirely until the interval issue is resolved

Show answer

Answer: A

Retrieval practice

Recall check 3 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q3What is the default BLE MTU size and why does it matter for IoT data transfer?

A256 bytes, which is sufficient for most sensor data

B23 bytes, leaving about 20 bytes for payload

C512 bytes, matching the maximum BLE packet size

D64 bytes, which requires fragmentation for sensor readings

Show answer

Answer: B Correct!

Q4Your office has 50 Wi-Fi networks on 2.4GHz and 20 BLE sensors. Users report intermittent sensor disconnections. What's the best mitigation?

ASwitch BLE sensors to 5GHz band

BIncrease BLE advertising power

CReduce number of sensors to 5

DEnable Adaptive Frequency Hopping

Show answer

Answer: D Adaptive Frequency Hopping (AFH) is Bluetooth's built-in coexistence mechanism.

Retrieval practice

Recall check 4 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q5This chapter's rule is supervision_timeout > (1 + peripheral_latency) x connection_interval x 2. For a connection with a 1 s interval and peripheral latency of 9, what does the chapter say about using a 10 s supervision timeout?

AIt's invalid -- the rule requires the timeout to exceed 20 s ((1+9) x 1s x 2) for that latency, so a 10 s timeout detects loss sooner but is invalid

BIt's valid, because 10 s already exceeds the 1 s connection interval by a comfortable margin

CIt's valid because the 300 ms bound from the earlier example is much shorter than 10 s, leaving enough time for several missed events before the connection is declared lost

DIt's valid, because peripheral latency only affects battery life, not the supervision timeout bound

Show answer

Answer: A The chapter's formula is supervision_timeout > (1 + peripheral_latency) x connection_interval x 2.

Print reference

Answers

Answer key.

A
A
B · Correct!
D · Adaptive Frequency Hopping (AFH) is Bluetooth's built-in coexistence mechanism.
A · The chapter's formula is supervision_timeout > (1 + peripheral_latency) x connection_interval x 2.