18  Quizzes and Practice Problems

Comprehensive Quizzes and Practice Problems

Keywords

bluetooth quiz, ble assessment, gatt quiz, bluetooth exercises

18.1 Putting Numbers to It

Quiz mastery targets are easiest to plan with threshold math:

\[ C_{\text{target}} = \left\lceil 0.8 \times N_{\text{questions}} \right\rceil \]

Worked example: For a 15-question quiz, target correct answers are \(\lceil 0.8 \times 15 \rceil = 12\). If a learner moves from 8/15 to 12/15, score rises from 53.3% to 80%, crossing mastery with four additional correct answers.

18.2 In 60 Seconds

This assessment covers core Bluetooth concepts (Classic vs BLE, piconets, frequency hopping), real-world IoT scenarios (fitness trackers, smart homes, medical devices), and technical details (GATT, iBeacon, security pairing, Bluetooth Mesh). Use it to identify knowledge gaps and reinforce design decision-making skills.

Phoebe’s Field Notes: What The Channel Actually Carries

Phoebe’s Why

This assessment already tells you Bluetooth hops across 79 x 1 MHz Classic channels (or 40 x 2 MHz BLE channels) inside the 2.4 GHz ISM band, and that Classic EDR tops out near 3 Mbps while BLE 5.0 tops out near 2 Mbps. Those two facts are not independent. Every radio channel has a hard ceiling on how many bits per second it can carry, set only by its bandwidth and the receiver’s signal-to-noise ratio – not by cleverness. Bluetooth’s actual data rate sits well under that ceiling on purpose: GFSK is a simple, constant-envelope modulation a cheap, low-power receiver can demodulate without a linear power amplifier or heavy digital signal processing, which matters more for a coin-cell sensor than squeezing the last few bits per hertz out of the channel.

The Derivation

The wave-speed lock behind every band choice in this assessment:

\[\lambda = \frac{c}{f}\]

Comparing two candidate ISM bands at the same distance, the free-space loss difference depends only on the frequency ratio, since distance cancels:

\[\Delta\mathrm{FSPL}_{dB} = 20\log_{10}\frac{f_{high}}{f_{low}}\]

Shannon-Hartley sets the ceiling any modulation scheme must respect for a channel of bandwidth \(B\) at signal-to-noise ratio \(\mathrm{SNR}\):

\[C = B\log_2(1+\mathrm{SNR})\]

Worked Numbers: This Chapter’s Own Bands And Channels

• This chapter’s four ISM-band quiz options, checked against the correct 2.4 GHz answer: \(\lambda_{2.4\,GHz} = 3.00\times10^{8}/2.44\times10^{9} = 12.3\) cm. Moving up to the 5 GHz option costs \(20\log_{10}(5000/2400) = 6.38\) dB of path loss; moving down to the 900 MHz option would have saved \(20\log_{10}(2400/900) = 8.52\) dB; the 433 MHz option would have saved \(20\log_{10}(2400/433) = 14.9\) dB. Bluetooth’s 2.4 GHz choice trades away some of that possible low-band range for a globally available ISM allocation.
• Classic’s 1 MHz channel, at a catalog-typical 20 dB link SNR: \(C = 10^{6}\times\log_2(101) = 6.66\) Mbit/s Shannon ceiling. This chapter’s own 3 Mbps EDR figure uses only \(3/6.66 = 45.1\%\) of that ceiling.
• BLE’s 2 MHz channel at the same 20 dB SNR: \(C = 2\times10^{6}\times\log_2(101) = 13.3\) Mbit/s ceiling. This chapter’s own 2 Mbps BLE 5.0 figure uses only \(2/13.3 = 15.0\%\) of it – BLE gives up more channel headroom than Classic does, consistent with Bella the Battery’s rule that power comes first, not how close the radio runs to the channel’s limit.

18.3 Key Concepts

