Project

# Title Team Members TA Documents Sponsor
62 Voice Coded Lock
Aman Thombre
Logan Greuel
Zicheng Ma design_document1.pdf
final_paper1.pdf
photo1.png
photo2.png
presentation1.pdf
proposal2.pdf
video
# Voice Coded Lock

Team members:
- Aman Thombre (thombre3)
- Logan Greuel (lgreuel2)

## Problem

Currently, accessing secure areas usually requires some type of access card or keys, which can easily be misplaced, left at home, or stolen, leading to being locked out of your area of work or a security risk. These can also be hard to operate with your hands full - for example, trying to get an iCard out while accessing a lab in the ECEB while holding a laptop and FPGA can be quite difficult. Additionally, other keyless options requiring physical contact, such as a keypad, may pose a health concern for some users, especially during cold/flu seasons or a pandemic.

## Solution

Our proposed solution is to implement an audio-based locking system for a door. We plan to create an attachment on or near a door which will listen for a user’s voice, and upon hearing a user saying some keyphrase, the device will automatically unlock the door. This system will use keyphrase recognition to identify an audio password, allowing for completely hands free operation of a keyless lock.

## Solution Components

### Subsystem 1: User Interface

The user will interact with our locking system through a microphone and LEDs. Keyphrases will be listened for using a microphone, which will send the audio signal it records in real time to our microcontroller. An RGB LED will be used to signal to the user the state of the locking system - we plan to use different colors to indicate locked, unlocked, and listening.

### Subsystem 2: Keyphrase Recognition

Audio signals will be fed from the microcontroller to a Raspberry Pi, which will perform keyphrase recognition. We plan to code this software in Python, and use some machine learning model (determined by which models give us best results in testing) to determine whether a given keyphrase is correct or incorrect. Signals will be fed from the Raspberry Pi to the microcontroller, signaling whether the keyphrase heard was correct or incorrect.

### Subsystem 3: Door Lock Operation

We plan to use a deadbolt style lock which retracts when audio is verified. This can be achieved by using a motor and a screwing mechanism to engage/disengage the lock, or a more specialized moving component that can move side to side like a deadbolt lock. We also plan for this lock to retract in the event of loss of power as well, so that a loss of power does not lock users out permanently.

### Subsystem 4: Microcontroller on a PCB

The microcontroller will be used to send signals to/from our user interface, perform some processing of the audio signal, and send signals to our door locking subsystem. The microcontroller will receive audio signals from the microphone, and when an audio signal passes over a certain threshold level, the microcontroller will send this audio signal to the Raspberry Pi for keyphrase recognition. When the audio signal is verified, the microcontroller will send a signal to the locking system to disengage the lock, and after a period of time, send a signal to re-engage the lock. The microcontroller will also send signals to our RGB LED, displaying whether the door is locked, unlocked, or whether a phrase is being processed.

### Subsystem 5: Power System

Current electronic lock systems tend to use 4 AA batteries, so we plan to use up to 4 AA batteries to provide power to our microphone, LEDs, microcontroller, Raspberry Pi, and locking/unlocking operation.

## Criteria for Success

- Keyphrase recognition should be able to consistently correctly classify audio password as correct/incorrect
- Keyphrase recognition should be performed in reasonable time (<10 sec)
- System should be able to operate a door lock automatically

Master Bus Processor

Clay Kaiser, Philip Macias, Richard Mannion

Master Bus Processor

Featured Project

General Description

We will design a Master Bus Processor (MBP) for music production in home studios. The MBP will use a hybrid analog/digital approach to provide both the desirable non-linearities of analog processing and the flexibility of digital control. Our design will be less costly than other audio bus processors so that it is more accessible to our target market of home studio owners. The MBP will be unique in its low cost as well as in its incorporation of a digital hardware control system. This allows for more flexibility and more intuitive controls when compared to other products on the market.

Design Proposal

Our design would contain a core functionality with scalability in added functionality. It would be designed to fit in a 2U rack mount enclosure with distinct boards for digital and analog circuits to allow for easier unit testings and account for digital/analog interference.

The audio processing signal chain would be composed of analog processing 'blocks’--like steps in the signal chain.

The basic analog blocks we would integrate are:

Compressor/limiter modes

EQ with shelf/bell modes

Saturation with symmetrical/asymmetrical modes

Each block’s multiple modes would be controlled by a digital circuit to allow for intuitive mode selection.

The digital circuit will be responsible for:

Mode selection

Analog block sequence

DSP feedback and monitoring of each analog block (REACH GOAL)

The digital circuit will entail a series of buttons to allow the user to easily select which analog block to control and another button to allow the user to scroll between different modes and presets. Another button will allow the user to control sequence of the analog blocks. An LCD display will be used to give the user feedback of the current state of the system when scrolling and selecting particular modes.

Reach Goals

added DSP functionality such as monitoring of the analog functions

Replace Arduino boards for DSP with custom digital control boards using ATmega328 microcontrollers (same as arduino board)

Rack mounted enclosure/marketable design

System Verification

We will qualify the success of the project by how closely its processing performance matches the design intent. Since audio 'quality’ can be highly subjective, we will rely on objective metrics such as Gain Reduction (GR [dB]), Total Harmonic Distortion (THD [%]), and Noise [V] to qualify the analog processing blocks. The digital controls will be qualified by their ability to actuate the correct analog blocks consistently without causing disruptions to the signal chain or interference. Additionally, the hardware user interface will be qualified by ease of use and intuitiveness.

Project Videos