Transforming Internet of Things Education Through Project-Based Learning: A Decade of Experience

Abstract

Effective Internet of Things (IoT) education requires students to integrate sensing, actuation, embedded programming, networking, and application development into complete cyber-physical systems. Achieving this integration remains challenging, particularly because students often enter IoT courses with widely varying backgrounds in hardware and networking. This paper presents a decade of experience in the iterative development of an undergraduate project-based IoT course and reports course evaluation results from four recent offerings: Fall 2020, Fall 2021, Spring 2023, and Spring 2024. The course adopts a three-stage project sequence consisting of (1) a single-node sensing and actuation system, (2) a network-connected IoT device using standard communication protocols, and (3) an open-ended capstone prototype, progressively scaffolding students from guided implementation to independent system design. We describe instructional strategies for addressing common implementation challenges, including hardware debugging, software toolchain configuration, and project scoping, and present representative student projects. Course effectiveness draws on anonymous pre- and post-course surveys together with rubric-based project assessment. Across all four offerings, students consistently reported high perceived learning gains, while final project performance remained strong across cohorts with different levels of incoming hardware experience. The course design, instructional framework, and assessment methodology provide a practical and adaptable example for project-based IoT education that can be readily adapted by other institutions to accommodate diverse student backgrounds and local curricular needs.

1. Introduction

The Internet of Things (IoT) is widely considered the next step towards a fully digital society and the IoT market is set to witness a significant surge in revenue, reaching an estimated US$1.18 trillion by 2026 worldwide [1]. As IoT applications expand across domains such as manufacturing [2], smart cities [3], healthcare [4,5], and education [6], there is growing demand for graduates who can move beyond theory and build functioning, end-to-end prototypes. At the undergraduate level, however, teaching the Internet of Things (IoT) is difficult not because any single topic is unusual, but because students must connect several layers of a system at once: sensing and actuation, embedded programming, networking, services, and user-facing applications. A review of 60 studies on IoT curriculum, pedagogy, and assessment found substantial variation in both the technical scope of IoT courses and the ways learning is evaluated [7]. Other work has similarly identified practical, technical, and instructional challenges in IoT-based teaching and learning [8]. Taken together, these studies suggest that the design of an IoT course should consider curriculum, pedagogy, and assessment as an integrated whole rather than treating the hardware platform itself as the curriculum.

Project-based learning (PBL) provides one way to organize this integration around a sustained design task. Reviews of PBL in higher education show that learning outcomes are assessed in different ways, including knowledge, technical skills, attitudes, engagement, and project artifacts [9]. Engineering PBL is also implemented in substantially different forms, making details such as scaffolding, supervision, teamwork, and assessment important when comparing course designs [10].

PBL can connect technical learning with professional practice, while project structure and assessment remain important factors in its implementation [11]. Broader evidence from undergraduate STEM also supports the value of active learning [12], although this evidence does not by itself establish the effectiveness of a particular project structure. A recent systematic review of experiential learning in engineering education found that hands-on design activities are most effective when students cycle repeatedly through building, testing, and reflecting, especially in courses with a laboratory component [13]. In an IoT course, these conditions include access to reliable components, timely assistance with debugging, and enough instructional structure for students to progress from isolated hardware or software tasks to a functioning integrated system.

Recent studies in technology-rich engineering education also highlight the importance of implementation. Challenge-based learning has been combined with Scrum, laboratory activities, and staff preparation in Industry 4.0 education [14], while other work has examined project design and evaluation in PBL environments supported by IoT and intelligent computing [15]. Although these settings differ from our course, they reinforce the importance of considering both the technology and the instructional process.

Recent IoT PBL studies also use quite different teaching and evaluation designs. One undergraduate IoT course compared a lecture-based phase with a project-based phase and examined student engagement, satisfaction, and classroom interaction [16]. Another used a three-step sequence consisting of skills preparation, project work, and evaluation, with pre- and post-course measures used to assess learning [17]. A third combined flipped instruction with PBL in an undergraduate IoT course and examined both academic performance and self-regulated innovation skills [18]. These studies show that PBL can be implemented in different ways, and that the way projects are structured and evaluated matters when comparing outcomes across courses.

Other work has focused more directly on the conditions needed to support practical IoT learning. Remote laboratories have been used to give students access to IoT hardware and programming activities when local equipment is limited [19]. PBL has also been incorporated across an entire IoT engineering degree, where tutor support and access to appropriate resources are part of the instructional model [20]. While this is more extensive than the single-semester course described here, it reinforces the importance of treating instructional support and access to resources as part of course design rather than as separate logistical issues.

