A VESC, rebuilt phase wiring, and a handlebar display I actually wrote

01 — Premise

Why replace a controller that worked

A stock ebike controller is a black box with a throttle input and a speed limit. You cannot see phase current, you cannot see FET temperature, you cannot change the ramp, and when it fails it fails silently. The stock display is worse: a battery bar with four segments and a number that is nominally miles per hour.

A VESC turns all of that into a documented, configurable, instrumented system. It runs field-oriented control instead of trapezoidal commutation, it reports every state variable I care about over CAN, and it lets me set the current limits from the actual ratings of the pack and the board rather than from whatever the factory decided.

The catch is that a VESC also lets you destroy the board and the motor in about four seconds if you commission it carelessly. Most of the work below is about not doing that.

02 — Hardware

Three boxes and the wires between them

The whole system is a pack, a controller, and a display. Everything interesting happens at the boundaries.

The display board is the right board for this

Most ESP32 dev boards would need an external CAN transceiver bolted on. This one has a transceiver, a 16-position screw terminal that exposes CAN-H and CAN-L directly, a 120 Ω termination switch on the back, and a 7–36 V input — so it takes bike power through a buck converter without another regulator board in the loop.

Verified GPIO map

03 — High current

Phase and hall terminations

The replacement controller arrived with a different connector scheme than the motor's harness, which means the three phase leads have to be joined somewhere. At 100 A continuous this is the single most consequential mechanical joint on the bike — a bad phase connection does not fail gracefully, it arcs, heats, and eventually welds or opens under load.

A printed block instead of a bundle of heat shrink

Rather than butt-splice and hope, I designed a parametric 3-post terminal block in OpenSCAD and printed it. It joins each controller phase to its motor phase with crimped M5 ring terminals on a shared stud, inside a shell that makes a phase-to-phase short physically difficult.

• 22 mm post pitch — clears M5 ring terminals of roughly 15 mm outer diameter with real margin at 100 A+.
• Captured hex pocket under each post, so the bolt cannot spin while the nut is torqued from above. Bolts drop in from below before assembly.
• Six 12 mm open-top wire entries cut fully through both long walls, so flexible 12 AWG and its lug necks enter without a sharp bend.
• Full-height divider walls between phases, so a loose lug or a dropped tool cannot bridge two of them.
• Snap-on lid closing the entire live area while keeping the joints serviceable.

Hardware per block

• 3 × M5 × 16 mm hex-head bolts
• 3 × M5 all-metal lock nuts, kept within their temperature rating
• 6 × copper ring terminals, 5 mm stud hole, crimped to the real wire gauge

Hall sensors

The motor is hall-sensored, which is what makes smooth starts from zero possible without sensorless startup tricks. The controller's HALL port carries 5 V, a temperature line, three hall signals, and ground. Those run back to the motor's sensor connector unmodified — the hall harness is low current and the factory connector is fine.

The temperature pin is the interesting one: the controller can read a motor thermistor through it, but only if you know which thermistor type the motor actually uses. I have not confirmed that, so motor temperature sensing stays disabled rather than configured with a guess.

04 — The link

Two nodes, one bus, three wires

The display is a passive telemetry node. It listens; it does not command the motor. That distinction matters both for safety and for configuration — a setting like Multiple VESCs Over CAN assumes any other CAN node is a second drive controller, which would mean throttle commands get repeated to the display. It is not, so that setting is off.

Three rules that are not optional

• Share a ground. CAN is differential but it is not magic — without a common reference between the controller and the display, the bus floats and you get nothing, or worse, intermittent garbage.
• Twist CAN-H and CAN-L, a few twists per inch. This is a bike with three unshielded phase wires switching tens of amps a few centimetres away. The twist is what makes the differential pair reject that.
• Terminate both ends at 120 Ω. Two nodes, two terminators. The display has a switch on the back for this.

What the display decodes

VESC status frames are extended-ID CAN, with the command in the upper byte of the identifier (cmd = ID >> 8). Enabling status messages 1 through 5 at 20–50 Hz in VESC Tool gives the dashboard everything it renders:

Speed is not on the bus. The controller reports electrical RPM, and turning that into miles per hour needs the motor pole count, the gear ratio, and the wheel circumference — which is why those live in the display's own settings page rather than being hardcoded.

05 — Tuning

Commissioning without cooking it

The phase-filter trap

This is the failure mode that kills these boards, and it is worth understanding before you plug anything in.

Flipsky's 75-series firmware from 5.03 onward has a Enable Phase Filters option. The Pro variant has phase-filter hardware. The non-Pro variant does not. If the option is set true on a board without the hardware and the motor spins, the board can be destroyed. Worse, the motor detection wizard offers to load default parameters — and answering yes re-enables the filter after you have carefully turned it off.

