My circuit setup, built using breadboards, wall warts, and lots of duct tape.
Course - ME218C - Smart Product Design Projects
Duration - 4 weeks, May 2020
Skills - software design, event-driven programming, circuit design, debugging
Skills - software design, event-driven programming, circuit design, debugging
Although my last quarter of the Smart Product Design sequence was completed under quarantine for COVID-19, I was able to learn more about microcontrollers (i.e., PIC16(L)F15356), assembly language, asynchronous communications, and communication protocols.
For this project, we formed teams of three, where each member manned a single station on a submarine and teams competed against each other. The game was turn based, and each submarine was only allowed one action per station per turn. Our submarine had to perform user-entered actions, automatically respond to enemy actions, and transmit/receive all information using audio over Mumble. Our class developed a communications protocol that used time-division multiple access (TDMA) to allow all teams to transmit 26-bit messages without collision.
Entire schematic capture, designed on Eagle. Click on the image for a higher resolution PDF.
I wanted more hardware experience since I mainly worked on software during my ME218A and ME218B projects. My main responsibilities involved designing the entire circuit (shown above) and writing services to receive messages and sync with other teams.
Since my 218B project had suffered from noise issues, I focused on ways to reduce noise for this project. For instance, I added bandpass filters to both the receiving and transmitting sub-circuits. For the receiving subsystem, a Schmitt trigger converted our filtered analog signal into a clean square wave. This digital signal was received by the PIC and parsed in software as a 26-bit message. A Schmitt trigger was not needed for our transmission subsystem, since we used the microcontroller's DAC (digital-to-analog) module to convert our message in software. Before the speaker module broadcasts the message, the digital signal passes through a unity gain buffer to reduce disturbances caused by current/power draw. We also decided to power the servo used for Push-to-Talk with a completely separate wall wart to avoid disturbances in our signals. Even with all of these precautions, we still suffered from noise due to Mumble. Thus, I also took steps in software to process noisy signals within the Receive Service, such as having large thresholds for each target frequency and error handling any bad messages.
Overall, I feel proud of what we were able to learn and accomplish while under quarantine. Feel free to learn more about our project on our website.
