Trying to simulate instrument errors in a VSI

[frumpy]

Hey there,
I am just thinking about instrument errors.
From what I understand how a VSI works, the needle displays the differential pressure between the saved pressure in the capsule and the actual static pressure. The higher the difference, the higher the deflection of the needle.
Now we know that air pressure sinks exponentialy with increase of altitude.
If there is no compensation of some kind, a vertical speed of say 1000 ft/min at 1000' leads to a stronger deflection than the same vertical speed at 30.000' due to less pressure difference. That leads me to two questions:

1.) Are standard VSIs (simple general aviation) in any way compensated (and how?)?
2.) If there is no compensation, to what altitude are they calibrated?

Thanks, Olli

[JackZ]

Hi.
What you described is the principle for an altimeter. The aneroid capsule is sealed and submitted to the ambient static pressure taken from the static port. Less ambient pressure outside the capsule, inflates the capsule and moves the needle through a set of reduction gear.

A VSI in its principle is different.
« Modern » VSI are compensated to take into account the lag between the change of pressure and the resulting needle movement. IIRC there is a small calibrated hole in the back of the instrument that let ambient (static) pressure inside the aneroid capsule to enter then bleed slowly and evenly to eventually be equal to the ambient pressure. This feature introduces a small delay, coupled with springs and counterweights, that will « compensate » the needle movement. There is no compensation related to altitude
https://www.pilotmall.com/blogs/news/ai ... es-it-work

[frumpy]

Yes, I know I omitted the calibrated leak hole for simplicity. I believe for the effect described, it does not matter.

There is no compensation related to altitude

Now thats interesting! When looking at a pressure vs. altitude chart, the pressure difference for a certain altitude change at sealevel is less than half the pressure difference at 25000ft for the same altitude change. That means when trying to descent lets say 1000ft/min at that high altitude, I need to get an indication of 2000ft/min or more. Thats a significant number. I have never heard of that before. I mean that must have been a topic in aviators training before IVSIs or indications based on the INS etc. came up? Or something like "VSI is reliable between altitudes GND to 5000 in standard atmosphere"?

edit: The calibration hole may have something to do with the compensation. With less dense air, fewer molecules need to pass the hole.
To calculate the flow/mass it goes quite deep into physics, so I am thinking of an easier mental model... or approximation.

[JackZ]

I “think” you are probably overthinking this.
In the standard atmosphere model the pressure decreases “almost” linearly with altitude since density is derived from temperature that changes linearly with altitude. The real formula is here:

http://fisicaatmo.at.fcen.uba.ar/practicas/ISAweb.pdf

Integrating the above and assuming P0 is the pressure at height z = 0 (pressure at sea level) the pressure at height z can be written as:
P=P0 exp(−zH)

Even though exponential one can see that the progression is “quasi” linear until 20000ft and between 20000 and 36000ft (11 km) where the standard tropopause stops.

https://en.wikipedia.org/wiki/Vertical_ ... _variation

Moreover IIRC a VSI uses pressure altitude instead of density altitude. The standard pressure lapse rate is 1 millibar per 30 feet in the lower atmosphere.
I guess that a typical VSI is calibrated on this lapse rate, meaning it’s more precise at low altitude where precise rates of climb are more important.

On liners, since the Air Data computer has also access to the Outside air temperature, I guess it is capable of real time computation of the pressure altitude at a given height and temperature

[JackZ]

The calibration hole is mainly here to introduce a certain lag in the indication so it’s more realistic, instead of showing an instant rate of climb/descent where the needle literally jumps to the max ROC/ROD. A slight delay if a couple of seconds is introduced.

[frumpy]

Thanks for your response. I have to think about it. It's a bit of a chaos in my head which I try to sort.

I am asking this, because I would like to calculate the instrument errors for the VSI. 15 years ago I was in PPL training and did steep turns at night. My instrument scan was focused on the VSI, this is what I learned in the flightsim. Just watch the VSI and I am fine. Well, not in real life! I quickly lost 200-300ft in the turn. This is where my motivation comes from. X-Plane and most other sims do not take the instrument error into account. ELITE flightsim from the 90ies did!

So I am trying to estimate the inner workings of the VSI, mainly the processes with the calibration hole and friction. I calculated the static air pressure in XP11 (in XP12 its already a dataref) at an altitude and when starting on the ground it's the same air pressure in the diaphragm. Every movement from that 0-position is either a climb or descent. The diaphragm contains the "old" static air pressure and the housing of the VSI the static pressure (or vice versa, for the calculation it does not matter).

Now when we are climbing, the static pressure in the housing sinks, the diaphragm expands. Air slowly starts moving through the calibration hole, but the diaphragm does not move yet. First it needs to overcome inner friction, so there needs to be a certain pressure difference to start the needle movement. Once the needle moves, pressure can be subtracted from the diaphragm. The speed at which this happens is dependend of the pressure difference. I think for this to take place in a realistic and smooth movement, I can take the vertical-speed-dataref from X-Plane directly and cut it at a certain maximum climb or descent rate (thats the limited flow of the calibration hole).

Technically I am thinking about these two containers of pressure and how they interact. How to get the equilibrium of these two in a changing environment (true vertical speed is changing as I fly). Pressure can be seen as energy potential energy and the inflow/outflow of molecules as kinetic energy. It's a closed system, so energy can be converted back and forth. Taking the formulas of potential energy E=m*g*h and kinetic energy E=1/2m*v^2 and setting m=1, I'll get v=sqrt(2*F*h). F is the difference the calculated pointer and the VSI-dataref from X-Plane (thus, the closer it gets to the target, the slower it gets), h the actual pressure difference between both containers (after overcoming friction) and v the speed (with a maximum) at which the diaphragm changes inner pressure to meet the pressure in the housing. There is no friction once the containers are in equilibrium, friction only comes into account after the direction of movement changes.
But I have to try that out, not sure if my thinking is reasonable enough or correct. This should give delayed smooth needle movements with a sudden onset due to friction.
Of course I could try to fill arrays with past vertical speeds and display them, but then I depend on fps and it's only half the fun. For now, I need to get deeper into LUA. I still don't know when and how to use functions and how to pass variables back and forth. I'll post it if I have any progress.