1. Identify which board you actually have

   Pro and non-Pro both report the 75_300_R2 firmware hardware target, so the firmware label tells you nothing. Go by the product listing and the physical board. Mine is documented as the non-Pro 75100 V2.0.

2. Set phase filters false, and write it

   Motor Settings → FOC → Filters. Set Enable Phase Filters = False and write the motor configuration before running detection. Not after.

3. Say no to "Load Default Parameters"

   During the wizard, when it offers to reload defaults, answer no. This is the step that undoes step 2 and cooks the board.

4. Run detection with the wheel off the ground

   FOC detection spins the motor. Do it on a stand, with nothing in the way, and with a hand on the disconnect.

The shipped configuration was wrong in six places

After capturing 24 screenshots of the controller's as-delivered state, six settings were not "untuned" but actively incorrect for this hardware:

Staged current limits, with a gate on each stage

Motor current is phase current and mostly controls low-speed torque. Battery current controls pack draw and roughly sets electrical power. They are not interchangeable, and the shipped values exceeded both the controller rating and the pack's label.

06 — Firmware & UI

The display firmware and cockpit architecture

PlatformIO, Arduino framework, LVGL 8/9 for the interface, and ESP-IDF's TWAI driver for CAN. The board runs a qio_opi flash and PSRAM configuration, which the 800×480 RGB panel needs for its double-buffered frame buffer and vector map runways.

Production screens (800×480) & layout hierarchy

The UI is designed around fixed 800×480 production roots with strict touch ergonomics (minimum 46 px interactive touch targets):

• Full-Map Drive Cockpit (Drive · Night / Drive · Day): The full canvas is occupied by a vector map runway backed by PSRAM with smooth GPS auto-follow, heading rotation, manual pan, recenter, and optical zoom steps (75%, 100%, 125%, 150%). Status pill, large digital speed, estimated range, ODO, trip meter, power gauge, and zoom controls float neatly along the borders.
• Thumb Rail (Right 76 px): The right 76 px is reserved as a thumb-friendly navigation and ride-mode selector (Eco, Normal, Sport) reachable while keeping a hand near the grip.
• Live Data & Settings (Live Data · Night / Settings · Day): Uses a 724×54 px top rail (status pills, clock, battery %) paired with a 724×426 px content canvas containing real-time telemetry tiles (FET temp, phase amps, pack volts, watt-hours) and persistent NVS settings.

Built in stages, each one provable

• Stage 1 · Panel

  Get the RGB panel and its timings right in isolation. Nothing else works until pixels do.

• Stage 2 · Cluster

  LVGL gauge layout driven by fake data, so the interface can be designed without the bike present.

• Stage 3 · Telemetry

  Real VESC CAN frames decoded and bound to the gauges. This is where the fake data gets deleted.

• Stage 4 · Settings

  Touch input, NVS calibration, and persistent odometer/trip storage.

Configuration on the screen, not in a rebuild

Wheel diameter, pole pairs, gear ratio, cell count, units and power scale are all set on the touchscreen and persisted to NVS. That was a deliberate call: those values needed verification against GPS on real rides, and a tuning loop that requires reflashing the firmware between every guess is a tuning loop nobody finishes.

Build and flash

# build and upload; the port is auto-detected
pio run -t upload

# serial logs on the native USB port
pio device monitor -b 115200

The board enumerates as a native USB JTAG/serial device (303A:1001), so it auto-flashes without touching the BOOT button. On macOS the port name moves around between usbmodem101, usbmodem2101 and similar, which is why the upload target auto-detects rather than hardcoding it.

07 — Status

Where it stands

Panel, LVGL cluster and live VESC CAN telemetry are working. Touch and the settings page are in progress. Next up are SD-card raster map tiles with GPS, and iPhone music metadata over BLE — the board has BLE 5 but no Bluetooth Classic, so there is no A2DP audio path; it uses Apple's Media Service to read track metadata and send transport controls while the phone keeps playing to its own output.

Accessory & Lighting Integration

The Jasion Retrovolt Pro's stock lighting harness (headlight model JZX-DDC-014 48V with integrated DC-DC converter, horn, and turn signals) runs directly off full pack voltage (~52–58.8 V). The display board's isolated digital inputs (DI0, DI1) are rated for 5–36 V, so turn-signal sensing uses a series dropping resistor network (or PC817 optocoupler front-end) to safely feed blinker states into the dashboard's top indicator bar.

What this one taught me

The firmware was the easy half. The hard half was refusing to accept any number I could not source — the pack's real discharge limit came off the label, the controller's real rating came off the manufacturer's specification, and the settings I could not verify (thermistor type, measured rollout) stayed explicitly disabled instead of being filled in with something plausible. On a system that turns a battery into torque, a plausible guess and a verified value look identical right up until they don't.