First real-world data.
The clusters are real.

Correction — June 2026 The noise reduction claims in this post contain an error. A correction has been published here.

Today GearSense rode a real bike on real roads for the first time. What came back wasn't just data — it was proof that the core concept works, a noise calibration breakthrough from an accidental experiment, and a rethink of the entire control model that makes GearSense smarter than originally conceived.

What we set out to do

The goal for today was simple: get the Phase 1 passive logger onto the bike, go for a commute, and see whether distinct gear ratio clusters emerged from the raw sensor data. No motor intervention, no control logic — just observe and record.

The hardware stack going into today: ESP32-D0WD dev board, KY-003 hall effect sensor on the front wheel, existing PAS sensor tapped at the bike's bottom bracket, 2S 1500mAh LiPo in a weatherproof case, BLE streaming to an Android phone via Serial Bluetooth Terminal. Total hardware cost well under $30. Everything already in the parts bin.

6
gear clusters detected on first commute
85%
of samples assigned to a cluster
0.29
std deviation on dominant gear — EXCELLENT quality
8%
noise after filter applied

The first ride

The first commute logged 8.5 minutes of data. Running the raw CSV through a peak detection algorithm produced six distinct gear ratio clusters — clean enough to be unambiguous. The dominant gear (ratio 11.99, the comfortable commuting gear) produced 563 samples with a standard deviation of just 0.35. That's a tight, repeatable signal from a real sensor on a real bike on real roads.

Key finding The gear ratio is exactly as stable and distinct as the theory predicted. Each gear produces a characteristic ratio that clusters tightly around a fixed value. The algorithm doesn't need to know anything about the bike — the clusters emerge from the data automatically.

Gear 7 didn't appear in this dataset — simply because it wasn't used on this particular commute. That's not a failure. It's expected behaviour and confirms that the system only learns what it observes, exactly as designed.

The noise problem — and an accidental breakthrough

Across multiple rides today, spurious clusters appeared at high ratio values (20–35) that couldn't correspond to any real gear on a 7-speed bike. Investigation pointed to the spoke magnet triggering twice per wheel revolution — once on approach, once on departure — effectively doubling the apparent wheel speed and therefore the computed ratio.

Various mitigations were tried: relocating the sensor further from the hub motor (it was already on the front wheel, so motor interference was ruled out), increasing the firmware debounce constant from 5ms to 15ms for the wheel signal specifically. The debounce change alone dropped noise from 35% to 8%.

Then the spoke magnet fell off mid-ride.

It's not a bug, it's a feature. In one dataset we have the required signal with noise, followed by pure noise. It tells us exactly what this system is seeing that we need to filter out.

— Paul O'Rorke, realising the accidental experiment's value

The dataset where the magnet detached mid-ride splits cleanly into two phases: signal plus noise before the detachment, pure noise after. The noise-only phase is a fingerprint of exactly what the sensor picks up when there is no real wheel signal — road vibration, electrical interference, whatever else triggers a hall effect sensor in a real-world environment.

This led directly to the noise calibration protocol:

Ride 1 — calibration

Install GearSense fully but with no spoke magnet fitted. Ride normally to work. Every wheel signal the sensor sees is definitionally noise — the magnet isn't there to produce a real signal. Log everything. This is the noise fingerprint under real operating conditions, with the motor running and pedals turning.

Between rides

Fit the spoke magnet.

Ride 2 — learning ride

Ride home normally through all gears. GearSense already knows what to ignore. Any ratio that appeared prominently in the calibration ride gets flagged as noise and discounted from the cluster analysis.

Subsequent rides — running mode

Real-time gear detection with noise filter active. Gear map refines continuously as more data accumulates.

The filter was implemented and tested against the split dataset. Noise dropped to 8%. The two surviving clusters showed a step ratio of 1.282x — right in the expected range for a Shimano 7-speed cassette.

// Noise filter — runs in main loop, not interrupt handler bool is_noise(float ratio, const NoiseProfile &profile) { if (profile.magic != GEARSENSE_MAGIC) return false; int bin = (ratio - profile.bin_min) / (profile.bin_max - profile.bin_min) * profile.bins; if (bin < 0 || bin >= profile.bins) return false; return profile.density[bin] > profile.threshold; }

Trail feedback — unsolicited market research

During one of today's rides, several eBike riders were encountered on the trail. The GearSense concept was explained to each of them. The responses were unanimous.

So like an automatic vs a standard car?

Trail rider — immediately grasping the concept

Fucken DO it. I'd buy one.

Trail rider — on understanding the retrofit proposition

None of the riders encountered had an eBike that offered anything like what GearSense describes. The gap in the market that GearSense targets is real and felt.

One rider asked: "How does it know when there's a hill?" That question led directly to a rethink of the control model.

