Keywords

1 Introduction

Every day, more and more everyday objects are becoming “smart.” With new capabilities such as sensors, computing power, and Internet connectivity, these smart, connected objects have significantly improved capabilities and new applications. Designing, connecting, improving, and securing these everyday “things” to the Internet is now a rapidly growing field, now known as the Internet of Things (IoT).

Since the “Internet of Things” term was first coined in 1999 [1], IoT technology has evolved and spread quickly. IoT and smart, connected devices are already impacting industrial, manufacturing, technology, healthcare, and consumer markets and will continue to do so. In 2019, $750 billion dollars were spent on IoT [2]. By 2023, it is expected the field will grow to over one trillion dollars [3]. As this field has grown, so does the need to effectively teach and expose students to this new area of computer science.

Currently only a few institutions in the California State University system offer courses in IoT, but interest in the area is rising. As interest in IoT continues to grow, we expect the number of courses to increase as well.

One key challenge of designing and teaching IoT courses is the highly interdisciplinary nature of IoT and its increased focus on hardware. To successfully understand, design, and build IoT projects, students and educators need a broad background in software and hardware, and also need to understand how to make software and hardware work well together. In teaching and learning IoT, students and educators may be exposed to many topics outside of the traditional computer science curriculum, including hands-on hardware prototyping and debugging, wireless sensors, wireless communications, and design tradeoffs to optimize power, performance, or device size. Another important consideration is making hardware kits and tools available to students for hands-on projects and labs. Since these parts likely need to be purchased and made available to students, one must also consider budget and materials availability when designing projects and assignments. Having dedicated lab space and space for student groups to work outside of class is also very beneficial.

Even when budget, space, and materials are available, successfully selecting and integrating hardware and materials into labs can be extremely challenging and time-consuming. Many kits, hardware, and software are available, yet educators need to provide ones which are easy to use, versatile enough to be used in many projects, and reasonably priced to fit in department budgets. While IoT courses are becoming increasingly popular, very limited information is available regarding which types of hardware and kits work best with IoT courses, and how to best integrate hardware into the IoT curriculum. This lack of existing material can make setting up a new course very challenging.

With these challenges and considerations in mind, we share in the present work how we designed, prepared, and taught an IoT course at California State University, East Bay. The course requires prerequisite knowledge in data structures, networking, and C++ and was open to graduate students as well as advanced undergraduates. We have now taught the course for two semesters (Fall 2019 and Spring 2020) and are able to share lessons learned and outcomes based on these two semesters. We especially focus on sharing information about the hardware, components, and software packages used in the course and why we chose them. We anticipate that these lists of materials, lab activities, and recommendations will be beneficial to educators and others looking to develop courses in the IoT field.

We start by examining related work in Sect. 2. We examine classes that cover IoT content and the different approaches used to teach IoT at several other universities. Next, we discuss how we designed our course in Sect. 3. We then describe and list the hardware kits used in the course in Sect. 4. In Sects. 6 and 7, we discuss our first two experiences teaching the course and the lessons learned from each semester. Section 8 documents changes to the course and next steps. Finally, we summarize our findings in Sect. 9.

2 Related Work

In designing our IoT course, we first examined teaching approaches used by others in the field. As previously mentioned, IoT is a highly interdisciplinary field covering many technical areas. As a result, many different departments offer different versions of IoT. IoT courses tend to be offered under computer science, computer engineering, information systems, and electrical engineering departments [4,5,6]. However, course offerings have also been seen in departments such as business [7] and even art [8]. In addition to offering individual courses, there are also programs and certificates with a focus on IoT [6].

The learning objectives, student audience, hardware vs software focus, and topics covered vary greatly from course to course. Most courses cover a combination of both software and hardware topics. For example, the instructors of [5] utilize a hardware and web-service approach. Students are given kits and work in groups of two to three students. Projects are utilized for the midterm and final exams with the topic of the project chosen by the students. A small budget is available to buy components for projects. In order to get components, students must justify the purchase to the instructor through an “investor” pitch. In addition to projects, students are also given assignments and quizzes. For their choice of platform, students utilized microcontroller hardware made by Particle [9]. An advantage of this platform is that it comes with administrative cloud software for managing devices. The drawback for these devices is that they are roughly two to four times the cost of other similar platforms.

