Difference between VELOCITY WORLD Y, VARIOMETER RATE and VERTICAL SPEED

Hello,

I’m currently looking at a variometer code of a third party aircraft (to understand how instruments are working) and I’m wondering what is the difference between:

VELOCITY WORLD Y
https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Miscellaneous_Variables.htm#VELOCITY_WORLD_Y

VARIOMETER_RATE
https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_System_Variables.htm#VARIOMETER_RATE

and

VERTICAL_SPEED
https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_Misc_Variables.htm#VERTICAL_SPEED

Kind regards

hi @scls19fr

Not sure which glider exactly you are looking at, but I guess math are almost the same in all as taken from B21’s vario tutorial for FSX.

VELOCITY WORLD Y is raw velocity, calculated between frames

VARIOMETER_RATE does not work in MSFS, at least for me

VERTICAL_SPEED is the weird one. in docs it has description “The current indicated vertical speed for the aircraft.” but I don’t feel it is indicated, but the same VELOCITY WORLD Y (trigonometrical) just aggregated, i.e. value reach current moment vertical velocity with delay. it definitely not suitable for TE calculations.

And final note - we are using delta altitude divided by delta time, as it, probably, more reliable.

Thanks @thealx2901 for explanation. I’m looking at Discus 2c variometer code (but I never tried myself at FS dev before (but have some general dev skills)
delta altitude divided by delta time is probably the best method for calculating uncompensed vertical speed.
I think Vz_TE should be Vz + 1 / (2 g) d/dt (v^2)
Em = Ep + Ec
with potential energy Ep = m g z
and kinetic energy Ec = 1/2 m v^2
let’s calculate derivative over time (assuming mass and g are constant)
d Em / dt = dEp / dt + dEc / dt = m g dz / dt + d/dt ( 1/2 m v^2 )
by dividing by m g
Vz_TE = 1 / (m g ) * d Em / dt = dz / dt + 1 / (2 g) d/dt (v^2)
Vz_TE = Vz + 1 / (2 g) d/dt (v^2)
ie Vz_TE = delta altitude divided by delta time + 1 / (2 g) d/dt (v^2)
I’m sorry but I haven’t been able to find url of “B21’s vario tutorial for FSX” you indicated.
Because as a IRL glider pilot (and instructor) I can really confirm that it shouldn’t behave like current version ! Maybe I should post a video with either an other simulator whom variometer behave correctly (or with IRL flight… but that’s definately not the good season for flying where I live)

Some variometers also have 2 positions to calculate average of the vertical speed over an integration time of 3 or 5 seconds (3 seconds is often the default). This not a so big integration time because anyway variometer are lagging (at least the most common in gliders’s club)

Before we proceed to the theory, we have to remember that variometer react on glider behaviour. If glider does not have accurate flight model (like incorrect drag or lift) vario will show unexpected values. Currently MSFS has weird incidence drag, sometimes airplane even accelerate during sharp manoeuvrers. But possibility of error in the code is high so let’s see what’s inside.

Link to the @MSGamerTag01 math: Variometers

Current peace of code responsible for TE calculations. You may ask why it’s XML - because this kind of script has most stable timings and frequent updates compare to JS or WASM gauges.

1) (A:PLANE ALTITUDE, meters) (L:LAST PLANE ALTITUDE, meters) - (A:ANIMATION DELTA TIME, seconds) /
2) (A:AIRSPEED INDICATED, meters per second) 2 pow (L:LAST AIRSPEED INDICATED, meters per second) 2 pow - 
3) 2 (A:ANIMATION DELTA TIME, seconds) * 9.80665 * /
   +
4) (A:AIRSPEED INDICATED, meters per second) (A:AIRSPEED TRUE, meters per second) 
   / * s15
						
   l15 10 < l15 -10 > and if{
6)	1 (A:ANIMATION DELTA TIME, seconds) - (L:TOTAL ENERGY, meters per second) * (A:ANIMATION DELTA TIME, seconds) l15 * +
	-10 max 10 min (>L:TOTAL ENERGY, meters per second)
   }
  1. Vertical speed which we discussed above: delta altitude / delta time
    +

  2. Delta airspeed calculations, and it looks not quite right I think: Vcurrent^2 - Vlast^2
    /

  3. 2 * delta time * G
    /

  4. indicated airspeed / true airspeed (indicated velocity modifier)

  5. average TE value like 0.95 * old TE + 0.05 * new TE

maybe it should be (Vcurrent - Vlast)^2 instead?
and indicated modifier, isn’t it should multiply previous value, not divide?

