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, alarm 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.
- The headlight switches on across the whole brand, the older models included. Sherman, Sherman Max, Sherman S and Abrams understand only the text light command - their firmware carries no binary one at all, and the light button used to do nothing on them. The app now looks at which wheel answered and sends the command that firmware parses.
- Keeping a parked wheel awake.
- Firmware flashing sits in the dashboard menu as its own item, and only on LeaperKim wheels: other brands do not get the item at all. It has only been proven on the Lynx S; the other wheels of the brand use the same file format, but nobody has tested the bootloader entry on them, and the Sherman L runs a different microcontroller on top of that. 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.
The V11 writes a wider set: speed limit, pedal angle and sensitivity, voice volume, standby timeout, headlight brightness, the acceleration and braking assists, sound, daytime running lights and the wheel's own automatic light. After every write LoEUC asks the wheel to re-read its settings, so what you see on the screen is what the wheel accepted rather than what was requested. The two fan rows are shown but not writable: one of them is a state the wheel reports rather than a setting, and neither has a write command I trust.
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.
Wheel model#
Charge from voltage is the pack voltage divided by the number of cells in series, and that
number comes from the catalogue — along with capacity and full-charge voltage. The catalogue
has one key: the model name. Most wheels report it; Begode does not. It advertises as
GotWay_005913, which is a serial number, and answers nothing to a name request.
So the model is picked by hand: dashboard menu → Model. The pick is stored for that wheel and survives a reconnect. If the app recognised the model on its own, the menu shows its name marked "detected from name" and there is nothing to do.
Until the model is picked or recognised, charge is not shown. The series-cell count cannot be derived from a single voltage even in principle: a full 36S reads 151.2 V, and so does a 40S at 3.78 V per cell. The app used to guess here from voltage, and on a T4 it guessed wrong — a sag below 90 V moved the divider from 24S to 20S, and charge read 100 % on a half-empty pack for the rest of the ride.
If you set the voltage class by hand before, it keeps working until you pick a model.
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:
- A capture of the conversation with the wheel. The app records it through the service screen and exports it as a file.
- 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.