Since hardware can be a challenging topic for software-focused students, other IoT courses choose a more application and service oriented view of IoT with little to no use of hardware. For example, the instructors of [4] use readily available REST APIs for student assignments. They start with scaffold examples showing how an existing REST API, such as a publicly available transportation API, can be used and then show how different public REST APIs can be combined. Students then create their own IoT services that can in turn be combined with other IoT services. This approach has the advantage of being able to capture the “spirit” of IoT with minimal cost, hardware, and prior knowledge. A student with basic CS knowledge would be able to understand and create IoT applications and services. However, this approach is one-dimensional. It does not capture other issues common in IoT such as sensor limitations, energy conservation, fog computing, and architecture design.

Also important to note is that group work is a common feature of many courses [4, 5]. Though not explicitly stated, this is likely due to availability of hardware. Purchasing kits, hardware components, and software licenses can get costly for both students and universities. Additionally, with components, software, and protocols frequently changing, keeping components up to date may become challenging. While group projects can be a valuable part of an IoT course, it is also important to implement peer evaluations and incentives to encourage all group members to contribute to and understand their projects [10].

3 Approach

Given the interdisciplinary and changing nature of IoT, there are many considerations needed to design a course for IoT. Do we focus of the current state of the technology and the protocols in the marketplace? Do we focus on software, hardware, or a combination of the two? If we utilize hardware, how do we handle material? How much does hardware cost? How much prior experience is needed with hardware? Given that many different technologies are used in IoT, how do we make material deep enough to be useful yet broad enough that students do not get bogged down in unnecessary details? These are just a few of many considerations. We explain our key considerations and our thought process behind our course design in the following sections.

3.1 Audience and Assumptions

In our IoT course, we targeted the material toward graduate students and advanced undergraduate students in computer science. We needed our students to have a solid foundation in computer science. We therefore required that students have taken coursework in data structures, algorithms, and networking. We also required a familiarity or the ability to use C++ since the Arduino modules we had available in our hardware kits use C++. Since most computer science students at CSUEB have limited coursework in hardware, we assumed students have little or no exposure to embedded systems or hardware. We also limited the number of students in each class to thirty students. Keeping the class size small allowed the students to work in smaller groups of 2–3 students per group. This allowed us to stretch our materials and hardware budget to provide as many parts as possible, and helped students more easily get individualized help on projects.

3.2 Course Structure

Our goal in developing our IoT course was to provide students a broad introduction to the IoT field in general, as well as the opportunity to gain hands-on experience in hardware and prototyping for IoT. Based on our review of other IoT courses, we determined that combining hardware and software topics is essential in order for students to gain a solid introduction to IoT. Hands-on hardware projects allow students to experience firsthand some of the many challenges one might face when designing, testing, and improving IoT devices. Also, many computer science students at CSUEB would otherwise have little or no prior introduction to hardware and prototyping. The IoT course provided a valuable opportunity for these students to gain exposure to hardware. Therefore, we decided to make the course contain a significant lab component.

To allow sufficient time for both teaching IoT concepts and gaining hands-on practice, we decided that about half of the class time should be lecture-based, with the remaining half dedicated to labs and building hardware skills. The IoT course was scheduled to meet twice weekly for two 90-min periods. Each week, the first 90-min section was dedicated to lecture and introduce topics. The second 90-min section was reserved for completing hands-on lab assignments.

Given the hands-on nature of IoT, a significant portion of the course grade was dedicated to completing the hardware labs and assignments. To further emphasize the importance of students understanding each assignment, students did not simply “turn in” a finished lab. Instead, students needed to demo their working assignment with the professor or teaching assistant in order to demonstrate full understanding of the assignments. Additional office hour time was therefore reserved for “grading hours,” in which students would demonstrate that their assignment was complete and working.

Many of our students were seeking to gain experience in IoT for their resumes or for capstone projects. With this in mind, we decided to also assign a final project, allowing students to build a working IoT device. To help students apply the skills and concepts from the labs, the final project was required to embody key elements of IoT, including leveraging one or more sensors, using communication protocols, and performing data management. During week 7, instead of having a lab activity, each group of students prepared a proposal of their final project idea and presented it to the class in an “elevator pitch” presentation. During the elevator pitches, other students and the instructor would provide written feedback to help each group improve their ideas. Finally, during the last 1–2 months of the semester, students would complete the final project. Some students even chose to use their final project from the IoT course as a starting point for their capstone or thesis project.

