Massive, sweeping inconsistencies in altimeter functionality accross the platform and among 3rd party modules.

[m4ti140]

Recently, while trying to figure out why the altimeter in the M2000C doesn't zero-out at listed QFE, I discovered some extremely concerning issues with how DCS presents data to the user, how altimeter settings are defined and how third party modules handle altimeter modelling. I've realized there are extreme (even thousands of feet) inconsistencies in altimeter indications in almost all 3rd party modules whenever sea level temperature doesn't match ISA, possibly stemming from an omission in the briefing screen and the mission editor.

When setting up static weather in ME, the mission designer is required to set real sea level pressure and temperature. These settings are obviously valid only at sea level, with pressure and temperature at most airfields being appropriately lower. The changes in pressure and temperature lapse rates depending on sea level conditions are appropriately modelled in the platform, however the sea level pressure is listed as "QNH" in both the Mission Editor and the briefing. This is incorrect for sea level temperatures other than 15°C. QNH, by definition, is calculated by reducing station pressure to sea level elevation, assuming ISA lapse rates and disregarding temperature offset. Since most barometric altimeters are calibrated for ISA, setting QNH results in the instrument reading a correct field elevation despite the temperature offset. This means for static pressure distribution across the map, the QNH will differ from real sea level, the difference increasing with field elevation, and therefore needs to be calculated from station pressure for individual airfields.

In case of ED modules, all altimeters seem to be replicating these effects correctly, whether it is by using pressure as input and replicating real altimeter's scaling to it, or by correctly applying error to known altitude value. That means they behave correctly when using QFE listed in briefing (they show 0 elevation) and a QNH correctly calculated from the QFE (they show field elevation, barring small measurement errors, even at maximum temperature offset allowed by the editor). This also means they show wrong elevation when set to QNH listed in the briefing (which is correct, since it's that QNH that is wrong).
The inconsistencies are apparent in 3rd party modules. Out of all modules I could check (Which included all 3rd party fixed wing jets), the only module where the altimeter behaved consistently with ED modules (and realistically with relation to pressure) were the C-101 and AJS-37 modules. Other 3rd parties seemed to each have a unique systematic error:

• Razbam - all modules (MiG-19, Harrier, Mirage) completely disregard changes to lapse rate with temperature. When set to the real sea level pressure (listed as QNH in briefing) they show their real altitude ASL regardless of temperature offset. Consequently, setting the QFE listed in briefing or given by ATC results in non-zero indication. In the stock campaign shipped with the Mirage in particular, setting the ATC QFE results in an error bigger than 200ft. Necessary 0 elevation setting is obtained by calculating QFE from "QNH" listed in briefing.
• Heatblur:
  • AJS-37 - Viggen has 2 altimeters. Backup altimeter is consistent with a real altimeter as well as with ED modules. Main altimeter appears to be deliberately temperature corrected and shows correct field elevation when set to real sea level pressure, shows 0 when set to briefed QFE, and shows real altitude above station we set QFE of. Given how Viggen's weapons system works I assume this is a feature of the aircraft and was done deliberately.
  • F-14B - the altimeter displays correct field elevation when set to the real, computed QNH and wrong field elevation when set to the QNH listed in briefing, which is consistent with ED modules. However, when set to the QFE listed in briefing it displays the same altitude error as Razbam modules, suggesting that altitude is being calculated from pressure, but additional correction (possibly duplicating existing one) is applied to it. It requires further investigation, or input from HB.
• Magnitude 3 - the MiG-21 displays an equal in absolute value but opposite error from Razbam modules. All Razbam modules show elevated altitude when set to QFE at positive temperature offset, and a negative altitude at negative temperature offset. MiG-21 shows a reversed relationship. Why it works that way is a mystery to me, either way indications are wrong.
• Deka Ironworks - same issue as with Razbam modules. It should be noted however that testing was done at standard pressure, disregarding any further errors - and the altimeter modelling in in the JF-17 previously displayed a disregard even for sea level pressure, always showing real altitude at 29.92. The recent changelog seems to indicate this part, at the very least was fixed, but it wasn't tested. Temperature offset is certainly disregarded, indicating altimeter simply shows real altitude read from platform.
• AvioDev - C-101 altimeter was consistent with ED modules.

These inconsistencies have severe impact on usability of altimeters. Although in some cases they make them more accurate, that is not what is expected in real life, because it's hard to achieve in real life conditions - therefore altimeters need to be consistent, and baring instrumentation or reading errors they should indicate the same measured altitude at the same real altitude with the same altimeter setting, regardless of aircraft. As it stands, that is not the case unless mission sea level temperature is 15°C. If there's any offset, there will be substantial differences in indication from module to module, regardless of what pressure setting is used as reference. At 50°C (which is expectable on some terrains) differences are in the order of 10%, making altimeters useless for altitude deconfliction, and forcing reliance on INS/GPS or even on the info bar.

