New wind estimator in INAV 10 is too sensitive

[error414]

I noticed that new wind estimator from #11614 is too sensitive and mark wind data as invalid (astersik near wind OSD element). I happened to two planes.

My setup:
Inav version: Maintanence-10.x
Plane 1: Heewing T2, real pitot tube
Plane 2: Heewing T1, virtual pitot tube

video from T2: https://www.youtube.com/watch?v=ClvGF0pV3Sw
BB log:

LOG00002.TXT

If you would like I can provide logs and video from T1 as well

[breadoven]

It may well need fine tuning but it could also be indicating that the wind has changed and the estimate become unreliable. The previous wind estimate could be flagged as reliable even though it was in fact completely inaccurate. I'll have a look at the log and see if that shows anything useful that might help to improve things.

[error414]

Be honest I have no idea how wind estimator works at all. But what I testes in xplane11 (8m/s wind, 4m/s guts), I noticed that plenty of calculation was rejected due to restirction to 3ms or 6ms (depend on state).

If you would like I can make new test with debug_mode = WIND_ESTIMATOR. What values would you like there?

• validityScore
• hasValidWindEstimate
• spikeFilterDynAdjustment
• lastValidEstimateAltitude

is it ok?

[error414]

I added extra info to BB debug. see https://github.com/error414/inav/commits/error414/multitest/multitest-auto-speed/

LOG00003.TXT

DEBUG_WIND_ESTIMATOR debug channels (src/main/flight/wind_estimator.c)

Index	Value	Unit	Updated	Meaning
0	estimatedWind[X]	cm/s	Every cycle	Filtered wind estimate, North axis (earth frame)
1	estimatedWind[Y]	cm/s	Every cycle	Filtered wind estimate, East axis (earth frame)
2	estimatedWind[Z]	cm/s	Every cycle	Filtered wind estimate, vertical axis (earth frame)
3	V (raw airspeed)	cm/s	Only on new estimate calc	Last raw airspeed estimate from the ground-velocity / attitude-change equations (eq. 6), before spike filtering
4	validityScore	count (0–30)	Every cycle	Estimate validity score; increments on each new estimate, decrements on 10 s timeout. Estimate becomes valid above 15 (WINDESTIMATOR_VALIDITY_THRESHOLD), invalid at 0
5	spikeFilterDynAdjustment	count (0–40)	Every cycle	Dynamic spike-filter relaxation. Spike threshold is 300 + value × 40 cm/s, so 0 = baseline 3 m/s threshold, 40 = fully relaxed (19 m/s) to un-stick the estimate
6	State bitmask	flags	Every cycle	Bit 0 (1) = hasValidWindEstimate, bit 1 (2) = initialEstimate (still building the first estimate). So: 0 = invalid, 1 = valid, 2 = invalid + initial phase, 3 = valid + initial phase
7	spikeFilterRejections	count (cumulative)	Only when a sample is rejected	Running total of new wind samples discarded because one axis exceeded the spike threshold

Notes

• Indices 0–2 and 4–6 are written unconditionally at the top of updateWindEstimator(), so they are fresh every cycle — even when GPS heading/velocity is invalid and the function returns early.
• Index 3 only changes when a new estimate is actually computed (attitude change large enough, diffLengthSq > 0.04). A frozen value means no new wind calcs are happening — cross-check with index 4 draining and index 5 rising.
• Index 7 is never reset, so watch its rate of change rather than its absolute value. A fast-climbing count together with a high index 5 indicates the estimate is stuck and the spike filter is relaxing to recover.

[breadoven]

Looking at LOG00003.TXT I can see the issue is the one I noticed when testing myself. When spikeFilterDynAdjustment is active it decrements validityScore by 2 to degrade validityScore more quickly because spikeFilterDynAdjustment being active indicates the estimate has lost accuracy. The issue is that even if the raw estimate makes it past the spike filter validityScore still ends up being decremented by 1. Maybe this is too pessimistic.

Simple solution is to decrement validityScore by 1 rather than 2 so that it doesn't decrement at all if the raw estimate passes the spike filter. This would stop the estimate becoming untrusted in the log above during transient periods of excessive spikes. The best solution would be to fix the spike issue but I'm assuming this is just how this wind estimator model works. The other possibility is to only flag the estimate as invalid after a timeout period with a validityScore of 0, maybe 30s or so.