This increased focus on labs and hardware skills also required that we design labs and hardware kits for the students. Ideally, we would be able to provide individual kits for every student; unfortunately our budget allowed us to purchase only one kit per 2–3 students. Since students would be working in groups for the entire semester, we also implemented measures to incentivize students to learn the projects and contribute equally. First, as part of the grading process, both lab partners were required to demo and explain each project. Rather than simply turning in a lab report, all group members needed to show that they understood each lab in order to receive full credit. Second, we included a peer-review component as part of the final course grade. Finally, we also included individual assessments in the course grade to ensure each student individually understood the material. The first time we offered the course, both a midterm and final exam were given. The second time we offered the course, we replaced the midterm and final exams with weekly online quizzes, to free up more class time for hands-on prototyping. Details of the grading breakdown are as follows: 30% In-Class Assignments, 5% Participation/Peer Reviews, 10% Midterm, 10% Initial/Final Project Proposals, 45% Final Project Presentation and Report.

3.3 Introducing Key Hardware Skills Through Hands-on Labs

As mentioned previously, we believe exposure to hardware is a critical component to IoT. However, since the hardware and software used in IoT can rapidly change, it can be challenging to decide which topics to focus on. We therefore chose to focus on core concepts that are likely to persist rather than areas of IoT such as protocols, which are continually changing. One area of IoT which continues to be important is understanding how to successfully prototype and integrate hardware and software together. Rather than having students memorize protocols and hardware components which might go out of date, we kept the focus on developing key skills for designing, troubleshooting, improving, and evaluating IoT devices.

Many students in computer science are not familiar with hardware. To address this need, we specifically designed our lectures, labs, and projects to gradually introduce key hardware skills to students. These topics are shown by Table 1. We used the lecture to introduce each topic, and then the students would gain hands-on practice during the lab portion in the following class meeting.

Table 1 Schedule of topics covered in the IoT course
Full size table

For example, during the Sensors and Actuators week, we used the lecture portion of the class to teach students about how to read spec sheets and how sensor devices work. Then, during the lab portion, students gain firsthand practice on reading a sensor’s spec sheet, connecting software to the sensor, and collecting data remotely from the sensor. Students need this experience to enable them to design feasible applications based on actual documented component performance rather than a simple notion of what each component does.

In designing and evaluating IoT projects, students also need to know how to examine specification sheets and understand hardware limitations. For example, students may not know that a gas sensor requires a 20-min warm-up period for reading to be accurate and needs to be calibrated to the current room temperature. A student wanting a wireless sensor to run off a battery will need to calculate a suitable duty cycle from a device specification sheet to achieve a target operational time. This meta-knowledge and hardware experience is not easily learned simply from lecture. By teaching IoT concepts with lecture followed by hands-on practice, we are able to provide a richer, more valuable learning experience for students.

The hands-on practice in the IoT lab also allows students to develop a different set of debugging skills. Computer science students typically only experience software errors. They rarely attribute errors they experience to the compiler, computer, or IDE as it is almost never the source of errors. As a result, many times when students experience difficulties with hardware, they often assume error are caused by their code and not the hardware. They often overlook issues such as reversed wires, improper hardware, or even broken hardware. Though not all students will need to interact with hardware at such a low level in industry, the value of debugging hardware makes students sensitive to the types of issues that hardware can cause when working on a deployment. Even when hardware is working correctly, students also need experience to debug issues caused by the environment. For example, students may not realize that a thermostat temperature sensor is deployed too close to an air vent, causing thermostat readings to be artificially high or low. Students may deploy a camera in a position such that early morning lighting conditions cause false positives for a classification application. Working with hardware in a real-life environment helps students develop intuition and debugging skills for successful hardware deployments in the field.

