Bluetooth & BLE · Study deck
BLE App Development on ESP32
Picture a room sensor that appears in a scan but sends an old temperature after reconnecting.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A phone is usually the central because it has the screen, the app, and the power budget to search for nearby devices, and in connected GATT examples it usually behaves as the client.
- Explain: This nearby-device scanning is signal-strength proximity analysis in miniature, and it lets you see that BLE is not magic; it is a stream of short radio messages with measurable signal strength.
- Explain: That ordered discovery connects the scanner exercise to the code below: the ESP32 becomes ESP32-TempSensor, but interoperability comes from the standard service contract rather than the device name.
Major section
Start With the Story
Seeing the device is only the first step.
- The app must show which value it read, when it changed, and why it is current.
- Bluetooth Low Energy, or BLE, is a short-range radio system designed for small exchanges and low power.
- Firmware means the software stored on the board.
Major section
The BLE Idea
Each lab below stops at a different observable boundary on that path.
- The sequence becomes the chapter's running checklist for proving each step.
- The default BLE MTU is only 23 bytes.
Major section
Phoebe's Field Notes: Where n=2.5 Comes From, And Why It Is Not n=2
The mathematical gist.: The chapter’s d=10^((TxPower−RSSI)/10n) gives 3.98 m for −59/−74 dBm at n=2.5, but 5.62 m at free-space n=2.
- The device that advertises is the peripheral.
Major section
Phoebe's Field Notes: Where n=2.5 Comes From, And Why It Is Not n=2 (continued)
The remote sends command messages through a BluetoothSocket.
- In our build, the ESP32 becomes a peripheral when it behaves like a temperature sensor or an iBeacon, and in connected GATT examples it is also the server.
- The device that scans or connects is the central.
- A successful socket connection is therefore not proof that the actuator path is correct.
Major section
Phoebe's Field Notes: Where n=2.5 Comes From, And Why It Is Not n=2 (continued)
One source-era Classic Bluetooth remote-control design makes the connected roles concrete without pretending that its socket API is GATT.
- The receiver listens with a BluetoothServerSocket, accepts a BluetoothSocket, parses each message, and dispatches the result to a GpioProcessor that owns the hardware action.
- GATT is BLE's way to organize connected data.
- The value in that characteristic is the live reading.
Major section
Phoebe's Field Notes: Where n=2.5 Comes From, And Why It Is Not n=2 (continued)
A temperature sensor might have an Environmental Sensing service, and inside it a Temperature characteristic.
- The properties on a characteristic say what a central may do.
- We start by listening before we transmit, because the fastest way to understand BLE advertising is to watch real advertisements arrive.
- A phone is usually the central because it has the screen, the app, and the power budget to search for nearby devices, and in connected GATT examples it usually behaves as the client.
Major section
Build the BLE Sensor, Step by Step
This section is one continuous build.
- This nearby-device scanning is signal-strength proximity analysis in miniature, and it lets you see that BLE is not magic; it is a stream of short radio messages with measurable signal strength.
- RSSI-based distance estimation is approximate.
- The characteristic UUID 2A6E says the value is temperature.
Major section
Build the BLE Sensor, Step by Step (continued)
The important path is BLEDevice::init(), then BLEDevice::getScan(), then a callback that runs for each BLEAdvertisedDevice.
- Checkpoint: you should now see scan results in the Serial Monitor.
- The service UUID 181A tells generic BLE tools that this is Environmental Sensing data.
- RSSI is the measured signal strength at the receiver.
Major section
Build the BLE Sensor, Step by Step (continued)
That ordered discovery connects the scanner exercise to the code below: the ESP32 becomes ESP32-TempSensor, but interoperability comes from the standard service contract rather than the device name.
- PROPERTY_READ supports polling, while PROPERTY_NOTIFY supports real-time updates after the client enables notifications.
- The temperature is packed as an int16_t in 0.01 C units, so 22.50 C travels as 2250.
- Checkpoint: you should now have an ESP32 that broadcasts an iBeacon frame.
Major section
Build the BLE Sensor, Step by Step (continued)
Checkpoint: you should now be able to discover ESP32-TempSensor, find service 0x181A, read characteristic 0x2A6E, and receive changing notifications once the client writes the CCCD.
- Unlike the connected GATT example, receivers must interpret this advertisement without negotiating a service contract.
- UUID identifies the deployment namespace, Major and Minor subdivide it, and TX Power supports a rough RSSI-based distance estimate.
- Quick self-tests for what you just built.
Major section
Build the BLE Sensor, Step by Step (continued)
This layout connects the connected sensor build to a connectionless pattern: the phone can classify nearby beacons, but payload meaning, calibration, privacy, and authenticity must be designed in advance.
- The worked example below runs two actual measurements through the formula — open it to see why exact distances wobble and why the zone labels are the trustworthy part.
- The path loss equation shows how RSSI translates to distance, though environmental factors add significant error.
- A scanner should be able to see the UUID, major value, minor value, and calibrated signal power, then estimate distance from RSSI with visible uncertainty.
Major section
Build the BLE Sensor, Step by Step (continued)
But human body blockage can shift RSSI by ±8 dBm, making the same beacon appear 2m to 15m away—why zone-based proximity (near/medium/far) is more reliable than exact distance.
- After the scanner, temperature service, and beacon all work, the next useful move is practice.
- These challenges keep the same code path but ask you to change one design decision at a time.
- Track how many devices are in each proximity zone and display a summary after each scan.
- The hierarchy matters because a characteristic only has application meaning inside an agreed service, UUID, encoding, properties, and access policy.
Deck summary
Key takeaways
Seeing the device is only the first step.
- Each lab below stops at a different observable boundary on that path.
- The mathematical gist.: The chapter’s d=10^((TxPower−RSSI)/10n) gives 3.98 m for −59/−74 dBm at n=2.5, but 5.62 m at free-space n=2.
- The remote sends command messages through a BluetoothSocket.
- One source-era Classic Bluetooth remote-control design makes the connected roles concrete without pretending that its socket API is GATT.
Retrieval practice
Recall check 1 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q1A GATT characteristic is configured with PROPERTY_NOTIFY, but a connected client never receives updates. What is the most likely cause?
Show answer
Answer: B BLE notifications are opt-in: the client must explicitly write 0x0001 to the CCCD (UUID 0x2902) before the server sends any notify packets.
Retrieval practice
Recall check 2 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q2In an iBeacon deployment for indoor positioning, what does the 'Signal Power' calibration value represent?
Show answer
Answer: B Correct!
Q3Place each BLE implementation layer where it lives so you can trace an application action down to the controller without mixing host and radio responsibilities.
Show answer
Answer: A Separate application intent, host-side BLE services, and controller execution so you can locate an implementation fault at the right boundary.
Retrieval practice
Recall check 3 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q4A BLE implementation works once in a demo. What evidence is still needed before accepting the design?
Show answer
Answer: B BLE implementation review needs observable behavior, not just a one-time demo result.
Retrieval practice
Recall check 4 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q5How does BLE achieve low power consumption?
Show answer
Answer: D BLE achieves ultra-low power through multiple techniques: connection intervals (device sleeps between transmissions), fast connection (6ms vs 6 seconds), simpler modulation (GFSK), fewer channels (40 vs 79), optimized protocol stack, and role separation (Broadcaster, Observer, Peripheral, Central).
Retrieval practice
Recall check 5 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q6Your BLE temperature sensor advertises every 1 second. After deployment, you notice smartphone battery drains faster than expected. What's the optimization?
Show answer
Answer: B BLE advertising is for discovery, not data transfer.
Print reference
Answers 1 of 2
Answer key.
- B · BLE notifications are opt-in: the client must explicitly write 0x0001 to the CCCD (UUID 0x2902) before the server sends any notify packets.
- B · Correct!
- A · Separate application intent, host-side BLE services, and controller execution so you can locate an implementation fault at the right boundary.
- B · BLE implementation review needs observable behavior, not just a one-time demo result.
Print reference
Answers 2 of 2
Answer key.
- D · BLE achieves ultra-low power through multiple techniques: connection intervals (device sleeps between transmissions), fast connection (6ms vs 6 seconds), simpler modulation (GFSK), fewer channels (40 vs 79), optimized protocol stack, and role separation (Broadcaster, Observer, Peripheral, Central).
- B · BLE advertising is for discovery, not data transfer.