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

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

34 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

It has likewise been a pleasure working with you and the Asobo devs!

-Ross

4 Likes

Outstanding information! Thank you very much for taking the time to explain the current protocols and how they are used by the network and pilot clients.

This looks like an excellent solution. The only question I have, not knowing the update rate of the variables and calculations within VATSIM, is that I assume you all considered airplanes with high closure rates (high descent rate for the airplane above and high climb rate for the airplane below) when setting the 3,000 foot boundary such that there wouldn’t be too much jumping around of these airplanes’ relative vertical positioning or if that could even be an issue?

That’s a good thought, but the position updates every 5 seconds so I don’t think it’ll be an issue. We can increase the 3,000 foot threshold if needed.

2 Likes

Great. Thank you so much.

Out of interest how does Velocity fit into this as I thought (although I might be completely wrong) that Velocity would mean that the updates would have to be a lot more frequent?

5s update speed should not be a problem. IMHO. Do the math with the usual expected GS. Everything under ca 750 kts moves less than a mile in those 5s.

See separation requirements and ATC accuracy here for example.
https://www.skybrary.aero/index.php/Separation_Standards

Ross, fantastic post that I will read several times to fully understand! :grinning: Thank you so much for posting this.

The one potential drawback I foresee with using an altitude variable based on aircraft’s own sensed pressure altitude correct by SLP, would be if the SLP suddenly changes, the aircraft transmitted altitude will jump up or down. Those of us who fly with Live Weather on a regular basis have probably all seen sudden pressure shifts that result in an (often) 100-300 foot change in indicated altitude.

My understanding from the original MeteoBlue partnership video is that the MeteoBlue weather model atmospheric emulation is subdivided into discrete “cells” both horizontally and vertically. I suspect a pressure shift (when in occurs) happens when transitioning across a cell boundary.

Usually, when a pressure shift occurs in Live Weather, if the autopilot is in altitude hold mode, the aircraft will slowly “work its way back” to the selected altitude without further action on the part of the pilot.

I have not monitored the simvars when such a pressure shift occurs to see which variable is actually changing. I suspect it is “ambient pressure” But it might also involve a change in the simvar “sea level pressure”

A couple of questions for Matt @Bishop398 . If this is “proprietary” and you cannot give a definitive answer, I completely understand.

  1. Last year, real-time METARs were added to Live Weather for airport pressure, wind speed and direction, and temperature. Is there a specific AGL altitude where the injected variables transition between METAR and MeteoBlue for those values? In flying with Live Weather while conducting approaches, as near as I can determine, wind speed and direction appear to transition to the METAR values at about 1000-1500 feet AGL, but I am not certain. Not sure about the transition between METAR and MB pressure or temperature - or if there is a specific radius around the airport for the transition.

  2. When flying at higher altitudes, where the MB model is the sole source of injected weather, is the simvar “sea level pressure” coming from the closest airport METAR, or from the MB model prediction of what the SLP “should” be?

Obviously when flying over the ocean, or in a remote area far from any airport, I assume the SLP simvar would come from the MB model regardless of altitude.

Real TCAS systems calculate vertical position offset between “own” and “other” aircraft targets by using the transmitted pressure altitude of each target aircraft’s mode S transponder, and comparing those values to “own” pressure altitude.

I don’t think Velocity will change anything. Updates will be much more frequent, but I don’t see how that would affect anything that’s being discussed here.

1 Like

I don’t think there’s anything we can do about that. It would be nice if the sim smoothed the ambient pressure data from cell to cell so you don’t get those unrealistic sudden shifts in indicated altitude. It’s like bad wind shear at every cell boundary. :smiley:

I think the only way we could avoid that being an issue is if we used only true altitude for everything, and that’s not good at all for ATC, and has the separation issues I mentioned above for pilot-to-pilot interaction.

1 Like

Since the autopilot in most default aircraft does (slowly) correct back to the selected altitude after a pressure shift, any related variables would change in any case - indicated, pressure and true altitudes, and any “new” variables derived from those. So, as you said, there is probably not much that can be done. The beauty of VATSIM is that it supports pilots flying on multiple sim platforms, but the drawback is the difference in how individual sims calculate air data, and differences in real-time weather data.

I know that improvements to Live Weather are on the roadmap for future MSFS development, so perhaps more stability in pressure will be part of that. Before the “high temperature” bug that arose recently, my experience with Live Weather upper level winds and temperatures is that they tend to be quite stable in general, and usually match closely to other weather models such as the GFS. It is mainly pressure that tends to be “twitchy” on occasion.