Though hardware is emphasized, it is not the sole focus of the course. Roughly half of the labs and topics of the class examine non-hardware concepts such as communication, security, and network architecture. These topics are shown by Table 1. While software, protocols, and architectures may change as the IoT field becomes more mature, many of the core issues such as scalability, integration, and robustness will continue to persist. By teaching students key skills to prototype, debug, integrate, and optimize their projects, we anticipate that the course will be a valuable foundation even as IoT continues to evolve.

4 Hardware

There are several key challenges utilizing a hardware-based approach to IoT. The first is supplying hardware to students. Depending on the hardware chosen, purchasing components and tools can potentially be a significant upfront cost. This cost can be partially defrayed by having students work in groups and share hardware. However, limits to sharing must also be considered as too many students sharing hardware can potentially lead to effort imbalances in groups where some students do not have the opportunity to use the hardware. For our class, we planned for two to three students per group. The second challenge is choice of hardware. There are numerous choices for the computing platform and even more for peripheral sensors and actuators. Lastly, we need to consider the toolchain and programming environment students will use. Again, there are many different approaches each with their advantages and drawbacks. In this section, we address each of these concerns.

4.1 Microcontrollers

Numerous choices are available for microcontrollers. There are several considerations that need to be examined to choose an appropriate platform: Availability of resources and support, overall capability, cost, and wireless communication capability. Table 2 compares several popular microcontroller options. Perhaps the most popular is the ubiquitous Arduino Uno [11], which has long been a favored microcontroller platform for educators and hobbyists. The board is moderately priced, has a large support community, and supports many electronic components through the Arduino software platform. However, this board does not have any native wireless communication and requires additional radio hardware. The board has somewhat limited computing resources. For sensing applications, this Arduino board could be sufficient, but anything requiring moderate amounts of computing may prevent the platform from being used. The platform also is not designed for low-power applications and does not have an effective deep sleep mode.

Table 2 Comparison of several different microcontroller options
Full size table

The Raspberry Pi [12] is another platform that is a popular choice. Rather than a simple microcontroller, it actually is a multicore computer that is capable of running a full Linux operating system complete with a graphical interface. This is an excellent platform where battery life is of little concern and substantial computing power is required on location. Interfacing components is well-supported and libraries exist for the most popular components. While capable, this platform is costly and is not suitable for many instances where sensing and battery life are a concern.

Particle Photon [13] boards are very capable boards designed for IoT prototyping projects. They are capable of light computing and have native Wi-Fi integrated into the board. At the time of this publication, the company offering this platform provides free cloud device management for the first 100 devices. The provided library gives a simple publisher/subscriber interface model that allows for easy data management. One downside to this platform is higher cost. The other drawback is the high energy use in deep sleep mode (80 μA).

A similarly capable board is the NodeMCU ESP8266 [14]. This is an open-sourced design based on the ESP8266 Wi-Fi chip [15]. This design is manufactured by many different companies. While the support by these individual companies varies greatly, there is an active userbase for these devices. While not quite as capable as the other platforms, these boards are still able to do some light computing. The platform also has a very low energy deep sleep (10 μA). Perhaps their greatest advantage is cost. In bulk, each node can be bought for $2–$4 at the time of this publication.

The last board we examined is the NodeMCU ESP32, which is the successor to NodeMCU ESP8266. This board has a faster processor than the NodeMCU ESP8266 and a very aggressive deep sleep. It is able to consume 2.5 μA at a deep sleep state, which makes the platform particularly well suited for long term monitoring deployments relying on battery power. The board also has 18 analog/digital channels rather than just one analog and 17 digital channels as compared with the ESP8266. There is also a slightly more expensive version of the ESP32 board made that includes a 900 MHz Long Range (LoRA) radio module that is able to communicate long distances.

For our class, we chose to use three different boards: a variation of the NodeMCU ESP32 called the M5 Stack [16] with a built-in screen and sensors, an ESP32 board with LoRA, and a Raspberry Pi (see Fig. 1). The ESP32 platforms have many input and output options, many different sleep options for long term deployments, and three different radios for various situations. The Raspberry Pi is useful for fog and edge computing as well as functioning as a simple server. This combination of platforms allows for a variety of potential IoT projects and applications at a good price point.

Fig. 1
figure 1

