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! 
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.
-
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.
-
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. 
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.
Will the altitude indicator in Volanta show correctly once this issue gets fixed? I’m currently getting about 2-3000 feet above my PFD altitude indicator on their tracker.
Meteoblue model is continuous and should pass it that way to MFS.
Transitions aren’t abrupt, but rather, smooth.
Now, it all depends on how the assimilation of the data is made inside of MFS.
Regarding the way Geopotential Height is being calculated ( if that’s what’s being used ) in MFS, I assume it is fed under “Live Weather” by Meteoblue.
For non “Live” I honestly think MFS should probably stick to ISA pressure gradient with altitude.
If the VATSIM clients have access to the geopotential height internal variable - must be used somewhere within MFS, so I hope there’s some variable associated - then it would be very simple to determine, using even linear interpolation, a true altitude.
Unless Asobo is using a mnemonic approach, which would be a not so good idea…
I would really be surprised (but pleasantly) if MSFS uses geopotential altitude. There is no simulation variable for it in the SDK. Not much accuracy is lost by neglecting it. It’s usually (or at least used to be) neglected in performance calculations anyway.
My understanding (based on what Matt has said) is that for non-live weather, the ISA pressure gradient is indeed what is being used.
I think ASOBO should make clear how they’re applying reflecting Temperature in the pressure gradient with altitude.
If they’re using something like 
or if they’re simply getting the model geopotential height from Mateoblue’s feed.
If the formulas described in the link above are used then they could be used by the VATSIM clients to “normalize” the true altitudes between simulation platforms.
OTH, using QFF, with one of the calculation methods, would also normalize the data among simulators:
https://www.metpod.co.uk/calculators/pressure/
or… why not using a flag to announce a client is or is not “T-aware”. This way when a client receives data from another “T-aware” client it simply proceedes, depending on itself being T-aware, with the positioning of the aircraft in it’s World at the same geodetical height OR in case they differ, at it’s local consistent geodetical height.
This all assumes consistent sources of weather data, such as T, QNH and area QNH among cliens, and also the same Geoid model ( WGS84 usually ).
1 Like
I just found out that the altitude on the HUD in slew mode shows something different than the indicated altitude of the aircraft (when releasing slew mode), I don’t know if this is a conscious design choice or a bug?
Slew mode seems to default the air mass to ISA.
Exactly, maybe this is done on purpose? I would prefer indicated altitude, think it would be more useful. I tried to test the temperature effect low to the ground, seems ok for temperature above ISA, for temperature below ISA guess we need to wait until it gets colder, couldn’t find sufficiently cold place other than Antarctica 
.
You can try Alert (CYLT), it should be around -2C/ ISA-17 right now.