Standard Pressure altimeter incorrect

I am being told off by ATC on every flight on vatsim (using vpilot). Yesterday I was at FL330 but ATC said I was shown at FL337. That’s a difference of 700ft / 30 = 23 of pressure so I am effectively using 1036 instead of 1013

This issue is only happening at Standard Pressue (QNE), I have not had an issue alerted to me with QNH

I’m using prosim 737 with MSFS

Log:-

2023-03-20 14:09:25.039 -03:00 [INF] vPilot version 3.5.1 starting up
2023-03-20 14:09:25.054 -03:00 [INF] Running in "Host" mode
2023-03-20 14:09:26.507 -03:00 [INF] Downloaded 1 servers
2023-03-20 14:09:30.178 -03:00 [INF] Validating "Msfs"
2023-03-20 14:09:31.523 -03:00 [INF] Custom model matching rules loaded.
2023-03-20 14:09:31.531 -03:00 [INF] Model matching rules generated.
2023-03-20 14:09:31.535 -03:00 [INF] "FbwVpilotActive" value changed: false
2023-03-20 14:10:11.879 -03:00 [ERR] Error fetching automatic server address via HTTP
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 159.65.171.192:80
   at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at dq.f.a()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at e4.a.a()
2023-03-20 14:10:12.544 -03:00 [INF] Connecting to network
2023-03-20 14:10:12.995 -03:00 [INF] Connected to network
2023-03-20 16:21:55.105 -03:00 [ERR] Network error: The server has failed to respond to the authentication challenge.
2023-03-20 16:21:55.106 -03:00 [ERR] Disconnected from network

I think this is an issue of Prosim. I think there are some discussions about it on the forums run by Prosim.

It’s the way MSFS reports altitude.

Yes and the same is true for X-Plane 12: they are reporting “true altitude”, corrected for pressure and temperature. vpilot, xpilot and swift pilot client have all been modified to report the “correct” altitude to the VATSIM servers.
Apparently, something’s going on with Prosim.

It’s kinda odd because I only get this issue when I’m on standard pressure (1013) which doesn’t use true temp and pressure, so unsure why real temp and pressure would cause this issue

When I’m on QNH I don’t have an issue (I have never been alerted by ATC)

Temperature always has an impact no matter what the altimeter setting is. The isobaric line of 1013 hPa does not sit static at a certain height, because even if the local QNH remains the same, a significantly higher or lower temperature will make isobaric line descend or climb.

Temperature will change your REAL altitude, yes, but it won’t change your pressure altitude (ie your flight level with 1013), because pressure altitude is based on ISA conditions, which are based on a fixed temerature at sea level and a fixed pressure gradient as you climb.

Maybe the MSFS sea level changes

Yes, as long as the pressure altitude for all planes in the area is the same at 1013 hPa. Come in the temperature and you got someone flying higher or lower, depending on the simulator (correction or no correction calculated).

Effect_of_OAT_on_indicated_altitude

Yes, but you are rererring to True Altitude, which will change, I’m referring to Pressure Altitude which should not. That’s why it is used for flight levels.

ATC have me at a wrong Presure Altitude (flight level) which is not based on real temperature changes, etc, it is based on fixed temperatures and fixed pressure changes

So if all these values at Pressure Altitude don’t change, everyone on 1013 should be at the same altitude

EDIT - looking at Roger’s post above, it seems it is a bug in MSFS which is not calculating Pressure Altitude for flight levels, but True Altitude, which is clearly wrong as it is not what happens in real life

Pressure altitude also changes with temperature.

Pressure altitude also changes with temperature.

This is incorrect. Presssure Altitude does not change, it is based on fixed ISA values for temperature (15 c at sea level) and a standard temperature reduction of 2c every 1000 ft above sea level.

You may be confusing this with your True Altitude or Density Altitude, which will change if temperature and pressure are different from the ISA values.

