esk8 calc donate now

VESC FW 5.0 - Beta Testers wanted


No, because I build for transportation, reliability, and safety. That’s never even possible, by design.

I know what a full-throttle 27mph (43.4km/h) power cut feels like — it feels like you slammed the brakes and turned into Superman.

But regarding the cutoffs, I’m not sure why it’s even allowing your voltage to fall that low, and adding a ramping time would seem to exacerbate that problem in my mind.

I’d suggest using a lower power setting… your problems will evaporate…

1 Like

I’m building a better battery.

1 Like

Fair enough

1 Like

It might, but giving me more time to react is precious for not streetfacing.

1 Like

This is also exactly why I prefer one radio receiver per motor. Reaction time is precious.

If one motor loses signal 50ms before the other one, that can be the difference between streetface or not.

1 Like

IM very HO about the MTPA, field weakening isn’t great for e-sk8 and tiny motors, on big motors like e-bikes we can compensate the extra heat generated by cooling directly the motors. On tiny motors it will most probably just heat up & run less efficient, then lose torque thus speed after heating too much.

With a lighter load or bigger motor this could be a thing, but we’re already pushing these tiny motors to their limits there. We can’t even attach proper fins or try stuff like liquid cooling / statorade / mineral oil. Internal thermal patch and limited airflow is the only thing left, and we’re fighting with little fans the size of 50 to 80mm diameter, at best.

I can see benefits for other domains of use since Ben has tailored his work for many uses an not just esk8 or scooters. But for us the benefit of MTPA is null I believe.

Feel free to demonstrate me wrong on the road. Or off road.


I’ve been trying to use larger EV motors with VESCs to no avail. I’d love to be able to provide data as I know that some vesc projects have turned up for EV use. Unfortunately I am unsure of how my testing setup needs to change to accommodate these larger motors but I would appreciate any features that are targeted towards this market as it is obviously a target for Benjamin. Anyone with guidance on this issue would be great


Can you share which motor and which VESC model you’ve been trying ? Which battery voltage ?

Bigger examples I know of are running higher voltage and pretty high amperage than off the shelf VESC6 and 4. However on principle, even a 10 and 12S setup should work :thinking:

I think it’s this.

A Toyota Pruis drivetrain and FSESC 6.6


Ok, here is a probable cause : very low Kv motor and too low voltage setup causing detection issues for the VESC classic current sensing scheme. Also it’s a big mass of motor, how much amps are needed to run detection?

FSESC6.6 is way underpowered for that thing.

Only official version I know able to drive at circa 450/500v this would be Axiom. Already runs in a CRX conversion.


While rated for 500V these things can most definitely be run lower than that. I’m not sure of how many amps would be needed to get it to spin up, and I didn’t want to up the amps and have a spectacular explosion. I don’t care that the vesc doesn’t work in this specific scenario but if there is a way to get it to run on a normal 12S battery for testing that would be awesome


I’m ready with my changes on app_ppm.
Tested on bench with all control types.
I added a last minute feature :

  • ADDED : Traction control auto-disabling in case of fault on master, re-enable only if no effect on motors will happen (avoid weird behaviour exiting fault state on master).

Unfortunately, I can’t do the same on slave as it doesn’t send the fault over CAN (Could be great to use half of the spare slot in CAN_PACKET_STATUS_5 for this, couldn’t be?)

However, looking at app_nunchuk (WAND) if I want to apply the same relative command strategy (sending % instead of absolute current value), it would require to change the way the ramping is done (currently, ramping is done directly on current output instead of relative setpoint (%) like in app_ppm).

So, I’m not sure I want to touch this as it may lead to affect the remote behaviour for users and change ramping pos/neg parameters units (and default values). :confused:

For app_adc, it’s already using relative current value. :man_shrugging:


I was looking at the spec sheet of the brand new 900 volt fets. Motor controllers are going to take a quantum leap.
tenor (11)

I was confused by this when I was comparing app_nunchuck’s Cruise control implementation and app_adc’s. Opened an issue to see what was up with the that

1 Like

My App PPM has been merged to the dev branch.
Please, keep in mind that, if you want to test the last version out, it could behave strangely !
I was able to test my work on the bench only as I was still missing some part to rebuild my board for a real ride.

I’m really curious to read your feedbacks !
Thanks testers !


@Pimousse thanks, I just flashed this to the stormcore and will let you know how it goes.

FYI, this new build also adds @NuRxG support for IMU on Stormcore and Unity.

i have tested on stormcore 100D and the IMU is showing up, going to try balance app tonight. i believe the 100S is also tested. The IMU on unity is not currently tested but should in theory work (@Flux)


Thanks buddy!! :grin:
my unity is not fully working well after some water encounter, so the IMU doesn’t show up, probably the ESC is faulty, I can’t confirm anything.

1 Like

I’ll give the beta FW a try on the unity I have on the bench and see if motor temps come back.

As far as the unity guys that are having issues. You don’t have to write your settings down.
Just connect, Scan the can, then proceed with writing your motor settings. Run foc detection and write.
Now, hit the CAN button and write the current motor settings. Viola, you copied everything. Now just overwrite the foc parameters when you do motor detection on that side and you’re don’t.

I almost never hit the “read” button because I’m always moving thay way. Write to one, write to the next and do the foc for that side. Then I don’t hit the motor parameters again.

1 Like

My focboxes spit out faults like it’s no ones business.

Does this mean if there is a slave fault, master keeps going… and a master fault slave keeps going? if so I may be loading this up tonight and giving it a go tomorrow.

Sorry for the late reply.

This is already the case with current FW

This is the purpose of my PPM app rework :+1:

Anyone could give the latest beta a try ?
Still no board rebuilt yet for trying IRL. :confused:

1 Like