The three platforms used in the class. (a) The M5Stack is a platform based on the NodeMCU ESP32. It includes, a screen, microphone, SD card reader, buttons, and LED’s. (b) This is a NodeMCU ESP32 based platform that has a LoRA radio integrated into the design. (c) A Raspberry PI 3 B+ platform was used as a server for labs and projects. Pictured is the most recently released version 4B

Full size image

4.2 Sensors, Actuators, and Peripherals

Great care was taken to choose sensors, actuators, and peripherals. The goal was to minimize cost while maximizing the capability of the kit.

4.2.1 Sensors

When possible, we bought sensors that had multiple sensing capabilities. In particular, we chose the BME680 and APDS9960 sensors to maximize sensing with minimal sensors. The BME680 [17] is primarily a gas sensor able to detect presence of volatile organic compounds. However, it also has temperature, humidity, and barometric pressure sensors. The APDS9960 [18] is able to detect whether someone is close to the sensor using multiple light sensors. It is also able to measure light intensity and color. Using the multiple sensors, it is sensitive enough to detect simple hand gestures. By combining sensing capabilities, we are able to capture the following with only six different sensors boards; moisture, movement, proximity, light intensity, color, hand gestures, temperature, various gases, humidity, location, and sound.

4.2.2 Actuators

For actuation, we include micro servos and a simple relay. As the servo is essentially a mechanical lever, it can be applied to any situation where small motion is required. For example, the servo could be used to turn on a light, push a button, or lift a latch. This makes this simple actuator very versatile. The relay can be used in situations where an electronic device needs to be turned on or off. While only two servos are included in the provided kit, we had many held back in reserve for students needing additional actuation for their final project.

4.2.3 Peripherals

Several peripherals were bought for the Raspberry Pi kits. The goal was to be able to provide students with a relatively portable server that could also potentially serve as a user interface for an IoT project. For this we included a 10.1” touchscreen and small keyboard to use with the Raspberry Pi kit.

4.3 Arduino vs. Real Time Operating System vs. Developer Framework

Another important consideration is the programming framework used. We considered three different options: Arduino, FreeRTOS, and the developer framework.

Arduino, which uses C++ as the programming language, is a widely used platform for microcontrollers. The platform is open-source and designed for students without an electronics background and is often used in education and by hobbyists. Code developed on one microcontroller can often be ported to another type of microcontroller without too much effort. The Arduino Software IDE is available for Windows, OSX, and Linux and is designed to easily access libraries and examples for hardware. The software also greatly simplifies the toolchain setup. One drawback is that Arduino is not a true OS and better suited for running a single application. While it is possible to create multiprocess applications with Arduino, it tends to be more complicated. Another drawback is that not all board functionality may be available through the Arduino interface.

There are many real time operating systems available (RTOS) for microcontroller platforms. FreeRTOS [19] is well known and available for the ESP32 platforms. This allows for multiple applications to be run on a platform. However, drivers are sometimes not readily available, and writing drivers for hardware is time consuming and outside the scope of the class. Working with an RTOS may mean working with the system at a lower level of abstraction.

The last option is the provided developer framework for the ESP32 [20]. Similar to Arduino, it is primarily designed for single applications. The advantage of using the official developer framework is that all features are available. Again, hardware drivers are not always available and may be time consuming to create. This lack of hardware drivers may require working at a lower level of abstraction.

Our course focus was learning about IoT by creating applications. Thus, Arduino was a clear choice. While there may be situations where multiple applications could be useful, the vast majority of situations only require a single application running on the platform with perhaps a few simple threads.

5 Labs

5.1 Lab Preparation

Most of the lab equipment were purchased directly off the shelf and ready to use out of the box. However, some preparations were required to ensure that the component kits were ready for students. Given that students in the course had limited hardware experience, we decided to complete some soldering in advance. The following soldering was completed before the start of labs each semester:

  • Solder all of the header pins onto the ESP 32 chips (Note that the headers were included with each ESP 32, but not pre-soldered).

  • Solder header pins on to the PIR, gas, light, and sound sensors. (Note that the headers were included with each sensor, but not pre-soldered).

If the course were taught to students who have a stronger hardware background, this soldering could be done as part of the lab. We chose to do the soldering in advance to ensure students had components which were connected properly to avoid potential shorting or solder-related errors.

