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

What you are saying is relevant regarding true versus indicated altitude. Problem is that the pressure altitude when setting 29.92 is still off apparently which is purely an ambient pressure versus altitude reading relationship, actual pressure and temperature only come into the equation when talking about true altitude.

2 Likes

Hey @AGuther, good to see you here. Just to bring you up to date, it’s the pressure altitude that is at variance here. The indicated altitude, with baro set to STD, is the pressure altitude except for the inaccuracies I noted above. Matt found legacy coding for the pressure altitude that was reporting incorrect values. As I understand what Matt is saying, this will be fixed to match the indicated altitudes, and both will be fixed for non-standard pressure (could be wrong about that part, though), but I hope both will also be massaged a bit more as I’ve suggested above.

I agree that as it stands right now with the current production build, the non-standard pressure corrections are not done correctly and there are some inaccuracies in the standard pressure vs altitude relationship.

Hello,

to give an example, standing right now in GCXO:

Ambient Pressure (sim)   =  946.915 mbar
Pressure Altitude (sim)  = 1872.16  ft
Indicated Altitude (STD) = 1947.55  ft
Pressure Altitude (calc) = 1861.64  ft

The calculation was done using the formula from @AwarePlot117729, the code as follows in C++:

double calculateAltitudeFromPressure(
    double pressure,
    double altimeterReferencePressure,
    double defaultPressure
) {
  // calculate pressure ratio
  double pressureRatio = pressure / defaultPressure;

  // calculate pressure altitude
  double pressureAltitude = 145442.15 * (1 - pow(pressureRatio, 0.190263));

  // if altitude is higher than tropopause correct pressure altitude
  if (pressureAltitude > 36089.24) {
    pressureAltitude = 36089.24 - 20805.8 * log(4.47706 * pressureRatio);
  }

  // calculate altimeter correction
  return pressureAltitude - 145442.15 * (1 - pow(altimeterReferencePressure / defaultPressure, 0.190263));
}

The function was called like this:

calculateAltitudeFromPressure(simData.ambientPressure, 1013.25, 1013.25)

Another important thing that I’ve observed is that it seems pressure smoothing is only applied to indicated altitude and not to pressure altitude.

Best,
Andreas

1 Like

When flying with STD pressure set on the altimeter, one would expect the simvars for indicated and pressure altitude to be very close, and at the moment they are very far apart. Of course, the question could then be asked: “which value is in error - indicated or pressure altitude”? From all I have seen, indicated altitude appears to be OK.

I did a flight yesterday at FL340 in the CRJ while monitoring all of the altitude and pressure simvars. The simvar for pressure altitude was tracking very close to “plane altitude” which is true geometric altitude, and that definitely seems to point to an error in the pressure altitude calculation. Both plane and pressure altitude were showing about 1200 feet above indicated. They were not exactly the same - but close.

That would be correct for “plane altitude”. At high altitude when temperatures are ISA+ true geometric altitude can be significantly higher than indicated - but pressure altitude should always track close to indicated.

I was using Live Weather, and at the time (mid-afternoon Saturday), the extreme high temperature bug was not in evidence - (but I have read other reports today that the problem is back). The Live Weather injected temperature at the time was ISA +12 which was a close match to the NOAA GFS forecast for that altitude and location.

I later did a flight between 7000 and 15000 feet (again using Live Weather) with the altimeter set to 29.92. I leveled off every 1000 feet, and compared the simvar for pressure altitude to the displayed indicated altitude and pressure altitude was significantly higher. Not a perfect match to “plane altitude” but close.

I then took the simvar for “ambient pressure” and ran it through an online calculator at weather.gov that uses the same formula for calculating pressure altitude as the one @AwarePlot117729 posted above, and it was a very close match to the indicated altimeter altitude (within 25 feet) at each test point between 7000 and 15000 feet. All that leads me to believe that indicated altitude is OK and the error is in the pressure altitude sim var.

Just out of curiousity, I did a test this morning where I took off from JFK and flew out over the ocean. I used the clear sky (ISA standard) preset while comparing indicated altitude to the radar altimeter altitude, and they were an exact match until 2500 feet MSL which is the upper limit for the radar altimeter. This again leads me to think that the indicated altitude simvar is working correctly.

When flying over the ocean, a radar altimeter is a also a direct indication of true altitude - but limited to a maximum altitude of 2500 feet in the civilian aviation world. When I started my avionics career in the USAF in 1974, the C-141 transport had a Doppler nav system that could give radar altitude all the way up to 40,000 feet!

1 Like

apologies for the redundant question but if using a preset weather option instead of live weather does the problem with altitude reporting still exist on vatsim?

I believe it will work correctly on Vatsim if you use the clear sky preset, and keep your altimeter set to 29.92

Maybe one more input to the temp bug. It is not only the temp but also wind and it appears as if there is a discontinuity in the weather data.

Test flight: EDDF/CINDY3S RWY18 - DKB (VOR) - EDDM (RNAV ROKIL, ILS08L).
I flew that flight twice back to back today (around 13:40 UTC).

TempBug:
Between CINDY and DKB you see within 1 minute (UTC13:47 to 13:48) the temp going from plausible -27degC at FL230 (yes I know, I forgot to switch to QNH1013) to +14degC (yes this is the already known temp bug, with the respective jump in IAS).