• FHSS (Frequency Hopping Spread Spectrum): Classic Bluetooth technique of switching among 79 channels at 1600 hops/second to avoid interference
• Piconet: Basic Bluetooth network unit with one master and up to 7 active slaves sharing a 1 MHz channel
• Scatternet: Overlapping piconets where a device acts as master in one and slave in another, enabling extended range
• GATT (Generic Attribute Profile): BLE application-layer framework organizing data into services and characteristics with read/write/notify operations
• GAP (Generic Access Profile): Controls BLE device discovery (advertising) and connection establishment roles (central/peripheral)
• Connection Interval: Time between BLE connection events, ranging from 7.5 ms to 4 seconds, balancing latency against power consumption
• Advertising Interval: How often a BLE peripheral broadcasts advertising packets, from 20 ms (fast discovery) to 10.24 s (low power)
• MTU (Maximum Transmission Unit): Maximum payload size per BLE packet; default 23 bytes, negotiable up to 517 bytes with GATT MTU exchange

18.4 Quick Check: Review Decision Boundary

18.5 Minimum Viable Understanding

This assessment validates your Bluetooth knowledge across core concepts (Classic vs BLE, piconets, frequency hopping), real-world IoT scenarios (fitness trackers, smart homes, medical devices, smart locks), and technical details (GATT characteristics, iBeacon identifiers, security pairing, Bluetooth Mesh TTL). Completing these questions will identify areas needing further study and reinforce practical design decision-making skills.

Chapter Roadmap

Use this assessment in four passes:

1. First verify the core boundaries: Classic vs BLE, piconets, frequency hopping, profiles, and GATT vocabulary.
2. Then apply those boundaries to product scenarios where power, topology, reliability, and security make one answer defensible.
3. Next work through comparison, matching, calculation, ranking, and practice widgets so the same ideas survive different question formats.
4. Finally rehearse release-style evidence: advertising edge cases, concept relationships, final knowledge checks, pitfalls, and next-step review links.

Checkpoint callouts summarize what you should be able to defend before you continue. Collapsed quizzes, widgets, and deep-dive blocks are practice breathers, not extra required reading on a first pass.

18.6 Learning Objectives

By completing this assessment, you will:

• Demonstrate mastery of Bluetooth fundamentals including Classic vs BLE, piconets, and frequency hopping
• Apply Bluetooth knowledge to real-world IoT design scenarios
• Diagnose common BLE configuration problems and select appropriate solutions
• Evaluate trade-offs between Bluetooth technologies for different IoT use cases

18.7 For Beginners: Bluetooth Assessment

This assessment tests your knowledge of Bluetooth and BLE (Bluetooth Low Energy) technology. Think of it as a checkpoint to verify you understand how your wireless earbuds, fitness trackers, and smart home devices communicate. Working through these questions helps solidify the concepts covered in earlier chapters.

18.8 Sensor Squad: The Bluetooth Challenge

“Assessment day!” announced Max the Microcontroller. “Let us see how well you know your Bluetooth. Remember, Classic Bluetooth and BLE are like two cousins – related but very different. Classic is for streaming audio and transferring files, while BLE is for tiny sensor readings that need to last months on a battery.”

Sammy the Sensor raised a question. “What is the biggest difference I should remember?” Max held up two fingers. “Two things: power and data pattern. Classic Bluetooth maintains a continuous connection and streams data – great for music but drains batteries fast. BLE sends short bursts and sleeps between them. That is why fitness trackers last weeks, but wireless headphones need charging every day.”

“Do not forget about GATT!” added Lila the LED. “It is the language BLE devices use to share data. Services group related data together, and characteristics hold the actual values. A heart rate monitor has a Heart Rate Service with a Heart Rate Measurement characteristic. Knowing this structure is key to understanding any BLE device.”

Bella the Battery shared her study strategy. “When in doubt, think about power first. Every design decision in BLE – advertising intervals, connection parameters, notification frequency – affects how long I last. The best BLE engineers always ask: what is the minimum data I need to send, and how infrequently can I send it?”

