Field session · 7 Sep 2026 · an empty parking lot · Honda Rebel 1100 DCT
The Miracle Happened!
The About page ends with a phone on the handlebars, some raw data handed to a Claude Code AI session, and a request for a miracle.
This is what happened next.
Twenty-one minutes of numbers
The input wasn't much to look at. It was one zip file from an app called Sensor Logger, recorded during 21 minutes and 35 seconds of parking-lot drills, plus a short clip recorded in the garage. It had no video, no notes about which drill was which, and no cones. It held a few million rows of numbers from the phone's accelerometer, gyroscope, compass and GPS, and that was all.
The one instruction was roughly this: here's the data, I tapped the phone to mark my drills, see what you can find.
The obvious answer was a blob
The natural first move is to plot the GPS track. Phones know where they are, so the drills should just appear.
They didn't. The GPS dots made a featureless smear across the lot. The phone's position was only good to about 4 meters (12 feet), and the drills themselves are only 6–12 meters across. Asking GPS to draw a figure eight is like signing your name with a paint roller.
Claude noticed one thing hiding in the same data, though. The GPS speed was excellent, good to about a sixth of a mile per hour. Speed comes from the Doppler shift of the satellite signals, not from position, so it doesn't share position's blur.
That became the key idea: let the gyroscope draw the shape, and let GPS supply the speed. The gyro knows exactly how the bike is turning, moment by moment. GPS knows exactly how fast it's moving. Combine the two and walk forward one two-hundredth of a second at a time. Navigators call it dead reckoning: no map, just "which way am I pointed, how fast am I going, and for how long."
The same session, the same 21 minutes. On the left is what GPS sees. On the right is what the phone's own sensors drew: rounded rectangles, serpentines, figure eights and tight circles, all overlapping where they were ridden in the same corner of the lot.
That was the moment.
Finding the taps in a running engine
Rich had marked his drills by tapping the phone: three taps to start, two between reps, four to end. That's easy to see in a quiet room and hard to see on an idling 1100 cc twin.
The first attempt failed. The obvious method listens for sharp, high-pitched jolts, and the engine floods exactly that range. Filtering harder didn't help, because the engine is loud at every pitch the filter could pick.
So Claude asked what makes a fingertip different from an engine, and found two answers:
- A tap is sudden. It's over in a few milliseconds.
- A tap twists the phone. A finger lands off-center, so the gyroscope feels a small rotation. Engine vibration mostly shakes the phone back and forth without twisting it.
A real tap has to show up in both sensors at the same instant. That rule cut through the engine noise.
To test it, Claude used the short garage clip, recorded with the engine off. Rich had tapped three times before each flip and shake of the phone. The detector found every one of those triple-taps, about three-tenths of a second apart. It had learned Rich's rhythm.
Then came the real test. With no list of drills to go on, the detector found a three-tap, four accelerate-and-stop runs separated by two-taps, and a closing four-tap. It had worked out the emergency-braking drill and the marking scheme from the signal alone.
It also found taps while the bike was rolling at 8–10 mph, with spacing so even that the analysis notes called it "a metronome, not a pothole." So the app shouldn't assume a rider stops before marking.
Every drill, drawn
With the taps found, the ride split into segments, and Claude drew each one.
Claude learned to read them without being told what they were:
- A circle turns a full 360° every lap.
- A figure eight turns plenty but ends up facing about where it started.
- A U-turn turns 180°.
- A stop-and-go run has a stop every few seconds.
One segment came out as four neat lobes, which matched Rich's description of the offset weave. Another turned 1,169° in 46 seconds, which is about three and a quarter tight circles. Two long stretches had no taps at all, but the drawings showed real drills in both. Some taps had simply been missed, which turned into a lesson for the app: marking has to be easy, or it won't get done.
Claude got one guess wrong. It expected a long pause where Rich had stopped to fiddle with a camera, and the data said there was no such pause in this file. Claude reported that plainly instead of bending the data to fit the story.
The braking numbers held up
The emergency-braking reps produced real coaching numbers: speed at the brake, stopping distance, and how hard the bike slowed.
| Rep | Speed at braking | Distance to stop | Peak slowing |
|---|---|---|---|
| 1 | 23 mph | 40 ft | 0.79 g |
| 2 | 28 mph | 56 ft | 0.91 g |
| 3 | 28 mph | 63 ft | 0.88 g |
| 4 | 32 mph | 50 ft | 1.00 g |
Rich looked at those distances and pushed back: are these twice too long?
That was the right question to ask, and the answer wasn't "trust me." Claude measured the distance again two more ways that share no code with the first: once from the raw GPS speed, and once from the GPS position. The raw-speed figure agreed within 2–7%. The position figure came out a little short, and the reason is known: phones smooth their position, so it lags during a hard stop. The distances were real.
The interesting part was why they were long. On every rep the brakes reached their peak, but late. Average slowing was only about half of peak, because the distance was lost while the brake pressure was still building, not at the peak. Reps 2 and 3 started at the same speed but stopped 7 feet apart. Rep 4, the fastest, scaled down to 20 mph, would have passed a common 25-foot standard with room to spare. One genuinely good stop and three that weren't is far more useful to a rider than an average.
Then came an unexpected idea: entry speeds varied by 9 mph from rep to rep. Since stopping distance grows with the square of speed, that one inconsistency could almost double the stopping distance before technique even enters into it. A beep at the target speed would fix most of that, and the numbers say even a slow beep would do.
What it couldn't find, and what that led to
Not everything worked. Claude searched hard for countersteering, the brief push of the bars away from the turn that starts every lean. It didn't find it. Rather than claim a result, it worked out why: in 21 minutes of slow drills, the bike was turning above 20 mph for less than one second. The experiment simply hadn't asked the question.
Three weeks later, with a camera on the frame and another on the bars, it did. That story is in Countersteer, caught on two cameras.
So, was it a miracle?
No magic was involved. A phone on the handlebars, one ordinary practice session, and an AI that:
- tried the obvious thing first and said so when it failed,
- looked for a second way in: gyroscope for shape, GPS for speed, a twist for a tap,
- checked its own work against a quiet garage, a known drill, and three independent measurements,
- reported what it couldn't find as clearly as what it could.
By the end of the day, a pocket phone had drawn every drill, found every marked brake rep, scored them, and pointed to the habit that was costing stopping distance.
For a rider who practices without cones, that's close enough to a miracle. It's also why MotoDrill exists.
What's next
Rich's next ride brought new challenges. He now had an app that clearly marked each drill, but the phone's sensor logger stopped running. A totally wasted ride? No. Claude Code pulled another rabbit out of a hat. This time a 360 hat.