These comprehensive projects integrate multiple concepts from across the book into real-world IoT system designs. Each project is designed for 4-8 weeks of work and covers the full IoT stack from sensors to cloud analytics.
Learning Objectives
After completing a capstone project, you will be able to:
Design and implement a complete IoT system from requirements to deployment
Integrate hardware (sensors, actuators) with software (firmware, cloud)
Apply security best practices throughout the IoT stack
Analyze data and create meaningful visualizations
Document and present technical solutions professionally
Work with real-world constraints (power, cost, connectivity)
1640.2 Prerequisites
Before starting a capstone project, you should have completed:
Sensor Fundamentals and at least one sensor lab
Networking Fundamentals including MQTT or similar protocol
Cloud Computing basics or edge computing concepts
Security Fundamentals including device authentication
Basic programming skills (Python, C/C++, or JavaScript)
NoteKnowledge Check: Project Planning Priorities
Show code
{const container =document.getElementById('kc-project-planning');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"You're starting an IoT capstone project with a 6-week timeline. During week 1, you discover that the specialized sensor you planned to use has a 4-week lead time. What is the BEST approach?",options: [ {text:"Wait for the sensor and compress the remaining work into 2 weeks",correct:false,feedback:"Compressing a 6-week project into 2 weeks would severely impact quality and likely result in an incomplete project."}, {text:"Find an alternative sensor with similar specifications that's immediately available",correct:true,feedback:"Correct! Flexibility in component selection is crucial. Finding an alternative sensor maintains your timeline while meeting requirements. Always have backup component options identified during planning."}, {text:"Remove the sensor requirement from your project scope",correct:false,feedback:"Removing core requirements compromises the project's learning objectives and may not meet evaluation criteria."}, {text:"Start building the rest of the system and integrate the sensor when it arrives",correct:false,feedback:"This risks integration issues. Without the actual sensor, you can't validate your sensor interface code, calibration routines, or data pipeline."} ],difficulty:"medium",topic:"project-planning" })); }}
Design and build a comprehensive indoor environment monitoring system that tracks air quality, temperature, humidity, light levels, and noise. The system should provide real-time dashboards, historical analytics, and automated alerts when conditions exceed healthy thresholds.
1640.3.2 Business Context
Poor indoor air quality costs businesses $150 billion annually in lost productivity. Your system will help facility managers maintain healthy environments and comply with workplace safety regulations.
1640.3.3 Requirements Specification
1640.3.3.1 Functional Requirements
ID
Requirement
Priority
F1
Measure temperature (Β±0.5Β°C accuracy)
Must Have
F2
Measure relative humidity (Β±3% accuracy)
Must Have
F3
Measure CO2 levels (Β±50 ppm accuracy)
Must Have
F4
Measure particulate matter (PM2.5)
Should Have
F5
Measure ambient light (lux)
Should Have
F6
Measure noise level (dB)
Could Have
F7
Display real-time readings on local screen
Must Have
F8
Send data to cloud every 5 minutes
Must Have
F9
Send alerts when thresholds exceeded
Must Have
F10
Provide historical data visualization
Must Have
F11
Calculate and display air quality index
Should Have
F12
Support multiple sensor nodes
Could Have
1640.3.3.2 Non-Functional Requirements
ID
Requirement
Target
NF1
Battery life (if portable)
> 7 days
NF2
Data transmission reliability
> 99%
NF3
Sensor reading latency
< 2 seconds
NF4
System uptime
> 99.5%
NF5
Data storage retention
1 year
NF6
Total hardware cost
< $100
1640.3.4 Recommended Hardware
Component
Options
Est. Cost
Microcontroller
ESP32, Raspberry Pi Pico W
$5-15
Temperature/Humidity
DHT22, BME280, SHT31
$5-15
CO2 Sensor
MH-Z19B, SCD30, SCD40
$15-50
Particulate Sensor
PMS5003, SDS011
$15-30
Light Sensor
BH1750, TSL2561
$2-5
Sound Sensor
MAX4466, INMP441
$3-8
Display
0.96β OLED, 2.4β TFT
$5-15
Enclosure
3D printed or project box
$5-10
NoteKnowledge Check: Hardware Selection for Environment Monitoring
Show code
{const container =document.getElementById('kc-hardware-selection');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"For the Smart Environment Monitor, you need to choose between the DHT22 ($5) and BME280 ($15) for temperature/humidity sensing. The BME280 also includes barometric pressure. Which factor should MOST influence your decision?",options: [ {text:"Always choose the cheaper option to minimize cost",correct:false,feedback:"Cost matters, but the cheapest option isn't always best. The DHT22 has slower response time (2s vs 1ms) and lower accuracy than the BME280."}, {text:"The BME280's I2C interface allows multiple sensors on one bus, simplifying wiring",correct:true,feedback:"Correct! The BME280's I2C interface is crucial when you're also connecting a BH1750 light sensor and OLED display on the same bus. The DHT22 uses a one-wire protocol requiring a dedicated GPIO pin and separate timing."}, {text:"The barometric pressure feature justifies the extra cost",correct:false,feedback:"While barometric pressure is useful, for indoor air quality monitoring, it's not as critical as CO2 and PM2.5. The interface compatibility is more important for this project."}, {text:"The DHT22 is more widely documented online",correct:false,feedback:"Documentation availability is helpful but shouldn't override technical requirements. The BME280 also has excellent documentation and library support."} ],difficulty:"hard",topic:"hardware-selection" })); }}
1640.3.5 Architecture Design
%% fig-alt: "System architecture diagram for Smart Environment Monitor showing three layers: Sensor Node layer with temperature, CO2, PM2.5, and light sensors connected to ESP32 MCU with OLED display and Wi-Fi; Network layer using MQTT over Wi-Fi; Cloud layer with MQTT broker, InfluxDB time-series database, Grafana dashboards, Node-RED automation, and email alerts."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#ECF0F1'}}}%%
flowchart TB
subgraph Sensors["π‘οΈ Sensor Node"]
T["Temperature<br/>DHT22"]
CO2["CO2<br/>MH-Z19B"]
PM["PM2.5<br/>PMS5003"]
L["Light<br/>BH1750"]
end
subgraph MCU["π§ Microcontroller"]
ESP["ESP32<br/>Main Controller"]
OLED["OLED Display"]
SD["SD Card<br/>Backup"]
end
subgraph Cloud["βοΈ Cloud Layer"]
MQTT["MQTT Broker<br/>Mosquitto"]
DB["InfluxDB<br/>Time-Series DB"]
VIZ["Grafana<br/>Dashboards"]
RULES["Node-RED<br/>Automation"]
ALERT["Alerts<br/>Email/SMS"]
end
T & CO2 & PM & L --> ESP
ESP --> OLED
ESP --> SD
ESP -->|Wi-Fi/MQTT| MQTT
MQTT --> DB
MQTT --> RULES
DB --> VIZ
VIZ --> ALERT
RULES --> ALERT
style T fill:#E67E22,color:#fff
style CO2 fill:#E74C3C,color:#fff
style PM fill:#9B59B6,color:#fff
style L fill:#F1C40F,color:#000
style ESP fill:#2C3E50,color:#fff
style MQTT fill:#16A085,color:#fff
style DB fill:#3498DB,color:#fff
style VIZ fill:#27AE60,color:#fff
Deliverables: - [ ] Wi-Fi connectivity with reconnection handling - [ ] MQTT publishing to broker - [ ] Cloud database storing data - [ ] Basic Grafana dashboard
MQTT Topic Structure:
environment/
βββ {device_id}/
β βββ temperature
β βββ humidity
β βββ co2
β βββ pm25
β βββ light
β βββ status
βββ alerts/
βββ {device_id}
NoteKnowledge Check: MQTT Topic Design
Show code
{const container =document.getElementById('kc-mqtt-topics');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"Looking at the MQTT topic structure above, why is each sensor value published to a separate topic (e.g., environment/{device_id}/temperature) rather than all values in a single JSON payload to environment/{device_id}/all?",options: [ {text:"Single-value topics use less bandwidth than JSON",correct:false,feedback:"Actually, publishing to multiple topics creates more overhead due to repeated topic strings in each message. JSON payloads are typically more bandwidth-efficient."}, {text:"Subscribers can receive only the specific data they need, reducing processing",correct:true,feedback:"Correct! Topic-per-sensor allows selective subscription. A dashboard showing only temperature can subscribe to environment/+/temperature without receiving unnecessary CO2 or humidity data. This is especially important for resource-constrained edge devices."}, {text:"MQTT doesn't support JSON payloads",correct:false,feedback:"MQTT supports any payload format including JSON, binary, and Protocol Buffers. Many IoT systems use JSON for readability."}, {text:"Separate topics are required for QoS settings",correct:false,feedback:"QoS is set per-message, not per-topic. You can publish different messages to the same topic with different QoS levels."} ],difficulty:"medium",topic:"protocol-design" })); }}
Implement machine learning for occupancy detection
Create mobile app for monitoring
Add multiple rooms with mesh networking
Integrate with building management systems
NoteKnowledge Check: Data Storage Strategy
Show code
{const container =document.getElementById('kc-data-storage');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The Environment Monitor stores sensor data in InfluxDB (a time-series database) rather than PostgreSQL (a relational database). With 5 sensors publishing every 5 minutes, you'll have ~1.4 million data points per year. Why is InfluxDB the better choice?",options: [ {text:"InfluxDB is free while PostgreSQL requires a license",correct:false,feedback:"Both InfluxDB and PostgreSQL have free open-source versions. Licensing isn't the deciding factor."}, {text:"InfluxDB automatically handles time-based data compaction and downsampling",correct:true,feedback:"Correct! Time-series databases like InfluxDB are optimized for temporal data. They provide automatic data retention policies (delete data older than X days), downsampling (aggregate old data to hourly averages), and time-range queries that are orders of magnitude faster than relational databases for this use case."}, {text:"PostgreSQL cannot store numeric sensor values",correct:false,feedback:"PostgreSQL can store any data type. The difference is in how the data is organized and queried, not what types it supports."}, {text:"InfluxDB provides built-in visualization that PostgreSQL lacks",correct:false,feedback:"While InfluxDB can integrate with visualization tools, both databases typically use external tools like Grafana for visualization. This isn't the primary advantage."} ],difficulty:"hard",topic:"data-management" })); }}
1640.4 Capstone Project 2: Smart Agriculture System
NoteProject Overview
Domain: Precision Agriculture / Smart Farming
Difficulty: βββ Advanced
Duration: 6-8 weeks
Team Size: 2-3 people
1640.4.1 Project Description
Build an automated plant care system that monitors soil conditions, environmental factors, and plant health, then automatically waters plants based on intelligent algorithms. The system should work both indoors (houseplants) and outdoors (garden), with solar power capability for remote deployment.
1640.4.2 Business Context
Global water scarcity affects 40% of the worldβs population. Smart irrigation systems can reduce water usage by 30-50% while improving crop yields. Your system demonstrates IoTβs role in sustainable agriculture.
{const container =document.getElementById('kc-soil-sensor');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The hardware list specifies 'Capacitive (not resistive!)' soil moisture sensors. Why is this distinction critical for a long-term agricultural deployment?",options: [ {text:"Capacitive sensors are more accurate than resistive sensors",correct:false,feedback:"Both sensor types can achieve similar accuracy when properly calibrated. Accuracy isn't the primary differentiator."}, {text:"Resistive sensors corrode over time due to electrolysis from DC current through the soil",correct:true,feedback:"Correct! Resistive sensors pass DC current through the soil, causing electrolytic corrosion of the probes. In outdoor deployments, they typically fail within 1-3 months. Capacitive sensors measure dielectric properties without direct electrical contact with soil, lasting years in the field."}, {text:"Capacitive sensors are cheaper than resistive sensors",correct:false,feedback:"Resistive sensors are actually cheaper ($1-2 vs $3-8). The cost difference is justified by the dramatically longer lifespan."}, {text:"Capacitive sensors require less power than resistive sensors",correct:false,feedback:"Power consumption is similar for both types. The corrosion resistance is the critical factor for outdoor/agricultural use."} ],difficulty:"hard",topic:"hardware-selection" })); }}
def should_water(soil_moisture, weather_forecast, last_watered):""" Intelligent watering decision algorithm. Args: soil_moisture: Current soil moisture (0-100%) weather_forecast: Dict with rain_probability, temp last_watered: Datetime of last watering Returns: (should_water: bool, duration_seconds: int) """# Define thresholds (plant-specific) DRY_THRESHOLD =30# Water if below this WET_THRESHOLD =70# Never water above this RAIN_THRESHOLD =60# Don't water if rain likely MIN_INTERVAL_HOURS =6# Minimum time between watering# Check if too soon since last watering hours_since = (datetime.now() - last_watered).total_seconds() /3600if hours_since < MIN_INTERVAL_HOURS:return (False, 0)# Check if rain is expectedif weather_forecast['rain_probability'] > RAIN_THRESHOLD:return (False, 0) # Let nature do the work# Check soil moistureif soil_moisture > WET_THRESHOLD:return (False, 0) # Already wet enoughif soil_moisture < DRY_THRESHOLD:# Calculate watering duration based on how dry deficit = DRY_THRESHOLD - soil_moisture duration =min(deficit *2, 60) # Max 60 secondsreturn (True, duration)return (False, 0)
NoteKnowledge Check: Smart Watering Algorithm
Show code
{const container =document.getElementById('kc-watering-algo');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The smart watering algorithm above checks MIN_INTERVAL_HOURS before allowing watering. Why is this safeguard important even if soil moisture readings indicate dry conditions?",options: [ {text:"To save water by limiting total daily watering",correct:false,feedback:"Water conservation is a benefit, but the algorithm already controls water based on moisture levels. The interval serves a different safety purpose."}, {text:"To prevent sensor glitches from triggering excessive watering that could damage plants or waste water",correct:true,feedback:"Correct! A malfunctioning sensor could read '0% moisture' even in wet soil, triggering continuous watering. The minimum interval acts as a safety valve, preventing runaway conditions. This is a critical IoT design pattern: never trust a single sensor reading for critical actuations."}, {text:"To allow time for the water to soak into the soil before measuring again",correct:false,feedback:"While water absorption time matters, 6 hours is excessive for absorption. Soil moisture readings stabilize within 15-30 minutes after watering."}, {text:"To synchronize watering times across multiple zones",correct:false,feedback:"This algorithm handles a single zone. Multi-zone coordination would be a separate concern."} ],difficulty:"medium",topic:"algorithm-design" })); }}
{const container =document.getElementById('kc-connectivity-protocol');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The agriculture system offers 'LoRa or Wi-Fi connectivity' as options. For a field deployment 200 meters from the farmhouse with no Wi-Fi coverage, which factor makes LoRa the clear choice?",options: [ {text:"LoRa is faster than Wi-Fi for data transmission",correct:false,feedback:"Wi-Fi is actually much faster (Mbps vs kbps). Speed isn't LoRa's advantage - the small sensor payloads don't need high bandwidth."}, {text:"LoRa's sub-GHz frequencies penetrate obstacles better and require less power for long range",correct:true,feedback:"Correct! LoRa operates at 868/915 MHz (sub-GHz) while Wi-Fi uses 2.4/5 GHz. Lower frequencies travel farther and penetrate vegetation/soil better. A LoRa link at 200m might use 10-50mW while Wi-Fi would need 100+ mW and still struggle with range. For solar-powered outdoor deployments, this power difference is critical."}, {text:"LoRa doesn't require any gateway infrastructure",correct:false,feedback:"LoRa still requires a gateway (shown in the architecture diagram). The gateway receives LoRa transmissions and forwards them to the internet."}, {text:"LoRa provides built-in encryption that Wi-Fi lacks",correct:false,feedback:"Both LoRa and Wi-Fi support encryption (LoRaWAN has AES-128, Wi-Fi has WPA3). Security is achievable with either protocol."} ],difficulty:"medium",topic:"protocol-selection" })); }}
1640.4.7.4 Week 7-8: Intelligence & Dashboard
1640.4.8 Evaluation Rubric
Criteria
Points
Description
Sensor Integration
20
Accurate, calibrated, reliable
Watering Control
20
Precise, safe, effective
Power Management
15
Solar-capable, efficient
Connectivity
15
Long-range, reliable
Algorithm
15
Smart decisions, water savings
Documentation
15
Complete, reproducible
Total
100
NoteKnowledge Check: Security for Outdoor Deployments
Show code
{const container =document.getElementById('kc-outdoor-security');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"Your Smart Agriculture System is deployed in a remote field accessible to the public. An attacker could physically access your device. Which security measure is MOST important to implement?",options: [ {text:"Use HTTPS for all cloud communications",correct:false,feedback:"HTTPS protects data in transit, but doesn't help if an attacker has physical access to the device and can read stored credentials directly."}, {text:"Store credentials in secure flash with hardware encryption and use device attestation",correct:true,feedback:"Correct! With physical access, attackers can dump firmware and extract plaintext credentials. Hardware-backed secure storage (e.g., ESP32's encrypted flash, hardware security modules) protects secrets even with physical access. Device attestation ensures the cloud rejects connections from cloned or tampered devices."}, {text:"Use a strong Wi-Fi password on the access point",correct:false,feedback:"Wi-Fi passwords don't protect against physical attacks. An attacker with device access can extract the password from firmware."}, {text:"Implement rate limiting on the cloud API",correct:false,feedback:"Rate limiting helps against DoS attacks from the network, but doesn't address physical device compromise."} ],difficulty:"hard",topic:"security" })); }}
1640.5 Capstone Project 3: Fleet Tracking System
NoteProject Overview
Domain: Logistics / Asset Tracking
Difficulty: βββ Advanced
Duration: 6-8 weeks
Team Size: 2-3 people
1640.5.1 Project Description
Design a GPS-based asset tracking system for vehicles or valuable equipment. The system should provide real-time location tracking, geofence alerts, movement history, and battery-efficient operation for long deployment without charging.
1640.5.2 Business Context
Fleet management is a $31 billion market growing at 15% annually. Businesses lose $164 billion annually to fleet inefficiency. GPS tracking reduces fuel costs by 15% and improves asset utilization by 20%.
{const container =document.getElementById('kc-cellular-tech');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The Fleet Tracking System uses LTE-M or NB-IoT rather than standard 4G LTE. For a tracker sending 100-byte location updates once per minute, why are these IoT-specific cellular technologies preferred?",options: [ {text:"LTE-M/NB-IoT have better GPS integration than standard LTE",correct:false,feedback:"GPS integration is handled separately from cellular. The cellular module just transmits the GPS coordinates - it doesn't affect GPS accuracy."}, {text:"LTE-M/NB-IoT modems cost 10x less than standard LTE modems",correct:false,feedback:"While cost is lower, the difference isn't 10x. Both LTE-M and standard LTE modems are available in the $20-40 range."}, {text:"LTE-M/NB-IoT provide deep indoor coverage and power-saving modes designed for battery operation",correct:true,feedback:"Correct! LTE-M/NB-IoT use half-duplex communication and Power Saving Mode (PSM) that can reduce idle current to microamps. Standard LTE maintains continuous connections requiring milliamps even when idle. For a battery-powered tracker, this difference means months vs days of battery life."}, {text:"Standard 4G LTE doesn't support small data packets",correct:false,feedback:"Standard LTE can handle any packet size. However, it's designed for high-bandwidth applications and maintains overhead that wastes power for small, infrequent transmissions."} ],difficulty:"medium",topic:"protocol-selection" })); }}
// Power states for maximum battery lifeenum PowerState { DEEP_SLEEP,// GPS off, cellular off, ~10uA LIGHT_SLEEP,// GPS acquiring, cellular off, ~1mA ACTIVE_GPS,// GPS tracking, cellular off, ~30mA ACTIVE_TRANSMIT // GPS + cellular active, ~150mA};// Adaptive reporting based on movementvoid adaptiveTracking(){if(isMoving()){// Vehicle in motion: frequent updates reportIntervalSeconds =60; gpsMode = CONTINUOUS;}elseif(hasMovedRecently(30)){// Recently stopped: medium updates reportIntervalSeconds =300; gpsMode = PERIODIC;}else{// Parked: infrequent updates reportIntervalSeconds =3600; gpsMode = ON_DEMAND;}}// Estimated battery life calculation// 3000mAh battery// Moving 4 hours/day: ~35 days// Parked most of time: ~90+ days
NoteKnowledge Check: Power Optimization Strategy
Show code
{const container =document.getElementById('kc-power-optimization');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The power optimization code uses an accelerometer to detect movement and adjust the GPS reporting interval. Why is movement detection essential rather than just using a fixed reporting schedule?",options: [ {text:"The accelerometer consumes less power than the GPS module",correct:false,feedback:"While true, this doesn't explain why movement-based scheduling helps. A fixed schedule would also turn GPS off between readings."}, {text:"Movement detection enables 10-30x power savings by using very infrequent updates when parked",correct:true,feedback:"Correct! Vehicles spend 80-90% of their time parked. Detecting this state allows 1-hour update intervals instead of 1-minute, providing massive power savings. The accelerometer uses only microamps to detect motion and can wake the MCU from deep sleep, while continuous GPS operation would drain the battery in days."}, {text:"The GPS module can't operate in low-power mode",correct:false,feedback:"GPS modules can operate in various power modes, but they still consume significant power (20-50mA) when acquiring position. The movement detection reduces how often the GPS is activated."}, {text:"Movement detection improves GPS accuracy",correct:false,feedback:"Movement detection doesn't affect GPS accuracy directly. It's used to optimize power consumption based on vehicle state."} ],difficulty:"medium",topic:"power-management" })); }}
1640.5.7 Implementation Milestones
1640.5.7.1 Week 1-2: GPS & Basic Firmware
1640.5.7.2 Week 3-4: Cellular Connectivity
1640.5.7.3 Week 5-6: Backend & Storage
1640.5.7.4 Week 7-8: Dashboard & Optimization
1640.5.8 Geofence Implementation
from shapely.geometry import Point, Polygonclass GeofenceEngine:def__init__(self):self.geofences = {}self.device_states = {} # Track inside/outside statedef add_geofence(self, name, coordinates, alert_on):""" coordinates: List of (lat, lon) tuples alert_on: 'entry', 'exit', or 'both' """self.geofences[name] = {'polygon': Polygon(coordinates),'alert_on': alert_on }def check_position(self, device_id, lat, lon):"""Check if device triggers any geofence alerts.""" point = Point(lon, lat) # Note: Shapely uses (x, y) = (lon, lat) alerts = []for name, geofence inself.geofences.items(): was_inside =self.device_states.get((device_id, name), None) is_inside = geofence['polygon'].contains(point)if was_inside isnotNone:ifnot was_inside and is_inside and geofence['alert_on'] in ('entry', 'both'): alerts.append({'type': 'entry', 'geofence': name})elif was_inside andnot is_inside and geofence['alert_on'] in ('exit', 'both'): alerts.append({'type': 'exit', 'geofence': name})self.device_states[(device_id, name)] = is_insidereturn alerts
NoteKnowledge Check: Geofence Implementation
Show code
{const container =document.getElementById('kc-geofence');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The geofence engine stores device_states to track whether each device is inside or outside each geofence. Why is this state tracking necessary instead of just checking the current position?",options: [ {text:"To reduce computation time for position checks",correct:false,feedback:"State tracking adds computation, not reduces it. We need to compare current position, retrieve previous state, and update state."}, {text:"To detect boundary crossings (entry/exit events) rather than just containment",correct:true,feedback:"Correct! Without state tracking, we only know if a device is currently inside or outside. By comparing to the previous state, we detect the transition moment - the entry or exit event. This is essential for triggering alerts at the right time, not continuously while inside a geofence."}, {text:"To support offline operation when the device loses connectivity",correct:false,feedback:"The state tracking shown here is server-side. Offline geofencing would require different logic on the device itself."}, {text:"To enable multiple devices to share the same geofence definitions",correct:false,feedback:"Geofence sharing is possible without state tracking. The state tracking is about detecting transitions, not resource sharing."} ],difficulty:"hard",topic:"algorithm-design" })); }}
1640.5.9 Evaluation Rubric
Criteria
Points
Description
GPS Accuracy
15
Consistent < 10m accuracy
Cellular Reliability
15
> 99% data delivery
Battery Life
20
Meets 30-day target
Geofencing
15
Accurate entry/exit detection
Dashboard
15
Real-time, historical, usable
Documentation
20
Complete, reproducible
Total
100
NoteKnowledge Check: Database Selection for Location Data
Show code
{const container =document.getElementById('kc-location-database');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"The Fleet Tracking System uses PostGIS (PostgreSQL with spatial extensions) rather than a standard time-series database like InfluxDB. What capability makes PostGIS essential for this application?",options: [ {text:"PostGIS can store more data points than InfluxDB",correct:false,feedback:"Both databases can handle billions of records. Storage capacity isn't the differentiator."}, {text:"PostGIS provides spatial indexes and functions for efficient geofence queries across millions of points",correct:true,feedback:"Correct! PostGIS provides R-tree spatial indexes and functions like ST_Contains, ST_Distance, and ST_Within that can check whether points fall within polygons (geofences) efficiently. Checking 100 vehicles against 50 geofences requires 5,000 polygon-containment tests - PostGIS can do this in milliseconds using spatial indexes. InfluxDB would require loading all coordinates into memory for geometric calculations."}, {text:"InfluxDB doesn't support latitude/longitude data types",correct:false,feedback:"InfluxDB can store latitude and longitude as float fields. However, it lacks spatial query capabilities for geometric operations."}, {text:"PostGIS is required for real-time map visualization",correct:false,feedback:"Map visualization is handled by frontend libraries like Leaflet or Mapbox. The database choice doesn't affect visualization capability directly."} ],difficulty:"hard",topic:"data-management" })); }}
1640.6 Project Submission Guidelines
1640.6.1 Required Deliverables
Technical Report (10-15 pages)
Problem statement and requirements
Architecture design with diagrams
Implementation details
Testing results and analysis
Lessons learned
Source Code Repository
Well-organized, commented code
README with setup instructions
Dependencies documented
Video Demonstration (5-10 minutes)
System overview
Live functionality demo
Key features walkthrough
Hardware Documentation
Bill of materials with costs
Wiring diagrams
Assembly photos
1640.6.2 Presentation Format
15-minute presentation + 5 minutes Q&A
Cover: problem, solution, demo, results, lessons
Be prepared to discuss technical trade-offs
NoteKnowledge Check: Documentation Best Practices
Show code
{const container =document.getElementById('kc-documentation');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"Your capstone project technical report must include 'wiring diagrams and assembly photos'. Beyond helping the grader evaluate your work, why is this documentation critical for a real IoT product?",options: [ {text:"To prove the project was completed without plagiarism",correct:false,feedback:"While documentation supports originality, this isn't the primary engineering value of hardware documentation."}, {text:"To enable reproducibility, maintenance, and troubleshooting by others who didn't build the original system",correct:true,feedback:"Correct! IoT products are maintained for years after initial deployment. Wiring diagrams allow technicians to diagnose issues, replace components, and make modifications. Without documentation, a simple sensor replacement might require hours of reverse-engineering. This is why professional IoT products include detailed hardware documentation."}, {text:"To satisfy regulatory compliance requirements",correct:false,feedback:"While some regulations require documentation, internal wiring diagrams are typically not submitted to regulators. They're essential for operational reasons."}, {text:"To calculate the total bill of materials cost",correct:false,feedback:"BOM costs can be calculated from component lists. Wiring diagrams serve assembly and maintenance purposes, not cost calculation."} ],difficulty:"easy",topic:"project-management" })); }}
NoteKnowledge Check: Technical Trade-offs
Show code
{const container =document.getElementById('kc-tradeoffs');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"During your presentation Q&A, you're asked: 'Why did you choose ESP32 over Raspberry Pi for your sensor node?' Which response demonstrates the best understanding of IoT trade-offs?",options: [ {text:"'ESP32 is cheaper than Raspberry Pi'",correct:false,feedback:"While true, this doesn't address the engineering trade-offs. Cost alone isn't a complete justification."}, {text:"'I'm more familiar with Arduino-style programming'",correct:false,feedback:"Familiarity is a practical factor but doesn't demonstrate understanding of the technical trade-offs between platforms."}, {text:"'ESP32's deep sleep mode uses microamps vs Raspberry Pi's milliamps, critical for battery operation. The Pi's Linux capabilities weren't needed for our simple sensor reading and MQTT publishing.'",correct:true,feedback:"Correct! This answer demonstrates understanding of: (1) power consumption trade-offs, (2) matching platform capabilities to requirements, (3) not over-engineering the solution. It shows you evaluated alternatives and made a justified decision."}, {text:"'Everyone in IoT uses ESP32 for sensor nodes'",correct:false,feedback:"Popularity isn't a technical justification. Many professional IoT solutions use different platforms based on specific requirements."} ],difficulty:"medium",topic:"project-decisions" })); }}