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

My understanding of the current state is that what you should do for VATSIM at this time is:

  • use live weather
  • use STD above transition altitude, as normal, so your indicated altitude matches pressure altitude
  • use the MSFS barometer setting below transition altitude if it differs from the VATSIM barometer setting, to ensure your indicated altitude is relatively close to your true altitude

(However I could be incorrect, as the only VATSIM flight I’ve been on recently – as wingman in a formation flight so I wasn’t the one dealing with the radio – had no active air traffic controllers in the area, so cannot confirm personally that it’s working as expected.)

1 Like

Just put in the remarks “MSFS 2020 - Altitude bug may be present”

1 Like

Ah thanks… that does not sound too hard to do… you pretty much ignore the ATC QNH and press B below the trans. alt., the rest is as usual.

If someone else could confirm this please… I might try myself later or tomorrow when I get to fly again.

True and indicated altitude rarely match, only in standard atmosphere will the indicated altitude be the true altitude. If the atmosphere is non-standard they simply won’t match, setting the altimeter to the correct QNH is not gonna solve that.

1 Like

Which is why (if it were my call to make), I would like to see online network clients use the simvar “indicated altitude”. It would solve all of the inconsistencies, and would effectively emulate exactly how things work in the real world where ATC is concerned.

R/W transponders always transmit pressure altitude, referenced to 29.92. When an aircraft is flying below the transition altitude, the ATC computers that drive the controllers’ display scopes will automatically apply a barometric conversion to the reported Mode C pressure altitude, using the pressure from whichever METAR-reporting station is closest to the aircraft’s current position.

This will result in the ATC controller seeing the same “indicated” altitude for a specific aircraft as the pilot of that same aircraft sees - assuming the pilot has also set his altimeter to the closest airport pressure, and the altimeter is within calibration limits.

Above the transition altitude, all aircraft in flight will be using 29.92 in/hg (or 1013 hPa) as their altimeter setting, so ATC transponder returns on controller scopes can use the reported pressure altitude directly without conversion.

In the real world, both the altimeter in the aircraft, and ATC controllers on the ground, are applying only a barometric correction to pressure altitude - without taking temperature into account. Since no temperature compensation is being used by either party, the resulting “indicated” altitude, will not be the same as “true” altitude unless atmospheric conditions are exactly ISA.

Effectively, since r/w ATC controllers are monitoring “indicated” altitude, (below the flight levels) then IMO, online ATC networks like Vatsim, IVAO and Pilot Edge should do the same - at least where their clients that interface with MSFS are concerned.

Agree, I didn’t check yet but it seems altimetry in FS2020 is working correct now so its up to VATSIM etc. to update their clients I suppose?

Can confirm I did a VATSIM flight EDDM to EGLL today with service online both above and below transition altitude. The QNH reading in the sim happened to match what VATSIM was issuing anyway but absolutely no problems with altitudes below the transition level doing it the way recommended.


That would be my take on the situation. Apparently, in the old FSX atmospheric emulation, (which also was inherited by P3D) the “true altitude” simvar would match “indicated altitude” if the altimeter was set to closest station pressure, which is no longer the case. If this change were to be adopted, I don’t know if it would involve a change at Vatsim’s end, or within network clients that connect to Vatsim (like VPilot) - or both. I believe the IVAO network protocol is the same as Vatsim.

Vatsim is an official MSFS partner, while IVAO is not. PilotEdge is a payware service, but since many of the controllers there are also real-world ATC controllers, I would assume that they would understand the change that has been made in MSFS altimetry, as would the PilotEdge developer(s) responsible for their network client.


The challenge with putting this back on VATSIM is I don’t know how receptive they are to seeing this as a problem on their side. If you go on their discord, several of their admins will point the finger back at Microsoft/Asobo and I have screenshots to show this. I can only hope that if vatsim needs to make a change that they’re receptive and understanding. After all, this heavily impacts our network.


Will its simple in my opinion, if VATSIM uses the plane altitude = geometric altitude simvar, they would need to change that. That the indicated altitude with baro set correctly matches the geometric altitude with the old and inaccurate FSX code doesn’t mean it is correct.

That seems like it would be incorrect to me: if the pilot has set the baro to a different pressure than they’re supposed to, then ATC would see the same incorrect value from the altimeter instead of the expected STD pressure-based altitude. You could effectively make ATC see you “climb” and “descend” by changing the barometer setting during level flight.

