VATSIM / IVAO / PILOTEDGE Users - Be aware of an important bug!

Big thanks to both @AwarePlot117729 and @Bishop398 for the above explanations – it’s much clearer to me now, and I understand why and how it can be off under transition altitude. :smiley:

The plane altitude simvar is just the exact geometric distance above zero. It does not take any pressure into account at all.

I think maybe we’re not totally communicating clearly here. A temperature only influence on the altimeter was removed as the data was not quite granular enough in practice. However, we now use directly the local pressure from the weather system. This is what I was referring to previously when I mentioned we would be keeping the pressure influence.

-Matt | Working Title

1 Like

For the standard pressure lapse rate, it would be the same thing.

Gotcha on the other and edited my previous post. Thanks for the explanation.

2 Likes

Totally understood and correct, just wanted to make sure folks didn’t think pressure was involved somehow in that one. That’s why it presently could be different than the indicated and/or pressure altitudes.

-Matt | Working Title

1 Like

I just did a flight in HF2 in the Aerosoft CRJ from LAS to SLC, with Live Weather. I monitored the simvars for plane altitude, pressure altitude, indicated altitude, sea level pressure and ambient pressure. I kept the altimeter synced to injected sea level pressure below 18,000 feet, and set STD passing 18,000. Below the transition altitude, with the baro synced to Live Weather, plane altitude and indicated altitude were a close match (as they should be). Above 18,000 with the baro set at 29.92, indicated altitude and pressure altitude were a close match (within +/- 20 feet.

This tells me that If VATSIM is indeed using plane altitude below the transition altitude, and pressure altitude above, then it would be necessary to keep the altimeter synced to whatever sea level pressure is being injected at the aircraft’s location by MSFS Live Weather, not the pressure given by the Vatsim controller, which may not be the same.

2 Likes

Thanks for all you’ve done and communicated to us Matt. Hope I haven’t taken too much of your time on this.

1 Like

Not at all, it’s really my pleasure! Hopefully that clears some of this up.

-Matt | Working Title

3 Likes

Hi Matt,

In other words the problem is no longer with FS2020, rather the parameter VATSIM uses? Do you know if there are any plans to reimplement the temperature effect on altimetry at some point in the future? The area where I’m usually flying in real life you really run the risk of flying into something when not correcting for temperature during winter. Its an immersion breaker for me not to have this, not only in the winter, on a hot summer day its equally weird to find the aircraft intercepting the glide slope exactly at FAP for example.

Thanks for taking the time to communicate what is going on behind the scene!

This is my bad for not being super explicit on such a technical topic.

The only reason temperature affects the altimeter is because a change in temperature also changes density. If the densities in your air column change, then your local pressures change. This causes a change in the altimeter reading. However, the temperature itself is not the cause of the error directly, on its own. In other words, if you’re exactly at ISA pressures but at -15C ISA, the altimeter will still be correct. Similarly, if you’re at 0C ISA but 10 mb off from ISA, then the altimeter will still be wrong. The atmosphere generally doesn’t get into those kinds of situations, though, so that’s why the rule of thumb given about altimeter error with temperature is mostly in the ballpark, because air is an ideal gas and all these things relate.

What was removed was a strategy that used only temperature data only to back into these variances. However, ultimately the pressure data is much more reliable and granular, so the switch was to using that. If there are non-ISA temps in the atmosphere, that will affect the weather model, which will affect density, which will change the pressure gradient. Thus the temperature effect is modeled, and more correctly, as it uses the only thing a real altimeter uses, which is local air pressure.

-Matt | Working Title

Guys,
I fly only on vatsim. After install latest hotfix SAT ISA temp work fine (show correct temp) but… on VATSIM (vatspy or any other app to track flight) it show higer altitude = for example in 748 with saly modl i set FL330. On map.vatsim.net or vatspy it show … 34300 ft (approx 1300ft higher then i set).
I make small test and turn off real weather and use preset. It show approx fl330 - so ok.
I make 3rd test. Turn on REX Weather system - it show weather and… 500ft over set FL.

So- where is problem? I see that still have some problem with weather/alt on MSFS with users who fly online. 100ft, 300ft is not problem but 1300ft alt diffrence can be problem.

Thanks Matt!

So temperature affects the pressure lapse rate? After the last hotfix there wasn’t any temperature effect though and I thought this hotfix only addressed the problem causing the pressure altitude disconnect.

I haven’t tried out the new hotfix.

It does and it was present in the previous hotfix also, in live weather only. In fact, granular local pressure data from the weather model has been there since launch (and observable in the ambient pressure simvar roughly), it just wasn’t used by the altimeter. User weather and weather themes use an ISA standard atmosphere.

-Matt | Working Title

I did some Testing with the Latest SU5 HotFix 2.

First, I googled the Flattest place on Earth. Turns out it’s the Salar de Uyuni, a famous “Sea of Salt” in Bolivia. I wanted to make sure there would be no influence to Height being different over the course of the test.

Then, I used the LiveFlightData Tool to plot a realtime Graph of three VAR from MSFS, PLANE ALTITUDE, INDICATED ALTITUDE and PRESSURE ALTITUDE.

Flying with AP on to hold 30000ft, STD Pressure, I started varying the Temperature Offset, from -100 to +50, and taking notes on what happened on the Graph while I did so. In the End. I varied the Pressure to check that the graph was showing correctly.
Here’s the Video:

First thing I noticed is that appears to have some kind of glitch in the Pressure Altitude VAR, it’s very noisy and spiking.

None of the three VARS showed any variation with these 150C difference settings? I’m not sure how Asobo implementation has Temperature affecting the Altitude.

I suggest you read the previous messages in this thread. VATSPY and other similar 3rd party apps do not use the same simulation variable for altitude that the VATSIM ATC uses for altitudes above the transition altitude. So what you are showing from VATSPY is not what the controller sses. Above the transition altitude, as long as you have STD (1013.25 /29.92) set for your altimeter, VATSIM ATC and your indicated altitude will be in sync.

Below the transition altitude, VATSIM ATC uses the wrong simulation variable from MSFS for the airplane’s transponder altitude. Therefore, there can be differences between what is indicated on your altimeter and what ATC sees. The error will vary, but should not typically be all that large.

So, this is only enabled on Live Weather Preset? Didn’t know that… That explains why my video above shows no effect of Temperature on any Altitude Var. Will do some more testing

Live weather only. User weather and weather themes use an ISA standard atmosphere. Since you can only change ground temp, the assumption is that the rest of the atmosphere follows ISA relative to that above you.

-Matt | Working Title

1 Like

This issue will be corrected in the next world update.

-Matt | Working Title

3 Likes

More advanced altimetry systems that use Air Data Computers can compensate for density changes caused by cold temperatures on approach , though interestingly, in the case of the Collins Proline 4 avionics system (designed in 1991), this resulted in the uncovering of a long-standing bug in the FMS code.

The Proline 4 FMS in the CRJ has (or rather, had), a temperature compensation option that can be enabled when conducting an approach when the air temperature is below -15C. This will compensate for the “aircraft is lower than indicated altitude” phenomenon that results from cold dense air.

After 30 years, someone found a bug where (if temperature compensation is active) , in rare occasions, if the aircraft has to perform a missed approach with the autopilot controlling lateral path, and the procedure involves a turn, it might turn the opposite direction to that encoded in the procedure.

This could also be induced if pilots manually modified any altitude constraints in the procedure with temperature compensation active.

Not sure why temperature compensation (which involves the air data computer) would affect lateral nav (which involves the FMS and autopilot) but it does.

Rockwell Collins could not determine why this occasionally happens - even after careful analysis of the FMS source code, using debuggers and systems emulators. They suspected it might be a race condition that only occurs in very rare circumstances. It was complicated by the fact that the FMS code is written in assembly language, and the engineers who originally designed it are long since retired or dead.

(Shades of dealing with “old FSX code”!)

This resulted in the issuance of two Airworthiness Directives. The first required revising the flight manual to prohibit pilots from using the temperature compensation option, and a later AD required going into the master configuration module for the Proline 4 system, and changing a DIP switch, which now prevents the temperature compensation option from even appearing as a selectable option in the FMS.

Since the ADs went into effect, in some cases this may prohibit a cold weather approach entirely if the procedure is annotated to require temperature compensation below a certain temperature.

Which has probably led CRJ flight crews in cold weather climates to exclaim “Why wasn’t this found during beta?” :smile:

3 Likes

vatsim uses the real transition alts

1 Like

Aha live weather only, I’ll give that a try!