Project

# Title Team Members TA Documents Sponsor
33 HelpMeRecall
 Michael Jiang
Sravya Davuluri
William Li
 Hossein Ataee design_document2.pdf
proposal3.pdf
# HelpMeRecall

Team Members:
- Sravya Davuluri (sravyad2)
- William Li (wli202)
- Michael Jiang (mbjiang2)

# Problem

Many individuals have difficulty remembering recent activities and completing routine tasks like eating or taking medication.

# Solution

A standalone assistive device that supports activity recall using sensor-gated voice interaction. It allows users to verbally log activities they have completed, and later query if a specific activity has been performed. It uses an onboard microphone and on-device audio processing on a microcontroller to perform keyword detection.

This device is always on and will be verifiable with an LED, but the voice input is only accepted if the device is worn (capacitive touch sensor) and specific words from a limited vocabulary is said to avoid accidental logging. To address the possibility of reduced correct detection of supported keywords, we will have various keywords targeted for an activity. So in the case of taking medicine, it might be medicine, medication, pill, drug, and prescription. This also simplifies the problem and prevents confidence rate issues. To validate a completed action, the action is logged only if an accelerometer detects physical movement around the time in order to reduce false logging. If a voice log is accepted, haptic feedback is provided by the device. Activities are also timestamped and stored in local memory. If the device notes that a specific activity has been completed, it affirms it including the timestamp using an integrated speaker.

The logs reset at midnight automatically since the activities repeat on the daily. There is also an option of a hard reset button to clear logs. There will also be a button to delete the latest log in case of a logging mistake by the user.

# Solution Components

## Subsystem 1: Microcontroller Unit and Controls

Acts as the central unit for logic. Manages the sensor inputs, and executes a finite state machine. The FSM states are start, idle, listening, logging, and replying.

Components: ESP32-S3-WROOM-1

## Subsystem 2: Audio input processing unit

Captures the voice input from the user and performs keyword detection on a limited vocabulary, where each action can be mapped to multiple set keywords to improve detection.

Components: Digital MEMS microphone (INMP441), ESP32-S3-WROOM-1

## Subsystem 3: Sensor gating and activity validation

Uses a capacitive touch sensor and an accelerometer to detect motion, which ensures that voice input is only received and accepted if the device is worn and recent movement is detected by the accelerometer instead of continuous voice recognition. A "cooldown" period is enforced where the microphone will be disabled for 10 seconds if there's motion but no logging during the listening period multiple times in a row to help conserve some battery.

Components: Capacitive touch sensor (AT42QT1010), Accelerometer (MPU-6050)

## Subsystem 4: Feedback and Output

Uses a speaker for audio feedback as a response to the user’s query. This subsystem also provides haptic feedback as an indication of an accepted user voice log. To indicate if the device is on, the LED is green. If the device is listening, the LED is yellow. If the device is low on power, the LED will be red.

Components: Speaker (8 ohm speaker), amplifier (MAX98357A), coin vibration motor, transistor (2N3904), RGB LED

## Subsystem 5: Time logging and local storage

Stores the activity voice logs along with timestamps. Allows automatic reset at midnight to support daily repetitive tasks. Timekeeping is done using ESP32’s internal RTC.

Components: ESP32-S3-WROOM-1

## Subsystem 6: Power

Supplies power to the device.

Components: Battery (Li-Po battery)

# Criterion For Success
- Correctly detects supported keywords with an accuracy of at least 80% in a quiet environment
- Device will only log upon verifying physical activity and hearing a keyword from the user within a 5 second window
- Upon successful logging, the speaker will output audibly and haptic feedback can be felt by the user with a 2 second vibration
- While querying logs, speaker will output and LED will be solid
- Logs will be automatically cleared at midnight and can be manually reset with the reset button
- Latest log will be deleted upon pushing a separate button
- LED stays solid while device is powered
- False log rate < 1 per hour in normal conversation when worn.

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