This article explains what FC looptime is and how faster looptime might affect your quadcopter’s flight performance. We’ll also talk about gyro update frequency and ESC refresh rate which are equally important.
With all the new technology coming out every day in the FPV racing drone world, it can be hard to keep up. “Looptime”, “Gyro update frequency”, “ESC protocols”, and how they affect the FC and ESC, are some of the concepts being discussed regularly within the FPV community.
If you are new to quadcopters, please check out our guide on the basics of flight controllers first.
What is Looptime in flight controllers?
Generally there are 2 things you need to know about that are related to looptime:
- Gyro sampling rate – how often are we reading the Gyro sensor
- FC looptime – how often are we running PID loop using the data from Gyro
You sometimes see people talking about 4K/2K or 8K/8K, the first number is Gyro update rate, while the latter is FC looptime. Obviously, it only makes sense if Gyro sampling rate is the same, or higher than FC looptime.
FC looptime can be represented by either the time it takes a flight controller to complete a PID loop, or how often the PID loop is run, the two things are actually interchangeable. For instance, when PID loop is running at 1KHz (1 thousand times a second), the looptime would be 1ms (1000us).
- 1000us = 1khz
- 500us = 2khz
- 250us = 4khz
- 125us = 8khz
The Different Looptime in Firmware
Today, the four main flight controller firmware for mini quad’s are Betaflight, Cleanflight, Raceflight, and the KISS FC firmware. Each firmware might or might not allow FC to run at different looptimes.
For example KISS FC operates at only 1kHz (1000us looptime), while Betaflight normally runs 8KHz (125us looptime) and Raceflight can even do 32KHz.
Update (Feb 2019): From Betaflight 4.0, it will no longer support 32KHz. There are benefits of running 32KHz, it reduces latency but it also increases noise. In order to reduce noise we’d have to use additional filtering, which introduce latency back (or even more latency than non-32khz). So the devs think 32KHz is not really worth it as it also uses more processing power we could use for something else.
But, PID Looptime Isn’t Everything
The reason we want higher FC looptime is to reduce latency, but there are so many other things that can introduce delay other than just PID loops:
- Gyro Sensor Delay (caused by the built-in low-pass filter and limited sampling rate)
- FC PID Looptime (what we’re discussing in this article)
- ESC Protocol (the time it takes for data to be sent from FC, and read by ESC)
- Motor refresh rate (how often ESC updates motor)
- Motor/Propeller Physical Delay (aka, motor reaction time or, change of RPM)
- Moment of inertia of a quadcopter (which is related to the weight distribution of the quad)
- FPV system latency (caused by latency in FPV cameras, VTX, VRX, FPV Goggles and Displays)
- Radio transmission delay (the time it takes the TX to send commands to the RX)
- Receiver protocol delay (the time it takes the RX to send the command, and interpreted by the FC, for example SBUS is faster than PPM)
In this article we will focus on the first 3 things in this list, which are more closely related to FC looptime and can be improved in the FC software.
Table of Contents
Most F3 flight controllers these days are capable of 8KHz looptime, while some F4 can do 16KHz or even 32KHz. However, apart from processor speed, Gyro sampling rate also plays an important part in determining the maximum looptime in your mini quad.
Gyro Sampling Rate
PID looptime is restricted by Gyro sampling rate, because Gyro must be reading data as fast as, or faster than PID loop.
Gyro sampling rate is affected by 2 things: the type of Gyro sensor and the connection protocols between processor and Gyro sensor.
The popular MPU6000 Gyro with SPI BUS (protocol) can have a sampling rate of up to 8KHz, while the ICM-20602 can do 32KHz.
You should always run your Gyro at the fastest sampling rate whenever possible, because there is almost no downsides to running higher sampling rate (maybe slightly higher CPU load). I.E. for Gyro with i2c protocol, use 4KHz, for SPI protocol use 8KHz.
A Gyro sensor has physical delay when sampling data, but as it’s just a matter of microseconds, it is generally ignored.
What can cause a much more noticeable delay however, is the built-in low pass filter. A low pass filter (LPF) is designed to reduce noise above a certain frequency, which can affect the integrity of the signal. The default Gyro LPF in Cleanflight v1.0 is 42Hz, which equates to a delay of 4.8ms. That’s nearly 5 times as much as the PID loop delay!!
Here is a table that shows how much latency is caused by different Gyro LPF frequency.
So it seems like a no-brainer to use higher Gyro LPF frequency right? Yes, but not without the downside. The Gyro data could be noisier due to insufficient filtering, which could result in a noisier quad that is harder to tune.
While gyro delay doesn’t impact looptime, it does introduce latency to your quad, having a negative impact on its response time to stick inputs.
ESC Protocol determines how fast the ESC signals are sent from the FC.
Here is an introduction to ESC Protocols and firmware.
For example, it takes Standard PWM 2ms to send a signal, which is double the delay of a 1KHz (1000uS) looptime. Updating the ESC protocol you use can show a marked improvement on your quad’s flight performance and responsiveness.
OneShot was introduced to replace the old and slow Standard PWM, and successfully managed to increase the speed by 8 times. OneShot was followed by Multishot which improved the latency further by 10 times (80 times faster than standard PWM)!
More recently DShot was developed and it can be more reliable and faster than Multishot (when using DShot1200).
ESC Protocol “restricts” FC Looptime
There are limitations on what the maximum looptime you can use depending on ESC protocol.
The delay of Oneshot125 protocol is between 250us and 125us depending on throttle. Likewise, Oneshot42 is between 84us and 42us and Multishot is between 25us and 5us.
It makes perfect sense to have your ESC protocol running faster than FC looptime, because you simply can’t send more data than the protocol can handle, otherwise the ESC will get behind in its data and it can be overloaded.
Secondly, Oneshot and Multishots are still analog PWM signals, they are faster because the pulses are shorter. Each pulse has a leading edge and trailing edge as shown in the diagram below, and the ESC can only identify the signal correctly by reading the gap between the trailing and leading edges. If we are feeding data faster than the protocol can handle, there won’t be any gaps in the PWM signal if we give it full throttle (it will just be a straight line), which will cause issues with reading the data.
That is why, for example, Oneshot125 is too slow for 8KHz, because it has a latency of 125uS to 250uS (which is 8KHz to 4KHz), it can only handle 4KHz looptime in theory.
But in practice, you really shouldn’t run anything above 3.8KHz looptime with Oneshot125. This ensures a small gap in the PWM signal to allow the ESC identify the signal correctly, otherwise invalid signals can cause an ESC to shut down and malfunction.
Any protocol that is faster than Oneshot125 is capable of managing 8KHz looptime, such as Oneshot42 and DShot300, while for 32KHz looptime you will want to use Multishot, DShot600 or other faster protocols.
Benefits of Faster Looptime
There are benefits to running faster looptime and gyro sampling rate, but there are also risks that must be considered.
Nyquist Frequency tells us that we can only measure a frequency accurately if it is lower than half of the sampling frequency. That means, for example, by setting looptime at 1KHz, we can accurately measure frequencies below the 500Hz Nyquist Frequency.
The problem stems from vibration at frequencies higher than the Nyquist Frequency (the 500Hz in our example), these will not be ignored due to Aliasing, but show up at lower frequencies in the system. For example if there is an oscillation at 510Hz it could appear as 10Hz, while 1010Hz could also appear as 10Hz. As you can see, this could cause confusion to our flight controller algorithm.
To combat noise above a certain frequency, we employ a digital low pass filter in the Gyro. You need to understand however, that an LPF only reduces noise and doesn’t eliminate it completely, stronger noise can still get bypass the filter due to Aliasing.
Running a higher Gyro sampling rate increases the Nyquist limit, and higher frequencies can be measured more accurately. It also reduces the aliasing at lower frequencies. Not to mention the reduced latency in gyro data can make the copter react faster.
Faster Looptime In Practice – Noise
Most experienced pilots would agree that higher looptime and a faster ESC protocol can make a significant difference to flight performance. Just think about the days back when we were running 1KHz looptime with Oneshot125, compared to the 8KHz and even 32KHz that is now possible with DShot. :)
By making looptime faster, you are now also open to a broader spectrum of noise frequency. This broader noise spectrum can manifest as, what is known as “D-Term” oscillation in blackbox data. D-Term oscillation can make your quad harder to tune as well as causing excessive heat in your motors.
Some quadcopters actually run better at slower looptime because a faster looptime generates so much vibration, it is almost impossible to tune out. Therefore, running faster looptime can require additional filtering, that will eat up any latency advantage. Even then there can be some noise issues that the increased filtering can’t handle.
Gyro running a 32KHz sampling rate can be susceptible to noise, a good example would be flight controllers like the Raceflight Revolt which requires soft-mounting.
Looptime is not everything!
Just remember that setting looptime faster isn’t going to make you a better pilot overnight. Only practice and tuning is going to do that.
I tried KISS flight controller which was running at just 1KHz looptime, and the quad was flying just as “locked in” as my other quads running Betaflight at 8KHz. There are just so much more in the FC software that make the quad fly the way they are, and it’s very much up to personal preference.
Unsynced Motor Update Speed
Not long ago, “unsynced motor update speed” was made possible, to allow motor update be independent of, and faster than PID loop, up to 32KHz.
When motor update rate is faster than looptime, we can expect the same value to be written to the motors multiple times until a new value is calculated by the PID loop. Some argue this is useless work and doesn’t bring any benefit.
There is no exhaustive data to support whether this is of any advantage, however here is one of the reasons I think it can be beneficial.
The analog ESC protocols we use (such as Oneshot and Multishot) can allow noise into the system which negatively affect the accuracy of values sent to the motors. By writing to the motors more often, we might be able to average out the errors, and increase accuracy.
However this won’t be an issue to digital protocols like DShot which is why “motor update rate” is removed from Betaflight when using DShot.
Betaflight Users: What Looptime and Gyro Sampling Rate can I use?
Here is the maximum Gyro Sampling Rate and Looptime you can run in Betaflight depending on your flight controller hardware, and what ESC protocol you are using. We are assuming all FC uses SPI for their Gyro, which has become a standard for modern FC’s due to it’s faster speed.
Note that this table is only to give you an idea, the actual maximum gyro rate and looptime depends on the actual hardware, and what features you have on in betaflight.
|MCU & IMU
|DShot w/ Dynamic Filter
|F1 with MPU6000
|F3 with MPU6000
|F3 with ICM20608
|F4 with MPU6000
|Matek CTR F4 AIO
|F4 with ICM20608
|16K/16K – 32K/32K
|16K/16K – 32K/32K
|16K/16K – 32K/32K
|Kakute F4 AIO V2
To free up resources for higher looptime, you might need to disable some features, such as accelerometer and soft-serial.
After setting your looptime, make sure to check your CPU load (CPU usage). The General consensus is to keep it under 30% to 35% for stable performance.
- Nov 2016 – Article created
- Nov 2017 – Updated