Related work has also compared PBL outcomes across different engineering disciplines [21], showing that students with different disciplinary backgrounds can respond differently to a common IoT project framework.

This study takes a different perspective by examining the design and evolution of the three-project sequence, a core component of our IoT course that was introduced by Zhong and Liang [22] in 2016. While the previous work [22] focused on the effective use of Raspberry Pi for projects in IoT education, this study focuses on the three-project framework itself and its evolution rather than hardware device kits. We examine how this established project framework has been maintained and adapted as student preparation and teaching conditions have changed. We also provide a broader perspective on the project-based approach, including the use of both Arduino and Raspberry Pi, the instructional support needed to implement the projects, and course-survey records from recent offerings.

The contribution of this paper is therefore primarily practice-oriented. We describe how the course progresses from guided preparation to an open-ended system project, the support required to implement this project sequence, and how the course has evolved in response to changes in student preparation and available tools. We also summarize survey and project records from four recent offerings and discuss the limitations of these data. Although the course has evolved over approximately a decade, the quantitative results reported here are limited to Fall 2020, Fall 2021, Spring 2023, and Spring 2024.

2. Materials and Methods

The success of any project-based teaching approach depends not only on thoughtfully designed class materials and project series, but also on careful guidelines and support provided to our students. This section first outlines the course context, and then describes the three-project framework, instructional support, hardware platforms, and evaluation data. We examine how the course has been adapted for students with different levels of prior hardware and networking experience.

2.1. Course Context and Learning Objectives

Introduction to Internet of Things (CSCI 43300) is a three-credit, one-semester undergraduate course at Indiana University-Purdue University Indianapolis, now Indiana University Indianapolis. It is the only course in the department that provides hands-on hardware experimentation and emphasizes hardware–software integration through IoT system development. It is typically offered once a year, with approximately 40 students. The course brings together IoT architecture, sensors and actuators, embedded programming, wireless communication, protocol stacks, and application development. Its practical objective is to help students understand and explore IoT principles by designing, implementing, and demonstrating an IoT prototype through a three-project sequence.

Students enter with varied preparation. While the original design assumed prior networking knowledge, in practice most students have not completed that elective. Additionally, many lack prior hardware experience or even basic physics coursework, presenting unique challenges. To bridge this gap, the course integrates supplemental material covering basics of circuits (e.g., current, voltage, resistance, and Ohm’s Law), signals (digital vs. analog), and communications (e.g., radio waves, frequency, amplitude, phase, modulation). These topics are introduced alongside the project activities to provide necessary background knowledge.

The syllabus covers basic IoT concepts; smart-object node architecture; wireless LAN and PAN communication; application-layer architecture; a TCP/IP review; Micro-IP; the 6LoWPAN adaptation layer; and IoT applications.

It also includes practical assignments based on our three-project framework, emphasizing the skills and components students need to build working IoT prototype systems. Both Arduino and Raspberry Pi platforms are supported in projects, with additional preparation provided for students with limited prior hardware experience.

We note that Micro-IP and 6LoWPAN are covered through lectures as part of the broader IoT networking content, but they are not required implementation components of the student projects and are therefore not assessed through project-based implementation. The project sequence instead emphasizes hands-on integration of hardware, software, and networking using Arduino and Raspberry Pi.

2.2. Project Sequence and Scaffolding

Project work runs throughout the entire semester. Students may work individually or in self-selected pairs. The three-project sequence gradually increases in complexity, as described in Section 2.2.1, Section 2.2.2 and Section 2.2.3. Project 1 focuses on building and programming a single functional node. Project 2 adds network communication. The final project asks students to choose an application and integrate hardware, networking, and software into a complete prototype system. Student participation becomes progressively more open-ended across the project sequence. In Project 1, students work with defined inputs and parameters, such as the LED blinking frequency controlled by a button and the temperature-detection threshold. In Project 2, they select and connect sensors, expose sensor readings as CoAP resources, and inspect network traffic. In the final project, they independently choose the application, components, and overall system design.

Before Project 1, a recitation introduces basic hardware components, including breadboards, buttons, LEDs, resistors, sensors, and actuators. The instructional team also compares Arduino and Raspberry Pi, demonstrates simple programs, and reviews the laboratory inventory. Examples of previous final projects are presented to help students understand the expected scope and level of integration. Laboratory instructions and selected online resources are provided as references during project implementation.

2.2.1. Project 1: A Single-Node Sensing and Actuation System

The first project aims to familiarize students with the hardware platform and basic software development environment, focusing on the development of a single-node system for sensing and actuating. Students begin by installing and configuring either Raspberry Pi or Arduino development environment. Next, they build an application using four LEDs and two buttons—the buttons adjust the blinking frequency of the LEDs, with three LEDs displaying the frequency level. Students then integrate a temperature sensor and use a threshold value to control one LED. The main purpose of this project is to help students become comfortable with basic circuit construction, sensor input, and program-controlled output before moving on to networked applications.

