Reading rider intent.

Every eBike controller has to answer one question: how hard is the rider working, and how much should the motor help? Most systems guess, using cadence alone (are the pedals turning?) or a strain-gauge torque sensor (how hard are they pushing?). GearSense takes a different approach — it reads the drivetrain itself.

The mechanical insight

A bicycle drivetrain is a fixed-ratio mechanical system. At any given moment, the ratio between crank cadence and rear wheel speed is determined entirely by the selected gear. If you're in a gear with a 2:1 ratio, every crank revolution produces exactly two wheel revolutions. This is not approximate — it is a hard mechanical constraint imposed by the chain and sprockets.

GearSense measures both crank cadence and wheel speed continuously, at sub-revolution precision (1/1024 second timestamp resolution, matching the Bluetooth Cycling Speed and Cadence standard). From these two signals it computes the live ratio. Because the ratio in any given gear is fixed and knowable, the system can identify which gear the rider is in — without a gear position sensor of any kind.

The virtual torque sensor

Here is where it gets interesting. The ratio is fixed by the chain — but the chain can only enforce that ratio if the drivetrain is in mechanical equilibrium. The moment the rider increases effort, or the bike hits a hill, or a headwind increases drag, the drivetrain is momentarily out of equilibrium: the load increases faster than the system can respond. Cadence dips. The ratio shifts.

That shift is the signal. GearSense monitors the deviation of the live ratio from the expected value for the detected gear. A ratio deviation means load has increased. The motor should respond.

No strain gauge. No additional sensor. The drivetrain itself is the sensor.

Total load — not just rider torque

This is an important distinction. The ratio deviation signal does not measure rider effort in isolation. It measures total drivetrain load — the sum of everything resisting forward motion:

• Rider effort — pushing harder on the pedals loads the drivetrain
• Gradient — climbing a hill increases resistance exactly as rider effort does
• Drag — a headwind, rolling resistance, or a loaded pannier all show up the same way

From the ratio deviation signal alone, these three are indistinguishable. And that is precisely the point. An eBike motor should provide more assist when the rider is working harder. It should provide more assist on a hill. It should provide more assist into a headwind. The virtual torque sensor responds to all three automatically, without needing to know which one it is.

A conventional crank-mounted strain-gauge torque sensor sees only rider effort — it is entirely blind to gradient and aerodynamic drag. The GearSense virtual torque sensor sees everything that matters.

Cadence as the on/off gate

There is one condition that cuts assist entirely: the rider stops pedalling. When cadence drops to zero, the crank sensor goes quiet. There is no ratio to compute, no deviation to measure, and no assist to provide — regardless of what the load signal might otherwise suggest. The motor will not drive a stationary rider downhill just because the gradient is steep.

Cadence is the gate. Load is the throttle. Together they give a control signal that is both responsive and safe.

How it works in the firmware

The DSM (Dual Sense Module) is a custom PCB that captures two independent clock signals — one from a crank event sensor, one from a wheel speed sensor. Each event gets its own high-resolution timestamp. The ratio is computed per-sample from these two event streams.

The Central firmware's detect() function currently snaps the live ratio to the nearest entry in a fixed gear table, using a ±0.12 tolerance and requiring two consecutive confirmations before accepting a gear change. This gives robust, noise-resistant gear detection.

The next step — monitoring ratio deviation from the detected gear's expected value, and translating that deviation into a motor assist demand — is the virtual torque signal, and is the active development frontier for GearSense.

Pedals as the throttle — the baseline-hold controller

There is a deeper observation hiding in the virtual torque sensor concept. On an eBike, riders get lazy. The motor holds their speed, so they naturally pedal slower than their gear demands. This is usually treated as a problem — the system has to decide whether to assist a barely-pedalling rider at 40 kph. But looked at from the other direction, it is a feature.

If backing off below your natural cadence slows the bike, and pushing above it speeds the bike up, then the pedals are the throttle. No modes, no buttons, no hand control — the rider's legs are the speed control, continuously and intuitively.

cadBase — the stable baseline

The control law depends on one number: cadBase, the rider's comfortable, natural pedalling rhythm under assist. This is not a configuration parameter — it is learned from the rider's own behaviour during steady assisted cruise.

A key insight makes this work: because the motor holds speed up hills and the rider is not doing the full mechanical work, cadence does not sag with fatigue and does not spike on gradients. The two forces that would otherwise move the baseline are exactly the two that assist removes. cadBase is therefore a stable, learnable constant, not a moving target.

The control law

Once cadBase is known, the assist demand follows directly:

• Cadence above baseline — the rider is pushing harder than usual. Interpret as "I want more speed." Raise the target wheel speed. Increase assist.
• Cadence below baseline, coupled to the drivetrain — the rider is deliberately backing off. Interpret as "slow me down." Reduce assist.
• Cadence below baseline, freewheeling — the rider has stopped pedalling to coast or rest. Hold the current assist level rather than cutting it.

Rate of change of cadence carries additional information. A rapidly falling cadence while wheel speed is stable is an unambiguous deceleration signal — the rider is easing off, not just resting. This allows assist to begin tapering before cadence crosses below baseline, giving the system a softer, more anticipatory response.

Runaway prevention — the bounded effort term

A baseline-hold controller has a positive-feedback risk: pushing harder raises speed, which raises cadence demand, which raises assist, which raises speed further. The fix is to treat the cadence deviation as a bounded nudge rather than an open-ended input. The effort term has a hard cap, and that cap is set by the active mode ceiling. No matter how hard the rider pushes, they cannot exceed the mode's target speed. The pedals give proportional control within the envelope, not unlimited acceleration.

A switchable mode

This behaviour is not always desirable. A rider who wants to cruise effortlessly without the bike responding to every cadence variation — the conventional eBike experience — should be able to have that. The baseline-hold controller is therefore implemented as a switchable mode alongside the fixed mode-speeds option.

In baseline-hold mode, lazy pedalling at speed is not possible — the bike will slow until the rider matches their natural cadence to the desired speed. In mode-speeds, the assist level is set by the selected ceiling and cadence is only the gate. The rider chooses which contract they want with the bike.

What remains to be built

• Baseline learning algorithm — sample cadence only during steady assisted cruise; ignore launches, gear changes, and coasting intervals. Converge on cadBase with a slow integrator so it tracks gradual rider fatigue without chasing noise.
• Baseline-hold controller — translate cadence deviation into a DAC target, with the effort term bounded by the mode ceiling.
• Coupled vs. freewheeling disambiguation — distinguish "backing off deliberately" from "resting/coasting" so the hold-assist behaviour triggers correctly.
• Rate-of-change deceleration signal — compute d(cadence)/dt and use it to anticipate deceleration intent before the full cadence drop arrives.