Bluetooth & BLE · Study deck
The Bluetooth Landscape
Picture a fitness sensor beside a phone.
Radio Remi is your guide for this deck.

After studying this chapter
Learning objectives
A Bluetooth design needs evidence for the particular behavior the product depends on.
- Bluetooth families support different patterns of local communication.Classic streams, short BLE exchanges, connectionless advertising, and mesh control are different jobs with different review boundaries.
- Discovery leaves data exchange, permission, and recovery unproven.The phone can see the nearby fitness sensor before useful readings, protected access, and return after a connection break are established.
- A battery claim needs radio-activity and sleep evidence.A sensor’s actual advertising schedule, wake cost, and sleep current can matter more than its low-energy protocol label.
- Device and receiver changes can require another review.A new phone OS, enclosure, firmware, or radio environment can invalidate an observation made with the earlier combination.
Major section
Start With the Story
Seeing a nearby sensor begins the investigation into whether the product works.
- A phone scan can establish nearby radio visibility under tested conditions.The first sighting of the fitness sensor is useful evidence, but it cannot establish the full reporting workflow.
- The sensor still needs useful data exchange with its intended application.The app must reach the expected service and value before the nearby device can provide a meaningful measurement.
- The design must protect the exchange and meet the battery goal.A working temperature notification can still be unauthorized or consume too much energy under an aggressive connection schedule.
- Recovery after the user walks away needs separate evidence.The sensor-to-phone product must demonstrate what happens after a broken connection rather than relying on the first successful scan.
Major section
Streams, short exchanges, beacons, and mesh
Different traffic patterns lead to different Bluetooth choices.
- Classic Bluetooth supports sustained streams and established audio uses.A speaker playing phone audio is a continuous-stream problem, so the relevant profile and connection behaviour need review.
- BLE supports short exchanges with time for device sleep.The heart-rate wearable can send small measurements between sleeping periods instead of maintaining a continuous stream.
- A connectionless beacon can announce an identifier without a connected path.Advertising interval, privacy, battery, and receiver behaviour still need evidence even when no data connection is required.
- Bluetooth Mesh supports managed local control through relaying devices.Mains-powered lights can pass group commands through rooms, with provisioner, relay, key-management, and support responsibilities to define.
Major section
From advertising to permitted data access
Discovery, joining, data meaning, and permission are separate steps in the product’s behavior.
- An advertisement can make a device visible to a nearby receiver.That announcement is evidence of presence, while connection and application data remain separate steps for the phone to establish.
- A connection provides the link for the next interaction stage.The linked sensor still needs service discovery and permission checks before the app can use the expected value.
- Service discovery identifies the named values available to the application.The temperature workflow needs its GATT service and characteristic to match the value the phone app expects.
- Permissions determine which operations the application may perform.An encrypted link cannot repair an incorrect characteristic permission that allows an unintended read, write, or command.
Major section
What Bluetooth Is Good For
This timeline shows feature evolution; read from Classic streams through BLE and then later additions.
- The Classic family is the timeline’s sustained-stream starting point.Audio and established continuous-connection uses are the first boundary to distinguish from the later low-energy sensor path.
- The BLE introduction adds a path for short exchanges and sleep.Small wearable measurements can fit this duty-cycled behaviour without turning the timeline into a universal battery guarantee.
- Later additions include extended range, richer advertising, and LE Audio.The timeline shows feature evolution, but a later label cannot establish support in every controller, phone, or profile.
- Both endpoints need verified support for the required feature and profile.A smart door sensor needs separate evidence for advertising, short configuration connections, and bonded owner-only settings.
Major section
Sensor reports and owner-only settings
A feature label does not establish the behavior of the complete device and phone combination.
- An occasional sensor report may need only BLE collection through a gateway.A device sending to a nearby receiver every few minutes can have a narrower requirement than continuous audio or mesh control.
- A wearable’s small measurements allow sleep between radio events.Its power claim still needs the actual schedule and device behaviour rather than an assumption drawn from the BLE name.
- A door sensor needs separate advertising, configuration, and ownership tests.A short GATT setup connection does not establish that the bonded owner alone can change protected settings.
- The review must name the required behaviour before claiming compatibility.Power, range, security, and application evidence are specific to the reviewed workflow and the endpoints that were tested.
Major section
Audio and mesh are different jobs
Choosing mesh or an audio profile creates a different engineering responsibility from collecting sensor reports.
- Continuous audio needs evidence for the relevant profile and stream behaviour.The phone speaker is a different approval boundary from a beacon that only announces an identifier.
- A mesh lighting network needs explicit device-role decisions.Provisioners, relays, friends, and low-power nodes are architectural responsibilities when lights relay group commands through rooms.
- Mesh key management and support belong in the architecture decision.A working group command cannot establish the long-term ownership and key-custody arrangements for the building-control network.
- The selected behaviour determines the relevant engineering tests.A local sensor report, audio stream, or lighting mesh needs its own power, range, security, and application evidence.
Activity 1 · Match
✎ Choose the Bluetooth behavior

