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

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.

2 Likes

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.

2 Likes

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)?

2 Likes

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

-Matt | Working Title

2 Likes

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.
L

2 Likes

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.)

@Bishop398

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.

2 Likes

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:

Wouldn’t it be possibly be to create a altimeter which shows the correct altitude. For example on a stream deck you an read the vars

I think if we learned something from this topic, then that there is no such thing as a “correct altitude”. :grinning: It’s all a matter of definition.

I’m still trying to get my head around all this. What I have not fully understood yet is: What exactly is real ATC using, when transforming the pressure altitude reported from the transponder when you are below transition altitude? Do they have the local (non-standard) pressure variations in their model (which are depending on your position in 3D, not only lateral position) when they convert your pressure altitude? This would be a bit strange because they would in the end try to emulate the error of the altimeter because of local pressure variance. Or is it the other way around: ATC will give you alitmeter settings that compensates for the error of local pressure variance? In this case, at least in theory, the given altimeter setting could be different depending on your altitude (or better, geometric position).

1 Like

Afik, they use one compensation pressure in their systems. But it is not that complicated as the area where this becomes relevant is not that big.

Simply put.

Center ATC cover the large areas, but everyone flies at Standard pressure anyhow, so all good.

Approach ATC (sometimes also subdivided in sectors) does not cover that large of an area that you would see significant differences in QNH. And even if, as long as everyone flies correctly relative to one another, all is safe (and the MSAs always have some buffer to avoid flight into terrain).

1 Like

Above transition altitude, everyone uses STD, but many GA piston and turboprop IFR flights may be conducted entirely below18,000 feet, (transition altitude in the US), so center controllers working low altitude sectors will have barometric compensation automatically applied to the Mode C returns of every aircraft target on the scope. Depending on the size of the sector, it will not be the same compensation for every aircraft.

Hi all, I’m the developer of vPilot for VATSIM, the MSFS/P3D/FSX client for PilotEdge, and a few of the ATC clients for VATSIM (VRC, vERAM, vSTARS). I’ve been discussing this issue with a handful of folks on various VATSIM discords, and I came across this thread when doing some searching. I finally managed to read through the whole thread and figured I should post some information about how things currently work and the various solutions that we’ve been discussing.

First, please note that anything I say about how the current online system works is specific to VATSIM. I am not talking about PilotEdge here … PE is a different animal and I’m sure PE will be addressing this issue appropriately for their network. The discussions I’ve been having recently have all been about VATSIM, and that’s what I’m going to detail here.

Second, I’m going to repeat much of what has already been said in this thread, because I think it’s good to have it all in one place as a summary.

As has been noted earlier in this thread, real ATC radar systems only receive pressure altitude from Mode C transponders. For aircraft below the transition layer, the radar system adjusts the pressure altitude using the sea level pressure (SLP) reading from a nearby weather reporting station. The real world radar systems that I’m familiar with have a grid overlying their airspace, and each cell in that grid corresponds to a weather reporting station from which the SLP will be used, when correcting the Mode C pressure altitude received from any aircraft within that grid cell.

The way it works currently on VATSIM is that pilot clients send two altitudes to the server. True altitude and pressure altitude. These altitudes are sent to both other pilots and to ATC. ATC clients display the pressure altitude in your data block if you are above the transition layer, and they display the true altitude in your data block if you are below the transition layer. The radar client is configured with the appropriate transition altitude for the airspace where the controller is working.

This has always worked just fine in the past because all sims prior to MSFS do not model non-standard pressure gradients in the atmosphere, so if you set the right altimeter setting in your plane, then the true altitude that is sent to the server is very close to (if not exactly equal to) the altitude that ATC would calculate based on your reported pressure altitude and the nearby SLP. This method, even though slightly unrealistic (because real world ATC does not have access to your true altitude) has a couple benefits: One is that the radar client software does not need to keep track of altimeter settings all over the controller’s airspace. The other is that the altitude shown in the data block will be correct even if the pilot is using weather that does not match the real-world weather that ATC uses.

Now MSFS comes on the scene with its more realistic altimetry model. It uses ambient air pressure at the aircraft’s location (including altitude) in order to simulate the pressure at the static pressure port, which feeds the altimeter. This is just like how a real altimeter works. This means that the true altitude read from the sim likely will not match the indicated altitude unless the ambient pressure outside the aircraft exactly matches what it would be in a standard atmosphere, which I gather is quite unlikely.

So with MSFS sending true altitude to VATSIM, and that true altitude does not match indicated altitude, you get the possibility of VATSIM ATC seeing an altitude in your data block that does not match what you as the pilot see on your altimeter.

