31 Bluetooth Assessment and Exercises
Comprehensive Quizzes and Practice Problems
bluetooth quiz, ble assessment, gatt quiz, bluetooth exercises
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.
- 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
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.
31.1 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
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.
“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?”
31.2 Quick Review Quiz
Test your understanding of core Bluetooth concepts:
## Scenario-Based Questions
Apply Bluetooth knowledge to real-world IoT scenarios:
## Technical Deep-Dive Questions
31.3 Comparison Questions
| 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)
31.4 Matching Questions
Q12: Match each Bluetooth profile/service to its typical IoT application.
HID for input devices, A2DP for audio, SPP for serial data, Heart Rate Service (0x180D) for fitness devices.
31.5 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:
- Duty cycle: 2ms active / 1000ms = 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.
31.6 Ranking Question
Q14: Rank these Bluetooth technologies by maximum range (longest to shortest).
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
31.7 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.
31.8 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 |
31.8.1 Knowledge Check: BLE vs Classic Selection
31.8.2 Knowledge Check: Bluetooth Mesh Troubleshooting
31.8.3 Knowledge Check: BLE Security
31.9 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”.
31.10 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 |