WindBug:
Also you see the wind go from a plausible 34kts/212deg to 1kts/112deg. The transition is felt as if there was clear air turbulence but I think the wind data is also faulty. It also appeared twice at the same position ca. 30nm before DKB and it jumped back to plausible around DKB (VOR).

Looks like there is a discontinuity in the weather data causing both temp and wind data to be faulty. Hope it helps, unless you guys already figured it out too…

Thanks btw. for the great G3000 mod.

Plausible

Bad/Not plausible

1 Like

I have also noticed that when the temperature bug hits, there is usually also an accompanying wind shift. I know that in the MeteoBlue partnership video last year, they said that they divide up the atmosphere into individual discrete “cells” both horizontally and vertically. I wonder if individual cells have corrupt data?

I am going to fly later today going up to FL350 looking for the temperature/wind bug. When it happens, I am going to do a 180 degree turn to reverse course to see if the readings go back to normal when I retrace my route in the opposite direction.

MSFS “old timers” will remember that the original release version of the sim had a Live Weather bug where the winds aloft simply did not work (at all) when flying over the US. The wind was always 253 degrees at 3 knots. There was a small area in Southern Florida where the winds aloft would work fine. The dividing line was just north of Key West. At that time you could fly S turns across the dividing line and watch the upper winds appear and disappear. As I recall they did not fix that bug until SU1 or maybe even SU2…

1 Like

One observation that I also made is that also tools like Volanta etc. need to check if they are using the right variables. Volanta for example uses variable PLANE ALTITUDE to show altitude. Which is in general fine, but it should be clear that it cannot be taken as flight level information.

I’m not sure what VATSIM etc. are using, if they are using the same, it’s also a problem on their end, even if in MSFS the altitudes are fixed and correct.

This altimeter smoothing is also a pain in the behind. I tried one of the flight lessons, the exercise starts in the air at 6000 ft, the altimeter starts at 5000 ft or so and slowly catches-up to 6000 ft, it takes minutes for the altimeter to stabilize. Same is true on the ground when changing QNH in the weather menu, not sure if this is such a useful feature. An altimeter is not that slow in responding to pressure changes, also not instantaneous of course but they could easily increase the rate by a factor of 10.

2 Likes

Can you start a new thread for that? Sounds like a separate issue, that shouldn’t get lost in a big thread like this!

I think it is related, it was implemented together with all the other altimeter trouble last update.

Well, a lot of stuff happened in the same update because they wait months between updates. :slight_smile: I hope you don’t get forgotten. Good luck!

I saw that, too, when I jumped into a flight in air by setting a custom departure point in the world map(to test something out). Not sure where it started but it definitely decreased for some time so could very well be that it always starts at 5000? VSI also showed a decent. I was very confused in the beginning…

Edit: I would like to add that I experienced the issue in the DA40 TDI. Could it be that only stream gauges are affected ( flight lessons are in the c152). I started in air with the c172 g1000 and do not remember seeing the issue, but I’m not sure, have to double check…

Thats a good point, I believe I saw the same thing. I’ll double check!

First flight yesterday with the update and I wanted to join a big VATSIM summer event at BHX yet couldn’t because I couldn’t trust the sim to work properly…

…so did a Doha to Jeddah on unicom. Viewers in the live chat were looking at vatspy as we were talking about it and throughout the flight my altitude went from -1000ft on vatspy compared to my altitude in sim and then randomly went to +2000ft above the altitude I was at in the sim

Really disappointed - the Hotfix was supposed to go some way to fix it and it hasn’t. VATSIM is supposed to be an official partner too and they need to pull a fix out of the bag too - but if all other Sims don’t use the same values, how can they fix it for us? They can’t - without shutting out every other simmer.

Urgently need a fix for this - I, along with plenty of my viewers who also fly along with me whilst live, and some of you here use Vatsim only so it does significantly impact our enjoyment of the sim post-update.

Hotfix for a Hotfix :eyes: perhaps updates shouldn’t come until proven to be stable and working well with no major bugs…

7 Likes

I dont want to fuel such destructive posts but, common. In this thread we stopped the negativity already 2 days ago and now its time to provide constructive input. Bug is acknowledged, explained and confirmed to be locked at, now its time to move on. There are enough other threads to went the frustration. This is not the one anymore. :slight_smile:

2 Likes

I think like many things, until there is more of an official answer in regards to an expected ETA, folks will continue to vent. Not the best thing, but it’s just the reality for a lot of what we see and read on here.

4 Likes

100 percent agree. It is and was in Asobos hands to manage expectations by their communication ie release notes, their press releases, interviews… etc.

Even when they messed up they could have communicated in a way to stem the frustration which vents itself in the negativity in forums like this.

So far I have not seen such communication from Asobo (… only Matt from WT said sth about it, but this is not his job to apologize/ acknowledge on behalf of Asobo. As he did it anyway, speaks for him and the WT team).

I d be happy to be proven wrong or misinformed as I try to keep up with messages.

2 Likes

Folks, please don’t pit us against Asobo in the court of public opinion. We’re all the same team. If I’m saying something, consider that we’re all saying it.

We’re looking at it; it’s a fairly complex issue, both in the code and logistically. We’ve implemented a fix so that takes care of the former, but given that it’s such a core system, it also obviously represents additional regression risk, which is where the logistical complexity comes in. When I have more information on when it can expect to land, I’ll happily let everyone know.

-Matt | Working Title

14 Likes