Additionally, this means that pilots will not see each other at the right altitude. This is because pilot clients use the reported true altitude to render the 3D model for the aircraft within the sim. So you could have two aircraft, one from an older sim, say X-Plane, at 5,000 feet indicated, sending a true altitude of 5,000, and another aircraft from MSFS at 6,000 feet indicated, but sending a true altitude of say 5,300 feet due to non-standard ambient pressure. The MSFS pilot will see the XP pilot at 5,000 feet, which is correct. However, the XP pilot will see the MSFS pilot at 5,300 feet, which is “correct” in the sense that 5,300 feet is the true altitude of the MSFS pilot, but if both sims properly modeled altitude in the non-standard pressure area, the XP pilot’s true altitude would be closer to 4,300 feet and they would have the 1,000 feet of vertical separation that they think they have. Since XP does not simulate the non-standard pressure, the XP pilot will be flying at 5,000 feet and rendering the MSFS aircraft at 5,300 feet, with only 300 feet of separation when they should have 1,000. This could cause issues like a TCAS RA.

So it’s a multi-faceted problem that will need a solution that corrects the issue for ATC as well as the issue for rendering other aircraft in the sim.

To fix the ATC issue, we’ve considered just sending pressure altitude to radar clients, and using the closest sea-level pressure to correct the pressure altitude when showing the data block for an aircraft below the transition layer. The issue with that, to which I alluded above, is that if the pilot is using weather that doesn’t match the real-world weather that ATC uses, then the data block altitude will not agree with the pilot’s indicated altitude. We also thought about changing the true altitude that is sent to radar clients, and instead of sending true altitude, we would send the pressure altitude corrected for the SLP below the aircraft. This would essentially move the work from the radar client to the pilot client, and ensure that ATC sees the correct altitude even if the pilot is using non-real-world weather. The benefit of this approach is that it requires no changes to radar client software. The problem with this approach is that it “loses” data. The true altitude is no longer sent to the network, and thus pilot clients can’t use it to render other aircraft in the right location. In my example above, where the MSFS pilot is indicating 6,000 feet but flying at a true altitude of 5,300 feet, other pilot’s clients would render that aircraft at 6,000 feet, instead of 5,300 feet. (Which may actually be what we want, more on that later.)

(As a side note, as was suggested earlier in this thread, we also briefly considered sending indicated altitude to the network for both ATC and pilot clients to use, but decided against this because if the pilot doesn’t set their altimeter correctly, both ATC and other pilots will see the aircraft at an invalid altitude.)

So, we need a solution to allow pilot clients to render aircraft at the right true altitude, regardless of whether or not the aircraft is using a sim that models non-standard pressure like MSFS does. So far, the best solution we’ve come up with is to calculate a correction factor that MSFS pilot clients would use to adjust the altitude data received from other sims in order to derive a true altitude that is correct for the pressure conditions present in the MSFS simulator. This correction factor would be derived from the difference between the MSFS true altitude and the MSFS pressure altitude corrected for SLP below the aircraft. This correction factor would then be applied to the true altitude received from other non-MSFS pilots. We’re thinking that we would only do this if the other aircraft was within say 3,000 feet of the MSFS pilot. Outside that range, the correction factor will have more and more error, and the correction isn’t really needed outside that range anyway, since there’s no risk of TCAS RAs or anything like that. This correction factor would be “smoothed out” for aircraft near that 3,000 foot margin boundary, so that their altitude would not jump when they cross that boundary.

This leaves the question of what to do for non-MSFS sims rendering aircraft flown by an MSFS user. Such as in my earlier example where the MSFS pilot is flying at 5,300 feet true altitude and 6,000 feet indicated. The XP pilot is flying at 5,000 true and indicated. I think we would want XP to render the MSFS aircraft at 6,000 feet, so we need to send 6,000 across the network somehow. Probably the simplest thing would be to add a new altitude that is sent over the network, that being the pressure altitude corrected for local SLP. This new altitude value would be used by both ATC and non-MSFS sims to render the aircraft. This method would be future proofed for any new simulator that comes on the scene, or if XP or P3D start using a more accurate pressure model.

I think that about covers it. If anyone sees any problems with this proposed solution, please let me know.

-Ross

45 Likes

Ross,
Thanks for the amazing reply! You did a great job of explaining how all the variables are working together. It’s great to have you apart of this thread now to provide that insight and hopefully with everything we’ve covered we can now implement one of those solutions.

@Bishop398 @Jummivana

3 Likes

Yep, Ross, myself, and a few other folks have been discussing strategies. :slight_smile:

I think he’s pretty well covered everything that we’ve tossed back and forth. It’s always, truly, super awesome to get to chat directly with the folks involved, and much thanks to @CByworth for inviting me to the party.

MSFS is doing a bit of a first here in flight simulation with correct granular pressure data, so there are definitely some teething issues to be expected. But obviously there are super talented and smart folks on the VATSIM side (and I’m sure other online ATC too) and it’s a pleasure getting to work with them.

-Matt | Working Title

8 Likes