Betaflight feedforward settings: jitter reduction, smoothing, boost, yaw hold and what changed in 2025.12

The PID sliders article on this site covers the Stick Response slider, which scales overall feedforward. This one is about the group of settings underneath it: jitter reduction, smoothness, averaging, boost, max rate limit, transition and the newer yaw hold. Their defaults changed in Betaflight 2025.12, so older advice needs a second look.

What feedforward does

The Configurator help text describes feedforward as an extra drive factor taken purely from stick input, which pushes the quad into fast stick moves. It is proportional to how quickly the stick moves, not to where it is. Hold the stick still at half deflection and feedforward drops away. Move it quickly and feedforward jumps.

The Betaflight documentation draws two conclusions from that:

• Feedforward cannot cause oscillation the way P can, so it is a safe way to get a sharper response. The 4.3 tuning notes say that a good amount (around 120-130) makes the quad very responsive without adding overshoot.
• It amplifies small, quick changes in the RC signal. Sticky or noisy gimbals, a nervous thumb or link problems turn into twitchy flight and jerky HD video.

The Feed Forward 2.0 page lists the signs of too much: overshoot at the start of a flip, especially at full stick travel, exaggerated reactions to RC steps, more visible shaking when you are cold or nervous, spikes in the motor traces and the gyro running ahead of setpoint in Blackbox.

Since 4.3 feedforward also works in Angle and Horizon. The 4.3 notes suggest that beginners who find Angle mode twitchy can simply reduce it.

Default values in 2025.12 and 2026.6

The per-axis gains are in the PID tuning tab (the Feedforward column) or in the CLI as f_roll, f_pitch and f_yaw. The defaults are 120 on roll, 125 on pitch and 120 on yaw. The rest lives in the "Feedforward" group of the same tab, and every one of these settings belongs to the PID profile.

CLI setting	Default (2025.12, 2026.6)	Default (4.3-4.5)	Range	What it does
feedforward_jitter_factor	7	7	0-20	Cuts feedforward when the sticks move slowly
feedforward_smooth_factor	65	25	0-95	Smooths the feedforward signal
feedforward_averaging	2_POINT	OFF	OFF, 2_POINT, 3_POINT, 4_POINT	Averages the last few feedforward steps
feedforward_boost	15	15	0-50	Adds a push based on stick acceleration
feedforward_max_rate_limit	90	90	0-200	Trims feedforward near full stick deflection
feedforward_transition	0	0	0-100	Fades feedforward out around centre stick
feedforward_yaw_hold_gain	15	-	0-100	Sustained feedforward on yaw (since 2025.12)
feedforward_yaw_hold_time	100	-	10-250	Decay time of the yaw hold, in ms

I took the 2025.12 values and ranges from the official CLI reference and checked them against the firmware source for 2025.12 and 2026.6. The 4.3-4.5 column comes from the 4.5.0 source.

To see what your quad has right now, type this in the CLI:

get feed

That lists every setting with "feed" in its name. If you read an older guide, note that these settings were called ff_... before 4.3 and were renamed then.

Jitter reduction

In the Configurator this is "Jitter Reduction". It lowers feedforward when the sticks move slowly, wherever they are. Slow arcs stay smooth, and fast flicks still get full feedforward with no delay. For the "shaky footage, crisp flips" problem this is usually the first setting to try.

The 4.3 notes explain how it works. Betaflight averages the two most recent changes in the RC command and compares them to a threshold. The value sets that threshold in tenths of a percent of stick travel, so 10 means attenuation starts when the stick moves less than 1% per RC step.

How the advice reads in the sources:

• The default of 7 suits most quads.
• The Configurator help suggests 10-12 for cinematic or HD freestyle and 5 for racing on fast links.
• The 4.3 notes went as far as 12-15 for freestyle and cinematic, but that was written for slower links. The pull request that reworked this code for 2025.12 says values much above 10 only make sense for links of 150 Hz or less.

That same change altered how low values behave. Earlier versions forced feedforward to zero whenever the sticks stopped for two packets. Now it never drops to exactly zero, and a low setting leaves a floor: with 1, 2 or 3, feedforward cannot fall below 50%, 33% or 25%. At 7 it is cut to about one eighth during slow stick moves. Racers get a quad that keeps reacting to very small inputs, at the price of more twitchiness.

Smoothing and averaging changed in 2025.12

This is where old recipes go wrong.

Up to 4.5, the default smoothing was 25 with averaging off, and you were expected to raise both for faster links. The 4.3 notes give 25 as the starting point, 40-50 with 2_POINT averaging for 250 Hz, and 65-70 with 2_POINT as a requirement for 500 Hz. The smoothing help text in the Configurator still reads like that (25 for 50-150 Hz, 40-50 for 250 Hz, 60-65 for 500 Hz).

In 2025.12 the defaults moved to 65 and 2_POINT. The code change behind it fixed the fact that feedforward_smooth_factor used to depend on the receiver packet rate, which meant the real filter changed with the link. The smoothing is now scaled to a fixed 250 Hz reference, which a comment in the code calls the most common ExpressLRS rate. In practice that means the same number now does roughly the same thing on any link, so do not copy a per-link value from a 4.3 or 4.5 guide into 2025.12. Start from the default.

The same change merged the separate feedforward cutoff into the setpoint cutoff. The 2025.12 CLI has only rc_smoothing_setpoint_cutoff and rc_smoothing_throttle_cutoff, so old snippets containing rc_smoothing_feedforward_cutoff will fail.