The following measures are suggested to resolve the situation:

1. Correct the terminology used in briefing and in ME. Sea level pressure should be listed as such, or as QFF. QNH should be calculated individually from QFE for player's spawn airfield and listed in briefing, next to the QFE value, for all 3 units.
2. Release clear guidelines for all 3rd parties on altimeter modelling to ensure consistency. Ideally, pressure should be used as input rather than altitude, to ensure altimeter indications are consistent with atmosphere modelling within the platform.

[Fresh]

Hi everyone,

I am trying to get the T-45C Goshawk mod to have the same indicated altitude as the Hornet.

I've created a mission in Nevada, set QFF to 29.92 and the temperature to +50°C

I then place a Hornet, a Tomcat and the Goshawk above Tonopah at 35,000 feet in the mission editor.

The Hornet reads 31280 feet on the HUD

The Hornet reads 31060 feet on the altimeter

The Tomcat reads 31195 feet on the altimeter

These readouts stay the same at Mach 0.5 and Mach 0.8

My code for the Goshawk makes it read 30740 feet on all three outputs (same code for each) 

local alt = ((sensor_data.getBarometricAltitude()*meters_to_feet)-(qff_inHg:get() - ALT_PRESSURE_STD)*938)
	local temp_error = ((temp - 15)/((273.15 + temp)-(0.5*0.00198*alt)))*alt --add an error for temperature effects on the atmosphere
	alt = alt - temp_error --add error to altimeter indication

Can anyone look at my code and see if there is an error. I guess the Hornet and Tomcat programmers did not include altimeter system errors for Mach, but I will test further...

(Hornet performance info says a/c is ca. 300 feet higher at M 0.8 than indicated on the altimeter and that FCC corrects it otherwise, I guess on the HUD)

Much appreciated!

Fresh

[silverdevil]

Just now, Fresh said:

I am trying to get the T-45C Goshawk mod to have the same indicated altitude as the Hornet.

hello. unfortunately you will need to take up this issue with mod creators. you will likely not get official support. hence why the OP got no reply. because one of the troubleshooting steps is to remove all mods.

[Fresh]

Thanks Silverdevil,

I was hoping those 3rd party programmers could share their knowledge and help me fix this. Or maybe the community could lay down a code for all mod creators, so that all our altimeters and indicated speeds are more or less correct (not counting specific airframe differences).

Fresh

Edited January 29 by Fresh
typo

[draconus]

48 minutes ago, silverdevil said:

unfortunately you will need to take up this issue with mod creators. you will likely not get official support. hence why the OP got no reply.

But OP does not talk about any mod.

[silverdevil]

55 minutes ago, draconus said:

But OP does not talk about any mod.

yes i realize now. my bad. but the reply by @Fresh is definitely asking about a mod. i guess i am wondering what the OP is posting about in the first place. now the OP is "ED Team" so i am confused. i guess having official AC problems.

[Schlingel mit Kringel]

On 8/24/2021 at 10:27 PM, m4ti140 said:

Recently, while trying to figure out why the altimeter in the M2000C doesn't zero-out at listed QFE, I discovered some extremely concerning issues with how DCS presents data to the user, how altimeter settings are defined and how third party modules handle altimeter modelling. I've realized there are extreme (even thousands of feet) inconsistencies in altimeter indications in almost all 3rd party modules whenever sea level temperature doesn't match ISA, possibly stemming from an omission in the briefing screen and the mission editor.

When setting up static weather in ME, the mission designer is required to set real sea level pressure and temperature. These settings are obviously valid only at sea level, with pressure and temperature at most airfields being appropriately lower. The changes in pressure and temperature lapse rates depending on sea level conditions are appropriately modelled in the platform, however the sea level pressure is listed as "QNH" in both the Mission Editor and the briefing. This is incorrect for sea level temperatures other than 15°C. QNH, by definition, is calculated by reducing station pressure to sea level elevation, assuming ISA lapse rates and disregarding temperature offset. Since most barometric altimeters are calibrated for ISA, setting QNH results in the instrument reading a correct field elevation despite the temperature offset. This means for static pressure distribution across the map, the QNH will differ from real sea level, the difference increasing with field elevation, and therefore needs to be calculated from station pressure for individual airfields.