Finally, in addition to preparing the hardware kits, short lab manuals were written containing detailed instructions for each lab as well as clear deliverables (tasks the students needed to demo with the teaching assistant or instructor in order to receive credit for the lab). To encourage creativity, small amounts of extra credit were always offered for students who voluntarily chose to build on and extend the assigned project. In some of the labs, suggestions on how to extend the lab were provided. Each week’s lab handouts were made available online in advance of the lab.

5.2 Lab 1: IDE and Toolchain Setup

During the first week of class, lab did not meet (the semester starts on a Tuesday, so there was only one lecture during the first week). Therefore, Lab 1 officially started during the second week of classes.

The focus of the first lab is to distribute the equipment and to familiarize students with the hardware and software needed for the course. First, students are instructed to form groups of two to three and each group is assigned a kit of components to use for the semester. For convenience, each kit is stored in a tool organizer with multiple compartments. Student groups needed to take home the kit and bring it back to lab week since storage space was not available.

Note that each group receives a kit of components, but students used their own laptops to install and run associated software. For the first lab, students needed to install VisualStudio Code, Platform IO, and the ESP 32 drivers. Platform IO offers the same functionality as the Arduino IDE but has other more advanced features available such as version control. The students are given instructions on how to set up Platform IO and how to program the M5Stack ESP32 to blink the LEDs and display a message on the OLED screen. In order to receive credit for the lab, students needed to demonstrate how to upload a program to M5Stack and show a successful blinking LED to the instructor or TA. This first lab serves as an effective initial checkpoint to verify that students are able to set up and connect to the hardware successfully (Tables 3 and 4).

Table 3 This table shows the components each kit contains and the approximate cost at the time of publication
Full size table
Table 4 The topics covered in each lab
Full size table

5.3 Lab 2: Sensors

Lab 2 happens during the third week of the class, when sensors and actuators are introduced in lecture. In this second lab, students gain hands-on experience with sensors to build on the lecture material. Students experimented with different types of sensors (gas, gesture, and PIR sensors) along with a few different types of ESP32-based boards. The students used a breadboard to make circuits with ESP32. Using various sensors like the PIR, BME680, APDS9960 and actuator servo and relay, students then verified each sensor’s functionality and observed how each component worked together. For example, by connecting the PIR along with a relay, students were able to demonstrate a PIR sensor which activated the relay whenever motion was detected.

While breadboards were provided, we found that very few students actually used the breadboards. Instead, students preferred to use jumper wires to connect directly to the sensors. However, many students would accidentally connect their sensors incorrectly. Another common error was that students would forget to read the documentation and verify that certain pins are not already dedicated to specific built-in hardware such as OLED or radio.

To receive credit for this lab, students needed to demonstrate they have successfully interfaced with the sensors and are able show sensed values in real time. Students were also given a list of short questions which they needed to answer (mainly to verify that students had read the specification sheets of each sensor and understand how to set up each sensor). Extra credit was offered for exploring any of the other features available or combining sensor functionality.

5.4 Lab 3: Communication Part 1

During week 4 of lecture, Wi-Fi communication was introduced. Therefore, this lab was dedicated to test the various wireless capabilities of ESP 32 boards. Students created a wireless sensor network by programming the ESP 32 to act as a Wi-Fi access point and setting up a wireless mesh network of sensors. The network should have one node with a PIR sensor, a node with a BME680 sensor, and a node with a moisture sensor. The computer would listen to all the sensors in network and print the outputs to the website hosted on the node.

Students were instructed to set up a network with the following:

  • The PIR node should only send a value if the PIR value changes.

  • The BME680 and moisture sensor nodes should do the following: Sample every second, calculate the mean value for the last 60 s, and calculate the standard deviation for the last 60 s.

  • The BME680 and soil moisture sensor samples calculate mean and standard deviation every second based on data for last 60 s. They send data only if new values differ by one standard deviation from the current mean.

To receive credit for the lab, students needed to successfully explain and demonstrate that the above wireless sensor network was working properly.

5.5 Lab 4: Communication Part 2

