Project

# Title Team Members TA Documents Sponsor
70 Automatic Drum Tuner
Joey Bacino
Jonathan Fejkiel
Max Wojtowicz
Shengyan Liu design_document1.pdf
final_paper1.pdf
proposal1.pdf
video
Members

Joey Bacino - jbacino2

Jonathon Fejkiel - jfejkiel2

Wojtowicz - mwojt3

Problem

Playing instruments is a pastime enjoyed by millions of people across the world. A task that almost every musician must endure before playing is tuning their respective instrument. For many this is done easily if they are of able body and have good pitch. However, turning lugs and listening for the right tune can be difficult if someone is weaker such as a child or the elderly, or if they are inexperienced in hearing perfect pitch such as a beginner.

Solution

The solution we propose is an automatic tuner for instruments that will adjust the instrument until the desired pitch is reached. We will specifically design our tuner for use on drums. The device will strike the drum, listen for the pitch, calculate how much it should either tighten or loosen the drum, and instruct a motor to do so. It will perform extra checks to ensure the drum was adjusted properly. Additionally, the mechanism will connect to a mobile app to select pitch if time permits.

Subsystem 1

Power Management System:

To have enough power for striking the tuning hammer and turning the pegs of the drums, we will utilize a power tool battery such as a Milwaukee M12 battery system. The same battery will power the microcontroller and sensors so it must be regulated to the correct voltages to ensure the safety of the components and the user as well. The power management subcircuit will have over-current and over voltage components such as fuses and diodes to ensure circuit protection. A buck converter will step the 12V supply down to the required inputs of the rest of the components.

Subsystem 2

Drum Striking Hammer:

For the motor that drives the hammer that would strike the drum, we will use a push-pull solenoid. We’re choosing a push-pull solenoid because they can provide a consistent and quick tap. Consistency is important around the entire drum, we need to make sure each strike is the same for every single hit on every single lug we would like to tune. A quick tap also allows the drum to resonate fully and not dampen the hit by leaving the hammer on the drum head. This is important because we want our pitch detection to be able to hear the purest/most dominant tone around each lug without any type of interference. Minimizing overtones will simplify our pitch detection system as we want as close to only one tone at any given time. Also, we would experiment with different materials such as rubber, wood, and felt to see which gets us the best result for our hammer.


Subsystem 3

Pitch Detection:

To detect the pitch of the drum at its current state, a microphone will begin to read the input of audio after the hammer has struck. The returned sound snippet will be recorded and the raw audio data will be converted to frequency domain data on the microcontroller. This can be done using a Fast Fourier Transform algorithm on the microcontroller. The dominant frequency will be noted as the pitch of the drum. Based on the input for the desired note, the microcontroller will then decide if the drum needs to be tightened or loosened and by what amount.

Subsystem 4

Tuning Motor Control:

For the motor that would be turning the lugs, we want to use a high-torque servo motor. High torque is a requirement for this part because when you want to tune your drum higher and higher, you need more and more torque as the drumhead provides more and more resistance against the tuning lugs. Servo motors also offer very precise control with feedback, so we could calibrate the motor to each lug and precisely determine how much the pitch changes with how much rotation.

Subsystem 5

Pitch Correctness LEDs:

The device will have LEDs that will indicate to the user if the current pitch of the drum is correct, close, or far off from the desired pitch. It will begin lighting when the drum is first struck. Every time the drum is struck after a pitch adjustment, the LEDs will display a different color so that the user will know the progress of the tuning. Green will be displayed and stay lit once the device has finished tuning to indicate to the user that they are ready to play. While the device is not in an active tuning task, the LEDs will stay lit blue to indicate a standby mode.

Criterion For Success

Our first criteria for success will be being able to accurately detect the pitch from our pitch detection system, as that will be the basis for how the two motors act. Another criteria for success will be repeatability, our system should return consistent pitch readings and tuning results across multiple tests. The second criteria is the accurate striking of the drum. This can not be too fast or slow, and must be the correct length of time. One more can be our lug-turning motor being able to accurately turn the lugs to the desired pitch without too many intermediate hammer strikes and adjustments. We also want minimal noise and interference from our motors.

Schnorr Protocol Key Fob

Michael Gamota, Vasav Nair, Pedro Ocampo

Featured Project

# Schnorr Identification Protocol Key Fob

Team Members:

- Michael Gamota (mgamota2)

- Vasav Nair (vasavbn2)

- Pedro Ocampo (pocamp3)

# Problem

Current car fobs are susceptible to different types of attacks. Rolling jam attacks are one of such attacks where an attacker jams and stores a valid "unlock" signal for later. Cars with passive keys/cards can be stolen using relay attacks. Since a car can be the most expensive item someone owns, it is unreasonable to allow people to steal them so discreetly by hacking the fob/lock combo.

# Solution

By leveraging public key cryptography, specifically the Schnorr identification protocol, it is possible to create a key fob which is not susceptible to either attack (rolling jam and relay) and also gives no information about the private key of the fob if the signal were to be intercepted.

# Solution Components

# Key Fob

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - The MCU will run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option.

## Subsystem 3

Power - We plan on using either a 5V battery or 3.3V battery with a boost converter to power the fob.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

# Lock

## Subsystem 1

Random number generation - We will use a transistor circuit to generate random numbers. This is required by the Schnorr protocol to ensure security.

## Subsystem 2

Microcontroller - This MCU will also run all the computation to calculate the messages. We will likely use an ATtiny MCU so we can use the Arduino IDE for programming. However, some group members have experience with the STM32 family so that is another option. This MCU will need to have PWM output to control the lock.

## Subsystem 3

Linear Actuator - We plan on using a linear actuator as a deadbolt lock for demonstration purposes.

## Subsystem 4

Wireless Communication - We plan on using the 315 MHz frequency band which is currently used by some car fobs. We will need a transmitter and receiver, since the protocol is interactive.

## Subsystem 5

Power - This subsystem will also likely require 5V, but power sourcing is not an issue since this system would be connected to the car battery. During a demo I would be acceptable to have this plugged into a power supply or a barrel jack connector from an AC-DC converter.

# Criterion For Success

Describe high-level goals that your project needs to achieve to be effective. These goals need to be clearly testable and not subjective.

Our first criteria for success is a reasonably sized fob. There is some concern about the power storage and consumption of the fob.

The next criteria for success is communication between the fob and the lock. This will be the first milestone in our design. We will need to have a message sent from one MCU that is properly received by the other, we can determine this in the debug terminal.

Once we are sure that we can communicate between the fob and the lock, we will implement the Schnorr protocol on the two systems, where the fob will act as the prover and the lock as the verifier. If the Schnorr signature implementation is correct, then we will always be able to unlock the lock using the fob whose public key is associated with full privileges.

Project Videos