18.9 Quick Review Quiz

Test your understanding of core Bluetooth concepts:

Checkpoint: Core Bluetooth Boundaries

You now know:

• BLE is the defensible answer for bursty sensors when the power target matters; Classic is still the audio answer.
• A Classic piconet tops out at 7 active slaves, while BLE design questions usually pivot to connections, advertising, or mesh instead.
• Bluetooth lives in the 2.4 GHz ISM band; Classic uses 79 channels, and the review answer must name the relevant profile or GATT behavior.

18.10 Scenario-Based Questions

Apply Bluetooth knowledge to real-world IoT scenarios:

The scenario questions shift from recall to diagnosis: each stem gives you the product constraint, and the correct answer is the one that explains the failure mode without inventing extra evidence.

Checkpoint: Scenario Decisions

You now know:

• For the 6-month fitness tracker, BLE beats Classic because the radio sleeps between small sensor updates.
• The 12-device smart-home case points to the 7-slave piconet boundary, not a random hardware or battery failure.
• The 50-light mesh case is a TTL-diameter problem when 35 lights respond and 15 spread-out lights do not.

18.11 Technical Deep-Dive Questions

18.12 Check Your Understanding: GATT Notify vs Indicate

18.13 Comparison Questions

Q11: Compare Bluetooth Classic vs BLE characteristics. Match each feature to the correct technology.

Feature	Classic Bluetooth	BLE
Best for continuous audio streaming
50-99% lower power consumption
Pairing time: 6ms
Uses 79 channels @ 1 MHz
Ideal for battery-powered sensors

Answers:

• Audio streaming: Classic (A2DP profile)
• Lower power: BLE (50-99% less)
• 6ms pairing: BLE (Classic takes ~6 seconds)
• 79 channels: Classic (BLE uses 40 @ 2 MHz)
• Battery sensors: BLE (months-years battery life)

18.14 Matching Questions

Q12: Match each Bluetooth profile/service to its typical IoT application.

HID Profile

A2DP Profile

SPP Profile

GATT Heart Rate Service

Wireless keyboard/mouse

Stereo audio streaming

Serial UART replacement

Fitness tracker sensor

HID for input devices, A2DP for audio, SPP for serial data, Heart Rate Service (0x180D) for fitness devices.

18.15 Calculation Problem

Q13: A BLE temperature sensor advertises every 1000ms (1 second) using non-connectable advertising with 20-byte payload. Advertising consumes 15mA for 2ms per advertisement. Sleep mode consumes 2µA. The device uses a CR2032 battery (220mAh capacity). Calculate the estimated battery life in days.

days

Calculation:

1. Duty cycle: 2ms active / 1000ms = 0.2%
2. Average current: (15mA × 0.002s + 0.002mA × 0.998s) / 1s = 0.032mA
3. Battery life: 220mAh / 0.032mA = 6,875 hours = 286-365 days

Accounting for self-discharge (~15%/year) and temperature variations yields approximately 1 year of battery life.

At this point the assessment changes format again: keep the same evidence habit, but expect the proof to be a matched pair, an ordered sequence, a computed budget, or a ranked trade-off.

18.16 Ranking Question

Q14: Rank these Bluetooth technologies by maximum range (longest to shortest).

BLE 5.0 Long Range (LE Coded PHY)

Bluetooth Classic Class 1 (+20dBm)

BLE 5.0 Standard (1 Mbps PHY)

Bluetooth Classic Class 2 (+4dBm)

Ranking (longest to shortest): 1. BLE 5.0 Long Range (Coded PHY): ~1000m with S=8 coding 2. Classic Class 1 (+20dBm): ~100m for industrial use 3. BLE 5.0 Standard (1M PHY): ~30-50m typical 4. Classic Class 2 (+4dBm): ~10m for consumer devices

