We Built a Cricket Speed Gun From a Phone Camera and Got the Physics Wrong

Every cricketer has wondered after a good spell: how fast was that delivery? Historically, the answer was always just a guess. Coaches used stopwatches, teammates would say it looked quick, or nothing at all. High-end equipment costs hundreds, if not thousands, of dollars, making speed measurement out of reach for most fans. Baseball has many tools for measuring pitch speed, but cricket has none.

Abdulbasit, a 19-year-old, and Mustafa Asim decided to build a solution. This is their story, including the time they realized their approach was flawed.

The plan was straightforward: film the delivery side-on, pinpoint when the ball left the bowler's hand and when it pitched, count the frames between, and divide by the frame rate to calculate speed. The pitch is a standard 20.12 meters, so distance over time equals speed. However, the initial design had flaws that would be discovered later.

First, they needed to determine if a phone's camera could record at a high enough frame rate. A cricket ball traveling at 140 km/h covers about 39 meters per second. At 30 frames per second, this would translate to one frame every 1.3 meters of travel, insufficient for accurate measurement. At 60 frames per second, the resolution improves, becoming workable.

To test this, they recorded on a Samsung S25, and the camera maintained a locked 60 fps across all nine recordings. They learned that phone advertised 60 fps could sometimes drop frames in low light, rendering the measurement useless. The app now requires a minimum three-second recording to ensure accurate frame rate measurement.

Two important lessons emerged from this week: the frame rate is a floating-point number that must be read per file, never hardcoded, and exposure settings significantly impact the recording. A fast-moving ball would appear as a smear if the shutter speed was too slow. They also turned off stabilization to prevent warped frames that could corrupt pixel positions. Importantly, the library they relied on, FFmpegKit, had been retired in January 2025, so they had to develop a local solution.

After establishing a reliable frame rate measurement, they realized the core calculation was flawed. The ball doesn't travel the full length of the pitch; it's released about two meters past the bowler's crease and pitches six to eight meters short of the stumps. This means the actual distance traveled by the ball is closer to eleven meters, not twenty. Consequently, any speed measurement would be roughly doubled, leading to inaccurate results.

The team corrected this by redesigning the app to measure the distance between the stumps and the ball's release and landing points. This approach required marking both sets of stumps — a minor change that made a big difference. They were now measuring the actual distance the ball traveled, not an inflated number.

However, even this new method had its challenges. During a test indoors, the app inaccurately recorded a slow-moving ball at 302 km/h. After debugging, they discovered the issue stemmed from a library that had been retired, causing the app to malfunction. They had to build a local solution to handle frame indexing, ensuring accurate distance measurements.

Their journey highlights the importance of verifying the last update of any library before integrating it into a project. By learning from their mistakes, they created a more accurate cricket speed measurement tool, albeit with a few setbacks along the way.