I want you to match the job before you approve a radio label.
Match these jobs to Classic or audio profile, BLE sensor connection, beacon advertising, BLE commissioning, or Bluetooth Mesh: continuous phone audio; temperature reports; identifier broadcasts; setup before joining another network; relayed group lighting commands.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Build the Bluetooth Design Record
A repeatable design record states what was chosen and which observations support the choice.
- The use case and traffic pattern determine the required radio behaviour.The temperature sensor reporting every few minutes is a specific workload, not a general claim that every Bluetooth task is supported.
- Mode, roles, and the service model define endpoint interaction.The record needs the sensor’s peripheral role, the phone’s central role, and the service carrying the measurement.
- Power and security constraints must fit the chosen interaction.Advertising and connection schedules need to work alongside pairing, authorization, key custody, and the required battery behaviour.
- Receiver population and retest triggers limit the supported approval.A successful sensor workflow is tied to its tested phones, app, firmware, conditions, and power budget until broader evidence exists.
Major section
The tested compatibility and setup boundary
Release evidence replaces assumptions with observations from representative products and failure cases.
- Tested devices and conditions define the observed compatibility boundary.The final enclosure, phone set, firmware, and site are part of the observation rather than interchangeable deployment details.
- One successful phone demonstration supports only that narrow combination.Other phone models, OS versions, or app permissions need evidence before the team can extend the compatibility claim.
- Pairing and authorization need evidence beyond discovery or encryption labels.Key custody and protected settings remain separate questions even when the phone can discover the sensor and establish an encrypted link.
- Commissioning needs ownership-transfer and failed-setup recovery evidence.BLE used only for setup must prevent unauthorized reconfiguration and recover from partial provisioning before that workflow is approved.
Major section
The sensor-to-phone reporting record
A temperature-reporting workflow needs timing, data, and recovery assumptions recorded together.
- The sensor is the peripheral and the phone is the central.Those roles identify the participating endpoints in the chapter’s temperature-reporting workflow and the receiver population that needs testing.
- The GATT service and characteristic define the expected temperature value.The app needs the correct read or notification behaviour and permissions, not merely a discovered radio.
- Advertising and connection intervals affect responsiveness and power.The schedule can change radio activity and wake costs, so the battery budget needs observations from the actual device.
- Phone, firmware, antenna, and permission changes can reopen the reporting review.Earlier evidence is bounded by the tested combination rather than a permanent promise of compatibility with future receivers.
Major section
Advertising pulses and the coin-cell budget
The battery example accounts for both advertising pulses and sleep before estimating lifetime.
- The illustrative advertising energy is 1.26 J/day.One 0.9 ms event at 5.4 mA each second is the chapter’s active-radio contribution for its CR2032 and BLE SoC example.
- A 2 µA sleep current adds 0.518 J/day.The device still consumes energy between advertising events, so the radio pulses are not the complete daily budget.
- The derated 1900.8 J budget supports an illustrative 2.93-year bound.That estimate uses the chapter’s pulse and sleep assumptions; it is not a measured lifetime guarantee for every BLE product.
- Doubling active current reduces the illustrative bound to 1.71 years.After a 2 dBi antenna loss, the example’s total is 3.04 J/day, connecting installation losses to the battery calculation.
Activity 2 · Predict
✎ Spend more energy on each advert

