JRBarrett

In both X-Plane and MSFS the VOR information in the database is used to actually place the Navaids into the scenery. The database includes the VOR LAT/LON, frequency, elevation, class of service and variation. The data comes from official sources. VOR variation describes the orientation of the VOR’s 000 degree radial in relation to true north. Clockwise from true north if the variation is East, and counterclockwise if the variation is West. In my example, both ABQ and FTI have their 000 degree radial set to 13 degrees clockwise from true north (East variation) based on 1965 variation data, which has never been changed in all the intervening years, even though the actual magnetic variation in that area is now closer to 8 degrees. The procedure I described in my previous post applies if one was flying along the airway using an actual Nav receiver: which requires tuning the VOR’s frequency, setting the published radial course in the OBS, and tracking the radial outbound with a centered CDI needle. It works differently when FMS navigation is being used. The VOR receiver is not used. The FMS sensed aircraft position in modern aircraft is based on GPS. In this case, VORs in a flight plan route are treated like any other GPS waypoint. If you enter a flight plan that includes a leg “ABQ DIRECT FTI”, the FMS will first calculate the true track between the two VORs using their published LAT/LON, and then apply current variation to give a magnetic heading. It is not necessary that the VORs are actually operational, or even for the aircraft to be equipped with a VHF nav receiver when FMS/GPS nav is being used. In the case of ABQ direct FTI the true track between them is 65 degrees, and the magnetic course (based on current variation in that area of 8 degrees East) would be 57 degrees. If an aircraft flew that leg using FMS in a zero wind situation, the aircraft heading (which is the direction the nose points) would also be 57 degrees. The heading would be greater or lesser than 57 degrees if there is any crosswind component, but the magnetic track over the ground would always remain 57 degrees. If you were flying V190 using raw data from the VOR, with the CDI needle centered and the OBS set to 52 degrees, the aircraft heading would be 57 degrees. From a technical standpoint, a VOR’s published radial does not (necessarily) indicate the current magnetic course outbound. The radial number actually describes how many degrees that particular radial is rotated clockwise from that specific VOR’s 000 degrees radial. As mentioned, once the VOR 000 degree radial is aligned to current magnetic north (on the date it is first commissioned), it is never changed or updated again, even though local magnetic variation may change significantly in intervening years. It is becoming a moot point in any case, as more and more VORs are being decommissioned, and those that remain are being relegated to a secondary “backup” role in aircraft navigation in favor of GPS

Most VORs in the southwestern United States are based on magnetic variation from 1965, and are now 5 to 6 degrees off from the current location of the magnetic North Pole. An example is the Albuquerque VOR (ABQ) which is calibrated to the 1965 variation of 13 degrees East. The actual variation at ABQ in 2026 is 8 degrees East. In other words, the 000 degree (north) radial of ABQ points at where the magnetic North Pole was in 1965, not where the pole is now. This really doesn’t matter. What many pilots (even highly experienced ones) do not understand is that a published VOR radial does not (necessarily) represent the magnetic heading of that radial. It represents the course that must be set into the OBS or course selector of the nav indicator in order to track that radial with a centered CDI needle. Going back to ABQ: airway V190 departs the VOR to the northeast with the radial marked as 052 degrees. If you set 052 degrees into the OBS and fly the radial outbound with a centered needle, your track over the ground will precisely follow the track published on IFR or VFR charts - but your heading indicator will read 048 degrees. As a practical matter, is there is any amount of crosswind, the pilot will be using a left or right wind correction angle, so the heading indicator would not have read 052 degrees even back in 1965 when the radial really did correspond to a magnetic heading of 052 degrees. The FAA typically does not change the orientation of the 000 degree radial of a VOR (once set), because doing so is not a trivial exercise, and because the variation of all other VORs to which airways connect would also have to be changed. The previously mentioned airway V190 connects to the Fort Union VOR (FTI) which is also based on 1965 variation of 13 degrees East. The outbound radial number is 233 degrees, but the actual magnetic heading of that radial in 2026 would be 228 degrees. The inbound course (with a centered CDI) if following V190 from ABQ would be 53 degrees on the OBS/course selector.