The control model rethink — speed targets, not power levels

The original GearSense control concept allocated a fixed percentage of motor power to each detected gear — more power in higher gears. This works, but it requires the rider to manage assist level separately from gear selection, which is exactly the problem GearSense is supposed to solve.

The better model emerged from the hill question: GearSense doesn't need to detect hills. It just needs to maintain a target speed.

Your gear selection IS the throttle. The rider sets intent through gear selection. The motor executes.

— from today's design session

The revised model works like this: each detected gear has an associated target speed, set according to the rider's comfortable cadence range. The motor acts as a speed governor — when the bike falls below the target speed for the current gear (because of a hill, headwind, or load), the motor increases power automatically to compensate. When the bike exceeds the target speed, the motor backs off.

The rider never needs to think about assist level. Shift up, the target speed increases. Shift down, it decreases. The motor fills the gap between human effort and target speed continuously and invisibly. Hills are handled automatically — not because GearSense detects hills, but because it detects that the bike is below target speed and responds.

Modes redefined Ride modes (Cargo, Cruise, Sport) no longer set power levels — they set target speed profiles per gear and acceleration ramp rates. Same gear map, same sensor data, different speed targets and how aggressively the motor pursues them. The modes are the personality of the ride.

Hardware findings

FIRMWARE

Separating the PAS and wheel debounce constants was an important refinement. PAS stays at 5ms (cadence signal is clean). Wheel debounce raised to 15ms — this rejects spurious pulses arriving faster than a genuine wheel revolution at maximum speed, dropping noise from 35% to 8% in a single constant change.

HARDWARE

Front wheel placement for the speed sensor is confirmed correct. The front wheel is completely divorced from the motor, chain, and drivetrain — zero magnetic interference. And a key insight: the front wheel being a different size from the rear doesn't matter. GearSense doesn't need absolute speed — it needs consistent ratio. The clusters are always there regardless of wheel size.

BATTERY

The 2S 1500mAh LiPo is marginal for extended rides. A depleted pack gave out after two minutes. The Waveshare ESP32-S3 board (arriving tomorrow) with its onboard charge management and 2000mAh single-cell LiPo will be dramatically better — charge via USB-C wherever the bike is parked.

MAGNET

The 3D printed spoke clip retained the magnet but the magnet itself detached from the clip during a ride. The fix is a redesigned clip that positively captures the magnet mechanically rather than relying on adhesion. A cable tie sandwich works as an immediate interim solution.

Mark III concept — wireless self-powered sensors

A conversation today led somewhere unexpected. The XIAO ESP32-C3 (thumbnail-sized, ESP-NOW capable, deep sleep current under 50µA) makes a wireless sensor node genuinely viable. But the real insight was about power.

The very thing being sensed is also powering the sensor. A small coil on the fork, the spoke magnet passing at wheel speed, tiny pulses of induced current harvested into a supercapacitor. One magnet. Two functions. Zero batteries.

— on energy harvesting from the wheel magnet

This is Torque Monster in reverse — the same electromagnetic principles, miniaturised and inverted. Instead of electricity becoming rotation, rotation becomes electricity. The sensor node becomes: harvesting coil, bridge rectifier, supercapacitor, XIAO ESP32-C3, hall sensor. Fit and forget. No charging, ever.

This is Mark III thinking and won't be pursued until Marks I and II are proven. But it's worth documenting because it points toward the product's ultimate form.

What the data says overall

Across five ride datasets collected today, the pattern is clear. The gear ratio signal is real, stable, and detectable. The noise is real, characterisable, and filterable. The two are separable. The concept works.

The challenges remaining are engineering challenges, not conceptual ones. Magnet retention, noise calibration protocol, debounce tuning. These are solved problems with known solutions. The unknown — whether the gear ratio would cluster cleanly enough to be useful — has been answered. It does.

Next steps

  1. Redesign and reprint spoke magnet clip with positive mechanical retention
  2. Implement noise profile data structure and NVS storage on ESP32
  3. Calibration ride (no magnet) followed by learning ride (with magnet) — first full protocol test
  4. Commission Waveshare ESP32-S3 Touch LCD board — Mark II hardware
  5. Design speed target table and mode profiles for control firmware
  6. Implement cadence coherence checking to reject coasting data
  7. DBSCAN clustering on ESP32 for real-time gear detection

On the journey

GearSense is moving faster than any project in recent memory. The reason is simple: it sits entirely on top of solved problems. ESP32, hall sensors, BLE, PAS rings — decades of engineering by thousands of people, available for $30 in a parts bin. The only thing new is the idea of connecting them in this particular way, for this particular purpose.

That's what theIdea.club is for. The idea is the contribution. The rest is assembly.

Today a stranger on a trail said "fucken DO it." That's the clearest possible signal.