Project

# Title Team Members TA Documents Sponsor
35 Electric Scooter Battery Management System with Integrated SOC and SOH Estimation
 Edward Chow
Jay Goenka
Samar Kumar
 Xiaodong Ye design_document1.pdf
proposal1.pdf
# Title
UAV Battery Management System with Integrated SOC and SOH Estimation

# Team Members:
- Edward Chow (ec34)
- Jay Sunil Goenka (jgoenka2)
- Samar Kumar (sk127)

# Problem
UAV batteries are safety-critical and performance-critical as a weak or degraded pack can cause sudden voltage drop, shutdown, reduced flight time, or unsafe thermal behavior. The usual BMS implementations primarily rely on fixed thresholds for voltage, temperature or current to prevent immediate failures. However, threshold-only systems do not provide predictive insight into battery degradation. Battery health issues are often discovered only after runtime loss or unsafe behavior. Additionally high discharge currents and fluctuating temperatures are common in UAV operations, which fastens degradation. A lightweight BMS that not only protects the pack in real time but also estimates battery health and degradation risk would improve reliability, reduce unexpected failures, and enable better operational decisions such as deciding if the battery is safe to use or needs to be retired.

# Solution
To address the delicate nature of UAV batteries we decided to undertake a project with the aim to design and construct a compact and efficient battery management system that seamlessly integrates reliable real-time protection with intelligent prediction. Our primary algorithm for estimating the battery’s State of Charge (SOC) will be coulomb counting, which relies on continuous current measurement. We are researching the Kalman filter method as a second algorithm for more accurate calculation. The BMS will also monitor cell voltages and temperatures to ensure safe operation and provide valuable data for battery condition assessment. By analyzing SOC history, voltage behavior, current profiles, and temperature data, the system should be able to estimate the State of Health (SOH) of the battery. SOH over time will help us understand the capacity fade and degradation trends over time. We also plan to log all measurements and stream it to an external dashboard for visualization and analysis. As an extension, the project could also incorporate a lightweight AI-driven model to assist in SOH estimation and degradation assessment.

# Solution Components
## Slave Board
The slave board will be responsible for monitoring individual cell voltages and temperatures and supporting passive cell balancing. It will report accurate measurement data to the master board, ensuring safe operation of the battery pack at the cell level. The HW components and sensors include: Cell monitoring IC: Analog Devices LTC6811 or LTC6813s (multi-cell voltage sensing with built-in diagnostics and balance control) isoSPI communication interface: Analog Devices LTC6820 Temperature sensors: 10 kΩ NTC thermistors (e.g., Murata NCP18XH103F03RB) Passive balancing: bleed resistors (33–100 Ω) and N-MOSFETs per cell Cell sense connectors and basic RC filtering/ESD protection Power regulation: buck converter (e.g., TPS62130) and 3.3 V LDO

## Master Board
The master board is responsible for actually performing pack-level protection, SOC and SOH estimation, data logging, and external communication. It makes sure safety limits are enforced by aggregating data from the slave board. The HW components and sensors include: Microcontroller: STM32H7 series Current sensing: shunt resistor with TI INA240 current-sense amplifier Protection switching: back-to-back N-channel MOSFETs with gate driver (e.g., BQ76200) Power regulation: buck converter (e.g., TPS62130) and 3.3 V LDO Communication: isoSPI (LTC6820), CAN Data logging: microSD card or onboard flash memory

## BMS Viewer
The BMS Viewer will be a software dashboard used to visualize real-time and logged battery data and assess battery health.

Potential features: Live display of SOC, SOH, pack voltage, pack current, and temperature Time-series plots of voltage, current, temperature, and SOC Data ingestion via USB, CAN, or wireless telemetry Backend implemented in Python or Node.js with a web-based dashboard

# Criterion For Success
- BMS detects and mitigates fault conditions within a bounded response time (≤100 ms).
- Cell voltage within ±50 mV per cell, pack current within ±10%, temperature within ±5°C after calibration.
- SOC remains within ±10% of a reference SOC over a full UAV-like discharge cycle.
- SOH estimate is within ±15% of a capacity-based reference and shows consistent degradation trends.
- BMS Viewer displays and logs SOC, SOH, pack voltage/current, and temperature in real time.

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