Skip to content

Documentation

Wheels by brand

What is supported on each brand, and how well it has been confirmed on real hardware.

Every brand's protocol is decoded separately. Below is a straight account of what works and what was reconstructed from the manufacturer's app and still needs confirming on a real wheel.

The rule all of this follows: a command is only ever sent to a wheel once its meaning has been confirmed by a real capture or a real write. Reverse engineering someone else's app produces a hypothesis, nothing more.

LeaperKim#

The most complete support.

  • All telemetry, including angles, left and right battery currents and the wheel's own limits.
  • Battery cells, page by page.
  • Wheel settings are written from the app: pedal stiffness and ride mode, tilt-back speed, PWM threshold, screen backlight, pedal angle, transport mode, units, voltage correction, low battery mode, high speed mode, button volume, maximum charge voltage, acceleration and braking assistance, and more.
  • Setting presets.
  • Automatic light, automatic volume.
  • Keeping a parked wheel awake.
  • The debug screen can flash firmware to the wheel. It was built for this brand specifically. I strongly advise against using it: a failed flash turns a wheel into a heavy piece of furniture.

NOSFET#

The same protocol as LeaperKim, so everything is available: telemetry, battery, wheel settings, presets, lights, power off.

The only gaps are keeping a parked wheel awake and firmware flashing. Both are tied to LeaperKim for now. If someone volunteers to test them on a real NOSFET, I will add them.

InMotion#

V11 and everything newer. V12, V13, V14 and P6 are the best understood.

  • Full telemetry.
  • Battery.
  • The list of faults and warnings the wheel reports about itself.
  • Quick actions: low and high beam, automatic light, power off.
  • The P6 also reports tyre pressure.
  • The polling interval is adjustable: polling more often gives smoother readings but loads the connection harder.

For V12 and for the V14 family including the P6, light settings are written: turning the wheel's own automatic light on, its light sensor thresholds, and brightness. V12 and V14 lay these out differently internally, and that is accounted for.

A caveat: these writes have been verified against the checksum maths and the manufacturer's own code, but not fully confirmed on real hardware. A few settings, such as the high beam switching threshold and the turn signal state, are read-only because I know of no way to write them.

Begode#

Both current models and old ones such as the RS.

Read reliably:

  • battery voltage,
  • cell voltages of both batteries,
  • charge level,
  • speed,
  • PWM,
  • temperature.

Still in question: current and power. The sign and exact meaning of those fields need checking on a real wheel under load, so do not treat them as final.

The voltage class can be switched by hand from the menu if the app guessed it wrong.

No settings are written to the wheel.

KingSong#

Built from the manufacturer's app plus one real capture from an S22.

  • Telemetry and ride statistics.
  • PWM.
  • The speed ceiling and the flag the wheel raises while holding it.
  • Watt-hour counters.
  • Battery with cells and temperatures. The decode closes on itself: thirty cells add up to within a fraction of a percent of the voltage the same pack reports as a whole.
  • Headlight control.

What is missing: writing settings. Not one setting command is implemented, and none will be until a real capture confirms what they mean.

The test base is small and I do not own one of these wheels, so some readings may be off.

Solowheel Xtreme#

The oldest wheel here, from Inventist, from before InMotion. It sends three numbers as short text about once a second.

The app shows speed and voltage. Voltage is confirmed by a real capture, and the speed scale was calibrated from a real ride. The third number is some kind of state whose meaning is unknown, so it is shown as it arrives rather than dressed up in an invented label.

Your brand is not here#

Write to me. Adding support takes two things:

  1. A capture of the conversation with the wheel. The app records it through the service screen and exports it as a file.
  2. A couple of known values from the wheel's own display or the manufacturer's app: voltage, speed, distance. They are what turns a guess into a check.

The longer the capture and the more varied the riding in it, the more fields can be worked out.