There's a thread on r/10s called "Am I really serving 130 mph?" and a near-identical companion thread, "Is this Swing Vision MPH accurate, my hardest serve only 66 mph?". One says the app is too generous. The other says the app is too harsh. Both are right that something's off — and both have the same underlying cause.

This post explains why phone-camera serve speed has a real error band, what produces the error, and how to actually use the number you get.

TL;DR

A phone camera sees in 2D. Serve speed is a 3D quantity. The system has to infer the depth, and it does that from the court keypoints.
If the court keypoints are slightly off — by a few percent — the inferred depth is off, and the speed reads systematically high or low by 10–20 mph.
The error is consistent for a given camera setup, which means the number is useful as a relative measure but not as an absolute one.
If absolute speed matters, use a radar gun. A PocketRadar costs about as much as one month of a top-tier video app.

The 130 mph problem (and the 66 mph problem)

Sam Groth's serve, the fastest officially recorded, was 163.7 mph at the Busan Challenger in 2012. Andy Roddick's career best was 155 mph. The men's tour average first-serve speed is roughly 120 mph; the women's tour averages ~105 mph. An NTRP 3.5 club player typically hits a first serve in the 80–95 mph range (we go deep on this in /blog/ntrp-3-5-real-serve-speed).

So when an amateur opens an app and sees "130 mph," the number is, on its face, implausible. The Reddit thread title speaks for itself: "Am I really serving 130mph?" The community answer is consistent: probably not, the camera setup probably caused an over-read.

The 66 mph thread is the same problem in reverse: a player who knows their serve is genuinely in the high 80s, watching the app report 66, asking r/10s what's going on. The community answer there is also consistent: probably the camera setup, probably an under-read.

These threads exist because phone-camera serve speed is fundamentally an estimation problem with a known structural error. Let's unpack it.

Why monocular speed estimation is hard

Speed = distance / time. Time, the camera knows precisely (it's just frame count divided by frame rate). Distance is the problem.

A phone records a 2D video. The ball moves in 3D. To turn the ball's pixel-by-pixel motion into a real-world distance, the system needs to know where the ball is in 3D space at each frame. There are roughly three ways to do that:

Stereo cameras — two cameras a known distance apart, triangulate. (Hawk-Eye uses 6–10 of these, calibrated.)
Depth sensor — LiDAR, structured light. (iPhone Pros have this; most Android phones don't; the resolution at 20+ metres is limited.)
Single-camera + scene geometry — infer 3D from a 2D image using known reference points (the court lines).

AceSense, SwingVision, and every other phone-based tennis AI use option 3. It's the only one that works on every phone. It also has a structural limitation: the inferred depth is only as accurate as the scene geometry, and the scene geometry depends on locating the court keypoints in pixel space.

Where the error comes from

A court keypoint detected 2% off in pixel space turns into a depth estimate that's a few percent off — and the speed scales with depth, so a 4% depth error becomes a 4% speed error. On a 90 mph serve, that's about 3.6 mph. Doesn't sound bad.

But the error compounds for a few specific reasons:

Off-axis camera. If the phone isn't centred behind the baseline, the apparent shape of the court is distorted. The detector still finds the keypoints, but the homography that maps pixel-to-court-coordinates is now solving a harder problem with more residual error.
Bad camera height. Phone too low (mounted at fence-bottom height) and the back baseline is barely visible; phone too high (held above the head from a balcony) and the perspective compresses.
Off-parabolic serves. A flat serve travels along a clean parabolic arc; a heavy slice or a dipping kicker doesn't. The 3D inference assumes a roughly ballistic path; the more your serve deviates from that, the noisier the inference.

Stack two of these and you can easily produce a 10–15 mph systematic error. That's the 130 mph problem and the 66 mph problem in one paragraph.

Why the error is systematic, not random

This is the bit that matters most. The error from a given camera setup tends to be in the same direction, with similar magnitude, for every serve in that session. If your court-keypoint detection is off by 3% high, every serve reads ~3% fast. If it's off the other way, every serve reads ~3% slow.

That sounds bad. Actually, it's the saving grace.

If you record on the same court, with the same camera in the same position, week after week, the relative serve-speed numbers tell you exactly what you want to know: am I getting faster? Are my second serves more consistent? Is the gap between first and second narrowing? All of those are accurate measurements even if the absolute number is 8 mph off.

This is why the community advice on the 66 mph r/10s thread and the 130 mph thread converges on the same answer: don't trust the absolute number, trust the trend.

How to set up to minimise the error

If you want the most accurate phone-based serve speed possible, do these four things:

Centred phone. Phone on the centre line of the court, behind the baseline. Off-centre is the single biggest error source.
Net-tape height or slightly above. 3 to 4 feet (1m to 1.2m). Too low and the back of the court compresses; too high and the perspective is wrong.
Far enough back. 8 to 12 feet behind the baseline gives the camera the full court in frame without overly extreme perspective.
At least 30 fps, ideally 60. Higher frame rate = finer time resolution = lower speed-per-frame error.

The full setup guide is at /how-to/film-your-tennis-match. It's not magic; it's the difference between a serve reading that's ±5% and one that's ±15%.

What AceSense actually shows you

We hedge serve-speed numbers explicitly. The report shows:

The estimated speed, with an explicit confidence band based on the camera-setup quality detected from the video.
A flag if the camera setup looked off-axis, off-height, or off-distance — with a "consider re-shooting" note.
A trend chart over your previous sessions, which is the use that actually matters.

We'd rather give you "92 mph ± 6 mph, medium confidence" than "92 mph" when we know the latter is misleading. Players have been mis-sold on the precision of these numbers for years; we're trying not to add to it.

What about radar?

If absolute serve-speed accuracy matters to you — if you're calibrating against a published NTRP benchmark, or you've made a bet with your hitting partner — buy a radar gun. A PocketRadar Smart Coach is around $400; the Ball Coach version is closer to $200. Even the cheap radars are going to be more accurate than any monocular video estimate, by a wide margin.

Use video for the things video does well — shot patterns, heatmaps, technique scoring, match charting — and use radar for the one thing radar does well, which is absolute speed. Pairing the two is the right move if speed is your bottleneck.

What this means for the AceSense user

In a sentence: your serve-speed number on AceSense is a reasonable estimate, used as a trend it's reliable, used as an absolute it has a real error band, and we tell you when the band is wide so you can decide what to do with it. We won't pretend monocular video has solved a problem it hasn't.

If serve speed is mission-critical for you, pair AceSense with a radar gun. If you want everything else AceSense does — shot detection, classification, heatmap, stroke quality — those numbers don't have the same structural limit and are documented separately on /accuracy.

Related: How accurate is AceSense? covers the rest of the pipeline. The real serve speed for an NTRP 3.5 player is the benchmarks post that gives you something to compare your number to. And /features/shot-detection is the feature page if you want the product view.