2 Capstone Projects: Planning and Evidence

2.1 Start With the Decision

A strong capstone begins with one testable decision, not a pile of devices. The plan must connect users, evidence, risks, and acceptance checks.

2.2 Route Overview

This is part 1 of 3. Continue with Capstone Projects: Selection and Fleet Tracking.

2.3 Part Objectives

• Turn an IoT problem into a bounded project question and evidence plan.
• Define milestones, risks, and acceptance checks for a capstone.

2.4 In 60 Seconds

Build the Smallest Complete Proof First

Picture a student team planning a smart plant pot. One person wants three sensors, another wants an app, and another wants an automatic pump. The reviewer needs a finished evidence path, not a pile of parts that work only on separate desks.

Name one useful decision, such as whether the soil needs water. Write the event, user, allowed error, response time, safe pump state, budget, and date. Choose the smallest chain that can prove it: sense, read, send, store, show, and respond. Assign one owner to each hand-off.

Build that thin chain early. Try dry and wet soil, a loose wire, weak power, lost contact, a full store, a wrong user, a stuck pump, and a restart. Keep the raw reading, time, code version, final display, and action together so a reviewer can follow one case end to end.

Do not let a remote dashboard be the only safety path for water, heat, motion, or another physical action. Set a local limit and a safe state. Add features only after the first path survives its failure tests and the team can explain the result.

This opening does not select the final project or parts list. Practitioner turns the idea into milestones and acceptance evidence. Under the Hood examines power, wiring, code, links, storage, trust, integration, and known limits.

Use this first build check:

• Name one user choice.
• Build one whole path.
• Break one hand-off.
• Show the safe state.
• Keep the full proof.

Capstone projects turn the course material into working IoT systems. A strong project starts with requirements, acceptance criteria, and a realistic bill of materials before hardware is purchased. The main risk is integration: sensors, firmware, networking, storage, security, dashboards, and power assumptions may work separately but fail when combined.

Choose a project scope that fits the time, budget, team size, and experience level. Freeze must-have requirements early so the project can reach a polished demo. Treat power, connectivity, security, and data storage as design constraints from day one. Reserve meaningful time for end-to-end integration testing. Document architecture, wiring, code, tests, trade-offs, and known limitations.

2.5 Start With One Useful Decision

Before choosing sensors or cloud services, name the decision the finished project should improve. A room monitor might help someone decide when to ventilate. An irrigation prototype might help a grower decide when a zone needs water. A fleet tracker might help an operator decide whether a vehicle is inside a safe route. If that decision is not clear, every feature feels equally important and the project becomes hard to finish.

Then build the smallest path that can prove the decision: sensing, firmware, network hop, storage, dashboard, and one failure response. The first strong demo is not the one with the most parts. It is the one where a reviewer can follow the evidence from the physical event to the screen and understand what would happen if power, connectivity, calibration, or credentials failed.

Use the briefs below as starting shapes for that proof. Keep the parts that support the decision, adapt the parts that do not fit your budget or hardware, and record the trade-off so the final report reads like engineering evidence rather than a shopping list.

2.6 Learning Objectives

After completing a capstone project, you will be able to:

• Architect a complete IoT system from requirements gathering through deployment and validation.
• Integrate sensors, actuators, firmware, cloud services, and dashboards across the full stack.
• Apply security practices at device, network, application, and data layers.
• Analyse sensor data and build visualisations that support actionable decisions.
• Produce professional documentation including architecture diagrams, BOMs, wiring notes, and test reports.
• Optimise designs within real constraints such as power budget, component cost, connectivity range, and schedule.

2.7 How To Use These Project Briefs

Use each project as a structured brief, not as a rigid recipe. Keep the must-have requirements, adapt the hardware to what is available, and document any trade-offs you make.

2.8 Project Briefs Become Reviewable Claims

A capstone brief is useful only when it can be turned into a reviewable engineering claim. The three project families below are not shopping lists. They are worked examples of how to turn a problem domain into requirements, evidence, and a demo path. A smart environment monitor claims it can make indoor conditions visible. A smart agriculture system claims it can close the loop between soil evidence and watering. A fleet tracker claims it can preserve location evidence across power, cellular, and backend constraints.

Start by naming the user decision the system supports. Facility staff might decide when to ventilate a room. A grower might decide when a zone needs water. A fleet operator might decide whether a vehicle is inside a geofence or whether a route is stale. Once the decision is clear, each requirement needs a measured artifact: calibration note, payload sample, MQTT topic, database row, dashboard state, alert record, power measurement, security assumption, and demo script.