2.2.2. Project 2: Connecting the Node to the Internet Through CoAP

Project 2 adds network communication to the system developed in Project 1. Students develop a simple CoAP server, connect one or more sensors, and make the sensor readings available as resources that can be requested by a client. They are also guided to use Wireshark to inspect and analyze the communication between devices.

Arduino-based projects use an ESP8266 ESP-01 module for Wi-Fi connectivity, while Raspberry Pi projects use the available network interface or an external adapter when needed. The purpose of this project is to help students understand how sensor data can be made available through a network service.

In our earlier offerings of the course Copper was used as a graphical CoAP client. Because this browser-based tool is now outdated, students now can use currently supported alternatives such as the Python-based aiocoap-client [23] or libcoap’s coap-client [24]. The main learning objectives of the assignment remain the same: setting up a CoAP server, accessing sensor resources, and examining network communication traffic.

2.2.3. Final Project: An Open-Ended IoT Prototype System

For the final project, students are asked to develop a comprehensive IoT prototype system with wireless smart objects incorporating 3–6 sensors or actuators. Unlike the structured approach of the first two projects, this final project is open-ended, giving students greater freedom to choose their own topics and explore ideas that interest them personally. This flexibility allows them to work on projects aligned with their career goals or personal passions, whether that is home automation, environmental monitoring, or other creative applications. However, the scope must remain realistic for the available time and equipment.

To ensure project feasibility, detailed proposals early in the process are required. During the proposal review, we evaluate the workload and complexity of each project, providing feedback and suggestions to help students refine their ideas. This process helps students keep the project scope realistic for the semester while still being appropriately challenged. It also allows us to identify potential technical hurdles early on and guide students toward solutions or alternative approaches.

The final project gives students an opportunity to integrate hardware and software, practice system design and analysis, and communicate their work through a written report and presentation. We encourage students to explore electronic components beyond those used in previous projects. Over the years, students have incorporated a wide range of components, including temperature and humidity sensors, cameras, soil-moisture sensors, load cells, LCD displays, motion sensors, AD converters, pressure sensors, sound sensors, flame sensors, lasers, servos, relays, and other sensors and actuators. Representative examples of students’ final projects are presented in Section 3.1.

2.3. Instructional Supports and Implementation Considerations

Implementing this project-based approach brings unique challenges compared with theoretical computer network courses. The integration of hands-on hardware experience with software development significantly increases instructional workload, requiring additional support for both students and faculty. This gradual progression from guided exercises to more independent project work is consistent with PBL approaches that emphasize structured guidance and feedback as students take greater responsibility for their work [9,10,11].

Students who choose to work in pairs generally remain with the same partner throughout the project sequence. The first two projects provide guided practice, while the final projects vary across teams and therefore demand more individualized support. We use an intermediate progress check, during which students report their progress and receive feedback on implementation problems, integration, and project scope before completing the final system. This helps students manage their final project schedule and allows us to identify any potential issues early on. We also provide laboratory space for teams to work together and discuss technical problems and possible solutions with teammates and other groups. These interactions are encouraged as part of the learning process, although they are not used as a formal peer-grading activity.

Our implementation requires continuous hardware management and technical support. We regularly inspect devices to ensure proper functionality, provide detailed laboratory instructions, and manage the distribution and return of equipment each semester. Maintaining an adequate inventory of sensors, microcontrollers, and other components requires careful budget planning and procurement. Technical support is also needed throughout the projects because problems may involve hardware connections, software libraries, device configuration, or networking rather than a single component.

Instructional consistency has been another key factor. Over the past decade, the course has been taught by the same instructor with support from teaching assistants, ensuring stability in pedagogy and assessment.

2.4. Hardware and Software Platforms

We center our labs on two accessible, complementary platforms: Arduino microcontrollers and Raspberry Pi single-board computers. These choices balance simplicity with versatility. Arduino’s straightforward pin-based interface makes it well-suited for basic sensing and actuation tasks, while the Raspberry Pi’s full Linux environment supports networking, data processing, and higher-level programming. Both platforms are inexpensive, widely documented, and backed by large user communities—qualities that lower the entry barrier for students new to hardware development. Our laboratory currently maintains an inventory of 10 sets of Arduino Uno Rev 3 toolkits and 15 sets of Raspberry Pi toolkits: 6 sets of Raspberry Pi 2, 5 sets of Raspberry Pi 3, and 4 sets of Raspberry Pi 4. Each project team, whether an individual student or a pair, receives one toolkit based on students’ preference and availability.

