21 Quizzes and Practice Problems
21.1 Putting Numbers to It
Quiz mastery targets are easiest to plan with threshold math:
Worked example: For a 15-question quiz, target correct answers are . If a learner moves from 8/15 to 12/15, score rises from 53.3% to 80%, crossing mastery with four additional correct answers.
21.2 In 60 Seconds
Judge the Wireless Design Through One Real Use Case
Picture a fitness band that records steps all day and sends a summary to a phone. The designer must decide how it advertises, connects, shares data, saves power, protects the user, and recovers when the phone disappears. A list of radio terms is not enough.
Write the use-case record. Name the device, user, data item, send pattern, range, response need, battery aim, trusted peer, and safe offline behavior. Mark which facts are broadcast, which need a connection, and which action needs a fresh check of identity and rights.
Test first use, return use, a wrong phone, weak signal, a crowded room, a long message, a lost connection, a sleeping device, a key change, and a software update. Check time to find and connect, energy, repeated data, stale state, refusal, and recovery. Keep the phone and device versions with the result.
Do not let a nearby radio become proof of trust. Keep urgent physical action safe when the phone or remote service is absent. Share only the data needed for the stated use, and make removal and reset behavior clear to the user.
This opening does not answer every quiz or choose one mode for all products. Practitioner turns each scenario into a design and test record. Under the Hood examines discovery, connections, data services, message size, timing, mesh behavior, pairing, and security.
Use this product check:
- Name the right peer.
- Test the wrong peer.
- Test the lost phone.
- Check the safe reset.
21.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
21.4 Quick Check: Review Decision Boundary
21.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.
Use this assessment in four passes:
- First verify the core boundaries: Classic vs BLE, piconets, frequency hopping, profiles, and GATT vocabulary.
- Then apply those boundaries to product scenarios where power, topology, reliability, and security make one answer defensible.
- Next work through comparison, matching, calculation, ranking, and practice widgets so the same ideas survive different question formats.
- 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.
21.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
21.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.
21.8 The Bluetooth Challenge
“Assessment day!” announced 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.”
Temperature Terry 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 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.”
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?”
21.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.
21.10 Scenario-Based Questions
Apply Bluetooth knowledge by reading each scenario in the same order: identify the traffic and energy constraint, reject technologies that violate it, name the protocol boundary that decides the result, and state the evidence that would confirm the choice. This keeps the questions tied to product reasoning rather than isolated recall.
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.
21.11 Technical Deep-Dive Questions
21.12 Knowledge Check: GATT Notify vs Indicate
21.13 Comparison Questions
Work across the comparison one property at a time. Begin with workload—continuous audio or intermittent sensor data—then compare power behavior and setup time, and finish with channel structure and device role. The answer pattern should form one coherent technology choice: Classic for sustained profile traffic such as A2DP, BLE for short low-power exchanges, with radio facts used as supporting evidence rather than labels to memorise.
| 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 |
- 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)
21.14 Matching Questions
21.15 Calculation Problem
- Duty cycle: 2 ms active / 1000 ms = 0.2%
- Average current: (15mA × 0.002s + 0.002mA × 0.998s) / 1s = 0.032mA
- 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.
21.16 Ranking Question
Rank the options by separating coding gain from transmit-power class. Start with LE Coded PHY, whose redundancy trades throughput for receiver sensitivity, then place high-power Classic Class 1. Compare ordinary LE 1M operation next and finish with lower-power Classic Class 2. Treat the quoted distances as approximate examples: antenna design, interference, receiver sensitivity, regulatory limits, and environment still decide measured product range.
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, 2 ms 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.
21.17 Practice Exercises
Objective: Build a BLE scanner that discovers and analyzes nearby devices.
Tasks:
- Implement BLE scanning with 5-second duration
- Extract device name, MAC address, RSSI, manufacturer data
- Filter devices by service UUID (e.g., Heart Rate 0x180D)
- Calculate estimated distance using RSSI
Expected Skills:
- BLE Central role configuration
- Advertisement packet parsing
- RSSI-to-distance conversion
Objective: Connect to a BLE device and interact with GATT characteristics.
Tasks:
- Scan and connect to a specific device
- Enumerate all services and characteristics
- Enable notifications on Heart Rate Measurement (0x2A37)
- Log real-time heart rate data with timestamps
Expected Skills:
- GATT service discovery
- CCCD configuration
- Notification callback handling
Objective: Analyze and implement BLE security measures.
Tasks:
- Compare pairing methods (Just Works, Passkey, Numeric Comparison)
- Implement LE Secure Connections pairing
- Enable BLE privacy (random MAC rotation)
- Create security checklist for medical device
Expected Skills:
- Security level selection
- Pairing implementation
- Privacy configuration
Scenario: Smart home with 15 sensors and 1 central hub.
Tasks:
- Design network to overcome 7-device piconet limit
- Calculate connection intervals for each sensor type
- Estimate power budget for 2-year battery life
- Optimize advertising vs GATT connection strategy
Expected Skills:
- Topology selection (BLE vs Mesh vs scatternet)
- Power budget calculation
- Connection parameter optimization
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 locationsThe Fix: Use zone-based positioning instead of coordinate-based positioning:
Zone-Based Approach (Practical):
- Divide warehouse into 10m x 10m zones
- Place 1 beacon at each zone intersection (shared by 4 zones)
- 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)
- Apply moving average filter (5-10 samples over 3-5 seconds)
- 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 approachKey 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.
21.18 Practice Widgets
21.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.
21.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.
21.21 Debate: Wi-Fi vs. BLE for Indoor Positioning
This scenario is drawn from a hospital asset-tracking deployment and is meant to be worked through as a design-decision exercise, not just read.
21.21.1 Wi-Fi vs BLE for Indoor Positioning
Choose From the Hospital Job, Not the Radio Name
Picture a nurse searching for one of 200 pumps before treatment. The hospital wants room-level location, long tag life, and a system the support team can maintain. A strong signal on a plan does not prove a useful position.
Wi-Fi is the local wireless network used by many phones and computers. Bluetooth Low Energy, or BLE, is a shorter-range radio designed for small, low-power exchanges. The design team should first name the required area, update time, accuracy, battery life, privacy rule, and response when a tag is missing.
Install a small trial in real rooms and corridors. Move people and equipment, change tag direction, close doors, and repeat the same route. Compare wrong-room results, missed items, maintenance work, and existing equipment for both choices.
Let the nurse and support worker judge the trial. The nurse needs a quick useful place, not a perfect map. The support worker needs a clear way to find dead tags and moved equipment. Count both search time and upkeep before choosing.
Record the worst areas, not only the average. A basement store, lift, or crowded ward may decide whether the service is safe to trust. Mark any place where the screen should say “unknown” instead of showing a confident but wrong room.
Neither radio guarantees one-metre accuracy. Practitioner designs the fair field trial. Under the Hood explains signal fingerprints, beacon geometry, reflections, calibration, and error bounds.
Scenario: A hospital needs to track 200 medical equipment items in a 50,000 sq ft facility with 1-meter accuracy.
Debate: Wi-Fi RSSI fingerprinting vs BLE beacons?
Defend Your Position:
- Infrastructure requirements
- Battery life for asset tags
- Accuracy achievable
- Maintenance burden
21.22 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
| 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 |
21.23 Final Knowledge Check
21.24 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
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.
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.
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.
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”.
21.25 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 |
21.26 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.