Lab 4 continued building on the low power and IoT for the home topics covered in class. This Lab was designed to give students practice with the LoRa capabilities of the provided ESP32. Students were asked to make a long range moisture sensor which also provided GPS coordinates. To receive credit for the lab, students needed to create a node that is able to measure and transmit soil moisture every 5 s to another node. The node should send the moisture reading along with a GPS location of the node. Students were also asked to complete simple questions to reinforce concepts about LoRA vs LoRaWAN communication, transmit capabilities, and how to improve energy efficiency.

5.6 Lab 5: Communication Part 3

Lab 5 was paired with the in-class discussions on low power wide area networks and IoT for the home. Students test the Bluetooth Low Energy capability the ESP32 modules. This lab gives an introduction how to create a simple BLE device and server.

Students were familiarized with GATT (Generic Attributes)—BLE Service and BLE Characteristic. Students learn how to work with them to build a BLE client and server network. Students used the BLE server and a BME680 node to send temperature value to a BLE client connected with a relay. Students needed to demonstrate a client which examines the temperature value of the server node and turns on a relay if the temperature goes above some threshold value.

Extra credit was offered for extending this project. One interesting idea is having the client connect to another commercially available device such as a heart rate monitoring watch.

5.7 Lab 6: Management

This lab was designed to reinforce the IoT management topics covered in lecture. In this lab, students learned how to interface with the MQTT broker and how to publish/ subscribe from an ESP32 node. Students also created and used Amazon AWS free IoT services.

The lab was focused to register the IoT device (BME temperature sensor) and going through the steps to use the free IoT AWS services like creating security credentials, adding policy, connecting with MQTT broker using ARN, adding the broker address to the AWS account. Finally, students needed to publish the sensor values at regular intervals and have the sensor subscribe to itself to determine how often to sample the temperature.

To receive credit for this lab, students needed to show their working sensor. Extra credit was available for having the ESP32 subscribe to a second service that is responsible for adjusting the sampling rate of the node.

5.8 Lab 7: Security

The LoRA library and other labs completed previously do not implement security; everything is transmitted openly. In this lab, students build upon the security topics discussed in lecture and learn how to use encryption to secure transmissions.

Students modified the code from the previous LoRA lab to utilize RSA encryption/decryption. Students learned how to secure the data transmitted in LoRa packets using symmetric, asymmetric, and LoRA encryption approaches. In this case, the transmitting node encrypted data and sent data to a receiver node, where the message gets decrypted and printed on the serial console.

To receive credit for the lab, students needed to demonstrate successful encryption, transmission and decoding of a message. Extra credit was offered to students who were able to generate an AES key on the fly and use RSA to pass the AES key to the other node/nodes.

5.9 Lab 8: Visualization

Lab 8 was designed to reinforce the data analytics topics covered during lecture. Students are asked to create an ESP32 program that outputs serial values of a sensor of the students’ choosing. Then, students connect the ESP32 to a Raspberry Pi and create a Python script that pushes the data from the ESP32 into the MySQL database continuously. This data should then be displayed on a website using PhP to pull data from the database.

Students first set up the Raspberry Pi and install the LAMP(Linux, Apache, MySQL, PhP) stack. Then, students used Python scripts to read the serial data coming from ESP32 and push it to MySQL database. Finally, to receive credit for the lab, students needed to display the useful information collected in database on a webpage.

5.10 Additional Activities During Lab Sessions

In addition to the eight labs covered previously, some of the lab time was allocated for other tasks. One lab session in week 7 was used for elevator pitches, in which student groups shared their idea for the final project and received feedback (during each student presentation, the rest of the class was required to document and share anonymous feedback with the presenter). After the eight labs were completed, the rest of the lab slots were reserved for additional lectures. During the last week of the semester, the entire week was reserved for “open lab” to allow students extra office hours and time to meet to get help on their final projects.

6 First Class: Spring 2019

6.1 Student Feedback

Reviewing feedback from students during and after the semester revealed additional insights and areas where we could improve. The feedback received from students was overall very positive. The labs were overall very well received and students found the hands-on experience to be new, interesting and valuable. Many students commented that the hands-on experience in the labs was very helpful for reinforcing and learning concepts from lecture. Some students decided to use their IoT projects as a capstone or thesis project. One student was even able to secure an internship in IoT, in part due to having gained a basic understanding of IoT from taking the course.