In case of ED modules, all altimeters seem to be replicating these effects correctly, whether it is by using pressure as input and replicating real altimeter's scaling to it, or by correctly applying error to known altitude value. That means they behave correctly when using QFE listed in briefing (they show 0 elevation) and a QNH correctly calculated from the QFE (they show field elevation, barring small measurement errors, even at maximum temperature offset allowed by the editor). This also means they show wrong elevation when set to QNH listed in the briefing (which is correct, since it's that QNH that is wrong).
The inconsistencies are apparent in 3rd party modules. Out of all modules I could check (Which included all 3rd party fixed wing jets), the only module where the altimeter behaved consistently with ED modules (and realistically with relation to pressure) were the C-101 and AJS-37 modules. Other 3rd parties seemed to each have a unique systematic error:

• Razbam - all modules (MiG-19, Harrier, Mirage) completely disregard changes to lapse rate with temperature. When set to the real sea level pressure (listed as QNH in briefing) they show their real altitude ASL regardless of temperature offset. Consequently, setting the QFE listed in briefing or given by ATC results in non-zero indication. In the stock campaign shipped with the Mirage in particular, setting the ATC QFE results in an error bigger than 200ft. Necessary 0 elevation setting is obtained by calculating QFE from "QNH" listed in briefing.
• Heatblur:
  • AJS-37 - Viggen has 2 altimeters. Backup altimeter is consistent with a real altimeter as well as with ED modules. Main altimeter appears to be deliberately temperature corrected and shows correct field elevation when set to real sea level pressure, shows 0 when set to briefed QFE, and shows real altitude above station we set QFE of. Given how Viggen's weapons system works I assume this is a feature of the aircraft and was done deliberately.
  • F-14B - the altimeter displays correct field elevation when set to the real, computed QNH and wrong field elevation when set to the QNH listed in briefing, which is consistent with ED modules. However, when set to the QFE listed in briefing it displays the same altitude error as Razbam modules, suggesting that altitude is being calculated from pressure, but additional correction (possibly duplicating existing one) is applied to it. It requires further investigation, or input from HB.
• Magnitude 3 - the MiG-21 displays an equal in absolute value but opposite error from Razbam modules. All Razbam modules show elevated altitude when set to QFE at positive temperature offset, and a negative altitude at negative temperature offset. MiG-21 shows a reversed relationship. Why it works that way is a mystery to me, either way indications are wrong.
• Deka Ironworks - same issue as with Razbam modules. It should be noted however that testing was done at standard pressure, disregarding any further errors - and the altimeter modelling in in the JF-17 previously displayed a disregard even for sea level pressure, always showing real altitude at 29.92. The recent changelog seems to indicate this part, at the very least was fixed, but it wasn't tested. Temperature offset is certainly disregarded, indicating altimeter simply shows real altitude read from platform.
• AvioDev - C-101 altimeter was consistent with ED modules.

These inconsistencies have severe impact on usability of altimeters. Although in some cases they make them more accurate, that is not what is expected in real life, because it's hard to achieve in real life conditions - therefore altimeters need to be consistent, and baring instrumentation or reading errors they should indicate the same measured altitude at the same real altitude with the same altimeter setting, regardless of aircraft. As it stands, that is not the case unless mission sea level temperature is 15°C. If there's any offset, there will be substantial differences in indication from module to module, regardless of what pressure setting is used as reference. At 50°C (which is expectable on some terrains) differences are in the order of 10%, making altimeters useless for altitude deconfliction, and forcing reliance on INS/GPS or even on the info bar.

The following measures are suggested to resolve the situation:

1. Correct the terminology used in briefing and in ME. Sea level pressure should be listed as such, or as QFF. QNH should be calculated individually from QFE for player's spawn airfield and listed in briefing, next to the QFE value, for all 3 units.
2. Release clear guidelines for all 3rd parties on altimeter modelling to ensure consistency. Ideally, pressure should be used as input rather than altitude, to ensure altimeter indications are consistent with atmosphere modelling within the platform.

Wow, great find. Sad to see there was no public response at all back when it was posted. Has there anything gone about this internally in the meantime? Totally agree with both your final points (also add wind direction to the list). Especially the second one: a thing i often see missing along DCS is an apparent lack of standardization along ED and 3rd party projects. Your finding is one but there are a lot of other things that should be unified along all modules. Like some module having cockpit fogging, but others not. Or how ECM affects radar. Wear and tear like in the upcoming F-4E. All such things normally should be a core feature with API access for every party. I think this is of crucial priority, because the more modules we get, the more 3rd parties, the more inconsistencies there will be. And eventually, with the DCS core changing and evolving, you will at some point have a huge mess too big to solve.

[Flappie]

This post was made in August 2021. Not the best month to get attention from devs and testers. I'll add it to my todo list and check.

[Schlingel mit Kringel]

