Bluetooth & BLE · Study deck

The Bluetooth Landscape

Picture a fitness sensor beside a phone.

Radio Remi is your guide for this deck.

Bluetooth Overview cover: Remi pairing nearby devices in a short-range personal network with signal arcs and check tokens.
iotclass.org

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.

I am beside a fitness sensor that has just appeared on a phone scan. I still need to follow useful data, permission, battery cost, and recovery before calling the product ready.

iotclass.org

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.

I watch the phone discover the nearby fitness sensor. I then follow the measurement into the app and the reconnection attempt after the person walks away.

iotclass.org

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.

I am comparing a phone speaker, a sleeping wearable, and lights relaying commands through rooms. I name their different workloads before choosing the Bluetooth behaviour that each one needs.

iotclass.org

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.

I can see the fitness sensor’s announcement on the phone. I now follow connection, service discovery, and permission checks until the app reaches the named value it actually needs.

iotclass.org

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.
Bluetooth landscape from Classic streams through BLE and later feature additions
Bluetooth landscape from Classic streams through BLE and later feature additions
iotclass.org

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.

I am reviewing a door sensor that advertises its presence and uses a short connection for configuration. I need separate evidence that settings stay restricted to its bonded owner.

iotclass.org

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.

I am planning a lighting network whose powered devices pass group commands through rooms. I need the node roles, key-management plan, and support responsibilities to belong to that mesh decision.

iotclass.org

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

Your answer
iotclass.org

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.

I am recording a battery temperature sensor that reports to a phone every few minutes. I keep its roles, GATT contract, timing, pairing, supported phones, and recovery path in one repeatable review.

iotclass.org

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.

I have a setup demonstration that worked on one phone. I keep the approval tied to that combination while checking ownership transfer, partial-provisioning recovery, and the other intended receivers.

iotclass.org

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.

I am following the temperature sensor as a peripheral and the phone as its central. I connect the GATT value with advertising, connection timing, and the changes that would require another reporting test.

iotclass.org

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.

I am working through the chapter’s illustrative coin-cell budget. I add advertising pulses to sleep consumption, then examine how the antenna-loss example changes the daily total and lifetime bound.

iotclass.org

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

Your answer
iotclass.org

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.

I see the fitness sensor in a scan, but its useful data path still has several possible failure points. I separate pairing, characteristic permissions, notification timing, and the crowded radio environment before choosing a diagnosis.

iotclass.org

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.

I am looking at a temperature app whose notifications have stopped. I check link and subscription state first, then use those observations to decide which application claim remains unsupported.

iotclass.org

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.

I am reviewing a beacon after an enclosure or scanning-policy change. I keep discovery evidence separate from later connection, data-model, and ownership changes so the retest addresses the right boundary.

iotclass.org

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.

I have an earlier successful sensor test and a phone with changed software or permissions. I need a new observation before extending the old compatibility statement to that changed receiver.

iotclass.org

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.

I return to the fitness sensor beside the phone with a completed design record. I can identify the reporting job, its tested boundaries, and the changes that require fresh evidence.

iotclass.org

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.

I am deciding what the successful sensor demonstration actually proves. I keep the profile, power calculation, security checks, recovery result, and supported receivers attached to that limited reporting claim.

iotclass.org

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?

ANothing. Bluetooth support proves range, battery life, security, and application compatibility.
BWhich Bluetooth behavior is being approved: Classic stream, BLE connection, beacon, mesh, profile, security, power.
COnly whether the radio uses 2.4 GHz, because application behavior is independent of Bluetooth design.
DOnly whether the phone can see the device once during setup.
Show answer

Answer: B Bluetooth is a family of behaviors, so the review must name the specific claim and evidence boundary.

iotclass.org

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?

ANothing. One successful phone connection proves BLE compatibility for the deployment.
BOnly the antenna vendor, because GATT and security behavior are app details.
CRole, GATT service, permissions, timing, power, reconnection, security, receiver population.
DOnly whether the device advertises, because connection behavior is automatic after discovery.
Show answer

Answer: C A single demo supports only a narrow observation unless the review records the engineering boundaries.

iotclass.org

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?

AOnly radio range, because discovery failure and data-model failure are the same Bluetooth problem.
BThe battery boundary, because advertising can succeed on a weak supply that fails during a connection.
COnly whether Bluetooth is enabled on the phone.
DThe link-to-application boundary: connection state, pairing or authorization, service discovery.
Show answer

Answer: D Discovery proves visibility, not the GATT, permission, or application-data path.

iotclass.org

Print reference

Answers

Answer key.

  1. B · Bluetooth is a family of behaviors, so the review must name the specific claim and evidence boundary.
  2. C · A single demo supports only a narrow observation unless the review records the engineering boundaries.
  3. D · Discovery proves visibility, not the GATT, permission, or application-data path.
iotclass.org

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.

iotclass.org

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.

iotclass.org