Checkpoint: Evidence Formats

You now know:

• Notify vs Indicate is a reliability question: Indicate adds client acknowledgment when missed readings are unacceptable.
• The coin-cell calculation depends on the stated 20-byte payload, 15mA transmit current, 2ms active time, and 220mAh battery.
• Range rankings depend on the named PHY or class: BLE 5.0 Long Range, Classic Class 1, BLE 5.0 Standard, then Classic Class 2.

18.17 Practice Exercises

Exercise 1: BLE Scanner Application

Objective: Build a BLE scanner that discovers and analyzes nearby devices.

Tasks:

1. Implement BLE scanning with 5-second duration
2. Extract device name, MAC address, RSSI, manufacturer data
3. Filter devices by service UUID (e.g., Heart Rate 0x180D)
4. Calculate estimated distance using RSSI

Expected Skills:

• BLE Central role configuration
• Advertisement packet parsing
• RSSI-to-distance conversion

Exercise 2: GATT Service Explorer

Objective: Connect to a BLE device and interact with GATT characteristics.

Tasks:

1. Scan and connect to a specific device
2. Enumerate all services and characteristics
3. Enable notifications on Heart Rate Measurement (0x2A37)
4. Log real-time heart rate data with timestamps

Expected Skills:

• GATT service discovery
• CCCD configuration
• Notification callback handling

Exercise 3: Security Analysis

Objective: Analyze and implement BLE security measures.

Tasks:

1. Compare pairing methods (Just Works, Passkey, Numeric Comparison)
2. Implement LE Secure Connections pairing
3. Enable BLE privacy (random MAC rotation)
4. Create security checklist for medical device

Expected Skills:

• Security level selection
• Pairing implementation
• Privacy configuration

Exercise 4: Multi-Device Network Design

Scenario: Smart home with 15 sensors and 1 central hub.

Tasks:

1. Design network to overcome 7-device piconet limit
2. Calculate connection intervals for each sensor type
3. Estimate power budget for 2-year battery life
4. Optimize advertising vs GATT connection strategy

Expected Skills:

• Topology selection (BLE vs Mesh vs scatternet)
• Power budget calculation
• Connection parameter optimization

Common Mistake: Assuming BLE Range Equals Distance for Asset Tracking

The Mistake: Deploying BLE asset tracking beacons in a warehouse and using raw RSSI values to calculate precise asset locations, expecting +/-1 meter accuracy without calibration, then finding that reported locations vary by 5-10 meters even when assets are stationary.

Why It Happens: Marketing materials for BLE positioning systems often claim “meter-level accuracy” without explaining the extensive calibration, filtering, and environmental mapping required. Developers assume RSSI translates directly to distance using the path loss formula, not accounting for multipath reflections, metal shelving, concrete floors, and human activity.

Real-World Impact:

Warehouse Scenario (40m x 60m with 4m metal shelving):
- Beacon at 2m actual distance
- RSSI readings over 30 seconds: -68 dBm to -84 dBm (16 dB variance)
- Calculated distances: 1.4m to 6.8m (4.8m error range!)
- Causes: forklift passing (signal blockage), people walking (body absorption),
  metal shelf reflections (multipath +/- 6 dB)

Without calibration and filtering:
❌ "Asset in Row 3" becomes "Asset somewhere in Rows 1-5"
❌ False "asset moved" alerts when beacon hasn't moved
❌ Unable to distinguish adjacent storage locations

The Fix: Use zone-based positioning instead of coordinate-based positioning:

Zone-Based Approach (Practical):

1. Divide warehouse into 10m x 10m zones
2. Place 1 beacon at each zone intersection (shared by 4 zones)
3. Classify zones using weighted voting from 3+ visible beacons:
   • RSSI > -65 dBm: “In Zone A” (high confidence)
   • RSSI -65 to -75 dBm: “Near Zone A border” (medium confidence)
   • RSSI < -75 dBm: “Far from Zone A” (exclude from voting)