The reason we all fly at Flight Level (pressure altitude) is precisely so that everyone is theoretically at the same altitude if they are close by each other, and there doesn’t need to be a constant recalculation of altitude based on temperature and pressure changes (which would be the case if we all flew at QNH or if Pressure Altitude changed with temperature)

Yes, we know this. But it does not mean that the PA is always the same. Of course, all planes that are flying at a vertical difference of 1,000ft, while all of them use the same altimeter setting, will keep their approximate minimum separation of 1,000ft. When it is extremely cold, those 1,000ft will shrink, though, because 1,000ft indicated difference will not match the true distance between the isobaric lines.

But it does not mean that the PA is always the same

Yes it does with respect :grinning:, what you are referring to again is True Altitude

Maybe an example will clear this up:

You have to airplanes, one is over London and one is over Paris, both are at FL 250 (Pressure Altitude).

But in London it is 5 degs colder, so the True Altitude of the London plane is lower than the True Altitude of the Paris plane.

But both are at the same Pressure Altitude.

It is this Pressure Altitude that ATC will see, not True Altitude.

Yes but until now no sim really simulated those temperature differences, now some sims do and others not. Some sims send true altitude and some send pressure aotitude to vatsim

This has been fixed on the vatsim client side but something within prosim must be messing up that fix would be my guess

Yes, something at prosim needs to be changed

It is important to note here that true altitude IS very important for VATSIM - because you need to see other traffic at thier TRUE altitude and not just the altitude they are seeing on their altimeter, or even their (local) pressure altitude. Likewise, ATC separation relies on TRUE altitudes being correct. If you simply report pressure altitude then whilst this may appear to fix the problem in the flight levels, ATC would then see incorrect levels when local pressure is being utilised, or aircraft would move up and down depending on their altimeter setting…

The differing approaches to altimetry across the breadth of supported simulators makes this a difficult challenge to solve. It is not as simple as just reporting pressure altitude to the ATC client, because if you have one user at FL350 in a sim which simulates temperature error and another user in the opposite direction at FL340 in a sim which does not, ATC might see both aircraft at the ‘correct’ level but in the sim there may be no separation at all because the true altitudes may be identical even though each is at the correct pressure altitude…

1 Like

Let’s focus on above Transition Altitude/Level, ie at Pressure Altitude or Flight Levels. Below that it is undisputed that everyone needs to set local QNH.

What happens in real life above Transition Altitude/Level? Does ATC separate based on calculating True Altitude for all planes or based on Pressure Altitude?

If we have that answer then hopefully Vatsim is doing as in real life.

Well it is not just atc calculations, true altitude is required so on tcas or visually you see others at the correct altitude, because there it is definitely true altitude

The issue is that this is a VATSIM-specific problem which is not relevant in real life, because in real life everybody is flying in identical atmospheric conditions and everybody’s equipment is, by virtue of physics, subject to the same inherent errors. The exact problem is that there IS no easy parallel to draw.

In real life, a transponder reports ONLY pressure altitude (entirely independently of the altimeter). It has no knowledge of the ambient pressure, temperature, TA/TL or what is set in the Kollsman window on the altimeter by the pilot.

The ATC radar system, however, does know both the relevant TA/TL and the local QNH. Thus below TA, in real life, the ATC system converts the pressure altitude received from the aircraft’s transponder to a QNH-corrected altitude for display on the controller’s screen. Above TA the reported pressure altitude is used.

There is no need for the controller (or pilots) to especially consider “true altitude” for separation purposes IRL because the nature of the system is that everybody will have the same error (if they are on the correct pressure setting, whether that is QNH below TA or SPS above).

As I mentioned, this is NOT the case in our world because different sims apply different (or no) altimetry errors. There are therefore fundamental incompatibilities which mean that two aircraft on VATSIM, both with the same real-world weather applied and with the same altimeter setting (let’s say Standard Pressure for the sake of ease) can be at two different TRUE altitudes because one has a temperature error simulated and the other does not.