Olli

[frumpy]

So here is some code which may work. Doesn't look like much, but after a lot of failing and frustration this seems to calculate reasonable numbers. I used ChatGPT to do that, as all the models I made up did not work. I should have paid more attention to my maths teacher

What it does, is that it uses a table. Next step for me is to understand the code and how I can incorporate the table into AM.
The variable verticalSpeed_speeds should be filled with the VS from XP, output delayed_vs_speeds can be used to move the pointer. Still a way to go, but progressing.

Code: Select all

local GLOBAL_DELAY = 3     -- Adjust this value as required
local INERTIA = 0.3        -- Factor between 0 and 1. The closer to 1, the higher the inertia.

-- Function to calculate the delay for delayed_vs's movement based on the force
local function calculateDelay(force)
    return GLOBAL_DELAY - math.min(GLOBAL_DELAY - 1, math.abs(force))  -- Adjusts delay based on force and GLOBAL_DELAY
end

-- Main
local verticalSpeed_speeds = {0, 100, 200, 300, 300, 300, 400, 500, 500, 500, 500, 500, 500, 600, 500, 500, 500, 400, 300, 200, 200, 100, 0, 0, 0, -100, -200, -300, -300, -300, -300, -300, -300, -300, -300, -300, -300}

local delayed_vs_speeds = {}
local delayed_vs_position = 0  -- This will represent the "distance" delayed_vs has been pulled due to inertia
local previous_verticalSpeed_speed = verticalSpeed_speeds[1] -- Initialize with the first speed

for i=1, #verticalSpeed_speeds do
    local desired_position = verticalSpeed_speeds[i]
    local acceleration = desired_position - previous_verticalSpeed_speed
    local force = desired_position - delayed_vs_position
    
    -- Calculate delay based on the acceleration compared to Boat B's speed
    local delay_factor = math.abs(acceleration - delayed_vs_position)
    local delay = calculateDelay(delay_factor)
    
    -- delayed VS responds with inertia after the delay
    local position_change = (desired_position - delayed_vs_position) * (1 - INERTIA) * delay / 4  -- divided by 4 to smoothen out the overshooting effect
    delayed_vs_position = delayed_vs_position + position_change -- new VS
    
        
    table.insert(delayed_vs_speeds, delayed_vs_position)
    
    print("VS: " .. math.floor(verticalSpeed_speeds[i]) .. "         VS delayed: " .. math.floor(delayed_vs_speeds[i]))
 
    -- Update the previous speed for the next iteration
    previous_verticalSpeed_speed = desired_position
end

--xpl_dataref_subscribe("sim/cockpit2/gauges/indicators/vvi_fpm_pilot", "FLOAT", vsi) -- VSI indication 
--xpl_dataref_subscribe("sim/cockpit2/gauges/indicators/altitude_ft_pilot","FLOAT", drc_altitude_ft_pilot) -- altitude

[frumpy]

I've been messing around with Excel, trying to find a formula which will fit. No luck so far, but it's giving an idea where to look. Just knowing the pressure in the instrument, the diaphragm and actual vertical speed does not help. I need an array of past vertical speeds too to calculate the flow through the calibration hole. After all, the speed of the flow is more like a curve which needs to be calculated. If it's linear, it will basically just drag the pointer a few seconds behind. So lets get into tables.

Right now I had most success utilizing ChatGPT. I copied the article of xpl_dataref_subscribe into ChatGPT and asked for a summary. This way ChatGPT will know the AM syntax, at least for the ongoing session (and forget it afterwards, hm!). Then I asked it to fill a table with the last 60 values of the vertical speed and discard the values after. Pretty handy!

Code: Select all

-- Define a table to store the last 60 values (1s at 60 fps)
local vviValues = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}

-- Function to handle the dataref subscription callback
function vviCallback(value)
    -- Add the new value to the beginning of the table
    table.insert(vviValues, 1, value)
    
    -- Check if the table has more than 60 values, and remove the oldest value
    if #vviValues > 60 then
        table.remove(vviValues)
    end

    -- Print the 20th place value (the most recent value)
    print("1st  Value: " .. vviValues[1])
    print("60th Value: " .. vviValues[60])
end

-- Subscribe to the dataref with the callback function
xpl_dataref_subscribe("sim/cockpit2/gauges/indicators/vvi_fpm_pilot", "FLOAT", vviCallback)

[frumpy]

So with ChatGPT I finally had some success. Without it, I would have probably not been able to do this.
It still needs some code optimization, but the first version is working. I think I like the delayed one the most, but perhaps I'll just adjust the speed of the pointer a bit.
I'll leave it the way it is for now.

Ideas for later: incorporate friction (needs a certain difference in altitude, once the direction of the pointer changes), random offset of the needle (+- 50ft is normal) and acceleration error.

Here is a demo:

AAA VSI with delay - VSI.siff

(157.95 KiB) Downloaded 114 times

AAA VSI with delay and slow motion - VSI.siff

(160.61 KiB) Downloaded 152 times

[SimPassion]

Woww !! never thought of such detail level, congrats and thanks for the good work
My choice is definitively the 3rd VSI instrument, which would avoid me some inappropriate anticipation on pitch axis, together with using unreliable joystick device
Will have a try soon