4. Apply moving average filter (5-10 samples over 3-5 seconds)
5. Require 3 consecutive readings in new zone before updating location

Results:

Before: "Asset at (12.3m, 28.7m)" ± 5m error → meaningless coordinates
After: "Asset in Zone C-4" → 85% zone accuracy, useful for workflows
Cost: Same beacon hardware, different software approach

Key Insight: BLE is excellent for “which zone/room/area” but poor for “exact coordinates.” Design your asset tracking system around presence detection (zone-based) rather than positioning (coordinate-based), and your accuracy will improve from 60% to 85%+ with the same hardware.

18.18 Practice Widgets

Interactive Quiz: Match BLE Concepts

Interactive Quiz: Sequence the BLE Connection Steps

Label the Diagram

Code Challenge

18.19 Start With the Story

A Bluetooth assessment is not a memory contest. The useful test is whether a learner can look at a product situation and choose the role, GATT model, pairing method, key behavior, implementation check, or debugging evidence that fits.

Use these questions as a release rehearsal. For each answer, ask what observable proof would make the claim true on a real device.

The final drill focuses that release habit on advertising, because a correct Bluetooth answer often starts before a connection exists.

18.20 Assessment Drill: BLE Advertising Edge Cases

Advertising questions usually test whether you separate discovery from data exchange. Advertising says a device exists and what interaction it permits; GATT carries application data after connection.

Scenario cue	Defensible answer
Any nearby phone must discover and connect	Use ADV_IND: connectable, scannable, and undirected.
Beacon only, no connection needed	Use ADV_NONCONN_IND: broadcast-only and non-connectable.
Known bonded peer should reconnect quickly	Use a directed advertisement for that specific peer address.
More discovery data is needed without connecting	Use active scanning: SCAN_REQ followed by SCAN_RSP.

Legacy advertising uses primary channels 37, 38, and 39 at 2402, 2426, and 2480 MHz. They are spread across the 2.4 GHz band to avoid the busiest Wi-Fi channels rather than placed next to each other. If one advertising channel is noisy, the other two can still carry discovery traffic; after connection, BLE moves to the data-channel map across channels 0-36.

A legacy advertisement has a 31-byte payload budget. Flags, a short name, a service UUID, manufacturer data, and calibrated Tx power can fill it quickly. Keep the critical discovery fields in the advertisement and move secondary text into the scan response when the advertising type is scannable.

The scan-response exchange is: advertiser sends ADV_IND with up to 31 bytes, active scanner replies with SCAN_REQ, advertiser returns SCAN_RSP with a second 31-byte payload.

Passive scanning only listens. Active scanning adds the request-response exchange, but only for scannable advertising types. A non-connectable, non-scannable beacon cannot provide a scan response unless the advertising type changes too.

Checkpoint: Release Readiness

You now know:

• Discovery and data exchange are separate: advertising announces presence, while GATT carries application data after connection.
• Legacy advertising uses channels 37, 38, and 39 at 2402, 2426, and 2480 MHz, with a 31-byte payload budget per advertisement.
• A defensible assessment answer names the connection mode, security method, topology, evidence limit, and retest trigger.

18.21 Summary

This assessment covered:

• Quick Review: Core Bluetooth/BLE concepts including power advantages, piconet limits, frequency bands, communication models, and profiles
• Scenarios: Real-world IoT application problems spanning fitness trackers, smart home hubs, medical devices, BLE sensors, smart locks, and building automation
• Deep-Dive: Technical details including GATT characteristics, iBeacon identifier structure, frequency hopping rates, and pairing security
• Comparisons: Classic vs BLE feature mapping across audio, power, pairing, channels, and sensor use cases
• Calculations: Battery life estimation using duty cycle, average current, and CR2032 capacity
• Exercises: Hands-on implementation practice for BLE scanning, GATT exploration, security analysis, and multi-device network design