I want you to connect the changed radio current to the battery claim.
On paper, predict the direction of the lifetime change when active current doubles after the chapter’s 2 dBi antenna loss. Copy the before and after lifetime bounds and name the unchanged sleep contribution. Explain why the BLE label cannot settle battery life.
3 minutes · Pen and paper · Answer: Activity 2
Major section
Layer Handoffs and Failure Boundaries
A symptom can appear above the layer where the Bluetooth failure began.
- A visible device can still fail pairing.The phone’s discovery result establishes presence but cannot prove that a useful protected data connection has been formed.
- An encrypted link can still allow the wrong characteristic operation.Incorrect permissions remain an application access problem even when the transport has established encryption.
- A working notification path can drain the battery.An aggressive connection schedule can increase radio activity, so successful readings do not establish the device’s power budget.
- A lab-visible beacon may behave differently at a crowded site.The tested radio environment is part of the evidence boundary, especially when shared air changes the observed reception.
Major section
Diagnosing notifications and battery drain
Diagnosis starts with the evidence immediately below the failed operation.
- Stopped notifications need link and subscription-state checks.The closest proof below the symptom can identify a missing connection or subscription before the team changes application parsing.
- Battery drain needs interval and wake-behaviour evidence.The actual radio schedule can explain increased consumption, so a weak battery should not be assumed from the symptom alone.
- A connection does not establish service, permission, or data correctness.The phone still needs the expected characteristic properties and app mapping before it can interpret the sensor value.
- Each handoff needs enough evidence to locate the unsupported claim.Discovery, role behaviour, link setup, application meaning, and operations are different boundaries in the sensor-to-phone review.
Major section
Retests at each layer handoff
Each handoff has its own reason to repeat the test.
- Antenna, enclosure, placement, and scan changes can alter discovery.A beacon seen in one lab arrangement may need another observation after the installed hardware or receiver scanning policy changes.
- Phone software and connection rules can alter link setup.OS, pairing, bonding, firmware, and app-permission changes are reasons to retest the previously observed connection behaviour.
- Service schemas and mappings can alter application interpretation.A changed characteristic property or gateway rule can affect meaning even when the radio and connection still work.
- Ownership changes can alter the supported operational workflow.Lost devices, resets, replacement devices, and reprovisioning need a working recovery path within the reviewed support boundary.
Major section
Changing phones, permissions, and installation
Changing one variable helps explain why the observed result changed.
- A phone or OS change may invalidate earlier compatibility evidence.A setup flow approved for one receiver population cannot automatically cover a new phone model or software version.
- Permission and firmware changes can affect access while discovery still works.The phone may continue seeing the sensor but lack the application authority needed to read its expected value.
- The same radio can behave differently after enclosure or antenna changes.The final installed arrangement needs evidence because moving the antenna can change the discovery and reception conditions.
- Approval stays limited until new observations support a broader claim.One phone, room, firmware, or service test is a bounded result rather than proof of general Bluetooth interoperability.
Major section
Summary
Bluetooth readiness is a claim about a tested workflow with known limits.
- The required job determines the appropriate Bluetooth behaviour.Streams, connected measurements, advertising, commissioning, and mesh control are different workflow boundaries to name before selecting the design.
- Radio visibility leaves permission, data, recovery, and battery behaviour unproven.The fitness sensor can appear in a scan while the useful reporting path still lacks evidence at later stages.
- The design record connects roles, meaning, security, timing, and receivers.The reviewed temperature workflow needs its GATT contract, phone population, power budget, and reconnection path in the same record.
- Retest triggers connect later changes to fresh evidence.Firmware, enclosure, phone software, permissions, and ownership changes can reopen the earlier approval instead of silently inheriting its result.
Deck summary
Key takeaways
The complete Bluetooth product extends beyond the first successful scan.
- Profiles and services give exchanged data its application meaning.The temperature app needs the expected GATT service, characteristic, permissions, and value mapping beyond the common Bluetooth label.
- Power claims depend on the actual event schedule and sleep current.The chapter’s illustrative energy calculation includes both advertising pulses and consumption between events before estimating a lifetime bound.
- Security needs pairing, authorization, key custody, and privacy evidence.Ownership transfer, lost-device handling, and reset behaviour are necessary parts of the review beyond successful encrypted communication.
- Recovery tests and receiver limits keep a demonstration claim bounded.A sensor working with one phone must still be reviewed for reconnection, supported phones, firmware, and the conditions of the reporting workflow.
Retrieval practice
Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q1A product note says a device is ready because it supports Bluetooth. What should the review ask next?
Show answer
Answer: B Bluetooth is a family of behaviors, so the review must name the specific claim and evidence boundary.
Retrieval practice
Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q2A BLE temperature sensor demo works once with one phone. What evidence is still needed before approving the design record?
Show answer
Answer: C A single demo supports only a narrow observation unless the review records the engineering boundaries.
Retrieval practice
Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q3A phone discovers a BLE device, but the app cannot read the expected sensor value. Which evidence boundary should be reviewed first?
Show answer
Answer: D Discovery proves visibility, not the GATT, permission, or application-data path.
Print reference
Answers
Answer key.
- B · Bluetooth is a family of behaviors, so the review must name the specific claim and evidence boundary.
- C · A single demo supports only a narrow observation unless the review records the engineering boundaries.
- D · Discovery proves visibility, not the GATT, permission, or application-data path.
Print reference
Activity 1 answer
Model answer.
Match: Continuous audio: Classic or audio profile. Temperature reports: BLE sensor connection. Identifier broadcasts: beacon advertising. Setup: BLE commissioning. Relayed group lighting commands: Bluetooth Mesh. Each choice still needs its own deployment evidence.
Print reference
Activity 2 answer
Model answer.
Predict: Lifetime falls from about 2.93 years to 1.71 years as total consumption rises to 3.04 J/day. The 2 µA sleep contribution remains 0.518 J/day. Actual event current, timing, sleep, and the derated energy budget determine the bound.