I run some agent farm on the software and reported issue... still waiting for my bike to build but maybe you can find anything helpful here
The full report:
Claude Artifact
AI agent farm analysis of the M620 / VESC "impact wrench" throttle issue
I ran a farm of AI agents through the complete M620/VESC setup: configuration files, firmware source, throttle/PAS command paths, current control, duty control, encoder behaviour, current limits and possible mechanical causes.
The agents reviewed the shipped VESC source line-by-line, challenged different root-cause hypotheses and produced a measurement-led RCA plus a proposed test/fix plan.
Short version:
The main hypothesis is that the throttle is not simply applying too much torque.
It is allowing the motor to build
too much speed while drivetrain slack is still open.
In current-control mode there is nothing directly bounding motor speed during this unloaded phase. The rotor can therefore accelerate very quickly on only a few amps. When the chain/freehub/gearbox slack closes, that stored kinetic energy suddenly hits the drivetrain.
This also explains why
duty mode behaves materially better: VESC clamps the modulation/duty, which effectively limits the voltage available to the motor and therefore bounds the free-spin speed before the drivetrain engages.
The existing 4-second throttle ramp helps, but it only reduces current/impact energy — it still does not create an actual speed ceiling.
Important: this is still a strong mechanism hypothesis, not a proven root cause. We do not yet have a telemetry capture from the affected bike, and the first step is verifying that the configuration archive actually matches what is flashed on the controller.
Other things found during the source/config review:
- Throttle and PAS are configured very differently: throttle positive ramp is 4.0 s while PAS is only 0.3 s.
- The throttle ramp is relative, meaning its actual A/s rate changes with assist level.
- Drive current is +160 A while negative motor current is only −20 A, so rebound-opposing authority may be much smaller than drive authority.
- Stock VESC already contains two potentially useful low-speed limiting features: foc_start_curr_dec and l_duty_start, but both are effectively disabled in the current configuration.
- The encoder→observer handoff is not the likely cause because the handoff occurs around 30,000 ERPM, far above this launch event.
- Throttle mapping itself is already extremely soft: with exp = −5, 10% throttle travel produces only about 0.44% command.
- Current-loop PI oscillation is still technically open, but there is not enough evidence to justify changing PI gains blindly.
- Mechanical backlash/freehub/gearbox slack remains an important possible co-factor.
Before changing firmware — proposed config-only experiments
The nice part is that several useful experiments can be done directly in VESC Tool without rebuilding anything.
A. Start Current Decrease — best first test
Enable the stock
foc_start_curr_dec feature.
Suggested initial sweep:
Code:
foc_start_curr_dec = 0.10 – 0.25
foc_start_curr_dec_rpm = 2500
For example, 0.10 would allow roughly 10% of the normal current ceiling at zero RPM and progressively restore full current by 2500 ERPM.
If this removes the hammering while hill/loaded starts are still acceptable, it might even be a usable config-only solution.
The downside is reduced standstill torque, and it affects PAS as well.
B. Duty-based current foldback
Test
l_duty_start below 1.
This reduces current as duty rises and is therefore the closest stock configuration feature to a speed-sensitive limiter.
Very useful diagnostically, because if this stops the problem while Start Current Decrease does not, it strongly supports the idea that limiting motor speed/voltage is more important than simply limiting initial torque.
It is
not recommended as the final shipped setting, because it is global and would also reduce current during normal riding at higher duty.
C. Increase |l_current_min| — only if logs show duty reversal
Current configuration:
Code:
l_current_max = +160 A
l_current_min = -20 A
If the motor is actually reversing duty/current during the rebound, the −20 A limit may restrict electrical damping.
Increasing its magnitude may shorten the ringing, but it
cannot prevent the first impact.
This should only be tested after confirming reversal in telemetry, and only inside reduced test-current limits.
D. PAS ramp experiment
PAS currently uses 0.3 s positive ramp versus 4.0 s for throttle.
It is worth trying a slower PAS ramp to understand the interaction, but this is mainly a rideability/tuning experiment and
not considered the root fix.
E. Duty mode
Duty control is already the known-good fallback for throttle launches.
It can be a perfectly valid solution for a throttle-focused bike, but it changes torque-sensor/PAS behaviour and therefore is not considered the ideal product solution here.
Recommended firmware direction
If the captures confirm the RCA, the preferred software solution is now:
F4 — current control + throttle-derived duty clamp
The idea is to stay in current-control mode but additionally impose a temporary throttle-derived maximum duty.
That gives us both:
- normal current/torque control,
- full standstill torque capability,
- but also a voltage/speed ceiling similar to the behaviour that makes duty mode work better.
Conceptually:
Code:
max_duty = d_floor + throttle * (l_max_duty - d_floor)
So low throttle corresponds to a low allowed duty/speed, and as the rider requests more power the duty ceiling opens progressively.
This should apply only when
throttle is actually the controlling source, not when PAS is supplying the command.
The report proposes implementing this with a dedicated motor-interface duty-clamp setter plus a timeout/failsafe so a stale application command automatically restores normal max duty.
Other firmware ideas
F5 — explicit slack detection / preload
A more advanced option:
During PRELOAD the controller would gently take up drivetrain slack, then release full power once engagement is detected from ERPM acceleration/rotation/time.
Potentially the best subjective behaviour, but also more complex because reliable slack detection is the hard part.
F3 — speed-feedback damping
Another investigated idea was subtracting current as motor speed rises:
Code:
iq_out = max(0, iq_cmd - kd * omega)
This can soften gentle launches but the final analysis concludes it has
too little authority to be the primary fix at high assist/current levels.
It may still be useful as a LispBM experiment, but it is no longer the recommended architecture.
Two additional firmware clean-ups
S1 — level-independent throttle ramp
Currently the same "4 second" throttle ramp corresponds to very different real A/s depending on assist level.
Example from the current setup:
Code:
Eco: ~4.4 A/s
Level 9: ~40 A/s
The proposed source change scales ramp time with current scaling so the actual current rise rate stays consistent between assist levels.
This improves rideability/consistency but does not solve the fundamental hammering mechanism.
S2 — PAS + throttle interaction
Throttle and PAS each have independent ramps and are merged afterwards.
That means if PAS is already requesting significant power, adding throttle can take seconds before the throttle ramp catches up and actually changes anything.
The proposed software change seeds the throttle ramp from the existing PAS command
only while the rider is actively pressing the throttle, with safeguards so seeded torque cannot survive after PAS disappears.
Again: useful behaviour fix, but not the root-cause solution.
Measurement plan
Before deciding which solution to build, the report proposes capturing:
- mapped/ramped throttle
- PAS target
- raw + decoded brake ADC
- post-brake throttle command
- commanded and measured iq
- ERPM
- duty
- battery/phase current
- encoder error
- fault state
- high-frame-rate video of chain/freehub motion
And comparing:
- Current-mode throttle from standstill
- Current-mode throttle after a small roll
- Duty-mode throttle from standstill
- Pedals-only launch
- Throttle with drivetrain deliberately taut vs naturally slack
Decision rule
If
Start Current Decrease fixes it and loaded starts remain good:
→ possibly ship it or develop a dedicated take-up current profile.
If
duty foldback fixes it but Start Current Decrease does not:
→ build the throttle-derived duty clamp.
If pedals-only launches also hammer:
→ the solution needs to move into a shared PAS/throttle path.
If encoder anomalies appear at the first impact:
→ investigate sensing before changing the control law.
If reducing mechanical backlash removes the problem:
→ mechanics becomes the actual root cause, and controller compensation becomes optional protection.
And if none of these experiments change ERPM/reversal behaviour:
→ the whole speed-driven RCA is wrong and we go back to current/voltage traces instead of continuing to tune around the hypothesis.
Full RCA, source references, proposed patches and measurement plan:
Full M620 CAN "impact wrench" RCA
Nothing has been compiled or bench-tested yet. All firmware patches are proposals and the physical estimates remain order-of-magnitude until we get real telemetry from the bike.
If anyone running an M620/VESC has similar behaviour especially someone able to capture ERPM, duty and iq during the first few hundred milliseconds of a throttle launch that data would be extremely useful
. Located in Finland so it'd probably have to be EU-based.
drive.google.com