Students did point out several areas where the course could be improved. Some students commented that it was sometimes challenging for group members to meet outside of class in order to complete the final project and to complete the more challenging lab assignments. Other students would have preferred to complete the projects individually rather than in groups, and to have more office hours to get help.

7 Second Class: Spring 2020

7.1 New Updates and Changes Made

Based on the feedback from the previous semester, several key changes were made to improve the course. These included the following:

  • Updating grading structure: We kept the assignments and peer evaluations, but replaced the midterm exam with weekly online quizzes. This allows students more opportunity to influence their individual grade.

  • Adding extra “open lab” time for final project: Removing the midterm and final exam timeslots frees up two more timeslots for students to work on their final projects with their groups.

  • Implementing weekly online quizzes: Quizzes were posted online each week, designed to check for understanding on basic lecture material. Weekly online quizzes also incentivized students to learn course material and provided an opportunity for students to have more control over their own grade rather than relying heavily on group projects.

  • Minor changes to labs for clarity: the labs were overall well received, so we kept the labs the same except for making changes to improve clarity.

7.2 Lessons Learned

One key item we learned from offering the class is that having a dedicated IoT space would be very helpful. Student groups needed to remember to pack and bring their component kits to each lab. Also, student groups would have benefited greatly from having more work space to meet during non-class hours to finish projects. While we were able to successfully run the course without having this additional space, we highly recommend making additional space available for students to store their kits and meet to work on projects. Since the student population at East Bay has many students who commute, this shared space would be extremely beneficial.

Even more ideal would be having a space where students could get help on their prototyping projects, and offering additional office hour time to support the students. In the course evaluations, several students commented that additional office hour time would have been beneficial. Often, a simple wiring error or small programming error would cause groups to be stuck for long periods of time. Students frequently used office hours to get help and found the sessions very useful.

We also found that students would likely have the best experience in the class if they are able to work either a group of two students or individually. Once the group of students became larger than two, it becomes more challenging for each student to gain as much hands-on practice and learning with the kits. Due to budget constraints, we were only able to have groups of two to three students. If smaller groups are utilized, we would also recommend allocating extra time for project demos and office hours, since meeting with additional groups does require more time from the instructor and assistants.

8 Plans for Next Class

While our first attempts at teaching IoT were very well received, we will continue to refine and improve the course. One area we would like to explore is creating an IoT “part two” or capstone course. Once students have learned the fundamental skills in the introductory course, more advanced skills and projects could be covered in a future course. Having a year-long course could also provide students and instructors the opportunity to dive deeper into certain areas and applications of IoT, such as medical, security, networking and data analytics.

Based on feedback from students, there is great interest in learning more about hardware and IoT areas. With growing demand for IoT, we could explore adding an IoT concentration, certificate, or minor to our computer science curriculum. Providing unique projects and experiences through the IoT curriculum also enables students to gain new, unique experiences and projects. These opportunities can help students improve their resumes and career competitiveness, be able to complete unique capstone projects, and better prepare students for challenges faced in designing real-world IoT projects.

9 Conclusion

In this work, we have shared our process for designing, planning, and teaching an IoT course for advanced undergraduate and graduate level students. Based on our experiences, we believe that combining hardware and software approaches is an effective way to introduce computer science students to IoT concepts. In particular, we found that introducing material during lecture, followed by hands-on practice in lab provided students a richer learning experience. Many of our students had never been exposed to hardware prototyping and debugging, yet these students were able to successfully complete the assignments and projects and found the course to be a positive and valuable experience. One student reported being able to secure an internship in IoT, due in part to having completed the course and having a solid introductory background. Other students were also able to use their IoT projects toward capstone and thesis projects.

For both students and instructors alike, we have found the project-based, hands-on learning strategies in our course to be powerful and effective in helping students not only learn IoT concepts but also apply them to new projects. We anticipate that these strategies will be beneficial to many students and educators who are interested in the IoT field. One of the key challenges we encountered while developing our course was identifying hardware and equipment to use in the course, and integrating it successfully into labs and assignments. By providing detailed lists of our hardware components, topics covered, labs, and course structure, we anticipate that we can help others continue to develop and improve IoT education.