2.4.1. Arduino and ESP8266 Platform

The Arduino Uno Rev 3 serves as the primary entry point for students with little or no hardware experience. Its plug-and-play setup, resilience to wiring mistakes, and straightforward coding environment make it particularly suitable for beginners.

To introduce wireless communication, we supplement the Arduino with the ESP8266 Wi-Fi module. Its low cost, compact form factor, and versatility make it a practical solution for embedding Wi-Fi functionality into microcontroller-based systems. Rather than focusing on low-level specifications, we emphasize how this module enables students to transform a basic single-node circuit into a network-connected device. This progression illustrates the transition from isolated embedded systems to connected IoT nodes, which is central to the course’s pedagogical goals.

2.4.2. Raspberry Pi Platform

The Raspberry Pi provides another option for projects requiring higher computing power, networking, or multimedia capabilities. Unlike Arduino, it offers a complete operating system environment, giving students the opportunity to experiment with programming in Python, Java, or other languages, to configure servers, or handle data storage and visualization. By maintaining multiple Pi models across nearly a decade of hardware evolution, we can allocate hardware based on project scope while supporting a common software environment across projects.

For example, students working on projects involving real-time video feeds or cloud-based applications often select the Raspberry Pi, while those focusing on low-power sensing tasks may remain with Arduino. This choice encourages students to critically evaluate hardware trade-offs—an important skill in real-world IoT system design.

2.5. Assessment Design and Data Sources

To document the course and support its ongoing refinement, we draw on routinely collected course assessment artifacts rather than a purpose-built education research instrument. The surveys were administered to assess incoming student preparation and to gather end-of-semester feedback to guide future course offerings. While these data do not constitute a control-based study, they provide meaningful insight into student experiences, engagement, and perceived learning for formative evaluation and ongoing course improvement. To complement these self-reports, we also summarize project performance using a rubric that captures both technical implementation and broader outcomes such as documentation, analysis, and communication. We focus our quantitative summaries on four recent offerings (Fall 2020, Fall 2021, Spring 2023, and Spring 2024) because these are the semesters for which consistent survey and rubric records are available, while the course design itself reflects iterative development over roughly a decade.

At the start and end of each offering semester since 2020, students completed anonymous online surveys. The pre-course survey captured prior exposure to circuits, embedded platforms (Arduino/Raspberry Pi), networking, Linux, and prior IoT experience (Appendix A). The post-course survey asked students to rate learning gains on a four-point scale (1 = “a little” to 4 = “very much”) and included open-ended prompts about challenges and suggestions. The surveys were designed as local feedback instruments rather than validated multi-item learning scales. The overall learning measure consists of a single item, so an internal-consistency measure such as Cronbach’s alpha is not applicable. The background questions likewise assess different types of prior experience rather than a single underlying construct.

In addition to self-reports, final projects were evaluated using a rubric that emphasized both technical implementation and higher-order outcomes such as creativity, analysis, documentation, and communication.

3. Results

3.1. Representative Student Projects

To illustrate the range of systems developed in the course, we present several final projects from recent offerings. These examples highlight the integration of sensing/actuation, networking, and application-layer interfaces within realistic constraints such as component reliability, limited compute resources, and incremental debugging.

3.1.1. Pet Autofeeder (Raspberry Pi)

This project involves the design and implementation of a motion-activated cat treat dispenser. When the motion sensor detects movement, the system dispenses treats and simultaneously activates a camera to record a 10-s video clip. Once recording completes, the video is automatically emailed to the user. The hardware components include a Raspberry Pi 4, a Tower Pro SG92R Micro Servo, an AM312 PIR Motion Sensor, and a Raspberry Pi Camera, with the application script written in Python 2.7. The prototype is shown in Figure 1. Inside the box, the camera connects to the Pi via ribbon cable to the dedicated Camera port. A breadboard mounted on the left interior side creates the central connection hub between all components and the Pi. The project emphasized system integration and user experience design.

Figure 1. The pet autofeeder system (student project; used with permission). (a) Final prototype box. (b) Internal circuit layout. (c) A display for treat distribution process.

3.1.2. Remote and Automated Plant Watering System (Arduino)