Averaging, per the Configurator help, takes the mean of the last 2 or 3 steps. It smooths the feedforward trace at the cost of some delay and works best against up and down jitter that faster links tend to produce. The help also mentions that original Crossfire in 150 Hz mode, before CRSFShot, needed 3_POINT.

Boost, max rate limit and transition

Boost ("Boost" in the Configurator) adds push in response to stick acceleration and deceleration. The help text says it reduces gyro lag caused by motors that need time to spin up, and it reduces overshoot when the sticks slow down by pulling back hard on the motors. The default works for most quads. Racers may raise it a little, and further tuning needs Blackbox logs. The 500 Hz racing RC link preset for 2025.12 sets it to 18.

Max Rate Limit cuts feedforward as the stick nears full deflection, to limit overshoot at the start of a flip or roll. It does nothing at the end of the move. Lower values start the cut earlier. The help says the highest value that still gives acceptable overshoot is best and that it usually needs no change. The 4.3 notes add that underpowered quads may need 100.

Transition fades feedforward linearly towards centre stick. A value of 30 in the CLI (shown as 0.3 in the help text) removes feedforward at dead centre and restores it fully beyond 30% stick travel. In 4.2 and earlier this was the way to soften the centre. Since 4.3 jitter reduction does the job better, and the help text says transition should be zero when jitter reduction is active. The 4.3 notes explain why: transition does nothing for smooth off-centre turns, a narrow range cuts feedforward abruptly and can cause wobble, and a wide range loses snap. Leave it at 0.

Yaw hold

Since 2025.12, yaw no longer uses boost. In its place is a high-pass filtered setpoint element that rises fast and decays slowly. The pull request by ctzsnooze explains why. On yaw the drive has to last after the stick stops moving, because the quad has to be kept turning, and normally I-term built that up. When you snap the stick back to centre after a long yaw spin, that accumulated I-term causes bounce-back.

feedforward_yaw_hold_gain sets the strength. The firmware comment calls 15-20 fine for a 5". Zero disables it. feedforward_yaw_hold_time is the decay time constant in ms. 100 suits a typical 5", shorter values let it fade faster, and longer values, according to ctzsnooze's earlier pull request #13575, suit quads with weak yaw authority. With yaw hold set well, the author says yaw I-term can usually be cut by about half.

The suggested test is full-stick flat yaw spins in a hover: stick out fast, hold for a full 360, stick back fast. In the log, check for overshoot or bounce-back at the end and compare gyro, setpoint and the PID terms on yaw.

Start with the RC link preset

Feedforward depends on how clean and how frequent the RC data is, so Betaflight handles it through RC link presets. The ExpressLRS packet rate article on this site describes loading one from the Presets tab. Here is what they set:

• 2025.12 has a separate preset for each ELRS rate. The 250 Hz preset sets 2_POINT and jitter 6, the 500 Hz one sets 2_POINT and jitter 5. On top of that you pick a flight style. For example, at 500 Hz racing uses jitter 3, boost 18 and RC smoothing 25, HD freestyle uses jitter 9 and smoothing 70, and cinematic uses jitter 11 and smoothing 90.
• 2026.6 has a single preset, "CRSF - ExpressLRS, Crossfire or Tracer", in which RC smoothing follows the detected packet rate. Its description says 2026.6 handles the link rate itself and rate-specific feedforward overrides are generally unnecessary. The flight style option now only changes rc_smoothing_auto_factor: 25 for racing, 50 for freestyle, 70 for HD freestyle, 90 for cinematic and 180 for ultra cinematic. There is a separate preset for a link locked to 50 Hz (averaging off, jitter 12, boost 5).

All of these presets carry the same warning: turn off the hardware ADC filter in EdgeTX or OpenTX.

When the footage wobbles: a short diagnosis

For random wobbles that do not look like PID oscillation, the 4.3 notes give a list of things to check. The feedforward and RC parts of it, in a sensible order:

1. Make sure the hardware ADC filter in EdgeTX or OpenTX is off and load the right RC link preset for your firmware version and link. Save your diff first, as described in the backup article on this site.
2. Raise jitter reduction to 10-12.
3. Do one test flight with feedforward at zero (the Feedforward column in the PID tuning tab, or f_roll, f_pitch, f_yaw set to 0 in the CLI). If nothing changes, feedforward is not the problem and you can go back to normal values.
4. With old gimbals or a shaky thumb, high RC smoothing helps. The notes mention an auto factor of 90 or more, which matches the cinematic presets.
5. To check whether the RC link itself is to blame, the notes suggest temporarily setting a wide deadband. With the sticks centred it removes all random noise from the link. If that changes nothing, the link is not the cause.

The same list reminds you that wobbles also come from a flexible frame, a loose part, a small capacitor or a poorly mounted camera, so do not look only in the settings.

set feedforward_jitter_factor = 11
save

This is only an example of a single change. Change one setting at a time and fly the same line after each one.

Checking it in Blackbox

The Blackbox article on this site explains the setup. For feedforward, compare the setpoint and gyro traces and look at the feedforward line itself. It should be smooth, and spikes on slow stick movement point to the RC link or the gimbals. To look closer, use debug_mode = FEEDFORWARD. According to the pull request, it records, among other things, the raw setpoint, the RC command change per packet, the jitter attenuation and whether a packet was a duplicate.

That last channel matters for links that repeat packets. Since 2025.12 Betaflight no longer extrapolates feedforward on duplicate packets for CRSF links (ELRS and Crossfire), which reduces noise during slow stick moves. FrSky and other protocols keep the extrapolation, because they send duplicate values randomly and feedforward would otherwise fall to zero and then double.