Project

# Title Team Members TA Documents Sponsor
27 Pickleball Paddle Sensor Module
 Alex Luckett
Levente Deak
Peter Brennan
 Eric Tang other1.pdf
other2.pdf
# Pickleball Paddle Sensor Module

Team Members:
- [Peter Brennan] (petersb2)
- [Teammate 2] ([netid])
- [Teammate 3] ([netid])

# Problem

Pickleball has exploded in popularity, but players at every level have no easy way to quantify their performance. Coaches and serious players in other racket sports (tennis, baseball) have long had access to swing analytics, but pickleball lags behind. Most "smart" options on the market today either require a bulky, fully sensor-laden paddle or rely on computer vision, which is impractical for casual, everyday play.

# Solution

We want to build a small PCBA-based sensor module that mounts to a standard paddle and automatically tracks meaningful in-game stats. Using an IMU, the board will detect and classify swing type (drive, dink, serve, volley, forehand, backhand) and estimate swing speed. A secondary sensing approach like a piezo or contact microphone tuned to the acoustic/vibration signature of ball-paddle contact will handle collision detection, distinguishing an actual hit from a practice swing or incidental bump.

As a stretch goal, we would like to refine the collision data further to estimate strike location on the paddle face (center vs. edge/off-center contact), giving players direct feedback on mishits and improving their awareness of the paddle's sweet spot.

This project leans harder on sensor fusion and signal processing than on component count. We expect the bill of materials to stay fairly small (IMU, piezo/vibration sensor, MCU, and a BLE module for stat offload), but getting reliable swing classification and clean contact detection out of noisy accelerometer/vibration data will take real iteration. We anticipate several PCB revisions to dial in mounting placement, sensor orientation, and noise isolation from the paddle material itself, along with meaningful firmware work to build out the classification logic.

# Solution Components

## Subsystem 1: Motion Sensing & Swing Classification

This subsystem captures raw motion data and classifies swing type and speed. It centers on an IMU (accelerometer + gyroscope) mounted rigidly to the paddle handle/frame, feeding data to the MCU for real-time processing. Given the sensor-fusion workload, we plan to use an MCU with sufficient headroom to run classification in real time, likely an STM32, though we will evaluate lower-power alternatives if battery life becomes a constraint on the wearable-scale board.

- IMU, part number TBD pending evaluation
- MCU: STM32 (family/part TBD), evaluating against lower-power alternatives

## Subsystem 2: Contact/Collision Detection

This subsystem determines whether the paddle has made genuine contact with the ball, as opposed to a practice swing or incidental bump. It uses a piezo element or contact microphone bonded to the paddle face/frame, tuned to the acoustic/vibration signature of ball-paddle impact, with supporting analog front-end circuitry (filtering/amplification) to condition the signal before it reaches the MCU.

- Piezo disc or contact microphone element, part number TBD
- Analog conditioning circuitry (amplifier/filter stage), parts TBD

## Subsystem 3: Data Offload & Power

This subsystem handles logging and wirelessly offloading swing/contact data to a phone or companion app, plus powering the whole module in a compact, low-profile form factor that can mount to an existing paddle.

- BLE module, part number TBD
- Battery and power management circuitry, parts TBD

# Criterion For Success

* The board reliably detects and classifies swing type (drive, dink, serve, volley, forehand, backhand) from IMU data with demonstrated accuracy across repeated test swings.
* The board estimates swing speed from IMU data with consistent, repeatable output across trials.
* The contact sensor reliably distinguishes an actual ball-paddle hit from a practice swing or incidental bump, verified through controlled testing.
* The PCBA is small and low-profile enough to mount to a standard paddle without interfering with normal play.
* Swing and contact data is successfully offloaded via BLE to a phone or companion app and can be logged for a full session.
* Stretch: the system estimates strike location on the paddle face (center vs. edge/off-center) with demonstrated accuracy.
* Stretch: a companion app or dashboard visualizes session stats (swing counts, types, speeds, contact accuracy).

Covert Communication Device

Ahmad Abuisneineh, Srivardhan Sajja, Braeden Smith

Covert Communication Device

Featured Project

**Partners (seeking one additional partner)**: Braeden Smith (braeden2), Srivardhan Sajja (sajja3)

**Problem**: We imagine this product would have a primary use in military/law enforcement application -- especially in dangerous, high risk missions. During a house raid or other sensitive mission, maintaining a quiet profile and also having good situational awareness is essential. That mean's that normal two way radios can't work. And alternatives, like in-ear radios act as outside->in communication only and also reduce the ability to hear your surroundings.

**Solution**: We would provide a series of small pocketable devices with long battery that would use LoRa radios to provide a range of 1-5 miles. They would be rechargeable and have a single recessed soft-touch button that would allow someone to find it inside of pockets and tap it easily. The taps would be sent in real-time to all other devices, where they would be translated into silent but noticeable vibrations. (Every device can obviously TX/RX).

Essentially a team could use a set of predetermined signals or even morse code, to quickly and without loss of situational awareness communicate movements/instructions to others who are not within line-of-sight.

The following we would not consider part of the basic requirements for success, but additional goals if we are ahead of schedule:

We could also imagine a base-station which would allow someone using a computer to type simple text that would be sent out as morse code or other predetermined patterns. Additionally this base station would be able to record and monitor the traffic over the LoRa channels (including sender).

**Solutions Components**:

- **Charging and power systems**: the device would have a single USB-C/Microusb port that would connect to charging circuitry for the small Lithium-ion battery (150-500mAh). This USB port would also connect to the MCU. The subsystem would also be responsible to dropping the lion (3.7-4.2V to a stable 3.3V logic level). and providing power to the vibration motor.

- **RF Communications**: we would rely on externally produced RF transceivers that we would integrate into our PCB -- DLP-RFS1280, https://www.sparkfun.com/products/16871, https://www.adafruit.com/product/3073, .

-**Vibration**: We would have to research and source durable quiet, vibration motors that might even be adjustable in intensity

- **MCU**: We are likely to use the STM32 series of MCU's. We need it to communicate with the transceiver (probably SPI) and also control the vibration motor (by driving some transistor). The packets that we send would need to be encrypted (probably with AES). We would also need it to communicate to a host computer for programming via the same port.

- **Structural**: For this prototype, we'd imagine that a simple 3d printed case would be appropriate. We'd have to design something small and relatively ergonomic. We would have a single recessed location for the soft-touch button, that'd be easy to find by feel.

**Basic criterion for success:** We have at least two wireless devices that can reliably and quickly transfer button-presses to vibrations on the other device. It should operate at at *least* 1km LOS. It should be programmable + chargeable via USB. It should also be relatively compact in size and quiet to use.

**Additional Success Criterion:** we would have a separate, 3rd device that can stay permanently connected to a computer. It would provide some software that would be able to send and receive from the LoRa radio, especially ASCII -> morse code.