RC-Hangout

I understand that a PWM esc protocol is slower than a ONESHOT125 esc protocol. What I don't understand is how much slower is PWM vs ONESHOT125.

The esc protocol has something to do with how fast information is sent from the esc to the motor, correct? There's probably not a "visible" difference?

Short answer: ONESHOT125 can be up to 8 times faster than traditional PWM. But that's theoretical maximum, and due to the nature of ONESHOT125 and the coupling of FC loop timing with ESC timing, the practical increase is probably less than that in any given application.

Those two protocols have to do with communication between the ESC and the flight controller. While they can have impact on the ESC's signaling to the motor (ONESHOT125 does, in particular) the protocols are not primarily about ESC->Motor but rather FC->ESC.

PWM is traditional servo control signaling. In the original analog servo days, it was a 20ms overall control signal period, of which about 1 - 2ms of it is taken up with an actual control pulse (that's the part you see listed as roughly 1000-2000us, or microseconds, in flight controller software under the receiver setup and/or ESC setup). But for what you're asking it's the 20ms part that's important. That means every second there are 50 throttle values being sent to the ESC by the flight controller. That is for a 50hz PWM signal, what used to be the norm for analog servos. It can be much higher. For instance, on many modern digital servos they are designed to operate with a 333hz control signal, or a period of 3ms. The same 1-2ms position/value pulse is used (except in some very high end servos), there is just a lot less "dead space" in the overall signal period (from 18ms of deadspace in the 50hz version down to 1ms of deadspace in the 333hz version). This same higher frequency signaling can be done with ESCs. For instance you may have seen reference to 400hz PWM capable ESCs, at least before all this oneshot and dshot stuff came about.

Now for ONESHOT125. ONESHOT125 still uses the "analog" PWM scheme for signaling, however it does two things in particular that make it "faster". First, it uses a value pulse of 125us-250us, instead of the traditional 1000-2000us. Second, and where the "one shot" name comes from, the ESC input timing is synchronized to the flight controller's PID loop timing. This means for every loop of the PID controller, the ESC(s) see a single update of the throttle value. Because of this second point, it is impossible to say how much faster ONESHOT125 is vs standard PWM, because it is dependent on the loop time setting on the controller. In theory, though, ONESHOT125 can be up to 8 times faster than the fastest variant of traditional PWM signaling. 500hz being the theoretical max for traditional PWM vs a theoretical max of around 4khz for ONESHOT125. That's with zero dead space in the signaling period of both protocols.

DSHOT is much faster still.

BOOM! Yep...he did it again...my mind just blew up. Lol.

Im just trying to get a grasp on what i can slow down on my 770 quad to get slower communication to the motors.

Well, with oneshot... as I said above the whole purpose of the protocol is to essentially synchronize the FC PID loop time with the ESC signaling rate, so that every new PID calculation output set is sent to the ESC(s) as they are calculated and the ESCs don't run at a different rate, meaning they either miss or duplicate inputs from the FC (depending on if the ESC is sampling at higher or lower rate). I do not know if there is a minimum loop frequency that oneshot can operate at, or more to the point that the ESCs can accept oneshot125 input at. There is a theoretical maximum of 4khz, but I don't know if you could run the FC loop frequency (and thus the esc signaling rate) at 500hz, for example, and have the protocol and the ESCs still work properly.

You could simply try it out and see what happens. Take off the props, make the PID loop time change to 2ms/2000us (aka 500hz) and see if the motors respond still. If that all works, throw the props on and see what effect it has on behavior in the hover testing. If it's significantly more sluggish in response to wind and stick inputs, then you'll need to up your gains to compensate for the slower pid loop timing. Or it may behave mostly the same, but just slightly less aggressive in response. This would mean you're getting the benefit of the slower motor latency but that your gains don't need to be changed to compensate for the loop time change. That all depends on the PID control logic and if it takes the timebase into account to generate normalized gains internally. I don't know enough about modern FC PID logic to be able to tell you up front what schemes/controllers will need it and what wouldn't.

What do you mean when you say "sampling."

When you said, "make the PID loop time change to 2ms/2000us (aka500hz)," is that the same thing as setting the CLI command to change the looptime to 2000? Stambo and Graham have talked to me about "looptimes" before but I don't fully understand the "hz" talk.

Sampling rate is how often a device will check (and often time convert from analog to digital) an input signal. In this case the reference was to how often the ESC logic is reading the throttle signal from the flight controller. The way it works with oneshot, I don't think it should matter if a slower loop time (and since they are coupled in oneshot, a slower signaling rate to the ESCs) is used. The ESC should still read the incoming signal, perform it's time reading on the value pulse width, and have a usable value to assert to the motors for however long it takes for the next input signal to come.

And yes, changing the loop time to 2000 (microseconds, is what the loop time's units is in the firmware) is the same as 500hz. 2000us is the same as 2ms (milliseconds, 1000 milliseconds per second, 1000 microseconds per millisecond). That is a loop period. The inverse of a period is the frequency, so 1 loop / .002 s = 500hz (loops, aka cycles, per second). If you want to try 250 cycles per second, you would set the loop time to: 1 s / 250 cycles = .004 s = 4ms = 4000us

Love Pauls explanations:)

Graham Lawrie wrote:Love Pauls explanations:)

I love his explanations, too, Graham! I just wish I could understand, and apply, what he was saying, lol.