Close
0%
0%

Building an ESP32-Based Basketball Dribble Tracker

ESP32 and MPU6050 embedded basketball tracker that detects dribbles, shots and rotation, with custom PCB and BLE mobile connectivity.

Similar projects worth following
0 followers
The goal of this project was to build a compact motion-tracking system that could be embedded directly inside a basketball and detect basketball movements without requiring an external tracking device.

The system combines an ESP32 microcontroller, an MPU6050 IMU, custom miniaturized PCB hardware, embedded motion-processing firmware, power management, and Bluetooth Low Energy communication with a companion mobile application.

A few months back, one of our engineers brought a simple question to the team: can we count basketball dribbles accurately without strapping anything to the player's hand? The answer turned out to be yes, and the build is a good example of what embedded application development services actually look like in practice — a real problem, a constrained bill of materials, and firmware that has to work on the first try.

This post walks through how we built it, the components we used, and the decisions we made along the way.

The Problem With Counting Dribbles

Dribble counting sounds trivial until you try it. A phone in a pocket picks up footsteps, arm swings, and crowd noise. A wrist wearable works, but players don't want extra gear during training. We wanted something that sits on or near the court — a small device mounted under the hoop or clipped to a pole — that detects the ball hitting the floor and counts each bounce.

That means we're detecting a specific vibration and impact signature, filtering out everything else, and doing it on battery power for weeks.

  • 1 × ESP32-WROOM-32E module dual-core, built-in BLE, plenty of headroom for DSP on the accelerometer data
  • 1 × LIS3DH 3-axis accelerometer SPI interface, low power, configurable interrupt thresholds. The onboard tap-detection feature is genuinely useful here
  • 1 × Custom PCB we designed ours in KiCad, roughly 30mm x 45mm, two layers

  • Logs

    Himanshu Dada14 minutes ago 0 comments

    We instrumented everything. Every detection event writes a structured log line: timestamp, peak amplitude, estimated interval since the last dribble, and a confidence score from the detector. Every BLE connect and disconnect gets logged. Every filter state transition gets logged at debug level.

    This wasn't just developer hygiene. It became a product feature. Coaches can export a session log as CSV and see not just *how many* dribbles a player did, but the cadence — whether they sped up, slowed down, or got sloppy as the drill wore on. One coach told us he could spot fatigue patterns in the interval data before he saw them in the player's body language.

    We also used those logs heavily during tuning. When a player reported a missed count, we pulled the raw IMU trace from that window and compared it against the detector's output. In nine out of ten cases, the miss was a genuine edge case — a very soft dribble, or a crossover where the hand motion changed direction mid-bounce. We tuned the detector against real data instead of guessing.

View project log

  • 1
    Prototype on breadboard

     Wire the LIS3DH to the ESP32 over SPI (SCK=18, MISO=19, MOSI=23, CS=5). Power from 3.3V. Flash a basic sketch that prints raw accelerometer values over serial.

  • 2
    Get the detection working

    Implement the bandpass filter and threshold logic. Tune the threshold by dribbling and watching the serial output. You want clean counts with no double-triggers.

  • 3
    Add BLE

    et up the GATT service. Test with nRF Connect or LightBlue before writing any app code.

View all 5 instructions

Enjoy this project?

Share

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates