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.
Here is an introduction to all the major mini quad flight control firmware.
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.
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.
Learn about the differences between F1, F3, F4 and F7 processors in flight controllers.
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||Multishot||DShot||DShot w/ Dynamic Filter||Example FC|
|F1 with MPU6000||2K/2K||n/a||n/a||Naze32|
|F3 with MPU6000||8K/8K||8K/8K||4K/4K||Omnibus F3|
|F3 with ICM20608||8K/8K||8K/8K||4K/4K||DTFc F3|
|F4 with MPU6000||8K/8K||8K/8K||8K/8K||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
Hi oscar plz hellp me
I was using a same set up for motor;
Motor brotherhobby r6 2700
Fc , esc tower hobbywing g3 esc 60 a
And high throttle was flying maximum for 5 minutes.
Now I build a same motor with exact set up and frame but this time is battery is at highest consumption.
The battery Full lipo is at 16:8 V
When I hit maximum trottlle (High voltage amperage) for 4 sec, battery hit the lowest voltage while alarm is beeping,
But would turn to maximum when there is no speed.
@Jim: 510 Hz signal sampled at 500 Hz will really appear as 10 Hz while 510 Hz signal sampled at 1000 Hz will appear as 490 Hz.
Hi! Thanks so much for this great article.
Quick question: I am running CLRacingF4 flight controller. I am on 4khz/4khz, just enabled RPM filtering. My stable CPU is ~30-38%, but maxload is over 100% sometimes (when I type tasks in CLI). Is that an issue? Shall I go to 2/2 or that’s too low?
Thanks a lot!
hi oscar, i’m new to the 32k scene having just purchased a HW Xrotor F4 G2 flight stack “capable of 32k/32k.” i run minimal settings on my quad: no accel, baro, mag, etc. no blackbox. i’m on BetaF 3.5.2 with dynamic filter enabled, gyro 1 & 2 plus dterm notches are all disabled. dshot1200 protocol, motor idle 5%. when i set gyro/PID loops to 32k/32k CPU is 100%. 32k/16k is 51%. 16k/16k is 38%. 16k/8k is 12%. i haven’t flown it yet (i’m just programming while waiting for a specific frame), but is 38% CPU on 16k/16k still too high to reliably fly?
38% is fine.
Hey Oscar, I have an F3 FC, DJI E300 ESCs, which I think are vanilla PWM.
What would you recommend for “Gyro update frequency” and “PID loop frequency” in Betaflight please?
I’ve read your article, but am struggling to map things to what I’m seeing in the Betaflight Configurator.
Find out the frequency of the “Vanilla PWM” you are using, and make sure your looptime is no higher than it.
I am running kakute f4 FC, speedix gs30a escs @ Dshot600. currently at 8khz/8khz but ig i try to enable 32khz sample rate, quad does not arm. is it my understanding that betaflight (v3.2.0) is not capable of this yet or is it the dshot600 limitation?
Thanks for the post Oscar!
I’m using 4/4k with Dshot 300 in my furibee fuuton (F3). Accelerometer on gives me 32% of CPU load. I do fly only acro but still do horizon to land… noob I know… :)
Increasing to Dshot 600, my cpu load goes to 38%.
Is this value acceptable? The increase of DSHOT in this case will be noticeable?
Thanks and sorry about my poor english!! :(
I personally would try to keep CPU load <30%
In your case... running 4k/2k would be the way to go.
Yeah I have a question, I have the Flycolor Raptor w/ F390 Tower 30A 4 in 1 ESC
ESC: BLHeli firmware, support Oneshot125/42,Multishot,Damped Light
I Tried setting it to 4K/4K and multishot and it would not arm or even ONESHOT42 and it still would not arm. The only way I can get it to arm is by putting it on ONESHOT125.
CPU LOAD was only at 29%
Do you know what that would happen? I tried asking the Amazon seller but they did not answer me.
i would recommend updating the ESC firmware first
The ICM20602 can sample only up to 8khz on the gyro; not 32k!
yes it can. that’s how raceflight run it’s looptime at 32Khz.
Would you please show me where in the ICM-20602 datasheet that shows the device can sample at 32khz. FYI the resonant frequency of the tuning fork in the device is only +-27khz; see the datasheet. The maximum sample rate is 8khz.
Perhaps you are misspeaking and must be referring to how fast the RaceFlight code is running its processing loop; at 32khz.
search for the keyword sample rate in the datasheet.
i have switched to beta flight on an 250 size quad..with naze32 and older 16amp opto RW.RC blheli esc..the quad arms but once i take off it goes out of control totally.. i know i has something to do with the both loop times i just dont want to mess around for ever to figure it out..so what is the origanal loop time on cleanflight to match beta flight..cleanflight worked fine..i am not haveing so much luck with beta flight being a easy switch..even my newly built 180 tyrant with new escs and things needed work to get flying again..
“If there is a signal of 510Hz it could appear as 10Hz, while 1010Hz could also appear as 10Hz.”
All 510 hz signal sampled at 50hz will alias to 490 hz.
hello ! I am making a quadrotor at stm32 microcontroller and using the traditional ESC running at 50 Hz. I am using the PID to control the copter but I don’t know at what frequency should i run the PID loop. Please guide me.
Hi, i have a questionar related to the how beneficial is running higher refresh rate on motors than kids? You mentioned inaccuracy because of noise, but this happens in analog signal, but with dshot, there isn’t any benefit at all? Since digital signals are precise and almost lossless? An example, running kiss at 1khz as it runs, andd running dshot600 which is around 37khz, so multiple unnecessary written signals to the motors? Is this theory right?
Betaflight now breaks looptime down into gyro looptime and pid looptime, so which is this article talking about? It’s my understanding that you want to run gyro as fast as the FC/gyro can handle.
yes you are right, betaflight has advanced since this article was written. “Looptime” in this article was referred to PID looptime.
Hi guys, based on what was said and Betaflight’s documentation. So on ESCs with Oneshot125 I run PID Loop Freq at 4kHz. Now I have an X-racer SPI which supposedly runs up to 8kHz, so if I change Gyro Update Freq to 8kHz it automatically changes PID Loop Freq to 8kHz as well. Is that an inherent dummy code that tells users if you are running 8k on gyro update you should also run 8k on pid loop ?
The PID loop is what processes the gyro data, so there is no point in running the PID loop at a different speed than the gyro update rate. For example, If you have the gyro update rate at 8k, and the PID loop at 4K, only every other gyro read will be processed by the PID controller. Same thing the other way around, if you have your PID loop running at 8k and your gyro update rate at 4k, the PID loop will run twice with the same data. The whole point of these faster refresh rates, is to have the freshest data possible, for the PID loop to process, and the more times you update your data in a given period of time, the more precise and less drastic the FC can be in its corrections, IE smoother flight.
I’m running some afro 12amp escs with the naze32. Hobbykings website says the afros run at 1khz so what would be the best looptime to run on the naze. I have flashed the escs with blheli (originally simonk).
After flashing your ESC’s with the BLHeli firmware, use the BLHeli suite to configure your ESC’s to ensure Oneshot125 is on. As the author of the article mentioned the Loop time for the ESC using Oneshot125 is between 250us or 4Khz and 125us or 8Khz. The author also recommend not running your FCU any faster than 250us or 4Khz, as this gives the ESC’s the best opportunity to identify the signal properly.
In short run your ESC’s with Oneshot125 enabled, and run your FCU(Naze32) 4Khz or 250us.
Hope it helps.
with their original firmware (old simonK), i think Looptime 2000 should do a pretty good job :)
Just checking to see if I got this article right…
I’m using littlebee’s 30a ESC’s which uses the SiLabs 390 48 MHz processor + SPRacing F3 FC on a HMB-230 frame (which is considered to be very rigid).
Please correct if I’m wrong but with RaceFlight and BLheli can I run multishot over this setup?
Pretty sure you need a modified version of blheli that supports multishot. But yea, those components are good to go
Yes the LB30A supports multishot and 8Khz looptime.
And how about LB30A running multishot but with F1 board – Naze rev6 (ACC disabled). I have at the moment 2,6K looptime, which is what Boris said is safe margin for F1 with ACC disabled and I have no clue what motor_PWM_rate I should set it to? Have it same as looptime or go with unsynced rate at 32K? Or is there even any sense to run multishot when my PID loop time is just 375us and article stays that multishot is for looptimes 25us and lower.
I would love to see you do a writeup on dRonin and test it out. :) Thinking about testing it out. The autotuning stuff sounds really nice and a lot of people have been talking warmly about it lately.
Maybe you can help ?
I have blHeli SN20A oneshot (they said oneshot 123 ? ) And Naze clone, which is Flip32. If I don’t want my cf to be “faster” than my ESCs, I have to set looptime around 125us to 250us in cleanflight ?
You mean oneshot125? LOL I think for your setup, setting looptime to 2Khz is probably the highest you can go with your setup…
On Raceflight my looptime is at 125 which is 8KHz and my Motor PWM Rate is at 16KHz… The gyro is not synced with the ESCs.
“Therefore, with lower looptime your quad can also be “noisier”, and the flight controller isn’t always reading the best data as the noise can interfere with the values going through the PID control loop. ”
That actually depends on the implementation of the filter. If the filter is very simple and only processes a fixed number of values, it’s true – but that would also be a crappy filter design. If the filter works on an actual frequency level, the opposite holds. In this case, higher loop times will allow you to correctly sample and then filter noise of higher frequencies. This improves your sensor data quality and makes the FC less sensitive to noise.
In my experience with betaflight on a noisy mini-quad, higher loop-times lead to cleaner logs and higher stability in flight. This leads me to believe that betaflight uses frequency-based filters in the right places. I may be wrong about betaflight, but maybe you could explain both possibilities (good filter/crappy filter) in the post. Just in case.
I may be mistaken as I haven’t kept up with the newer versions of Betaflight since I’ve been flying KISS. However, my understanding was that the LPF is turned off in Betaflight as soon as you go above 1khz because the filter can’t handle anything faster.
Very interesting point you bring out using your black box logs though.
“Therefore, with higher looptime your quad can also be “noisier”, ”
are you sure? maybe “lower looptime” (and higher refresh rate)?
Sorry, yes you are right i think the article meant to say lower looptime :) thanks for pointing that out.
You’re right, I mixed it up all over my comment.
Lower loop time -> higher acquisition frequency, less aliasing, higher quality sensor data. In case of betaflight: Lower loop time -> cleaner logs and better flight behaviour.
typo at “1khz (150us looptime)” should be 1000us otherwise you compare 150 to 150