This system monitors soil moisture and environmental conditions, and it automatically waters plants when soil moisture falls below a predetermined threshold, while also allowing users to remotely trigger watering for specific durations. Using HTTP protocol, it wirelessly displays critical environmental data—temperature, humidity, and soil moisture percentage—through an intuitive website interface as Figure 2a shows. Clients can access the web server to monitor and control the system. The implementation requires various sensors and actuators working together in a comprehensive manual/automatic watering system. Key components include a Peristaltic Pump (actuator), Capacitive Soil Moisture Analog Sensor, DHT-11 Digital Temperature and Humidity Sensor, and a 5 V Relay (actuator) as shown in Figure 2b,c. Additional essential parts include a 12 V DC 1A External Power Supply, 12 V DC Female Power Connector (2.1 mm), Silicon Tubing (2 × 4 mm), and an ESP-01 WiFi Module. The project demonstrated how sensor feedback can be translated into actuation logic and integrated with networked user interfaces.

Figure 2. The remote and automated plant watering system (student project; used with permission). (a) Web client webpage. (b) Circuit design. (c) Physical prototype.

3.1.3. Smart Rover (Arduino)

This project draws inspiration from the Mars Rover, creating a wirelessly controlled vehicle with video feedback capabilities for remote operation. The student selected the Arduino UNO Wi-Fi rev 2 as the main controller, leveraging its Microchip MEGA4809 processor and integrated ESP32 u-blox NINA-W13 Wi-Fi Module. The NINA-W13 Module functions as a self-contained System-on-Chip (SoC) with built-in TCP/IP protocol stack, enabling both network access and access point functionality. The rover’s physical construction incorporates an L298N Motor Driver, TT motors, power supply, and a car chassis. Additionally, the student integrated an ESP-32 CAM module to transmit real-time video back to the server. Figure 3 shows the circuit and assembled vehicle.

Figure 3. The smart rover (student project; used with permission). (a) Circuit design. (b) Prototype vehicle.

3.1.4. Garage Parking Distance Assistant (Raspberry Pi)

This project implements a smart garage parking assistant to guide drivers into optimal parking positions. It uses an HC-SR04 ultrasonic distance sensor to detect the precise position of a vehicle in the garage and a WS2812B LED light strip to send visual feedback. The main circuit is illustrated in Figure 4a. When a vehicle enters the sensor’s detection range, a single LED indicator illuminates at the top of the strip as shown in Figure 4b,c. As the vehicle approaches the sensor, this indicator progressively moves downward, changing color from green to yellow to red to indicate proximity. Once the vehicle comes within 60 cm of the sensor, all LEDs on the strip glow red, signaling the driver to stop. If the vehicle remains stationary within the optimal range for 10 s, the LEDs automatically switch off to conserve energy. The system also functions when backing out, with the LED indicator moving upward along the strip as the vehicle exits.

Figure 4. Parking distance assistant (student project; used with permission). (a) Circuit design. (b) LED indicator in “safe” state. (c) LED indicator in “unsafe” state.

Additionally, the project incorporates a Flask web server that streams live footage from a Raspberry Pi camera over the network, providing both a real-time view of the parking space and an LCD display showing distance measurements and parking status as illustrated in Figure 5. In short, this project demonstrated human–computer interaction design and multimodal feedback.

Figure 5. Web interface displaying car status (student project; used with permission). The three displayed states are (a) “CAR DETECTED”, (b) “MOVING”, and (c) “CAR PARKED”.

3.1.5. Smart Doorbell (Raspberry Pi)

This project is a smart doorbell combining motion sensing, video capture, and customizable notifications. It allows users to check on their front porch when they are away and receive alerts when someone or something approaches the door. They can then check the doorbell’s recorded video to find what is at their door and play an audio clip or leave an audio message. The ring sound for the doorbell is also customizable, and the user can upload their own sounds for extra customization. In addition to the Raspberry Pi, several other electronic components were used—a HiLetgo HC-SR501 PIR Infrared sensor for motion detection, and a Raspberry Pi Camera Module 2 for images and videos. The circuit design and the doorbell setup are shown in Figure 6. For the doorbell button, a KKSB 12 mm push button was added. To provide some visual feedback, they used one red and one green LED. A CHANGEEK CGS-M1 USB mic was for recording audio. The API for the doorbell was written in Python, using the Flask framework. The system highlighted the use of APIs, cloud connectivity, and user interface design.

Figure 6. Doorbell system (student project; used with permission). (a) Component connections. (b) Front view of the physical setup. (c) Back view of the physical setup.

The client UI (user interface) was a simple HTML/CSS/JavaScript web application. Figure 7 gives a webpage example. To make it easier for testing and connecting to different networks, the address for the doorbell API was stored in a config script that was loaded in each of the pages. Each page also shared a Socket.IO script to handle the events sent from the API. The requests to the API were handled using fetch in JavaScript.

Figure 7. Example of the smart-doorbell client interface (student screenshot; used with permission).

3.1.6. Summary of Student Achievements

Collectively, these projects illustrate the range of systems developed within the open-ended final project. Students combined hardware, networking, and application-layer components in different ways depending on their chosen application.

