Ann Arbor, MI · Looking for hardware internships

Jaden Rhee

Electrical Engineering Student · Sensing Hardware & Python Automation

I build sensing hardware and write the Python that turns its signals into results. Currently designing flex-PCB wearables and strain-gauge sensing for neck and back movement in a biomechanics research lab at Michigan.

View projectsRésumé (PDF)

Projects

The View in 3D models come straight from the real KiCad and CAD files.

Isometric render of the JRWatch 4-layer smartwatch PCB
PCBLow-powerZephyrBLE

JRWatch, a Low-Power BLE Smartwatch

A 36 mm nRF52840 smartwatch board that sleeps at about 15 µA, designed entirely in code.

Problem
Most smartwatches last a few days on a charge because low power is an afterthought. I wanted a watch that runs for months on a 150 mAh cell, with every current number justified before ordering the board.
What I built
A 4-layer 36 x 36 mm board with an nRF52840, an nPM1300 PMIC with two switched power domains and a 370 nA ship mode, a BMI270 IMU for motion wake, and a Sharp memory-in-pixel display that holds a static watch face at about 4 µA. The schematic is written in SKiDL, placement and routing are scripted through the pcbnew API, and the Zephyr firmware builds in CI with a custom board definition. The OpenSCAD case is dimensioned from the board file.
Outcome
ERC and DRC are clean. The firmware fits in 231 KiB of flash and 40 KiB of RAM. The power budget works out to 4 to 8 months per charge, with each line cited in the verification report. Next step is confirming the numbers with a PPK2 at bring-up.

nRF52840 · Zephyr RTOS · SKiDL · KiCad · nPM1300 · BMI270 · C · OpenSCAD

GitHub
Top render of the WiggleCam RP2040 co-processor PCB
PCBRP2040ImagingFirmware

WiggleCam, a 4-Lens Wigglegram Camera

A handheld camera with four synchronized 16 MP lenses, built around an RP2040 co-processor board that drives the flash, shutter, and battery telemetry.

Problem
Film wigglegram cameras need scanning and manual frame alignment, and multi-camera rigs ghost on moving subjects because the sensors fire at slightly different times. A Raspberry Pi 5 is also not suited to hard real-time or analog work: the LED flash needs constant-current drive with hardware safety limits, the shutter needs reliable debounce, and the battery needs monitoring, none of which should steal cycles from image processing.
What I built
A 76 x 50 mm 4-layer RP2040 co-processor board sits between the Pi and the hardware over a 2x6 header mapped onto Pi 5 GPIO, handling constant-current LED flash, shutter debounce, battery telemetry, and multi-camera synchronization over I²C and UART. Its schematic is SKiDL, placement is scripted, low-speed nets go through Freerouting with a DRC gate at JLCPCB limits at every stage, and the Pico SDK firmware exposes an I²C register file with a UART fallback. Four 16 MP sensors sit 40 mm apart behind the faceplate and are merged through a single CSI interface by an Arducam Camarray HAT, so all four exposures happen at the same instant. Python on the Pi 5 splits the frame, aligns the views with phase correlation, and renders a looping gif served over the camera's own Wi-Fi hotspot as a QR code. The body is parametric OpenSCAD with a BMS-protected 4x18650 supply.
Outcome
The co-processor board is fully routed with zero DRC violations and no unconnected nets at JLCPCB 4-layer rules, with 24 measured verification checks and fab files ready to order. The camera software is done and the physical build is in progress, at about $550 of stock-checked parts and an estimated 4.4 hours of runtime.

RP2040 · Raspberry Pi 5 · SKiDL · KiCad · Pico SDK (C) · Arducam Camarray · Python · OpenSCAD

GitHub

