Looptime and Flight Controller

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.

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.

FC Looptime

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.

Gyro Delay

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.

Gyro LPF Delay
256Hz 0.98ms
188Hz 1.98ms
98Hz 2.8ms
42Hz 4.8ms
20Hz 8.3ms
10Hz 13.4ms
5Hz 18.6ms

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

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.

Processor/Gyro Bus Oneshot125 Oneshot42 Multishot DShot(150,300,600) Example FC
F1 with I2C 2K/2K 2K/2K 2K/2K 2K/2K Naze32
F1 with SPI 4K/2K 4K/2K 4K/2K 4K/2K CC3D
F3/F4 with I2C 4K/2K 4K/4K 4K/4K 4K/(2K)(4K) XRacer V2
F3/F4/F7 with SPI 8K/2K 8K/4K 8K/8K 8K/(2K)(4K)(8K) Betaflight F3

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 concensus is to keep it under 30% to 35% for stable performance.

Edit History

  • Nov 2016 – Article created
  • Nov 2017 – Updated

31 thoughts on “Looptime and Flight Controller

  1. egvneto

    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!! :(

  2. Joshua

    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.

  3. seth gunter

    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..

  4. Jim

    “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.

  5. Bhargav

    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.

  6. xhitm3n

    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?

  7. moosestang

    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.

    1. Oscar Post author

      yes you are right, betaflight has advanced since this article was written. “Looptime” in this article was referred to PID looptime.

      1. Yao Wei

        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 ?

    2. John Holmes

      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.

  8. Luke Q

    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).

    1. Anthony Aery

      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.

    2. Oscar Post author

      with their original firmware (old simonK), i think Looptime 2000 should do a pretty good job :)

  9. Adam

    Hi all
    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?

    1. Reuben Horner

      Pretty sure you need a modified version of blheli that supports multishot. But yea, those components are good to go

      1. kubais

        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.

  10. Pie

    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.

  11. Jocelyn Da Prato

    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 ?

    THx :)

    1. Oscar Post author

      You mean oneshot125? LOL I think for your setup, setting looptime to 2Khz is probably the highest you can go with your setup…

  12. Some Dude

    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.

  13. Benjamin

    “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.

    1. Adriel Perkins

      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.

  14. Alex

    “Therefore, with higher looptime your quad can also be “noisier”, ”
    are you sure? maybe “lower looptime” (and higher refresh rate)?

    1. Oscar Post author

      Sorry, yes you are right i think the article meant to say lower looptime :) thanks for pointing that out.

    2. Benjamin

      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.


Leave a Reply


Are you Robot? *
