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