Back to all work
Flagship · Co-Founder & EE / Firmware Lead

Slingshot

Basketball training-load BLE wearable · LA / OC · Mar 2026 – Present

A battery-powered sensor pod worn on an upper-arm compression sleeve that turns a training session into data, fusing motion and heart-rate into a single Session Load Score, plus jump count, vertical, and heart-rate intensity zones. As co-founder and EE/firmware lead, one of just two engineers on the team, I own the hardware and embedded systems end to end: schematic capture, PCB layout, fabrication, assembly, and firmware bring-up of a matchbook-sized mixed-signal board.

PCB fabricated · in assembly Firmware in development Pilot, summer 2026
Slingshot 4-layer PCB, top side, 3D render
Top of the fabricated 4-layer board, Fusion 3D render (no schematic or layout). Tap to enlarge.
What it crosses
4-Layer Mixed-Signal PCBPower ElectronicsBLE / 2.4 GHzSensor FusionEmbedded C/C++Web Bluetooth

Most of the engineering difficulty here is coexistence: a 2.4 GHz radio, a switching power supply, and a microvolt-level optical heart-rate front end all have to share one matchbook-sized board without corrupting each other. The design is built around protecting RF range and signal quality while still fitting a full sensor suite, on-board logging, and a complete battery-management chain.

The board

A matchbook-sized 4-layer PCB

3D renders of the fabricated design, top and bottom. (Renders only, schematics, layout, and Gerbers stay in-house.) Tap either to enlarge.

Power architecture

The power tree

USB-C charges a Li-Po through a charger with power-path, and a buck-boost regulator holds a clean 3.3 V rail across the entire battery curve. A fuel gauge on the battery node reports state-of-charge.

In
USB-C
5 V
Charge
BQ24074
charger + power-path
Regulate
TPS63802
buck-boost
Rails
3.3 V / 1.8 V
MAX17048 gauge
Brain
nRF52840
BC840M module

Why buck-boost, not an LDO: a single Li-Po swings roughly 3.0–4.2 V, which crosses the 3.3 V output. A buck-boost holds the rail steady across the whole discharge curve where a buck or LDO would sag, a topology choice driven by the battery's behavior, with the switch-node loop kept tight and well away from the radio and the optical front end.

Sensing

Five-sensor suite

Fused over I²C / SPI / QSPI and read by the nRF52840, which logs to flash and streams telemetry over BLE.

HOSTNordic nRF52840 (Fanstel BC840M)
2.4 GHz BLE SoC, reads every sensor, logs to flash, and streams telemetry on a fixed 19-byte packet.
I²C/SPIBMI323
6-axis IMU, jump / sprint / deceleration
I²CMAX30102
Optical HR (PPG), upper-arm contact
I²C/SPIBMP585
Barometer, vertical-jump height
QSPIW25Q64
64-Mb NOR flash, session logging
I²CMAX17048
Fuel gauge, battery state-of-charge
Sensor fusion: the IMU's takeoff/landing signature is fused with barometric altitude to estimate jump height far more reliably than the IMU alone, then streamed out over BLE.
My ownership

What I own, end to end

Hardware / PCB
  • Designed a 4-layer mixed-signal stackup (Top / GND / 3V3 / Bottom) in Fusion Electronics; fabricated & assembled at JLCPCB.
  • Managed RF + switching-supply + sensitive-analog coexistence on one matchbook-sized board.
  • Owned BOM, sourcing, and DFM, basic vs. extended parts, CPL rotations, JLCPCB rules, and checked board-to-enclosure fit via ECAD↔MCAD.
Power electronics
  • Architected the full power tree: BQ24074 → TPS63802 → 3.3 V (+1.8 V), MAX17048 on the battery node.
  • Chose buck-boost over an LDO to hold 3.3 V across the whole Li-Po discharge curve.
  • Applied switching-layout discipline to protect both RF range and heart-rate signal quality.
Firmware
  • Embedded C/C++ on PlatformIO + nRF52 Arduino core for the nRF52840, two build environments (dev kit + custom board).
  • One codebase, two data paths: flash logging + USB-CDC dump (v1) and BLE streaming (v2), additive, no rewrite.
  • Built a synthetic "demo stream" to validate capture → packetize → stream before sensors were wired; SWD/J-Link via nRF52840-DK.
Design review
  • Caught an nRF52840 VDDH/VDD power-mode conflict and a switching-regulator feedback-divider error before fab, both the kind of mistake that kills a board and costs a multi-week respin.
  • Routed every datasheet number, pins, registers, electrical limits, to verification rather than memory.
  • Built in observability: rail test points and a debug header so a non-booting board isn't a black box.
Breadth

Beyond the board

The pod is only half the product. I also built the software that turns its data into something a coach can use.

Python pipeline → 1-page PDF reportWeb Bluetooth coaching consoleMulti-device connectRole-based access · CRUDCompany site on Vercel
Named parts

Real part-level fluency

nRF52840 (BC840M) · BMI323 · MAX30102 · BMP585 · W25Q64 · BQ24074 · MAX17048 · TPS63802
Stack
Embedded C/C++BLE · nRF52840PlatformIOFusion ElectronicsJLCPCBSensor FusionWeb BluetoothPythonGit