Enough gears. Time for throttle.

Mark IV did its job

The clearest proof came from a ride I wasn't paying attention to. The head unit was in my pocket on the way back to the office — fully assisted, no curated test conditions, nobody watching the screen — and when I finally checked it, it had correctly identified both gears I'd actually used. That's the kind of validation that matters more than a dozen careful bench tests: it worked when nobody was making sure it would.

That result, on top of a string of rides before it, is what moved me from "this seems to be working" to "I trust this enough to build the next system on top of it." Gear sensing doesn't need to be perfect to graduate — it needs to be reliable enough that I'm not still second- guessing it while I'm trying to debug something else entirely. It's there.

Why this is Mark V, not Mark IV.1

Mark IV's whole job was sensing — watching wheel and crank speed, working out which gear the drivetrain is actually in, and doing it reliably enough to trust. It never touched anything the bike does; it only watched.

Mark V changes that. It keeps everything Mark IV proved and adds a genuinely new capability on top: reaching into the throttle signal itself and, under firmware control, substituting a synthesized one. That's not a tuning pass on the old system — it's a new kind of system wearing the same head unit. New major version, not a point release.

The power side

A single battery does two separate jobs. It feeds the head unit directly, through the same battery header and power-latch logic already proven on the bench. And it feeds a boost converter, tuned to a clean 5.00V, which in turn powers everything electrically downstream of the ESP32: the DAC that will generate the substitute throttle signal, and the relay coils that decide whether that signal is actually in use.

The part that actually matters: how the signal switches

The real throttle signal passes straight through a relay by default — unpowered, that's simply what the relay does, no firmware required to keep it that way. Only when the ESP32 deliberately energizes it does the path switch over to the DAC's generated signal instead. A second relay, driven by the same signal, exists purely so the firmware can check its own work — reading back whether the commanded state actually happened, rather than just hoping the coil did what it was told.

I want to be honest about a limitation I'm knowingly accepting here. Two separate relay mechanisms genuinely can't prove to each other that neither one has welded its contacts shut — that would need a single relay body with two poles sharing one armature, which is a part I've since sourced but haven't built in yet. I'm comfortable deferring it for one specific reason: the brake lever on this bike is wired directly to the motor controller, independent of anything this circuit does, and applying it cuts power unconditionally. A stuck relay in that world is an annoyance, not a hazard. The stronger relay eventually goes in — just not before it's actually needed.

From schematic to solder

All of the above existed as a diagram before it existed as anything physical — battery, boost converter, DAC, and relay pair, worked out on paper first, with a deliberate build order: power verified with a multimeter before anything else connects, each subsystem checked in isolation, and the real throttle signal not touched at all until everything upstream of it has already proven itself safe on the bench. That plan is what I'm actually soldering to now.

Nothing about this changes what's still genuinely undecided — which head unit and screen this ends up living behind, and what the real enclosure looks like, are questions I'm deliberately leaving open a while longer. Sense the world reliably, then act on it carefully: that's Mark V's whole shape right now, and the box it lives in can wait until both halves have earned it.

— Paul