Honeywell, who manufactures the IRS units used in many airliners and bizjets, released a Service Information Letter (SIL) quite some time ago to state that the internal magnetic variation tables stored in many of their models is now quite old and that pilots need to be aware of the possibility of heading discrepancies vs. published procedures.

I used to maintain a Gulfstream G200 which uses the same PW-306 engines. Boris perfectly captured the groaning “howl” they make when accelerating after start!

The problem is that data for ASDA, TODA and TORA for a given runway is not contained in any navigation or facility database that MSFS uses - either default or Navigraph. For US airports, that information is contained in the FAA AFD supplement for a specific airport. Obviously, airlines that have their own custom performance apps would have that information in their database, but that info is not contained in any standard MSFS database.

Soy hablante nativo de inglés y me cuesta comprenderlo.

The YouTube clip says absolutely nothing about him being struck by a flying LP record?

I have a Fulcrum yoke and it is still recognized as such. I know some people have had issues with controller assignments and bindings changing, but that has never happened on my installation. All the controller assignments I made when 2024 first came out have never changed in all the subsequent SUs.

I browse Avsim almost exclusively with my iPhone using Safari. I use an ad blocker called “1Blocker” which is 100% effective. I have never seen an ad here even once.

I have done one flight so far from KMCO to KORD. The performance is fine, but this version definitely uses more VRAM than any other aircraft in MSFS 2024 on my system. I monitor VRAM using the Windows Gamebar performance widget. The 737 was using about 85% VRAM on the ground at MCO. It dropped to about 79% in flight and went up to a peak of 96% after landing at ORD. I did not run out of VRAM, but it came close. I have a RTX3080Ti GPU with 12 GB

The snow data provided by MeteoBlue does not have enough horizontal resolution in MSFS, so snow on the mountain peaks “spills over” into valleys. They do have higher resolution snow coverage data for New Zealand, which you can see if you go to the MB snow coverage map on their web site and zoom in. They either don’t provide the high resolution data to MSFS - (perhaps for reasons of cost?), OR MSFS cannot use the high resolution data because of the way the snow is overlaid on the underlying terrain tiles. The same problem exists in the European Alps.

Just because MSFS 2024 is a "new" sim, that does not mean that developers can (or should) re-write every bit of code "from the ground up". The data structures and classes that define the internal operations of something like the FMS take a long development time to test and optimize, and will almost certainly be re-used, because a new base sim platform does not automagically mean that there will somehow be a better way to implement those functions. For instance, the mathematical halversine formula, which is used to calculate the great circle distance between two sets of LAT/LON coordinates is over 225 years old, and is still used in every real world and flight sim FMS and GPS navigator today. The "ground up" rewrites will be for functionality that is new and specific to the MSFS 2024 SDK.

The approach should be valid. The current Navigraph Charts shows the RNP 24 approach at LSZG. The glide path angle is depicted as 3.34 degrees rather than 4.0 degrees. The chart is dated 06 March 26 and is effective 19 March 26. Could be a coding issue in the RXP nav data. I do not own the RXP product, so cannot verify.

If an aircraft is equipped with strobes, regulations require them to be operating at all times when airborne, no matter what the altitude. However, many airlines do switch off landing lights when climbing above 10,000 feet, and switch them back on when descending below 10,000.

In regular Live Weather, surface winds come from the latest METAR report (in knots) and winds aloft come from the MeteoBlue model. I believe the transition from METAR wind to MB model wind happens about 1500 feet AGL. Wind speed in a gridded weather model is always expressed in meters per second. The direction is expressed in rectangular coordinates U and V in which the U is the east/west component and V is the north/south component. Actual direction is calculated by doing a rectangular to polar coordinate transform. It appears that when winds are set manually, the entered direction is being used (as entered), but the conversion routines used for the MeteoBlue model wind speed are still active even though the model is not actually in play. That would explain why speed manually entered in knots is being interpreted as meters per second above a certain AGL altitude. It seems as if this would be an easy thing for the developers to fix. The MB model wind parser should be completely disabled when manually entering wind. The directional parser is indeed disabled, but the speed parser is still active when it should not be.