3.2. Course Assessment Results

3.2.1. Surveys and Student Backgrounds

Pre- and post- surveys were conducted for four offerings (Fall 2020, Fall 2021, Spring 2023, Spring 2024), from which student background information is partially summarized in Table 1. Because the surveys were used primarily to understand student preparation and support course improvement, these results are interpreted descriptively rather than as measures of instructional effectiveness.

Table 1. Selected background indicators across the four course offerings.

Background Indicator	Fall 2020	Fall 2021	Spring 2023	Spring 2024
Have done any IoT project or used sensors prior	49%	20%	35%	10%
Never used Arduino/Pi (Pre-class)?	54%	66%	56%	67%
Taking or have taken Networking course?	44%	46%	21%	33%
No prior Linux experience?	10%	7%	5%	8%
Some prior experience with IoT/Internet software tools/protocols?	46%	78%	84%	82%

One of the clearest differences was in prior experience with IoT projects or sensors. In Fall 2020, 49% of respondents reported previous experience in this area, compared with 10% in Spring 2024. The intermediate values, however, were 20% in Fall 2021 and 35% in Spring 2023, so this should not be interpreted as a steady year-by-year decline. Prior experience with Arduino or Raspberry Pi was also limited across all four offerings. The percentage of students reporting no previous use of either platform ranged from 54% to 67%, with the highest value occurring in Spring 2024.

Reported experience with Internet or IoT software tools was higher in the later offerings. This increased from 46% in Fall 2020 to 78% in Fall 2021, 84% in Spring 2023, and 82% in Spring 2024. In contrast, only 5–10% of respondents reported no prior Linux experience across the four offerings. This suggests that most students had at least some exposure to Linux, although the survey did not measure the depth of that experience. Participation in the department’s computer networking course also varied across offerings. The reported percentages were 44%, 46%, 21%, and 33%, respectively. Because this question asked whether students were currently taking or had previously taken the networking course, it is treated here as general background information.

Post-course survey ratings of perceived learning were summarized using counts and percentages, together with the mean, standard deviation, median, and interquartile range in Figure 8 and Table 2. Differences among the four offerings were examined using the Kruskal–Wallis test, with rank epsilon-squared reported as an effect-size measure. Survey response counts are reported separately from course enrollment and final project completion counts because these measures represent different groups of observations.

Figure 8. Self-reported overall learning gains at the end of each course offering. (a) Fall 2020. n = 39. (b) Fall 2021. n = 37. (c) Spring 2023. n = 38. (d) Spring 2024. n = 39.

Table 2. Post-Course Self-Reported Learning Gains by Cohort ¹.

	Fall 2020 (n = 39)	Fall 2021 (n = 37)	Spring 2023 (n = 38)	Spring 2024 (n = 39)
4—very much (%)	43.6	32.4	47.4	35.9
3—a lot (%)	33.3	54.1	28.9	53.8
2—moderate (%)	23.1	10.8	23.7	10.3
1—a little (%)	0.0	2.7	0.0	0.0
Mean (SD)	3.21 (0.80)	3.16 (0.73)	3.24 (0.82)	3.26 (0.64)
Median (IQR)	3 (3–4)	3 (3–4)	3 (3–4)	3 (3–4)
Rated 3 or 4 (%)	76.9	86.5	76.3	89.7

¹ n refers to valid responses to the end-of-course survey. Kruskal–Wallis test: H(3) = 0.33, p = 0.95, ε² = 0.002.

Open-ended survey responses were reviewed for recurring comments about project difficulties and possible course improvements. These responses are used as formative feedback and are reported descriptively rather than as a formal qualitative analysis.

Taken together, these results show noticeable differences in student preparation across the four offerings. This change has concrete instructional consequences. The relatively limited hardware experience in more recent offerings supported our decision to provide more structured preparation in circuit basics, sensor wiring, and hardware troubleshooting. Conversely, the greater reported familiarity with IoT software tools in recent cohorts creates opportunities to integrate more advanced protocols, data visualization, and lightweight data-driven components.

3.2.2. Perceived Learning and Assessed Project Work

Across the four offerings, students reported high perceived learning, while final project performance was also strong. Post-course surveys asked students to rate their overall learning gains on a four-point scale (1 = “a little,” 4 = “very much”). Figure 8 and Table 2 summarize the response distributions. Mean ratings were stable across cohorts (range 3.16–3.26) and between 76% and 90% of students in each offering rated their learning as “a lot” or “very much.”

