[Tomblarom]

Workflow and behavior

Former Innotrace X1 owners need to send a special CAN message before the controller becomes accessible in VESC Tool. X1-Unlocker packages that step as a LispBM script for VESC Express, intended to make the X1 appear as a VESC CAN device without sending the message manually.

At startup, the script turns on the red LED, selects CAN baud-rate setting 1, sends extended frame 0x00D431FF with payload 14 78 00 00 00 00 00 00, and scans the bus. If the scan finds no device, it repeats with baud-rate setting 2. A successful scan turns the LED blue and prints X1 available; otherwise it prints not found.

The script runs once at boot. There is no periodic availability check or reconnect loop, and a successful CAN scan is not an X1-specific identity check. The package contains the script and README, with no custom QML interface.

Using the unlocker

The X1-Unlocker README contains the full setup instructions and connector references. With the package installed on VESC Express, the documented sequence is:

1. Connect CAN-H and CAN-L to the X1, following the pinout below.
2. Turn on the battery and the display before powering/connecting the VESC Express.
3. Connect with VESC Tool, wait for the blue LED, then choose Scan CAN → X1.

The README describes support for X1 firmware 2.4.x.x and 2.5.x.x. Rotor calibration, maximum current and maximum wattage were reported as working in the original PR description; these are historical author reports, not results from a new hardware test. This remains experimental, with limited functionality and no claim that arbitrary controller parameters are supported.

Connector references

These are the existing wiring illustrations included in this PR, not before/after screenshots or proof of a successful connection.

Connector location	Connector pinout

Location image source: Green Bike Kit, as credited in the README. Pinout credit: @dedo's forum post. Connector references: female 04R-JWPF-VSLE-S, male 04T-JWPF-VSLE-S.

Current branch scope and review limits

The current diff also contains a later ebike/ addition copied from blacktip_dpv: a LispBM runtime, QML configuration UI, documentation, display assets, tools and Python smoke tests. Separate src_lbm/ files provide pedal-assist and Bafang UART reference logic. The root Makefile adds ebike to PKGS and changes TEST_PKGS from blacktip_dpv to ebike; res_all.qrc adds both packages.

This is broader than the X1 unlocker alone. The copied e-bike README/UI still contain DPV-specific content; those contents are not evidence of validated e-bike behavior.

QA and outstanding checks

Description review against head a374619503feaed44cb5da325d53a1c0c2581ab7 on 19 October 2026:

• Inspected the PR diff, unlock sequence, packaging files and existing images. No automated check results or reviewer validation are attached to the PR.
• No build, package installation, LispBM execution, QML UI session or controller test was performed for this description update. X1 firmware compatibility, parameter changes and LED/CAN behavior still need hardware verification. No before/after capture or runtime video is available.
• Static build gaps remain: x1_unlocker is referenced by res_all.qrc but absent from root PKGS; the e-bike Makefile still refers to ebike.lisp, while the committed runtime is ebike.lbm. A successful clean archive/package build is not established.
• The e-bike smoke suite implements Python copies of functions; it does not execute LispBM, the QML UI, Bafang communication or the X1 unlocker. Its presence is not a passing test result.