(A more likely case where this would be a problem is if someone simply forgets to update their barometer when going above/below transition altitude, and are now seen at the wrong altitude by ATC.)

According to Everything You Need to Know about Mode C Transponders | Flying that is not how mode C transponders work; they send the pressure altitude calibrated to STD only, and ATC corrects that below transition altitude based on their local barometer setting.

(However unless both the sim and the controller’s system have identical weather simulations, it all seems very … fragile anyway. :D)

1 Like

I and some others have been having a productive discussion with the vPilot developer regarding the problem. He seems genuinely keen to solve the issue but it’s obviously quite complex and we keep identifying new problems as to how behaviour varies between the sims.

@Bishop398 I wonder if you’d be able to join discussions to help (assuming you use VATSIM that is)?


@CByworth Sure, DM me the details, happy to join the conversation.

-Matt | Working Title


No. In almost all aircraft, the altitude encoder that transmits to ATC is a sealed, stand-alone “black box” that is not connected to the altimeter or any other aircraft system other than electrical power, the transponder and the external static pressure system. Its internal pressure reference is locked to 29.92, it always transmits pressure altitude, and you cannot change or influence the transmitted altitude by any adjustment you make to your altimeter’s pressure setting.

If ATC tells you that the current altimeter setting is 30.08, he will be locally correcting his display of your transponder pressure altitude to 30.08, (which is done automatically by the computer that generates the aircraft targets on his radar display). If your altimeter is set to the same pressure, the converted altitude that ATC sees will be the same as the altimeter-converted altitude that you see in the aircraft.

If your altimeter is set to a different pressure setting, and you maintain an assigned altitude based on that (incorrect) setting, then the pressure altitude that your transponder is sending out will no longer convert correctly at the ATC end, and he will see you above or below the assigned altitude,

ATC does not necessarily give “his” altimeter setting. This would be indeed be the case if you are under the control of an airport approach or departure controller whose radar is located at the same airport as the source of the current altimeter pressure setting. This is definitely not the case when you are under the control of an enroute ATC center in the cruise portion of a flight, because in that case, the controller may be hundreds of miles away from your aircraft and communicating with you by a remote-controlled transmitter over leased communication lines.

Enroute Center controllers always give you the altimeter setting from the airport closest to your current location in flight, and the altitude correction applied to your specific aircraft symbol on the radar display will come from that same airport.


Right, that’s what I’m saying!

If you changed it to report what’s indicated on the altimeter as you suggested, then it would be wrong and cause incorrect data sent to ATC.

(Maybe when you said “indicated altitude” you meant to say “pressure altitude”? Or is the “indicated altitude” simvar not actually the indicated altitude and you know it’s actually some other value that would be useful? Do I have my terminology backwards? Can someone double-check and provide a reference for the words & the simvar documentation?)