Experience

  1. Aug 2026 to Present

    Research Assistant · Musculoskeletal Biomechanics & Imaging Laboratory, U-M

    Ann Arbor, MI

    • Designed the electronics and flex-PCB layout in Altium for neck- and back-mounted IMU wearables, translating sensing requirements into schematics, circuit design, component placement, and routed boards.
    • Fabricated and brought up sensor prototypes by soldering and reworking flex-PCBs, then troubleshooting electrical faults and IMU signals with oscilloscopes, DMMs, bench supplies, and lab instrumentation.
    • Built data-acquisition code and ML-based analysis workflows for multi-axis IMU measurements, connecting hardware prototypes through data collection, evaluation, and validation of wearable biomechanics sensing.

  2. Apr 2026 to Aug 2026

    ECU Design and Validation Intern · Bosch

    Plymouth, MI

    • Analyzed Tesla Model 3 ECU wake-up waveforms as a known-good baseline for an intermittent startup failure, identifying abnormal power-rail timing and incomplete discharge in the failure condition.
    • Designed a high-speed ECU power-switching fixture with PMOS and NPN transistors to reproduce abnormal rapid power-up (83 to 85 µs) across 5 ECUs while preserving ground reference; measured startup current above the 30 A probe range.
    • Instrumented ECU PCBs for bring-up and debug, tracing the failure from vehicle input into internal power rails and correlating rail collapse with ground-reference movement using PicoScope and Teledyne LeCroy oscilloscopes.
    • Simulated buck and boost power circuits in CST and PSpice; recreated a boost-converter schematic and layout in KiCad and bench-tested automotive regulator efficiency against datasheet expectations.

  3. Sep 2025 to May 2026

    Research Assistant · Human-Automation Technology Lab, MSU

    East Lansing, MI

    • Developed a glasses-mounted wearable IMU prototype on Arduino Nano 33 BLE for head-nod detection, integrating motion sensing and data acquisition to capture 1 to 2 s multi-axis inertial windows for algorithm development and validation.
    • Evaluated DSP and deep-learning speaker-verification pipelines for resource-constrained edge hardware, optimizing MFCC, RMS, and ZCR feature extraction by about 50% and profiling accuracy, compute, and implementation tradeoffs.
    • Co-authored an IEEE MWSCAS 2026 paper; developed the embedded BLE case study and contributed experimental analysis, figures, and tables comparing deployable speaker-verification approaches.

  4. Education

    University of Michigan

    B.S. Electrical & Electronics Engineering, Minor in Computer Science

    Ann Arbor, MI · Expected 2028

    Michigan State University, Honors College

    B.S. Electrical Engineering (transferred)

    East Lansing, MI · GPA 3.7 · 2025 to 2026

Research

Lab work on wearable sensing and edge ML. Each study runs on a Python pipeline I wrote.

Isometric KiCad render of the five-channel strain-gauge interposer PCB with five trim pots, a flat-flex connector, and a 10-pin header
ResearchFlex PCBWearablesPython

Wearable Sensing for Neck and Back Movement

Musculoskeletal Biomechanics & Imaging Laboratory · University of Michigan · Aug 2026 to Present

Flex-PCB IMU wearables and strain-gauge sensing for the neck and back, with a Python pipeline that takes every trial from raw signal to ML result.

Problem
The lab needs sensors that sit on the neck and back and bend with the body, plus a repeatable way to turn their raw signals into measurements it can analyze.
What I built
Flex-PCB IMU wearables for the neck and back, designed in Altium from sensing requirements through schematic, placement, and routing. A five-channel strain-gauge interposer in KiCad with a trim pot on each channel. A Python pipeline that streams and logs every trial off the hardware, calibrates the sensors, filters the signals and splits them into individual neck and back movements, then plots the results and trains ML models on them.
Outcome
I fabricated and brought up the flex prototypes myself, soldering and reworking boards and tracking down electrical faults with oscilloscopes, DMMs, and bench supplies. The strain-gauge interposer is at v3.0 and in review before fabrication.

Altium · KiCad · Flex PCB · IMU · Strain gauges · Python

Python pipeline

  1. 01Stream and logStrain and IMU channels off the board, every trial saved
  2. 02CalibrateZero and scale each sensor channel
  3. 03ProcessFilter, then split into neck and back movements
  4. 04AnalyzePlots and ML models on the results
Figure from the paper plotting all 225 pipelines by peak memory and real-time factor, with the valid DSP pipelines inside the 512 KB and 0.8 RTF feasible region

AcceptedIEEE MWSCAS 2026

Speaker Verification on a 512 KB Microcontroller

Human-Automation Technology Lab · Michigan State University · Sep 2025 to May 2026

Nitish Maindoliya, Chenxin Zhang, Jaden Rhee, and Andrew J. Mason

An automated Python sweep of 225 audio ML pipelines to find which ones fit and run in real time on a microcontroller.

Problem
Speaker verification models are usually sized for phones and servers. On a microcontroller with 512 KB of RAM, every choice of audio feature and classifier trades accuracy against latency and memory. We measured every combination to find the best one.
What I built
Python that runs the whole evaluation. It extracts the audio features, with MFCC, RMS, and ZCR extraction about 50% faster after my optimizations, then trains, tunes, and profiles all 225 feature and classifier pipelines and generates the figures and tables in the paper. I also built the embedded BLE case study on an Arduino Nano 33 BLE, the target board, including the Python that pulls data off it.
Outcome
Only 118 of the 225 pipelines fit under 512 KB of RAM and a 0.8 real-time factor, and all of them use classic DSP features. Deep-learning embeddings were too heavy to fit. MFCC and RMS features into an RBF-kernel SVM gave the best overall tradeoff at 52.4 KB of RAM and a real-time factor of 0.01.

Python · NumPy · scikit-learn · Arduino Nano 33 BLE · SVM · MFCC

Read the paper (PDF)

Python pipeline

  1. 01ExtractMFCC, RMS, and ZCR features, about 50% faster
  2. 02SweepTrain and tune all 225 feature and classifier pipelines
  3. 03ProfileCheck each one against 512 KB of RAM and a 0.8 real-time factor
  4. 04ReportThe figures and tables in the paper

Get in touch

Email is the fastest way to reach me.

[email protected]Résumé (PDF)
GitHubLinkedIn