The briefs deliberately expose trade-offs. ESP32 and Raspberry Pi Pico W boards reduce cost but force careful firmware and power choices. BME280, SCD40, PMS5003, GPS modules, LoRa radios, and LTE-M or NB-IoT modems each change wiring, library maturity, current draw, and field risk. MQTT QoS 1, TLS, local buffering, InfluxDB, Supabase, Grafana, and OTA update decisions are project evidence, not decorative architecture terms.

2.9 Keep The Thin Slice Alive

The practical route is to protect one thin vertical slice before expanding scope. For an environment monitor, that means one sensor reading, one firmware loop, one transport path, one stored row, one dashboard value, and one alert rule. For agriculture, it means one soil reading, one actuator decision, one safety interlock, and one watering record. For fleet tracking, it means one GPS fix, one cellular publish, one backend insert, one geofence calculation, and one visible route state.

Write the project ledger while building. Each row should include requirement ID, component choice, firmware or dashboard commit, test method, artifact path, result, decision, and retest trigger. A useful artifact might be a serial log, packet capture, MQTT broker trace, InfluxDB query, Supabase row, Grafana screenshot, current measurement, watchdog reset note, or wiring photo. Do not wait for the final report to organize this evidence. The report should summarize the ledger, not reconstruct it from memory.

Use the tables in each brief as starting constraints, then make the constraints local. A target such as ”> 99% data transmission reliability” needs a run length, environment, retry policy, and definition of success. A battery-life estimate needs active, idle, sleep, sensor warm-up, radio transmit, reconnect, and failure-recovery states. A security claim needs device identity, credential storage, transport protection, authorization boundary, and recovery behavior after rotation or reset.

Plan the demo as an engineering test. Show the happy path, but also show stale data, reconnect, denied action, low battery, bad calibration, actuator lockout, or geofence boundary behavior when that failure mode matters. If a feature cannot be demonstrated, leave an artifact: test log, query, screenshot, captured packet, or short video. A reviewer should be able to tell which claims were measured, which claims were only designed, and which claims are outside scope.

2.10 Integration Evidence Has Interfaces

Under the hood, capstone projects fail at interfaces. Sensor accuracy can be real while units are wrong in the payload. Firmware can publish correctly while the broker topic violates the dashboard query. A database can store rows while timestamps use device-local time instead of UTC. An alert can fire during a demo while the stale-data path is undefined. A geofence can work in one map projection while the backend stores another coordinate assumption.

Treat every interface as a contract with evidence. Device-to-firmware contracts need pinout, bus speed, calibration, units, timing, error code, and warm-up behavior. Firmware-to-network contracts need topic naming, payload schema, QoS, retry behavior, local buffer limit, and duplicate handling. Network-to-cloud contracts need identity, authorization, TLS or DTLS posture where applicable, idempotency, schema version, and retention. Cloud-to-dashboard contracts need freshness labels, missing-data states, alert owner, and permission behavior.

Evidence also needs grain. A project can record one average latency, but reviewers need to know whether the latency was per packet, per batch, per geofence event, per watering cycle, or per dashboard refresh. Power evidence should separate sensor warm-up, MCU active state, radio transmit, radio receive, sleep, and fault recovery. Security evidence should separate authentication, authorization, encryption in transit, credential rotation, and operational recovery.

Fault injection makes those contracts visible. Unplug a sensor, restart the broker, send a duplicate message, deny a dashboard permission, force a GPS timeout, or run the actuator with an empty tank flag. The point is not to make the prototype production-grade; it is to prove the team knows where the interface can fail and what evidence shows the failure was handled honestly.

The deeper test is whether the project could be repeated by another team member after a change. A new sensor library, modem firmware, cellular plan, antenna placement, dashboard query, retention policy, or enclosure can invalidate earlier evidence. Record the retest trigger next to the evidence. A capstone then becomes more than a final demo: it becomes a maintainable engineering handoff that explains why the system worked and what would need to be checked before trusting it again.

2.11 How It Works: Turn a Project Brief Into Evidence

Step 1 — Name the claim. State the user, environment, decision, and measurable outcome before choosing extra features. Step 2 — Protect the thin slice. Build one sensor-to-decision path that crosses hardware, firmware, network, storage, dashboard, and demo script. Step 3 — Attach artifacts. Store the measurement, payload sample, query, screenshot, power note, and security assumption next to the requirement they support. Step 4 — Test the boundary. Exercise reconnect, stale data, actuator lockout, low battery, denied permission, bad calibration, or geofence edge behavior when it can change the claim. Step 5 — Package the handoff. Leave a reviewer with the claim, evidence path, result, remaining risk, and retest trigger.