Variometers formula for Vz_TE looks similar to what I wrote previously. I’m sorry but I don’t understand the XML piece of code (probably because of rendering) Where can I find this code (which manage the modern/electrical variometer on the right) in Discus2c community folder ? I also wonder where is the code managing the classical / mechanical variometer (on the left).
If interested you can find various informations about glider instruments available at Documents pour le pilote – ATO-CNVV
or Tous les documents – ATO-CNVV Documents pour le pilote
(in french only sorry) especially “Instruments de bord des planeurs” and “instruments modernes des planeurs”. In the book “Instruments de bord des planeurs” you will see how variometer should behave (p19 and following) in various situations (calm air constant speed, dolphin style of gliding (ie slow down then acceleration). I think diagrams can help to understand what is wrong currently.

Where can I find this code (which manage the modern/electrical variometer on the right)

Community\gotfriends-discus2c\SimObjects\Airplanes\gotfriends-discus2c\model\D2C_INT.xml

Thanks for the links.

Thanks ! and for classical vario ? (on the left)

PS : I understood that formula is using Reverse Polish Notation and it’s Vcurrent^2 - Vlast^2 which is correct

that’s right, this is FSX (and even older) style RPN

I have some questions… I don’t understand why IAS / TAS ratio multiply both delta altitude / delta time and (IAS^2 - IAS_last^2) / (2 * g) why not doing delta_altitude / delta_time + (TAS^2 - TAS_last^2) / (2*g)

I also don’t understand what

l15 10 < l15 -10 > and if{

                            1 (A:ANIMATION DELTA TIME, seconds) - (L:TOTAL ENERGY, meters per second) * (A:ANIMATION DELTA TIME, seconds) l15 * +

                            -10 max 10 min (>L:TOTAL ENERGY, meters per second)

                        }

means
(it seems that it deals with variometer values between -10 and 10 m/s)

I see for example

1 (A:ANIMATION DELTA TIME, seconds) -

1 - delta_time ?

that’s odd. How a duration (in seconds) could be substract to a number (without units)

I just don’t understand this part

we had hot discussion about which airspeed variables should be used but never reached agreement.
problem that TRUE AIRSPEED is not equal to TOTAL VELOCITY. we are using PLANE ALTITUDE for vertical velocity calculation, which should be compensated by air pressure to match INDICATED AIRSPEED

it ignore too high or too low values (for the case when user use slew mode to move around)

I’ve provided end result of this line before:

0.95 * old TE + 0.05 * new TE

as delta time usually 0.033-0.063. it’s simplest way to smooth result but should not create any error in the final value

1 Like

The TE calculation (as linked by Alex) above doesn’t depend on the glider it’s in, so the same code can be used in any glider. Microsoft (FSX) had the idea of including the TE value as a SimVar VARIOMETER RATE in FSX but failed to implement it and instead just set the value to the raw vertical speed, hence the (unmodded) FSX DG808S vario displays uncompensated vertical speed.

The FSX-based flight sims make it surprisingly difficult to implement the TE calculation (Xplane was a breeze in comparison). The formula is highly sensitive to

  • airspeed difference (squared),
  • altitude difference,
  • and the time difference between sample points

Note that all these values MUST refer to a coherent set of data points - you’d think this is obvious but the FSX-based sims obfuscate that and the formula goes horribly wrong if e.g. the time difference is NOT actually the exact sim time delta between the two altitude readings, or airspeed readings. Or if the altitude readings don’t match up in time to the airspeed readings. Errors here result in ‘jitter’ in the TE value. Note that in FSX/P3D/MSFS any naive calculation of the TE formula will have JITTER LARGER THAN THE ACTUAL TE READING. You have to take special care to compensate for the FSX/P3D/MSFS challenges, including:

  • the first step being (as Alex says) to implement the formula in XML rather than HTML/JS or C++. I suspect the calculation is impossible to do in MSFS JS/WASM due to async timing challenges.
  • use smoothing (e.g. as Alex step 5). The biggest noise sensitivity is actually airspeed (because it’s squared) and you can smooth that. But note any smoothing introduces a LATENCY into the result - the sim is already smoothing the indicated airspeed and indicated altitude values but using DIFFERENT TIME CONSTANTS, and this introduces yet another problem into the TE calculation. Really you want to do the minimum smoothing in the XML so you can have multiple vario gauges in the glider (TE, NETTO, STF) which themselves can have different response rates.
  • The sim provides alternative simvars (in particular ACCELERATIONS) and you can approximate or compensate for other sim challenges by using these vars (if you study the TE formula, you find you can write a close approximation using acceleration instead of velocity).
  • Cap the TE calculation to being within a narrow range of values to enable it to recover quickly from a spurious reading (e.g. +/- 10 m/s). Otherwise it will take a very long time to recover from unusual data values (due to smoothing).

None of these problems cause an issue with any gauge on a powered aircraft - no developer out there is trying to write code that does a ‘real-time’ calculation - i.e. you can move a needle on a gauge using a single FSX/P3D/MSFS variable and it doesn’t matter if the data has a variable undocumented latency of 0…50 milliseconds.

The current sim support for requesting a ‘set’ of simvar readings in a single request also (strangely) doesn’t solve the relative timing issue.

Note that the current calculation in the glider model XML tends to produce a fairly basic TE value (in meters per second) and I tend to refine that in whatever gauge I use it in (e.g. at low airspeed the indicated reading should tend to zero because of the lack of pitot pressure to move the needle). Moving forward I expect to put that simple code into the XML because every practical HTML/JS gauge needs it anyway.

So the ideal would be to use ‘indicated airspeed’ and ‘indicated altitude’ because that would give the most straightforward implementation of a realistic glider vario (which is dependent on pitot pressure (==ASI) and the derivative of static pressure (==Altimeter) but the realpolitik of what you have to work with in the sim ultimately drives the implementation.

What we want Asobo to do is implement a total energy VARIOMETER RATE inside the sim as Microsoft originally intended. In the meantime there is a ‘stock’ XML fragment available in all the freeware gliders which produces some “TE_MS” custom variable providing that value. The RPN language it’s in is bizzare though, so it’s not worth spending time working out how that particular code works as it has obscure optimisations - if you’re interested then just write a ‘plain’ TE formula (as per the math) in XML (even that is quite an exercise), and refine it from there. If you write to an L: variable then the SDK Behaviours window can show you that while you fly around (or indeed put it on a needle.)

1 Like