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
The peripheral tells nearby devices that it is ready.
- There, GATT reads, writes, and notices carry small values for the app.
- The role names are exact, but the flow is simple: announce, find, connect, and exchange.
- 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
Why does the same −74 dBm mean 3.98 m or 5.62 m?
- 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.
- At the −70 dBm NEAR/FAR rule, the n=2.5 model predicts −70.9 dBm at 3 m—already 0.9 dB beyond the boundary before the chapter’s ±8 dB body swing.
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.
- An illustrative ±8 dB RSSI change multiplies that estimate by 10±8/25, giving about 4.8 m to 20.9 m under the same assumed path-loss exponent.
Major section
Build the BLE Sensor, Step by Step (continued)
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.
- 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.
Deck summary
Key takeaways
Seeing the device is only the first step.
- The peripheral tells nearby devices that it is ready.
- 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.
Q2What carries commands, events and data between a Bluetooth host and controller?
Show answer
Answer: B HCI transports commands, events, and data between the host and controller.
Q3Complete the code to write a value to a BLE GATT characteristic:
Show answer
Answer: A BLE characteristics accept bytearray values.
Retrieval practice
Recall check 3 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q4A scanner sees several nearby devices. Which signal should it use for a rough proximity class?
Show answer
Answer: A RSSI can support a zone estimate after repeated samples.
Retrieval practice
Recall check 4 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q5A 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 5 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q6A BLE temperature sensor advertises a small periodic reading every second. Its phone app scans continuously to catch each reading, and measured phone battery draw is too high. Which alternative should the team test to reduce the scanning load?
Show answer
Answer: B The phone app's continuous scan is the stated cost.
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 · HCI transports commands, events, and data between the host and controller.
- A · BLE characteristics accept bytearray values.
- A · RSSI can support a zone estimate after repeated samples.
- B · BLE implementation review needs observable behavior, not just a one-time demo result.
Print reference
Answers 2 of 2
Answer key.
- B · The phone app's continuous scan is the stated cost.