I am looking for ESCs having the fastest response time as possible.
By response time I mean the time between the moment I change the speed setpoint via the PWM input and the moment the motor reaches this new speed.
Beside mechanical considerations (inertia and others), does the Basic ESC, on its own, introduces any kind of “speed ramp”, or smoothing the setpoint, or is there any delay before applying it ?
Hi @Eric68,
Yes, the Basic ESC does have a low pass filter on the response to input, as governed by the “Startup Power” setting in the BlHeli_S firmware, we set it to 50% by default:
You could change this to the maximum 100% to reduce this behavior, but there may still be some filtering present at this setting. For more information, I would recommend delving into the manual, code, or reaching out to the author.
I would like to note that reducing the response time/ramping will significantly increase the stress on the thrusters, and may lead to a reduced lifespan.
-Adam
1 Like
Adam, thanks for a fast and spot on reply.
I am now looking for ways to set up parameters and/or flash the firmware of the ESC if necessary.
The documentation provided on GitHub says "BLHeli ESCs can be divided into two different hardware platforms, depending upon whether they use a SiLabs MCU or an Atmel MCU. ".
Which case is the Basic ESC’s ?
Happy to help! The Basic ESC uses an SiLabs MCU, BlHeli Suite can easily be used to change the firmware settings.
-Adam
I noticed that the firmware has (slightly) different frequencies than the documentation. Do the actual ESCs ship with values of 1112/1512/1912 or 1100/1500/1900?
Thx
Hi @justin_time, welcome to the forum 
The ESCs do indeed ship with the values programmed as 1112/1512/1912. I’ve asked about this internally previously, and the reasoning provided was that when those parameters were being determined in initial testing it was found that setting those offset values made the ESCs more correctly register physical inputs at the desired pulse-durations (1100/1500/1900).
The pulse-durations the ESCs actually measure depend on the rise and fall times of the driving circuitry, so the ‘best’ values to use there are likely dependent on the flight controller hardware in use, and the electrical properties of the signal cables to the ESCs. As I understand it we haven’t done additional testing about whether that precise offset is actually correcting some underlying clock error in the ESCs, or if it’s just compensating for slow or weak driving by the outputs they were originally tested on.
If a constant offset is an issue for a particular application it’s usually possible to handle by specifying output trim values in the control software. Of course it’s preferable to avoid needing to manually set a trim for every ESC, so setting an offset in the ESC firmware that means it ‘just works’ for the most common use-case makes sense, and makes the user-facing aspects (e.g. parameters in control software) easier to understand and less complicated to work with
Thank you Eliot for the detailed explanation - it explains a lot! I was scratching my head, but this all makes sense.
Thx
1 Like