It’s a very common misconception that it’s possible to read the latest METAR file for real weather and then expect to see X-Plane report exactly those numbers in ATIS and other weather reporting tools.
This is completely wrong.
The sim’s weather is made up of many more datasources than a single METAR entry. Some of those are downloaded data, some are determined by the sim’s code which is under near-continual revision. There is a certain amount of randomness involved too. Looking at a single METAR is maybe 10% of the puzzle, and often much less than that.
How the weather data is blended
The weather is always in transition between two states; one “before”, one “after”. When it reaches the “after” state, “after” becomes “before” and a new “after” state, already prepared and waiting, is used. Each state is made up from forecast data (GRIB), past data (METAR), and in many places it’s affected by varying levels of randomness.
Very briefly, the background weather for the world is populated from the GRIB – forecast – data. This gives fairly coarse coverage, but it is a global dataset. After that, point weather samples such as METARs are overlaid. As the distance from the sample point – for a METAR, typically the airport’s center – increases, it has a decreasing effect until it eventually gets to the point where it has no effect whatsoever. This is one place where a small amount of randomness is used, to prevent these point data sources from appearing as neat cylinders of different conditions.
The strength of a point source is also reduced in line with its age. If a METAR is only a few minutes old, it will have maximum effect. As it gets older, it has decreasing effect until eventually it has no effect at all. Would you expect to read a weather report from six hours ago and go outside to find an exact, to-the-digit match for temperature, dewpoint, wind speed and direction etc.? Of course not.
> 💡 METARs are inherently outdated. They do not represent “what the weather is now”. They represent “what the weather was at some point in the past”.
Finally, we need to consider other point sources nearby. It’s very common to find airports close enough to each other for their METARs to overlap, even in some cases right at the airport’s centerpoint. Where two or more point sources overlap their blend becomes much more complicated because, for any given point near those airports, the resulting blend will be based on each source’s location, age, type (AUTO reports have a smaller radius of effect), and the random noise applied to each one.
How the weather data is sampled
To determine what the weather conditions are at any given time at any given point on the Earth, we need two states; one before, one after. The current time determines the proportions of each state, and a third final state is generated based on that proportion and the exact location of the sample. Only now is it possible to say “the visibility right here, right now, is X miles”.
Trivial Case
In the very simplest case for real weather, we would have a single isolated airport and the sample point would be on that airport. The center of each point reading is prioritised for some distance so in theory, the METAR would be applied at full strength for far enough out to give consistent results for even the largest airports. Therefore, the numbers reported in the sim should exactly match the latest METAR, right?
Wrong. Remember there are two states in time, and the resulting conditions will be somewhere between the two. If the previous METAR had different conditions, the result will not be exactly what the current METAR states.
In the even simpler (and unlikely) case where both the previous and current METARs have the same numbers, now we should be seeing those exact numbers, right?
Wrong. Or, at least, probably wrong. The age of the METAR is taken into account when it’s being blended over the background GRIB data. If one or both of the METARs are old then they will have less effect even at the center, so the background data will start to become more visible; the numbers you get will be partly from the METAR and partly from the forecast. If both METARs are so old as to be useless, even though they’re the latest in the downloaded files and you’re right in the middle of the airport, they will have no effect whatsoever.
> 💡 It is not possible, even in the simplest possible case, to determine what the exact weather conditions will be by reading a single METAR.
Trivial Case, off-airport
Continuing from the previous example, but sampling off-airport, the situation is more complex. Outside the central region around its location, a METAR’s effects fade away over a certain distance in a semi-random manner. This randomness is different for each airport, and for each launch of the sim (apart from special testing scenarios). If you sample the conditions inside this blend zone, the exact results will change with all the previous things (time, age of both past and current METARs) plus your exact location. If you sample 100 meters away, the noise pattern will be different and the background (GRIB) weather reading that’s being blended with will be different; this is also smoothed and blended in a semi-random way otherwise there would be harsh straight edges between 1 degree or 1/4 degree boundaries.
Complex, realistic case
For many major airports, these trivial scenarios are not relevant because there will be other airports close enough that their respective areas of influence overlap. In this situation, each airport will have two different METARs with two different ages. Each will have a different noise pattern affecting how strongly it should be applied to the background weather, and relative to each other nearby airport. Each may have a different radius of effect. The exact blend pattern resulting from these overlaps is highly variable and the code for producing these changes regularly. Even though we try to keep the areas close to the METAR’s center being blended at full strength, “full strength” may be almost nothing – or nothing at all – for an old METAR.
> 💡 Even at the center of an airport with an old, AUTO reading it is perfectly possible, and intentional, for an up-to-date non-AUTO reading from a nearby airport to affect the resulting conditions.
What do I really need to say that the sim’s weather at a given point is a bug?
To work out exactly what the weather conditions are likely to be for a given point, you need all the following information:
- The “before” METAR for this airport (for the conditions)
- The “after” METAR for this airport (for the conditions)
- Whether the METARs are AUTO or manual readings (to give the radius of effect)
- The exact current time (to work out how old the before and after METARs are, and therefore their maximum level of effect)
- All of the above information for all airports within around 20 miles
- The “before” background GRIB data for this airport, which will be a blend of nearby GRIB samples
- The “after” background GRIB data for this airport, which will be a blend of nearby GRIB samples
- The exact current time again (to work out what proportions of the before and after states are in use)
Only after evaluating all of this information to work out how strongly each METAR will affect the conditions at your exact location, taking into account their types, ages, distances and relative positions, and then applying that mix to the much simpler background weather conditions, is it possible to say whether a specific weather value at a specific point is broadly correct or not.
I still think it’s a bug!
Okay. The next step is to file a bug with a weather dump. This gives us a way to reproduce the exact conditions, including all data and randomness, and evaluate precisely what the conditions should be at any given point.
There are several places in X-Plane where information about weather are available. This tech note describes each of them and how they relate to each other. Different sources are highly likely to return different information, by design. Weather conditions at any given point will be different to the weather at any other point, in both location and time.
The Weather Configuration
While this is not really a source of weather information, it does have an impact on the weather. When set to 'static weather' mode, very specific conditions may be set. These conditions are applied when you start your flight as a starting point. The simulator's weather system will then, from this starting point, add more details specifically including a small amount of randomness which changes across both time and distance from your starting airport. Any weather information found from any of the simulator's other systems should be expected to be similar to, but not an exact match for, static weather.
The Map Window
It is possible to use the map to get basic weather information about an airport, by clicking on the airport's icon to show the 'Airport Details' popout. On the 'Details' tab, an item labelled "Conditions", or "Current Conditions" in 12.1.0b5 and higher, shows the weather at the clicked airport at the exact time the popout was opened. The displayed information does not change after the popout has opened, so will become stale. Although the text given is similar to an ATIS message, it is not ATIS; it has no rounding, corrections or unit adjustment applied.
ATIS Transmissions
Many airports will offer an ATIS radio service. This is accessed using your aircraft's radio. The conditions given are those that were present at the time and location of recording of the ATIS message, and that recording will have a validity of either 30 or 60 minutes. Therefore, you should expect ATIS messages to differ from current conditions to some extent especially towards the end of their validity period. If conditions change significantly, a 'special ATIS' message will be issued and the ATIS identifier will be changed. ATIS frequencies are listed in the ATC dialog and on the map.
AWOS Transmissions
Similar to ATIS, AWOS messages differ in that they are fully automated messages based on conditions at the time and location of transmission. They are differentiated from ATIS messages by the absence of an ATIS identifier, and the prefix "AUTOMATED WEATHER OBSERVATION".
The simulator provides AWOS services for untowered airports and ATIS for towered airports, where the airport is defined as having an automated weather service. Both ATIS and AWOS services have rounding applied to wind direction and will use local temperature- and elevation-corrected pressure units, and regional units and phrasing.
At airports with a tower but no ATIS service, you can request departure information from ATC before you request taxi. This provides the weather conditions at the exact time of the radio response, at the airport's reference point.
"Request Weather" ATC call
While you are in contact with any controller that is based at a specific airport, including regional controllers, you may request current weather at their location. This provides the weather conditions at the exact time of the radio response, at the airport's reference point.
"Request Weather At…" ATC call
While you are flying a planned (IFR) route under ATC control, or if you are receiving flight following and have programmed named waypoints into your FMS, you may request weather conditions along your route from most ATC controllers. This provides the weather conditions at the location of the navaid, at the exact time of the radio response.
Pressure in some ATC messages
Many ATC responses from controllers will include QNH settings. For airport-type controllers (clearance, ground and tower), this pressure will be valid at the time of the call at the exact location of the airport. For regional or tracon/approach controllers, the pressure given will be the single pressure value used for the controller's entire airspace. Currently airspace segments are not simulated. A regional controller, especially a large one, is likely to give you a different QNH value to the one given by an airport.
"/sim/weather/aircraft/" Datarefs
These provide an instantaneous readout of the exact conditions at your aircraft's location.
"/sim/weather/region/" Datarefs
These provide an instantaneous readout of the base conditions for the region surrounding your aircraft; at the time of writing this is approximately one square degree. These conditions will not match conditions at any specific point within that region, since the weather at any given point is also based upon local information where possible (i.e. METAR data), and is further affected by the weather simulation's inherent random variation.
These are snapshots of the current weather at an airport at a particular time in the past, used as a data source by X-Plane's 'Real Weather' mode. While many are updated hourly or more, others may not be updated for significant periods of time. They are inherently data reflecting a time in the past.
To produce X-Plane's weather in 'Real Weather' mode, these are blended with another datasource which is based on a forecast of regional weather in the near future. This blending of point samples from the past with a generalised regional forecast for the future, plus the small amount of randomness layered onto the results, means that the simulator's weather should be similar to actual conditions but will rarely if ever be an exact match with any other source of weather information.
External Websites
External sources should never be used for obtaining weather conditions in the simulator, even when flying in 'Real Weather' mode. They are highly unlikely to match due to the random elements to X-Plane's weather simulation, different data sources, and differences in the way that the various data-sources are processed.
Weather Datarefs in X-Plane 12
The old weather datarefs have been marked as deprecated in X-Plane 12 and replaced with two new sets. The old ones will remain in place but anything referencing them should be changed to use the new ones as soon as possible. The good news is that this should be fairly straightforward.
Previously the values returned in the datarefs were relative to the user's aircraft. This was fine for handling instrumentation but not ideal for working with the wider environment. There are now two similar sets of datarefs, one for the weather at the aircraft's exact position, and one for the surrounding region.
Aircraft
In general, all the old datarefs that lived under sim/aircraft/ have been moved under sim/weather/aircraft/ with very similar names. The only real thing to note here is that in some cases, units have changed. Also, all these aircraft-specific datarefs are read-only. This makes sense; the aircraft's immediate environment is a point sample from the regional weather.
Cloud, wind and turbulence datarefs are no longer represented by individual datarefs with an array-like notation, they are handled as real arrays. This means you should do proper array handling of these by querying the size of the array using XPLMGetDatavf() before your first read, and allocating enough space accordingly. Doing this will allow your code to continue to work with no changes if in the future the array size is changed. Temperature and wind arrays have already been increased to 13 elements from 3.
It's important to remember that the aircraft's immediate environment is a snapshot of a single point in a simulated 3D volume. This volume contains deliberate variations from whatever the base weather is, whether that's a fixed preset coming from the UI or a composite of available real-weather data if this is enabled. You should not, in other words, expect any value reported at the aircraft's position to exactly match any value you may see elsewhere that isn’t based on the aircraft’s position.
Region
New for X-Plane 12, the base weather that defines the aircraft's surrounding region is provided as a distinct set of datarefs under sim/weather/region/. Right now 'region' roughly corresponds to a square degree but this may vary in the future. The region base values determine a starting point for X-Plane's own weather simulation, which gets added on top. As with the aircraft's datarefs, this means that you should not expect any value returned in these datarefs to exactly match any value you see elsewhere since the weather at any given point is taken from the combination of the base weather and the weather simulation, not the starting data for that simulation.
Atmospheric Altitude Levels
Atmospheric temperatures are defined at preset altitudes which can be found in sim/weather/region/atmosphere_alt_levels_m . If you are working with temperatures aloft, please use the altitudes given in this array and don't hard-code them. The altitudes, or the number of layers, may change.
Modifying the Region
Most of the regional datarefs are writeable, meaning that you can use these to change the weather in a large volume surrounding the user's aircraft.
sim/weather/region/change_mode
This controls X-Plane's internal weather simulation, when used with static weather, by setting a general trend over time.
sim/weather/region/variability_pct
This controls the internal weather simulation's variability for those parts which use random noise to generate variation. The base weather also varies with distance from a given reference point. Typically the reference point would be the selected airport if you use the UI to select a weather preset, for example.
sim/weather/region/update_immediately
When this is non-zero, any changes to any regional dataref except clouds will take place immediately. Otherwise, the changes will start to fade in over a short period of time, currently 1-2 minutes. Clouds are handled a little differently because there is a delay between the cloud data being determined and the results of the GPU-based cloud simulation being returned. Even with update_immediately set to true, clouds will generally take a minute or so to update to the new values. When you absolutely, positively got to kill every cumulonimbus in the room, you can use the sim/operation/regen_weather command to trigger an immediate full reset of the current weather.
API Access
For simpler access if you are using a programming language that can use it, the X-Plane SDK contains some basic weather data access functions. These allow you to get a weather snapshot – that is, the equivalent of the aircraft datarefs, the output of the base weather plus the weather simulation – at a specific point.
While you are free to request weather for distant locations, the accuracy of the data returned will drop significantly outside of the current region. Errors are reported via the standard XPLMSetErrorCallback() mechanism.
A UDP output from X-Plane to drive you own weather radar display… perhaps for your own moving map!
Send the following data to X-Plane’s IP address by UDP into port 49,000:
The 5 chars “RADR” (four chars plus a NULL at the end!) followed by a STRING (also null-terminated of course!) that lists the number of radar points per frame that you want X-Plane to send right back to you
to drive your visual system. So send “RADR_10_”, where the _ is a null, to have X-Plane send you 10 radar data points per frame.
NOTE: X-Plane will send the message right back to the IP address and port number you sent the RADR command FROM!
This is in the settings menu, internet settings screen, right-most tab for data output.
And here is the data that will come to you, with no annoying struct-alignment issues: The data is all perfectly tightly packed with no spacing.
the four chars RADR, and a fifth byte that is internal-use.
float lon longitude of the scan point, which X-Plane will walk around the area
float lat latitude of the scan point, which X-Plane will walk around the area
float bases_meters the cloud basees in meters MSL
float tops_meters the cloud tops in meters MSL
float clouds_ratio clouds present at this lat and lon, as seen from top looking down, ratio
float precip_ratio precip present at this lat and lon, as seen from top looking down, ratio
