Project

# Title Team Members TA Documents Sponsor
16 Handheld Rocket Tracker
 Ben Olaivar
Manas Tiwari
Max Kramer
 Sanjana Pingali final_paper1.pdf
other1.pdf
proposal3.pdf
video
# Handheld Rocket Tracker

Team Members:
- Ben Olaivar (olaivar3)
- Max Kramer (mdk5)
- Manas Tiwari (manast2)

# Problem

Locating a rocket after a launch can be difficult. When the rocket reaches apogee (peak height), it deploys parachutes and glides back to the ground, often landing several miles away from the launch site (check out this video from the Illinois Space Society). Some tracking solutions exist, such as altimeters and radio beacons, however they all suffer from similar issues of being clunky, unintuitive, or expensive. Radio beacons don’t send out their exact location, and are tracked by following the strength of their signal, which only gives the general direction of the beacon. Altimeters send out their exact location, but are costly ($380+) and often require a laptop to receive their position, which is inconvenient to carry during a search. A few handheld trackers exist, however they are costly ($475+), difficult to reconfigure, and unintuitive. Additionally, all of these solutions are limited to 1 device.

# Solution

We want to make a 2-part tracking system: A tracking beacon (referred to as a “puck” or “beacon”), and a handheld tracking device (referred to as “tracker”). The beacon will be placed inside the rocket, and will continuously transmit its coordinates. On the receiving end, the tracker will compare its own GPS location with the coordinates from the beacon. To make this intuitive, the tracker will display the direction (using an arrow on the screen), as well as the distance to the beacon.

# Solution Components

## Subsystem 1: Microcontroller Processor (both beacon and tracker)
This will house the codebase for this project. This will mainly be to display to the screen of the tracker and handle button inputs by the user.

## Subsystem 2: TRACKING SENSORS
This subsystem consists of all required sensors/peripherals required for acquiring the location and direction from the tracker to the beacon
- **GPS Module (both):** To get longitude and latitude values of both components
- **GPS Antenna (both):** For connecting to satellites.
- **Magnetometer(tracker):** For measuring the heading of the user.

## Subsystem 3: COMMUNICATION SYSTEM
The entire project depends on successful communication between the beacon(s) and the tracker. Therefore we will need the following components to set up an ability for the tracker to search out certain frequencies and for the beacon(s) to send out the same frequencies.
- **Transceiver (both):** Required generating signal between beacon and tracker
- **Antenna (both):** Mid-ranged antenna capable of transmitting/receiving signals between 3-5 miles. Can be replaced in future with better antennas.

## Subsystem 4: BATTERY AND POWER SUPPLY
Create a battery management system that supplies consistent 3.3V to the necessary sensors and MCU.
- **LiPo Batteries (tracker):** 3.7V. Compact, have long battery life, and are readily available.
- **Voltage Regulator (tracker):** Regulating voltage from battery pack to sensors/MCU (3.3V)
- **Battery Holder (tracker):** Holding batteries

## Subsystem 5: DATA DISPLAY
This will simply be the screen we use to display all needed information for the user to track their beacons using the tracker
- **E-Ink Display:** For displaying compass, frequency, and distance data

# Criterion For Success

- Primary Criterion: Demonstrate that the “Beacon” or “Puck” can be found by an end user being guided by the “Tracker”’s on-screen information

- Additional Criterion: Demonstrate the ability to change frequency at which the “Beacon” and “Tracker” Communicate

# Github Link

https://github.com/ben-olaivar/ECE445_software

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