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:
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.
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)
}
Vertical speed which we discussed above: delta altitude / delta time +
Delta airspeed calculations, and it looks not quite right I think: Vcurrent^2 - Vlast^2
/
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.
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)
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
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.)
I just tried LS4 Rolladen-Schneider LS4 » Microsoft Flight Simulator and its vario set as TE (total energy) mode behave much better than the Discus. (try simply to slow down from 130km/h to say 90km/h and see how vario needle deflects down) I had a look at LS4_interior.xml : gauge_te_needle animation but couldn’t understand what (L:B21_COMPUTER_VARIO_NEEDLE, number) is linked with. The STF mode (speed to fly) mode is also great Speed to fly - Wikipedia Did you had a look?
I 'd also be pleased to understand gauge_netto_needle
(A:AIRSPEED TRUE, meters per second) d *
19.62 /
(A:PLANE ALTITUDE, meters) +
0.25 * (G:Var2) 0.75 * +
d (G:Var2) -
(E:ABSOLUTE TIME, seconds)
0.25 * (G:Var1) 0.75 * +
d (G:Var1) -
r (>G:Var1)
/
r (>G:Var2)
10 min 10 neg max
0.05 * (L:B21_TE_MS, meters per second) 0.95 * +
(>L:B21_TE_MS, meters per second)
(L:B21_BASIC_VARIO_NEEDLE,number)
</Code>
That ‘Code’ section in the LS4 model XML (I wrote it) is doing TWO things:
(1) it does a real-time calculation in the model XML to UPDATE a variable called L:B21_TE_MS which contains the Total Energy (m/s) reading for the current update cycle. This TE value is smoothed over approximately 1 second and capped at +/- 10 meters per second, both of which are necessary in the sim to act as a gust filter and also smooth out digital hiccups in the data coming from MSFS. But that L:B21_TE_MS reading is designed to be as responsive as necessary and generally useful in any gauge (there is a lot of stuff in the LS4/AS33 instruments that uses the TE value).
(2) The code section then READS a completely separate variable L:B21_BASIC_VARIO_NEEDLE which is being produced in the HTML/JS code 0…100 to animate the instrument needle, so that animation effectively throws away the L:B21_TE_MS value after it produces it.
Of course the HTML/JS gauge code for the vario is READING the L:B21_TE_MS variable, deciding what to do with it, and generating the 0…100 value in the L:B21_BASIC_VARIO_NEEDLE which the model XML is using to move the needle.
This technique means
(a) a total energy reading is being produced for the plane so all the gauge code can use it, and for various technical reasons this calculation HAS to be in the model XML as the html/js code doesn’t have the same millisecond-accurate real-time connection to the sim.
(b) Any gauge can read the L:B21_TE_MS value, and calculate some adjustment from it before it creates its animation value, e.g. in the LS4 the data going into the Netto gauge is slowed down slightly so the responsiveness is slower than the Computer Vario (and also it is calculating the amount to subtract for the glider polar before animating the needle). The Computer Vario can be given its own response rate, and also sending the TE data to the html/js code and then sending the animation data back to the gauge allows the needle to be easily flipped between the TE and the Speed to Fly reading.
In another aircraft, for the simplest code possible, the L:B21_TE_MS value (-10…+10) could be used to directly animate the gauge needle (e.g. for 0…100 just multiply by 5 and add 50.).
The code above is completely open source and works for any glider (luckily, the formula for TE doesn’t include the weight of the glider or any other unique parameter) so it’s a cut-and-paste freely available to use.
I know this is an aging thread but it seems the perfect place to get an answer without duplicating the subject. I cannot get my gauge_netto_needle to function. It sits stubbornly at zero on my VSI (the vsi needle works). I have copied exactly the LS4 code mentioned above, using an object name of gauge_netto and an animation name of gauge_netto_needle (I also tried naming the object gauge_netto_needle as well). I have used the same keying stages as the vsi needle. The only other issue I have is how to convert the output to the needle from m/s to ft/sec, I’m not familiar with RPN and struggle to understand some of it, e.g. G:Var1 and 2 are a mystery
My intention is to find a way to animate the central double-ball variometer in the cockpit which is currently being driven as a vsi not a variometer and although it isn’t in a T31 cockpit I created the vsi/vario instrument to experiment with the code and find a way.
I attach images of the Blender and the xml files and the cockpit but as a new user I must submit them in separate posts.
Blender