2.12 Deep Dive: A Capstone Is an Integration Project

A capstone project is not a collection of separate labs. It is a complete path from requirement to measured behavior: sensor input, firmware timing, network delivery, storage, security, dashboard display, alert handling, power budget, enclosure, and documentation. The hard part is making those pieces agree under realistic conditions. Read Figure 2.1 from the raw observation to the reviewer-visible outcome.

In Figure 2.1, begin with the raw sensor reading, then follow firmware formatting into radio and gateway delivery, onward through the cloud path, and finally to the dashboard update. Every arrow is an interface where units, timestamps, identity, retries, or freshness can be lost. Start small enough to prove that whole route. A reliable sensor-to-dashboard path with clear acceptance criteria is stronger than an ambitious feature list that never reaches integration.

The first useful milestone is a thin vertical slice: one real sensor, one firmware loop, one network path, one storage record, and one visible dashboard value. That slice exposes cross-layer assumptions early. A BME280 or SCD40 may read correctly on the bench, but the project is not integrated until the timestamp, MQTT topic, payload schema, database row, dashboard freshness label, and alert rule all agree. A tiny local reading becomes a larger, delayed, and failure-prone system event once headers, retries, brokers, storage, and browser rendering are included.

For each project, convert the brief into acceptance criteria that a team can run. A smart environment monitor might require SCD40 CO2 readings every 5 minutes, BME280 temperature and humidity on I2C, PMS5003 particulate readings over UART, MQTT publishing with QoS 1, InfluxDB or Supabase storage, Grafana or a web dashboard, and an alert within 60 seconds when CO2 exceeds the threshold.

Plan integration time as real work, not cleanup. Hardware may need pull-up resistors, level shifting, enclosure airflow, or sensor warm-up. Firmware may need watchdog recovery, nonvolatile configuration, timestamp handling, and OTA rollback. Network tests may reveal weak Wi-Fi, LoRaWAN duty-cycle limits, MQTT session behavior, TLS certificate problems, or duplicate messages. Dashboards may need missing-data handling and clear freshness labels.

Write each acceptance criterion as an observable run, not as a promise in the report. A useful record includes the requirement ID, firmware version or commit, hardware revision, sensor calibration note, payload sample, broker topic, database query, dashboard screenshot, measured latency, pass/fail result, and the decision that follows.

Most capstone failures are cross-layer failures. A sensor may be accurate on the bench but stale in the dashboard because timestamps are wrong. A Wi-Fi node may publish in the lab but fail in the installed room because RSSI is weak. A battery estimate may look strong until sensor warm-up, regulator quiescent current, and retransmissions are included. A secure design may pass login testing but fail device recovery because credential rotation and factory reset were not planned.

Use the data path as the organizing model. At the device, verify sampling rate, calibration constants, units, monotonic timestamps, watchdog behavior, and error codes. At the radio or gateway, record RSSI or SNR, retry count, channel plan, duty-cycle limits, local buffer behavior, and whether duplicate packets are possible. At the broker and cloud service, record MQTT QoS, retained-message policy, device identity, topic authorization, schema version, idempotency key, retention window, and alert-rule owner. At the dashboard, distinguish missing data, stale data, out-of-range data, and values suppressed by permissions.

2.13 Key Concepts

Requirements specification: A documented list of functional and non-functional requirements that must be validated before procurement or firmware development begins. System architecture diagram: A visual representation of sensors, gateways, cloud services, dashboards, integration points, failure points, and security boundaries. Bill of materials (BOM): A structured list of hardware components, quantities, and costs used for procurement and scope control. Integration testing: End-to-end testing from sensor to dashboard, distinct from unit testing individual components. Power budget: A calculation of current draw across active, sleep, sensor, and radio states compared against the battery or energy source. Over-the-air (OTA) update: A mechanism for remotely updating firmware without physical access to every device. Acceptance criteria: Specific measurable conditions a project must satisfy, such as delivery latency, battery life, alert timing, or data reliability. Field validation: Testing under realistic environmental, RF, mechanical, and operational conditions rather than ideal bench conditions.

2.14 Continue to the Next Part

Carry this evidence into Capstone Projects: Selection and Fleet Tracking, which begins with For Beginners: Capstone Projects.