Wikipedia says:

  • Indicated altitude is the reading on the altimeter when it is set to the local barometric pressure at mean sea level.
  • Pressure altitude is the elevation above a standard datum air-pressure plane (typically, 1013.25 millibars or 29.92" Hg). Pressure altitude is used to indicate “flight level” which is the standard for altitude reporting in the Class A airspace (above roughly 18,000 feet). Pressure altitude and indicated altitude are the same when the altimeter setting is 29.92" Hg or 1013.25 millibars.

This simvar doc page says:

  • INDICATED ALTITUDE Altimeter indication
  • PRESSURE ALTITUDE Altitude reading

(that one’s not as helpful, but at least claims specifically that “indicated altitude” is what’s on the altimeter, so I think I’ve still got my analysis right?)

1 Like

I’m afraid you do not understand. You cannot change the altitude transmitted by the transponder. The altitude encoder is completely separate and independent from the altimeter. It reports the actual pressure altitude that your aircraft is flying at. It is like an “independent witness” that (in a sense) “works for ATC” and never lies.

You, as a pilot, have zero control over what the transponder is sending out, other than by flying at the assigned altitude that ATC gives you, with the exact same altimeter setting that ATC is using.

If you set your altimeter to anything other than the current pressure setting that ATC is using, the controller absolutely will be able to tell that you are flying at the incorrect altitude, and exactly how far off you are.

This applies to real-world aircraft avionics and applies only when the aircraft is flying below the flight levels. Above 18,000 feet, (in the US) it is expected that you will set your altimeter to 29.92, in which case no conversion is required. In that scenario, your altimeter will display pressure altitude directly, and it should always match the altitude transmitted to ATC by your transponder.

We’re talking about making changes to how VATSIM connects to Microsoft Flight Simulator, aren’t we?

I can’t believe you meant that real-world airplanes should use the “indicated altitude” simvar from MSFS to send actual transponder data to real air traffic control.

Cause that doesn’t make any sense at all.

once again you said:

You literally used the words “online network clients” so I think you know you were talking about simulators…

(I should point out too that all your “corrections” are agreeing with the things I said! I’m explaining why your suggestion would be different from real-world ATC, and you’re agreeing with me apparently.)


AFAIK, up until now, VATSIM has been using the simulator variable “plane altitude” for aircraft operating below the flight levels,which is the airplane’s true geometric altitude above sea level. In a real altimeter, even if using the correct barometric setting, the altimeter does not indicate true altitude because the altimeter is also influenced by the temperature and density of the air.

At lower altitudes, if the temperature is close to ISA, true and indicated altitudes will be close. At higher altitudes, and especially when the air temperature is well above ISA, indicated altitude will be lower than true altitude.

It is my understanding (I may be wrong) that in previous MS and ESP-based sims, (FS9, FSX and P3D), as long as the altimeter is set to current pressure, then apparently the sim variables “indicated altitude” and “plane altitude” will match.

This is no longer the case. Asobo has changed the altimeter in MSFS so that it works like a real altimeter, and the variable “plane altitude” can no longer be (reliably) used because it can (and will) differ from indicated altitude more often than not.

Effectively, real ATC controllers “see” indicated altitude, not true altiude, and for VATSIM to work correctly with MSFS after the recent change, they would have to use the indicated altitude variable.

But… I think I understand now the point you were making before. In a real airplane/ATC environment, you cannot “fool” ATC into seeing you at other than your actual altitude (by setting your altimeter to something other than current pressure) - BUT in the sim, yes - you absolutely could.

The drawback to the “indicated altitude” variable is that (in the sim) it is simply a direct expression of whatever is shown on the altimeter. If you are assigned “6000 feet” and you hold that altitude on the altimeter, that is what ATC will “see” even if your pressure setting is completely wrong.

This would not be the case in a real airplane with an independent altitude encoder.

The other option would be for VATSIM to use the sim variable “pressure altitude” at all times, (as they currently do above 18,000 feet) and apply the current barometric pressure at the aircraft’s current location to correct it to indicated altitude, which is exactly how it is done by real ATC.

There is a sim variable “Sea Level Pressure” which gives the current pressure at the aircraft’s location being injected by Live Weather which could be used for this purpose.

But this would require additional processing and modifications by Vatsim on their end beyond just switching from “plane” to “indicated” altitude, which they would be unlikely to want to do, and probably rightfully so. Plus, it would require that Vatsim and the MSFS be using the very same pressure reference, which is unlikely to be possible.

Perhaps I am overlooking something glaringly obvious, but maybe the best solution would be for Asobo to create a new sim variable specifically for use by online ATC networks like Vatsim or Pilot Edge that could perhaps be named “network altitude”

This variable would be current MSFS pressure altitude, corrected to indicated altitude by locally (within MSFS) applying the sim variable “sea level pressure” . This is what a real altimeter does when correctly set.

This new variable would exactly match what is shown on the altimeter as long as the altimeter is synced to current Live Weather pressure - otherwise Vatsim or Pilot Edge would see the airplane as being at the wrong altitude, just as a real ATC controller would.

In this way, an MSFS pilot could not “game the system” by simply flying at an assigned altitude (on the altimeter) while ignoring setting the correct pressure, which is a drawback of using the “indicated altitude” variable directly.

Once an aircraft is above the regional transition altitude and using 29.92 as a reference, then Vatsim could simply use the “pressure altitude” variable directly as (I think) they already do in that scenario, (as does real world ATC).

The other advantage would be that using the local sim variable “sea level pressure” to create the new derived “network altitude” variable would not require the online network and the MSFS airplane to use the exact same pressure reference.

This new variable would avoid the disparity between assigned and reported altitude on Vatsim that could result from using “plane altitude” since the recent upgrade of altimeter accuracy in MSFS.


My apologies. Though the conversation started about online networks, it then shifted to real ATC and in the part where you were referring to deliberately setting the wrong pressure to force ATC to see you at something other than the correct altitude, I mistakenly believed you thought that would be possible in a real ATC system.

A possible solution occurred to me which I detailed in the post that should be above this one.

1 Like

No worries. We now understand each other, and you’ve got some good ideas there. :slight_smile: