#2841 VSI instrument: excessive FPM at init and oscillation on ground

[Benedikt Hallinger]

(A) When on the ground, the VSI needle oscillates slightly when around 0.
(B) At sim start, the instrument shows excessive deflection.

Reason is the C++ instrument code (which mentions this in the comments 😄 )

For the C172p we fixed this aircraft side, but since I consider that a workaround as this should really be fixed in the c+ instrument some time (so all other aircraft benefit too).

[James Turner]

Yes, this should be handled by trim phase, BUT it's likely also due to the atmosphere pressure setting (same as the altimeter movement on init)

Less sure about issue A), surely the VSI doesn't know anything about the ground? Isn't that more tuning the damping / filtering for a particular VSI (laggy vs twitchy)

[Benedikt Hallinger]

Re (A):
Yes, the "on the ground" is just a state where vertical FPM==0. That causes osciallation I the c++ filter (or so). In flight, the value is nearly never exactly 0, and these small oscillations are overlayed by actual flight fluctuations, so not noticeable (and in flight all is OK).

Re (B):
Yes, probably the instrument should be initialized so the FPM starts at 0. Maybe the weather engine causes this to change alot, problaby the instruments internal pressure value is initialized to a default value, which then rapidly changes when the weather engine kicks in and changes the pressure to the setting of the selected weather preset/conditions. that change in pressure is then "seen" by the VSI as change in pressure=>vertical movement, which it displays.
That even may be "correct" behaviour from a physics perspective, but not as viewed from a "sim user".
Also other instruments suffer from this, afaik, so for strtup it may be a broader issue, so that instruments are initialized after weather was initialized (which may be challenging for "live weather").

[James Turner]

Right B) there is a wider bug about fixing this but the timing becomes very complex. It's much noticeable on the ASI. Also different users seem to have very different tolerances on howm much it irritates them, which has caused some strong feelings about where the bug should be fixed.

[James Turner]

Just reviewing the VSI code: there is a reference to a numerical instability around the 0 crossing, and a term to counteract this. (See line 118 of vertical_speed_indicator.cxx). I'm wondering if should set the outputs to zero directly in this case, can you try that locally and see?

For B, we have the fact the outside pressure is 'slowly' interpolating from ISA standard to the real value from the weather engine, which shows up at vertical movement. That should be fixed in the weather code for sure.

[Benedikt Hallinger]

Tried this at line 118:

if( fabs(_casing_pressure_Pa - pressure_Pa) < 0.01 ) {
            orifice_mach = 0.0;   
            _speed_fpm_node
                ->setDoubleValue(0.0);
            _speed_kts_node
                ->setDoubleValue(0.0);
            _speed_mps_node
                ->setDoubleValue(0.0);
            _casing_density_kgpm3 = new_density_kgpm3;
            return;
        } else { 

Did not help.

[James Turner]

Okay, that's 'good' because it proves the pressure delta on the ground must be > 0.01 ... ie there really is some pressure.

We have the issue that Eric vdB built the lag into the model of the anenoid chamber, so we can't just add a low-pass filter on top or it will be too laggy when airborne. Hmmmm.

Ideally we would pull the sensitivity / damping term out of the coefficientd and make it a paramter, so we could tune it, but I'm not sure that is possible with the code as written.