Bluetooth & BLE · Study deck
Device Discovery and Connection Setup
A gateway is a device that passes data between a local device and another network.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The Bluetooth device address (BD_ADDR) is a 48-bit value normally written as twelve hexadecimal digits; the upper 24 bits identify the manufacturer allocation and the lower 24 bits identify the device within that allocation.
- Explain: Classic discovery is a rendezvous problem: the inquiring radio and the discoverable radio must land on the same carrier at the same time even though they do not yet share a piconet clock.
- Explain: A setup failure can therefore sit in discoverability, inquiry scan timing, paging, piconet address assignment, pairing, or profile discovery; the review should name which boundary actually failed.
Major section
Start With the Story
A gateway is a device that passes data between a local device and another network.
- Seeing the sensor nearby is only the first step.
- An advertisement is a short radio notice that says a Bluetooth device is present.
- A phone scans for that notice and may ask to connect.
Major section
Start With the Story (continued)
Pairing checks whether the two sides may trust each other.
- A service then groups the data and commands the app may use.
- Real products may have many services, link settings, phone rules, and security modes.
- At each fault, the app should say what failed and give a safe next step.
Major section
Start With the Story (continued)
The product should reconnect when it is safe or ask for trust again when it is not.
- It also states which phones and field sites were not tested.
- These messages help the user act and help support find the same fault.
- The old phone should not keep control after the product says it was removed.
Major section
Treat Connection Setup as a Chain of Evidence
A connected sensor that never sends notifications may have a GATT subscription or authorization problem, not a discovery problem.
- For BLE, discovery usually starts with advertising and scanning.
- Each step can pass while a later step fails.
- Worked example: a cold-room sensor is commissioned by a phone before it joins the building gateway.
Major section
Build a Connection Review Record
A practical Bluetooth connection review record says what setup path is being approved and what would make that approval stale.
- It should show the initiating device, discoverability state, connection role, security ceremony, negotiated behavior, GATT or profile handoff, failure recovery, and retest trigger.
- A setup-only BLE workflow, a background sensor link, a Classic profile connection, and a mesh provisioning path all need different evidence.
- The approval should not say that BLE is the product network.
Major section
Build a Connection Review Record (continued)
This record prevents teams from treating "connected once" as a broad release claim.
- A device uses BLE only to receive Wi-Fi credentials during first-run setup.
- It should approve the reviewed commissioning path for the tested phones, app permissions, firmware, reset behavior, and recovery states.
- A wearable sends periodic measurements to a phone.
Major section
State Machines, Timers, and Reconnection
Under the hood, connection establishment is a sequence of state transitions.
- Each boundary produces different evidence, so a friendly name discovered during inquiry does not prove that paging, address assignment, authentication, or profile setup succeeded.
- The inquiry and paging timers are also evidence.
- With a 625 microsecond slot, the added wait is therefore.
Major section
State Machines, Timers, and Reconnection (continued)
Those values describe the configured scan schedule, not a promise that every product will be found in 11.25 ms.
- Sniff schedules listening windows, hold pauses normal traffic for an agreed interval, and park gives up the active-member address until the master unparks the device.
- Classic inquiry uses wake-up carriers and inquiry-scan windows so undiscovered devices do not need to listen continuously.
- Connection parameters and supervision behavior are operational evidence, not tuning trivia.
Major section
State Machines, Timers, and Reconnection (continued)
If the inquiry transmission misses the window, it must continue hopping until a later overlap.
- They also show why Classic setup and BLE setup feel different in the field: timing depends on procedure, backoff, retries, and current radio conditions rather than a single guaranteed connection time.
- Paging then uses the discovered address and clock information to converge on the target's hopping sequence.
- The final local identifier is the 3-bit active-member address, AM_ADDR.
Major section
State Machines, Timers, and Reconnection (continued)
The Bluetooth device address (BD_ADDR) is a 48-bit value normally written as twelve hexadecimal digits; the upper 24 bits identify the manufacturer allocation and the lower 24 bits identify the device within that allocation.
- Friendly names are user-facing labels and can be duplicated, renamed, or include only part of the address for disambiguation, so they are not a substitute for address-level inventory evidence.
- A setup failure can therefore sit in discoverability, inquiry scan timing, paging, piconet address assignment, pairing, or profile discovery; the review should name which boundary actually failed.
- Aggressive timing can improve responsiveness but increase wakeups and failure sensitivity.
Major section
State Machines, Timers, and Reconnection (continued)
Classic discovery is a rendezvous problem: the inquiring radio and the discoverable radio must land on the same carrier at the same time even though they do not yet share a piconet clock.
- A discoverable controller periodically opens an inquiry-scan window; a representative controller schedule uses an 11.25 ms window every 1.28 s.
- Once a scanner hears an inquiry ID packet, it does not let every nearby device answer in the same reply slot.
- A friendly name may be fetched later and is not part of this timing proof.
- Long gaps between radio events can save energy but make interaction slower.
Major section
State Machines, Timers, and Reconnection (continued)
Values 1 through 7 identify the seven simultaneously active slaves in a Classic piconet; zero is reserved for broadcast traffic.
- The FHS response supplies the information the initiator actually needs for the next phase: the responder's Bluetooth address and native-clock information from which a clock offset can be estimated.
- Be precise about the bit widths: the DAC access code is constructed from the target's 24-bit lower address part (LAP); it is not merely a 24-bit address field on air.
- That record turns “Bluetooth setup was slow” into a timer or state hypothesis that can be retested.
Major section
State Machines, Timers, and Reconnection (continued)
The target returns the first page response, the pager sends an FHS packet carrying the master's clock and address information, and the target acknowledges with the second page response.
- Assignment of AM_ADDR is useful evidence that the paging exchange reached connected state, but it does not prove authentication, encryption, profile discovery, or application readiness.
- The review should tie those choices to the product workflow, not to a generic "fast" or "low power" label.
- Classic Bluetooth is a useful contrast because its setup path is explicit.
Major section
Discovery And Pairing Explorer
Once connected, the link layer uses data channels and adapts its channel map.
- BR/EDR inquiry and SDP,: BLE advertising/scanning and GATT, and: Bluetooth Mesh provisioning are different procedures.
- For BLE, the primary advertising channels are 37, 38, and 39.
- This separates an application-policy failure from a radio-duty-cycle trade-off.
Major section
Summary
Bluetooth connection establishment should be reviewed as a chain of evidence: discovery, link setup, security, application handoff, and recovery.
- Classic Bluetooth and BLE use different setup procedures, so the review should name the exact behavior being approved.
- A visible advertisement or one successful connection does not prove pairing safety, GATT correctness, battery behavior, or reconnection recovery.
- Pairing, bonding, authorization, privacy, timeout behavior, and ownership transfer need explicit evidence when they are part of the product claim.
Deck summary
Key takeaways
A gateway is a device that passes data between a local device and another network.
- Pairing checks whether the two sides may trust each other.
- The product should reconnect when it is safe or ask for trust again when it is not.
- A connected sensor that never sends notifications may have a GATT subscription or authorization problem, not a discovery problem.
- A practical Bluetooth connection review record says what setup path is being approved and what would make that approval stale.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1A phone sees a BLE device during scanning, but the app cannot read the sensor value after connecting. Which review response is strongest?
Show answer
Answer: D Discovery is useful evidence, but the failed value path lives in later connection, security, GATT, and application boundaries.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2A setup-only BLE product connects to a phone and receives network credentials during a lab test. Which approval statement is strongest?
Show answer
Answer: A The approval stays tied to the setup workflow and the evidence that can be repeated.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q3A bonded BLE sensor reconnects after a firmware update, but notifications stop until the user removes and re-adds the device. Which boundary should be reviewed first?
Show answer
Answer: B Reconnection still works, so the failure likely sits in persisted trust, service compatibility, subscription, or app handling.
Print reference
Answers
Answer key.
- D · Discovery is useful evidence, but the failed value path lives in later connection, security, GATT, and application boundaries.
- A · The approval stays tied to the setup workflow and the evidence that can be repeated.
- B · Reconnection still works, so the failure likely sits in persisted trust, service compatibility, subscription, or app handling.