The Kruskal–Wallis test found no statistically significant difference in these ratings across the four offerings. The very small effect size (ε² = 0.002) also indicates little variation in the distribution of self-reported ratings across cohorts. However, this result should be interpreted only as a comparison of students’ perceptions across offerings. It does not show that students in all cohorts learned the same amount or that differences in prior preparation were eliminated.

To complement survey data with a performance-based measure, we evaluated all final projects using a structured rubric. Table 3 summarizes the criteria and weighting used in the current rubric. This rubric emphasized both technical implementation and higher-order outcomes such as creativity, analysis, and communication. Bonus points could raise a project score up to, but not above, 100. The overall structure of the rubric remained stable across cohorts.

Table 3. Current Final Project Evaluation Rubric (Max: 100 points).

Criterion	Points
An IoT application proposal	10
Knowledge of IoT development and protocol environment	10
Solid design of IoT architecture and system	10
Successful and complete implementation of the system	30
Analysis of the application results including Wireshark	10
Clarity and care in report writing	15
Insightful discussion and observations	10
Quality of presentation and demonstration	5
Base Total	100
Bonus: Special contributions (e.g., new ideas, discoveries, or particularly insightful work)	Up to +10

Students could complete the final project individually or in pairs. Project expectations were adjusted when a student worked individually to account for the difference in workload. For paired projects, students also submitted a percentage allocation describing their respective contributions, which was considered when assigning individual grades. The same overall rubric was used to evaluate the final project across both arrangements.

The number of valid post-course survey responses differed slightly from course enrollment and final-project submission counts because the surveys were completed separately from graded coursework. Survey response counts are therefore reported with the survey results, while final-project submission counts are reported separately in Table 4. Completion rates were high across all offerings (94.9–100%), median scores ranged from 89 to 94 out of 100, and at least 89% of submitting students scored 80 or above in every cohort. These results show that students generally performed well on the final project across all four offerings and are consistent with the use of a structured project-based approach across cohorts with different levels of incoming preparation.

Table 4. Final Project Performance by Cohort.

Metric	Fall 2020	Fall 2021	Spring 2023	Spring 2024
Students completing final project/enrolled students	38/39	37/38	37/39	39/39
Median rubric score (out of 100)	91	94	89	93
Projects scoring ≥ 80 (%)	92.1	97.3	89.1	92.3

In the open-ended responses, students frequently identified the hands-on project work as one of the most valuable parts of the course. In survey responses, many emphasized that the opportunity to build real IoT systems, troubleshoot connectivity issues, and see theoretical concepts function in practice gave them a deeper understanding than lectures alone could provide.

3.2.3. Reported Challenges

Open-ended survey responses provided additional insight into the difficulties students encountered during projects.

Early cohorts (Fall 2020 and 2021): Students most often struggled with software issues, particularly installing libraries, using CoAP protocols, and debugging networking code. Many cited the instability of early open-source tools as a major barrier.

Recent cohorts (Spring 2023 and 2024): Students encountered difficulties primarily with hardware—sensor reliability, circuit assembly, and basic breadboarding. They also expressed frustrations about physical components not working as expected, highlighting their limited prior experience.

Across all cohorts, one challenge remained constant: the complexity of integrating hardware and software into functioning systems. Students consistently noted that while individual components could be made to work, combining sensors, networking, and application layers was significantly harder. This reinforces the rationale for our three-project structure, which incrementally builds skills before the open-ended final project.

3.2.4. Student Recommendations

Open-ended questions in the post-course survey invited students to suggest future course improvements. Valid responses were reviewed for recurring suggestions, which generally fell into three areas: hardware and laboratory support, collaboration and peer learning, and greater exposure to current IoT applications.

Hardware and Lab Support: Students asked for clearer hardware guidelines and technical documents, a list of reliable sensors, and more structured troubleshooting support. For example, one wrote, “I want more lab time and maybe you can share more different project ideas with different types of sensors/actuators used in different ways.”

Collaboration and Peer Learning: Many emphasized the benefits of teamwork and recommended more structured peer interaction. One student reflected, “Discussion with my teammate and other teams in lab was where I learned the most.” This feedback supports us to add scheduled peer-review checkpoints in future offerings.

Real-World Relevance and Emerging Topics: Students expressed strong interest in connecting IoT projects to current industry practices, suggesting modules on Bluetooth, IoT security, and even machine learning.

4. Discussion

In this section, we interpret the observed patterns and summarize implications for instructors designing similar IoT courses.

4.1. Course Improvements and Implications

Across the recent four offerings, students generally reported high perceived learning, while final-project performance also remained strong despite differences in incoming preparation. These observations are consistent with broader PBL research emphasizing the importance of structured guidance, feedback, and assessment when students work on complex engineering projects [9,10,11]. Recent IoT-focused PBL studies likewise show that staged preparation and guided project work can support students as they move toward more complete system development [16,17,18]. A recent comparison across different engineering cohorts also shows that students’ backgrounds can influence how they experience IoT project work [21]. Our results add a complementary perspective by following several offerings of the same computer science course as student preparation changed over time.

