Project

# Title Team Members TA Documents Sponsor
26 Software Controlled physical sound sources (SCPSS) Sponsored Project
Ben Sisserman
Micki Rentauskas
Won Woo Lyu
 AJ Schroeder design_document1.pdf
design_document2.pdf
final_paper1.pdf
other1.pdf
presentation1.pptx
proposal1.pdf
**Title: Software Controlled physical sound sources (SCPSS) *Sponsored Project* -- Ryan Corey (Post Doc), under Professor Andy Singer at CSL**

**TeamMates:**
-Won Woo Lyu - Online (wlyu2), Ben Sisserman - Online (bens3), Micki Rentauskas - On Campus (mar3)

**Problem:**
-Ryan’s lab does research on audio-processing, and they typically use speakers placed throughout a room to emulate various sound sources. However, speakers output audio that loses some specific features of actual sound sources due to sampling and compression, and physical sources also do not output the same exact sound each time it is struck or powered on.

**Solution Overview:**
-To solve this problem, we intend to design a wrapper/API that can interface with the lab’s test setup on the PC, which specifically triggers the sound devices from Python scripts or Matlab
-The interface would communicate by outputting a trigger signal to two different types of sound sources: one that physically strikes an object, such as a drum, using a servo motor and one that turns on a device, such as a blender using a relay. This modular approach allows for easy integration of different objects in the future.
- The two boards would communicate directly with the testing PC via UDP
**Solution Components:**
-Hardware
-Two separate PCB’s for each type of device. The striking device would use a servo motor attached to an arm to strike an object. This device could take into account strike velocity, and the servo sequence would have to be tuned before the device could be added to the network.
-The second PCB would be made for a device that can turn electronics on and off, and take into account duration of turning on of the device. This would be accomplished using a relay.
- 2 exp32 microcontroller for Wifi capability of the PCB's
-Software
- A Python module to detect and initialize the devices for use. The module then allows the user to give commands directly to the boards
-Firmware for embedded devices that broadcast their MAC and type for initialization and take commands over UDP

**Subsystems:**
-Striking-type board: this system utilizes a tuned servo to emulate striking an object when a HIGH signal is received. This can be duplicated to strike a multitude of objects and should only require specifying the servo pattern. Sound producing objects that would be used here would be a drum hit by a mallet or a bell struck by a small piece of metal.
-Relay-type board: this system utilizes a relay to turn on an electrical device when a HIGH signal is received. This system can also have a “duration” setting, since a relay must remain open for a certain amount of time. Examples for objects here would be a blender, where we would switch line power in and out for a specific amount of time, or a battery-powered toy, where we would switch the battery connections in and out.
- Python module on the test PC to establish communication with the boards and send commands.

**Criterion for Success:**
-The project would be successful if the SCPSS wrapper can take an input from the PC using our Python or Matlab interface, and produce sounds at the specified times in the script with a simple call such as “scpss.blender(HIGH, 10)”, which would trigger the blender to run for ten seconds once called. The solution should support moving the objects around a room as well for different test trials.
-Another criterion would be making adding new devices fairly easy to do without much system knowledge, specifically for the relay-type device, and would entail editing a config file and initializing the system again.
- Also key is to ensure consistent latency in the devices. They can have latency, but it needs to be known.

Contingency Plan for Covid-19:
In the case where we can no longer make use of the labs, we can use simulation software to ensure that the board design is sound and create the Python module and protocols entirely in software for testing. If the boards are already fabricated we could test the devices at home on our own routers.

Low Cost Distributed Battery Management System

Logan Rosenmayer, Daksh Saraf

Low Cost Distributed Battery Management System

Featured Project

Web Board Link: https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=27207

Block Diagram: https://imgur.com/GIzjG8R

Members: Logan Rosenmayer (Rosenma2), Anthony Chemaly(chemaly2)

The goal of this project is to design a low cost BMS (Battery Management System) system that is flexible and modular. The BMS must ensure safe operation of lithium ion batteries by protecting the batteries from: Over temperature, overcharge, overdischarge, and overcurrent all at the cell level. Additionally, the should provide cell balancing to maintain overall pack capacity. Last a BMS should be track SOC(state of charge) and SOH (state of health) of the overall pack.

To meet these goals, we plan to integrate a MCU into each module that will handle measurements and report to the module below it. This allows for reconfiguration of battery’s, module replacements. Currently major companies that offer stackable BMSs don’t offer single cell modularity, require software adjustments and require sense wires to be ran back to the centralized IC. Our proposed solution will be able to remain in the same price range as other centralized solutions by utilizing mass produced general purpose microcontrollers and opto-isolators. This project carries a mix of hardware and software challenges. The software side will consist of communication protocol design, interrupt/sleep cycles, and power management. Hardware will consist of communication level shifting, MCU selection, battery voltage and current monitoring circuits, DC/DC converter all with low power draws and cost. (uAs and ~$2.50 without mounting)