1 hour ago, Flappie said:

This post was made in August 2021. Not the best month to get attention from devs and testers. I'll add it to my todo list and check.

this is true.

Thank you. I think this is quite an important topic and worth keeping an eye on. I'd do some checks myself, but the only non-ED modules i got literally are the C-101 and AJS-37

[Art-J]

@Schlingel mit Kringel I agree with you to some extent and I know that unification sounds like a great idea at first glance, but it's just not always feasible in practice.

What if 3rd party figures they can develop some feature which is better than ED's one (e.g radar) or is missing in DCS core (e.g. wear and tear)? They can't sit and wait for ED to implement/improve their unified solution, because ED coders might have different, much more important "crucial priorities" to develop at that moment (e.g. Multithreading, Vulkan), so it could be a few-years-wait. Nobody can afford that.

What if opposite happens and ED develops a better feature while 3rd party module starts lagging behind? In theory 3rd party should revisit and upgrade their product to the newer standard, but who's going to pay for workload required? Most 3rd parties in DCS consist of part-time workers or volunteers and thus maintenance and upgrading of older products will always be of lower priority compared to new projects which bring new income and keep the teams going.

Realistically, I'd love to see unification of "small things" first, like convention of left/right mouse button flipping the cockpit switches up/down in some modules, but down/up in the others. Damn annoying and should be easier / more affordable to standardize by all parties involved in DCS.

[Raven (Elysian Angel)]

1 hour ago, Flappie said:

Not the best month to get attention from devs and testers.

Except that the original post was made by a developer, since their tag says "ED Team". It would be nice though if clarification was given on whether this is fixed already.

[Flappie]

Chances are m4ti140 wasn't part of the team back then, otherwise this post would not have been in the public part of the forum, unless ED's intention would be to announce an upcoming fix.

[Fresh]

QFF, QNH, QFE concepts and temperature and density effects in the atmosphere are quite complicated subjects, let alone the calculations for them. It would be great if there was some guidance material from ED on best practice for 3rd party and mod developers so that we all get standardised results for indicated altitude and indicated airspeeds. Perhaps a funtion to give indicated altitude and speed instead of the current true altitude.

Ideally AI would also fly at such indicated altitudes, instead of true altitude. It would be great to set up a tanker in the mission editor to fly at a flight level, and pilots could join at the same flight level.

Anyway, just my thoughts, getting off topic from OP...

[silverdevil]

12 hours ago, Flappie said:

Chances are m4ti140 wasn't part of the team back then

agreed flappie. this is most plausible. 

[Vakarian]

While it wasn't any definite test given that I lack modules from number of 3rd parties, I did throw a quick test with few ED, Heatblur, AvioDev and Razbam modules. 

With QNH set at default 29.92 in both tests, only thing changed was the temperature. First test I did was with the maximum allowable 40 degrees and second with the minimum allowable 20 degrees (Celsius, both values positive ofc)

In +40C test, briefing QFE was 29.38, in +20C briefing QFE was 29.35.

Aircraft	+40C measured QFE	+20C measured QFE
A-10CII	29.39	29.35
AV-8B	29.38	29.38
C-101	29.39	29.36
F-14B	29.37	29.33
F-15E	29.38	29.38
F-16C	29.39	29.36
F-5E	29.40	29.36

I did also include P-47D in the test, but for the love of god I cannot figure out how to read the pressure setting that was set

QFEtestWhileOnRwy_40c.trk QFEtestWhileOnRwy_20c.trk

[Fresh]

Hi Vakarian,

your test is difficult to interpret without knowing where you are. I suspect from the temperature range you are in the Mariannas, maybe Andersen based on the QFE? (Sorry, using my iPhone, can't watch your tracks).

Try January in Beslan, Caucasus with -12°C and same place in July with 50°C. Beslan being high will show bigger differences.

If you have Nevada, try Tonopah (5540 AMSL)

So your test tell us how the different developers coded their altimeters. As the OP says, each developer used a different formula to create the temperature error if at all. If you do try Beslan or Tonopah maybe do one test with 15° C (Standard ISA Temp)

Another test is to turn the altimeter from 28.00 to 29.00 and 29.00 to 30.00 to see how many feet an inch of mercury changes. From my research it should be 938 feet. The change is not linear, but I suspect some have used 1000' per inch. That will influence when 0 feet is reached as displayed on the Kollsmann window.

Thanks for your efforts!

Fresh


Sent from my iPhone using Tapatalk

Edited February 4 by Fresh

[Vakarian]

Yeah, it was quick and dirty test on Marianas just to see if there's any discrepancy after a few years. I'll do what you suggested sometime during this week. Have all maps so it shouldn't be an issue.