We went remote halfway through the project-based Embedded Systems course. It was our first time sending out kits and having students complete the work from different cities and states. It probably won’t be the last. One troubleshooting technique was hard to replicate: swapping in a known-good part in a system that’s not working. Software problems were easier to diagnose, except when they originated from interactions between the operating system and different installed applications, because by the fourth year no two students had the same setup. Stick to debugging student-written and student-modified code for better results. We decided not to do a team final project, but rather an individual code-based project. The final project did not carry the weight it normally did, but it still had the theme of connecting low-level machine code (the topic of this course) to the Arduino system that students worked with their first year. At the end of the spring final project, students customized some output from their boards and pasted it to a massively shared spreadsheet, illustrating how serial output from microcontrollers can drive graphical displays in sensor projects and other physical computing platforms. The result was pretty colorful.
Portable experiments
Most of us are working remotely as much as we can. Grad students have simulations and writing to do, and some coursework. Since courses have also gone remote, that works. Undergrad and Masters students have computer-based design or small experiments, things like collecting data from a sensor with an Arduino to get that final project done. The cleanroom is out of reach, but sensors, actuators, and other materials like this thermochromic coated wire are examples of low-cost and portable materials we are able to work with now. Later when the lab is open we might investigate this color-changing stretchable coating as a temperature-sensitive cladding for our stretchable optical fiber sensors.
Then there are the ECE 412 students (Embedded Systems). It is the first time the project-based course has been taught remotely. Embedded Systems students have portable setups consisting of microcontroller kits, electronic breadboards and a few components. They are able to do group work using shared text editors and apps. We have not yet figured out how to do the classic troubleshooting technique of swapping in a known-good part to a system that’s not working. Well, not quickly anyway.
Simulation station
Shaf continues his work with flow on microelectromechanical structures (MEMS) as tiny liquid flow rate sensors. Here he’s using COMSOL to simulate water flowing over a cantilever array. As the cantilevers bend, they affect how the water can flow around them, so the solver needs to calculate a new mesh (upper left image) at each step.
Scavenged signal sources
Is it possible to run optical sensors using only light from the environment? Turning off the light source, even if it’s a tiny LED, will save a significant amount of energy when we’re running the sensor from a small battery. This paper looks at how a pair of sensors with different optical absorbance might use existing office lighting as a signal source.
Embedded Systems projects posted
University of Louisville Embedded Systems final projects from 2019 are now up at the ECE 412 course blog. Class members are becoming embedded developers, and must go beyond examples to create original work. They don’t have to reinvent the wheel. It’s fine to re-use bits of other peoples’ code, especially other libraries, with attribution. However–as developers, students are asked to produce code others can use, and libraries make us think about what another user might need from the code. So, teams who used an Arduino had to develop a custom library to carry out their final project. Other teams prefer to build from scratch (or from the bones of previous lab reports), sticking with C or even AVR Assembly language for their final projects. It’s hard to tell unless you click on the “code snippet” posting for the project.