Beyond survey and rubric measures, we also noticed signs of engagement. Students frequently extended their work beyond the course requirements, and many voluntarily donated sensors and electronic components they purchased to support future cohorts, with contributions totaling several hundred dollars over recent semesters. These voluntary contributions were not measured as a formal learning outcome, but they provide one practical indication of the engagement and sense of community that developed around the course.

Going forward, we plan to strengthen early instruction in basic circuits, sensor use, and hardware debugging, particularly for students with limited prior hardware experience. In addition, we plan to provide the final project assignment and supporting materials earlier in the semester, giving students more time to plan, explore options and organize their work effectively. Meanwhile, students’ stronger software backgrounds will allow us to incorporate more advanced networking and data processing tasks.

Some student suggestions, however, would be better considered within the broader computer science curriculum rather than added directly to a single IoT course. Given that the department already offers several courses in machine learning, artificial intelligence, and security, duplicating content in our course may not be practical due to capacity constraints. Instead, we propose guiding students to integrate knowledge from these various courses into comprehensive practices and projects, such as combining IoT with machine learning. In this context, the department’s capstone project course serves as an ideal platform. We have actively encouraged students to pursue IoT-related projects in their capstone course and have provided ongoing support and guidance to those students.

More broadly, recent IoT education studies show that project-based courses can be organized differently depending on available equipment, instructional support, course duration, and student background. Some use remote laboratories to provide access to hardware [19], while others incorporate PBL across larger IoT programs [20]. These examples suggest that the three-project framework described here is best viewed as an adaptable framework whose implementation may vary across institutions.

4.2. Limitations and Future Work

While our findings are encouraging, there are several limitations.

Reliance on self-reports: Student surveys provide valuable perspectives but might overstate learning due to enthusiasm or novelty effects.

No control group: Without a lecture-based comparison cohort, causality cannot be claimed. We present our results as descriptive evidence from this course rather than as a causal test of instructional effectiveness.

Instructor consistency: The same lead instructor taught every course offering for a decade, including the most recent four, which ensured continuity but would potentially limit generalizability of the findings to other instructional settings.

Cohort-level comparisons: Table 1 highlights differences in incoming preparation, but our analysis is primarily descriptive and based on course-improvement surveys rather than controlled experimentation. Future work will apply additional statistical modeling to examine trends with greater rigor.

Survey design: The surveys were developed for course feedback and improvement rather than as validated educational research instruments. Future work could include more structured pre- and post-course measures and additional validation of the survey items.

Project assessment: Final-project scores reflect performance on supported course work, and some projects were completed in pairs. These scores therefore show how students performed on the assigned projects but do not provide an independent measure of individual learning gains. The present evaluation does not allow us to isolate the contribution of individual project components or fully distinguish learning gains from the effects of scaffolding or prior preparation.

Future offerings will incorporate more objective, baseline-controlled measures of learning. In particular, we plan to develop pre- and post-course conceptual diagnostic assessments aligned with the course learning objectives and to retain project performance at the individual rubric-criterion level. These measures will enable more direct analysis of learning gains and the relationship between specific project activities and learning outcomes, while providing a stronger basis for comparison across cohorts with different levels of prior preparation. Future assessment can also include cross-institutional studies, validation of survey instruments, and external evaluations of project outcomes.

5. Conclusions

This paper presents a project-based IoT curriculum that has been refined over nearly a decade and evaluated through surveys and rubric-based project assessments across four recent course offerings (2020–2024). The core instructional design is a three-stage project sequence that progressively scaffolds students from basic embedded sensing and actuation to networked IoT communication and, finally, to an open-ended prototype that integrates hardware, networking, and application-layer design and development.

Across cohorts, survey responses indicated high perceived learning gains, and rubric-based final project performance remained strong despite different levels of incoming hardware experience. These observations are consistent with the value of structured scaffolding, early proposal feedback, and regular mentoring in supporting students with different levels of prior preparation.

For instructors considering similar courses, the main takeaways are pragmatic: select platforms that tolerate beginner mistakes, provide repeatable troubleshooting workflows, and budget staff time for iterative project guidance. At the same time, course design should remain responsive to shifting student preparation by strengthening foundational hardware support when needed and leveraging stronger software skills to introduce modern IoT practices.

Overall, the course framework and assessment approach provide a practical example that may be adapted by programs seeking to incorporate hands-on IoT education within typical undergraduate resource constraints.