Automotive diagnostics. Embedded systems. Robotics. Software. If it has wires, an engine, or a compiler, I've probably taken it apart.
I'm a high school senior with a hands-on technical mind and a creative drive that pushes me past surface-level answers. I don't approach problems academically — I approach them the way a mechanic or engineer does:
What is it actually doing? What's really causing that? How do I fix it?
My interests span automotive diagnostics and performance tuning, electronics and power systems, computer vision and robotics, and software development — and I run projects across all of them at the same time.
I hold SACA certifications in manufacturing and automation, OSHA certification, and competed on FRC Team 4156 as a developer and builder. I learn fastest by building something real, breaking it, and debugging my way back.
Built a dual-vision system for Team 4156's competition robot. The primary pipeline ran NanoOWL on a Jetson Orin coprocessor — an open-vocabulary object detector that identified yellow FUEL balls in real time and streamed bounding box data over NetworkTables to the roboRIO.
When the Jetson had CSI camera issues during competition, I integrated a Limelight 3 as a drop-in replacement, writing a color-threshold pipeline for ball detection and a separate AprilTag pipeline for Hub targeting and autonomous distance calculation using the ty angle offset.
Debugged GPIO pin conflicts when the tilt stepper motor failed to initialize — traced to GPIO.setmode() not being called before output, and resolved with a proper cleanup/init sequence. Built the full Java robot architecture on WPILib + Phoenix 6 including a swerve drive base.
double ty = LimelightHelpers
.getTY("limelight");
double dist = (HUB_HEIGHT - CAM_HEIGHT)
/ Math.tan(Math.toRadians(
CAM_ANGLE + ty));
// feed to shooter RPM lookup table
double rpm = distToRPM(dist);
Built a 7.4V series Li-ion pack by harvesting Samsung 18650 cells from WORX 20V PowerShare drill packs — each pack yields 5 cells, 2 used in series for the gun, 3 spare. Identified that WORX "Nitro" and "ProPlus" labeled packs use non-standard cell formats and avoided those.
Wired a PWM motor speed controller (5–10A rated) directly from the pack to the gun motor, bypassing the boost converter that was browning out at the motor's 3–5A draw. The boost converter was rerouted to charging duty only, running CC/CV into the pack with manual monitoring at 7.7V.
Determined empirically that 8V is the sweet spot — above that, diminishing returns on speed with increasing heat. Below 7.4V, pressure drops noticeably. The nozzle diameter, not voltage, turned out to be the real range limiter.
| Cells | Samsung 18650 (from WORX 20V pack) |
| Config | 2S series — 7.4V nominal, 8.4V max |
| Controller | PWM, 5–10A, variable speed |
| Fuse | 15–20A inline blade on positive |
| Sweet spot | 8V operating — empirically tested |
| Wire | 14 AWG minimum |
Designed a fully parametric 3D-printable adapter that clicks onto any WORX 20V PowerShare battery the same way a tool would, exposing clean positive and negative terminals for external wiring. The WORX connector has 5 pins — only the 2 power pins matter; temp, voltage sense, and ID pins float.
Went through three full design iterations in OpenSCAD. V1 established the dovetail rail channel and contact geometry. V2 added a cantilever latch arm and spade connector housings. V3 matched a compact rectangular block form factor with top-face contact holes, a side-mounted cantilever latch with downward hook, bottom-accessible spade pockets, and internal wire routing channels.
Key design parameter: a tunable FIT variable (default 0.2mm) adjusts rail channel clearance for different printers. Material must be PETG or ABS — PLA will deform from battery heat and can't flex for the latch.
FIT = 0.2; // adjust for printer
RAIL_W = 14.5 + FIT;
RAIL_D = 6.0 + FIT;
module latch_arm() {
difference() {
cube([40, 12, 4]);
// hook cutout
translate([28,-2,0])
cube([8, 6, 4]);
}
}
Running a custom tune on a 2.5L I4 via SCT X4 tuner alongside an aftermarket intake and Vibrant resonator + Dynomax Super Turbo cat-back. The car is a rolling diagnostic project — I monitor it the way an engineer would, not just driving it.
Caught and diagnosed an O2 sensor heat soak event at sustained WOT near 110mph — AFR spiked to 21–23 on the datalog, which looked dangerously lean. Traced it to the upstream wideband sensor saturating thermally and reporting garbage, not actual lean mixture (the ECU runs open-loop rich at WOT regardless). The sensor recovered slowly on cooldown, confirming the cause.
Active PIDs being logged: measured AFR, STFT, LTFT, knock retard, RPM, MAF voltage, throttle position. Idle/cruise sits at 14.3–15 AFR — slightly lean-of-stoich, consistent with a minor vacuum leak or MAF calibration offset from the intake swap.
| AFR (idle) | 14.3 – 15.0 (slightly lean) |
| AFR (WOT) | 12.5 (target rich, open loop) |
| AFR (fault) | 21–23 (sensor heat soak) |
| STFT | Monitoring for vacuum leak signature |
| LTFT | Long-term correction baseline |
| Mods | Aftermarket intake, Vibrant res, Dynomax muffler |
| Tuner | SCT X4 — custom 93-octane tune |
Built a lightweight Python system-tray app that manages a USB Wi-Fi dongle as a rebroadcast hotspot — taking the laptop's primary connection and sharing it as a separate network to other devices. The UI lives entirely in the system tray with right-click controls, no window.
The key engineering challenge was VPN passthrough — to ensure hotspot clients get tunneled through ProtonVPN or Cloudflare WARP, Internet Connection Sharing must be configured on the VPN virtual adapter, not the raw Wi-Fi interface. Getting this wrong means clients bypass the tunnel entirely.
The app fires netsh wlan and netsh interface PowerShell subprocess calls under the hood, checks adapter state, and presents clean on/off toggle controls. Compiled to a standalone .exe with PyInstaller --noconsole so it runs silently in the background with no console window.
import subprocess
def start_hotspot(ssid, password):
subprocess.run([
"netsh", "wlan", "set",
"hostednetwork",
f"mode=allow",
f"ssid={ssid}",
f"key={password}"
], check=True)
subprocess.run([
"netsh", "wlan", "start",
"hostednetwork"
], check=True)
# ICS shares from VPN adapter,
# not raw WiFi — critical for tunnel
| Language | Python 3 |
| Tray UI | pystray + Pillow |
| Network | netsh (PowerShell subprocess) |
| VPN | ProtonVPN / Cloudflare WARP |
| ICS target | VPN virtual adapter (not raw WiFi) |
| Distribution | PyInstaller --noconsole → .exe |
Unlocked firmware write protection on a Dell Chromebook 3100 — a modern device with a CR50/Ti50 GSC security chip that controls WP in firmware, not a physical screw or jumper like older models. The only path is CCD (Closed Case Debugging) via a Suzy-Q USB-C debug cable.
Connected the Suzy-Q to a Linux laptop, verified the /dev/ttyUSB1 interface appeared, then used minicom to open the CR50 serial console. Ran ccd open — which requires physically pressing the Chromebook power button several times over ~5 minutes as an anti-remote-attack measure — then wp disable to kill write protection.
With WP off, developer mode was enabled and MrChromebox custom firmware was flashed. Followed the Chrultrabook project for Windows driver compatibility on the Celeron N4000 / Intel UHD 600 hardware.
# Verify Suzy-Q on Linux laptop ls /dev/ttyUSB* # → /dev/ttyUSB0 /dev/ttyUSB1 # Open CR50 serial console screen /dev/ttyUSB1 9600 # → cr50> # Check current WP state cr50> ccd cr50> wp # Initiate unlock (press power btn # on Chromebook ~5x over 5 min) cr50> ccd open # Disable write protection cr50> wp disable cr50> wp # → wp: disabled ✓
| Device | Dell Chromebook 3100 (APRICOT board) |
| Security chip | CR50 / Ti50 GSC |
| WP method | CCD via Suzy-Q USB-C debug cable |
| Console | /dev/ttyUSB1 @ 9600 baud |
| Firmware | MrChromebox (mrchromebox.tech) |
| OS | Windows via Chrultrabook drivers |
I'm a high school senior with a hands-on technical mind and a creative drive that pushes me past surface-level answers. I don't approach problems academically — I approach them the way a mechanic or engineer does: What is it actually doing? What's really causing that? How do I fix it?
My interests span automotive diagnostics, electronics and power systems, computer vision and robotics, and software development — and I work across all of them simultaneously. I learn fastest by building something real, breaking it, and debugging my way back.
I'm not the candidate who studied the textbook and passed the test. I'm the one who took the engine apart in the driveway, figured out why it was running lean at idle, fixed it, and then went inside to work on a robot. I learn fast, I don't give up when it gets complicated, and I bring genuine curiosity to every problem I touch. That's not something you can teach — it's just how I'm wired.
I'm a high school senior actively looking for opportunities in manufacturing, automation, automotive tech, and robotics. If you're building something interesting, I want to hear about it.