Concept Relationships

Core Concept	Builds On	Enables	Common Confusion
BLE GATT Services	Attribute Protocol (ATT)	Device interoperability via standard UUIDs	GATT vs. GAP roles
Connection Intervals	Link Layer timing	Power vs. throughput tradeoffs	Interval vs. latency parameter
Bluetooth Mesh	BLE advertising	Multi-hop IoT networks	Managed flooding vs. routing
Frequency Hopping	Adaptive Frequency Hopping (AFH)	Interference resilience in 2.4 GHz	Classic vs. BLE hopping rates
Pairing Methods	Secure Simple Pairing (SSP)	Encrypted connections	Just Works vs. Passkey Entry

18.22 Final Knowledge Check

18.22.1 Knowledge Check: BLE vs Classic Selection

18.22.2 Knowledge Check: Bluetooth Mesh Troubleshooting

18.22.3 Knowledge Check: BLE Security

18.23 See Also

• Bluetooth Fundamentals - BLE architecture and protocol stack
• BLE Protocol Deep Dive - GATT services and characteristics
• Bluetooth Connection Establishment - Connection parameters and optimization
• Bluetooth Implementations and Labs - ESP32 coding examples
• Bluetooth Hands-On Lab - Practical exercises

Common Pitfalls

1. Confusing Classic and BLE Assessment Questions

Classic Bluetooth and BLE have fundamentally different channel architectures (79 vs 40 channels), connection models (piconet vs central/peripheral), and power profiles. When answering assessment questions, identify which variant is being asked about. BLE advertising channels are specifically channels 37, 38, 39; all other 37 channels are data channels.

2. Misquoting Power Numbers Without Context

Stating “BLE uses X mW” without specifying operating mode (advertising vs connected vs sleep) is incorrect. BLE power consumption spans six orders of magnitude: ~2 µA in deep sleep, ~15 mA during active transmission. Always state the mode when quoting power figures in assessments.

3. Overlooking Bluetooth Mesh in Architecture Questions

When asked about BLE network topologies for large deployments (>7 devices), the piconet 7-device limit is a Classic Bluetooth constraint. BLE Mesh (Bluetooth 5.0+) supports thousands of nodes using publish/subscribe flooding. Distinguish between BLE point-to-point, BLE broadcast, and BLE Mesh in architecture questions.

4. Incorrect Version-Feature Mapping

Attributing features to wrong Bluetooth versions is a common error. Key milestones: 4.0=BLE introduced, 4.2=IPv6/privacy, 5.0=LE 2M/Coded PHY/extended advertising, 5.1=direction finding (AoA/AoD), 5.2=LE Audio/LC3, 5.3=connection subrating. Use the version timeline mnemonic: “4-BLE, 5-speed+range, 5.1-direction, 5.2-audio”.

18.24 What’s Next

Chapter	Focus	Why Read It
Bluetooth Fundamentals and Architecture	Protocol stack, Classic vs BLE architecture	Review the core concepts that underpin all assessment questions
BLE Protocol Deep Dive	GATT services, characteristics, and ATT layer	Deepen understanding of the GATT questions covered in this assessment
Bluetooth Connection Establishment	Advertising, scanning, connection parameters	Master the BLE connection lifecycle tested in scenario questions
Bluetooth Security	Pairing methods, LE Secure Connections, threat models	Strengthen knowledge of the security scenarios in this assessment
Bluetooth Implementations and Labs	ESP32 BLE coding, GATT server/client implementation	Apply assessment knowledge with hands-on ESP32 BLE projects
IEEE 802.15.4 Fundamentals	Foundation protocol for Zigbee and Thread	Expand from BLE mesh to other low-power wireless mesh technologies

18.25 Key Takeaway

Bluetooth assessment answers should justify the wireless choice, topology, connection mode, profile, security method, and power trade-off. Naming BLE or Classic is not enough without explaining why it fits the product constraint.