Jump to content
Sign in to follow this  
P*Funk

VOR Radial discrepancies relative to nav documents

Recommended Posts

So I've been flying raw data IFR stuff into and out of big American airports as a change from doing FMC GPS stuff. Its been good fun but I've run into an interesting thing where my VOR radials are apparently considerably inaccurate in many cases next to what the charts tell me. I've updated the magdec file to this year's and I've also updated some of the navaids using this utility, but the issue was present before and after that navaid update which seems to have had near zero effect on most aids in the US for my experience. http://www.aero.sors.fr/navaids3.html

Whats interesting is that using the EasyNavs tool (http://www.aero.sors.fr/navaids.html) I've been looking at the magdec settings for the default scenery VORs and they pretty much match the magdec for what they're set to in real life. However if I fly say the WHINZ4 (http://flightaware.com/resources/airport/KATL/STAR/WHINZ+FOUR) arrival into KATL on the segment from ODF to fix WHINZ the radial it calls for is a whole 6 degrees off of the actual position the fix says its supposed to be at. The FAA defines WHINZ as ODF*VORTAC*216.83/45.76 but the nearest I can see in my sim is the nearest radial to the fix is the 222 radial. ODF hasnt' had its magdec updated since 1965 apparently and that matches what the EasyNav says its at in my sim files. Meanwhile my ATL VOR is reading correctly compared to the charts with the waypoints spot on to the chart radials and the EasyNav tool confirms its set to current declination (updated in 2015 according to FAA). The other weird thing is if I set myself towards ODF on a given radial it tells me that radial is aligned to my heading tot he VOR but the RMI tells me the bearing to the VOR station is off by 6, so if I'm flying to it on a 042 radial it says my heading to the station is say 036' but if I fly 036 heading I don't overfly the station. I would have thought if the radials were offset to an old magdec then my heading should be correct and the radials should look off, not vice versa.

I've flown around in a GPS equipped aircraft that bases itself on up to date Navigraph data separate from the FSX database and I've been comparing where the radials lie with where the fixes are on GPS and its confirmed my observations. By my reckoning ODF is off by ~5-6', SPA by maybe 3-5' depending on which fix I check, IRQ by ~2', and DBN by some number I haven't checked. ATL however is dead on to the GPS database for 2017. I'm quite confused. The RMI also points to it when I fly towards it, unlike the rest it seems.

 

Now some of this isn't that big of a deal since being off by 1 or 2 radials on a short leg of a VOR airway probably keeps you within the margins legally (I fly on VATSIM so it does matter if I'm where I am supposed to be) but for something like ODF which is off by a whopping 6-7 radials when I get to where WHINZ should be I'm apparently several miles off and since the further you get the less accurate navigation gets, etc, when I follow the WHINZ4 arrival I'm supposed to go onto the 232 radial to ATL but I'm nowhere near that radial when I pass ODF 217/46. In general some VORs seem to be aligned correctly or at least not badly enough to notice using real charts while others aren't.

 

Anyone have any idea whats going on?

Share this post


Link to post
Share on other sites

Is it possible you're using addon aiports/sceneries that have, as part of the scenery itself, their own VORs (with an incorrect magvar value) that take precedence over the corrected default VORs?

I had this problem myself not too long ago, and finally realized an addon airport I was using (Marathon, FL - KMLB) had it's own VOR with the old value; by disabling the airport scenery, I found the default MLB VOR (updated with Hervé's utility) to be correct.

I later edited the airport using Airport Design Editor to update the VOR with the correct magvar.

See this thread describing my problem (and solution)....

https://www.avsim.com/forums/topic/491924-vor-radial-not-aligned-to-real-world/

Hope this helps,

Jeff

  • Upvote 1

Share this post


Link to post
Share on other sites

I'm pretty sure I checked against this by searching my addons with the tool to see whether there were any VORs conflicting. The only one of the batch of VOR I'd checked in game was SPA in a freeware airport which had the same setting for magvar, while the bulk of the other ones showing incorrectly in sim are not overlapped by any add ons. I also don't have any payware in the area and only freeware.

Maybe I'll be extra thorough in looking for conflicts. The strange thing is I've never installed add ons in this part of FSX until recently. I may have to play around with areas I know I've never dabbled in to see if its as messed up. Mostly the issue doesn't seem too severe. Being off by 1 or 2 radials is alright. Its the one with 6 off that really spiked my interest in examining it.

Also the thing with the RMI bearing seems odd. Should the RMI point away from the VOR if its magvar isn't up to date, ie. still at 1965's setting? I would have thought it'd be the other way around, with the RMI pointing to the magnetic bearing to the VOR and the radial being offset from that by however much its wrong compared to current magvar.

Share this post


Link to post
Share on other sites

You are exactly correct in your finding that the magnetic radials of many VORS no longer correspond to the actual magnetic headings that would be shown on an aircraft's DG while tracking those same radials. This is not an FSX or P3D error - this is exactly how it is in the real world.

ODF is a perfect example. As you discovered, the magnetic north (zero degree) radial of ODF was set in 1965, when the variation at ODF was zero. The variation today is 5W, so if an aircraft tracks outbound today on the 045 radial (on J48), its actual magnetic heading will be 50 degrees, not 45 degrees. (In a zero wind situation).

I just verified this in Foreflight by imputing a flightplan with a ODF J48 MOL segment.

HOWEVER, (and this is the important thing), if the pilot tunes in ODF and sets the VOR indicator's course selector to 45 degrees, and flies outbound, (while doing whatever is necessary to keep the needle centered) the aircraft's path over the ground will precisely correspond to the path of the J48 airway as shown on the charts.

Yes, the heading shown on the DG will be 5 degrees offset - but surprisingly, that doesn't really matter all that much, as the pilot (or autopilot in VOR mode) is primarily concerned with keeping the needle centered, not flying a specific magnetic heading.

In a small aircraft, on a bumpy day, it's hard enough flying a precise heading within +/- 5 degrees for protracted periods - and even so, if there is any crosswind, the pilot will have to apply a positive or negative wind correction angle to keep the CDI centered. With wind correction, the aircraft's heading would be something other that 45 degrees, most of the time, even if the variation of ODF current.

The geographic (LAT/LON) location of airway intersections defined as the crossing of two published radials from two VORs, will always be precisely correct, even if the alignment of the referenced VOR's zero degree radials are far offset from the current location of magnetic north. The reason for that is that VOR receivers and CDI indicators neither know, or care, where magnetic north is actually located. They simply display the data that the VOR transmitter provides.

The reason the FAA rarely change the variation of VORS once set is due to the fact that it is extremely complex and time consuming to do so.

The VOR would first have to be taken out of service - a real problem if that VOR defines several major airways, or appears as part of numerous SID, STAR or approach procedures.

After the magnetic north radial was reset, the VOR would have to be re-certified by the FAA before being returned to active service, which could involve weeks of test flights by the FAA's Flight Check aircraft.

Finally, every published SID, STAR, and enroute chart referencing the VOR, would have to be modified and republished to account for the change in radial numbers.

It is also true that an RMI (which overlies a gyro slaved compass card) will "see" the 5 degree error, but only because the underlying compass card is showing the aircraft's heading in reference to where the magnetic North Pole is currently located.

As for the RMI...

Many sim pilots, and even r/w pilots misunderstand what the RMI actually does, and how it is most effectively used in flight.

The RMI needle itself simply points at the VOR's current position in relation to the aircraft. The RMI actually doesn't know radials from rope, and in that regard, it is no different than an ADF indicator, (which also simply points at the current location of an NDB in relation to the nose of the aircraft). 

The way a VOR-driven RMI needle "knows" where the VOR is positioned, is very different than the way an ADF-driven RMI needle "knows" where the NDB is located, but the end result is the same.

Trying to fly directly to a VOR using an RMI (by keeping the needle at the top index mark of the indicator) only "works" if there is absolutely no wind, which is no different than tracking to an NDB with an ADF.

If there IS wind, then the pilot will have to take a wind correction angle , which will offset the needle left or right of the top of the index.

With a crosswind, it's perfectly possible to fly directly to a VOR while the needle points left or right of the top of the index.

Remember that the top index mark represents where the aircraft's nose is pointing. The RMI pointer represents where the VOR is located in relation to the nose. If there is a crosswind, the aircraft's nose cannot, and will not, "point" right at the VOR. The nose will be offset to one side or the other because the aircraft is (effectively) flying sideways to a greater or lesser degree in relation to its ground track.

For this reason, RMIs are not typically used to fly "VOR to VOR" in normal operations unless the HSI or OBS/CDI has failed. Doing so would be no different than flying cross country from NDB to NDB using an ADF. It CAN be done... but it would be a lot of work. It really is not correct procedure to try to use an RMI to track a specific radial over long distances.

The RMI's true utility is its ability to enhance a pilot's situational awareness by being able to see at a glance a VOR's relative position in relation to the aircraft, or to see when station passage is about to occur, (before the HSI shows it), or as an aid to keeping a VOR/DME station directly off of the wingtip while flying a DME ARC approach.

Can you tell what specific VOR radial you are currently "on" by looking at the heading mark under the tip of the RMI needle? The answer is: "sort of".

It is only "exactly" the specific radial IF the VOR's zero degree teference is set to current magnetic north, IF the variation at the aircraft's current location is exactly the same as the variation at the VOR and IF the aircraft's slaved compass system that drives the RMI compass card is precisely and accurately calibrated and has no errors.

 

 

  • Upvote 3

Jim Barrett

Licensed Airframe & Powerplant Mechanic, Avionics, Electrical & Air Data Systems Specialist. Qualified on: Falcon 900, CRJ-200, Dornier 328-100, Hawker 850XP and 1000, Lear 35, 45, 55 and 60, Gulfstream IV and 550, Embraer 135, Beech Premiere and 400A, MD-80.

Share this post


Link to post
Share on other sites

So here's what happened. I had several navaids that were out of sync due to having had their variation updated since FSX released. I investigated the issue, installed the updated navaids from the correct site, hopped into the sim and went to check on them. What I did though was use a payware aircraft with up to date nav data and a moving map to confirm the changes and that's where the confusion came from. It turns out this aircraft for whatever reason is displaying anomalous information in relation to the navaids, likely caused by some bug that is never sorted because who tests a modern RNAV capable aircraft being able to stay on VOR radials? I bet most people don't even realize you can do this. I'm pretty sure you actually can't by design in modern Airbuses too.

 

I go back and use the original aircraft without any GPS in it and the standard VOR radios with CDI and RMI and everything is working as it should, including the RMI pointing towards the VOR station in null wind despite being on a radial that's not corrected for the current declination. When in the payware aircraft it would show this inverted, meaning the Radial and the heading would be aligned and the RMI would point offset to the heading to the station in null wind.

I just flew across most of the airspace I was having errors n and it all came up perfect. FSX map showed me flying dead on the airways and nav points using the FAA published radials to get there. Turns out this is all because I broke the cardinal rule of experimentation - I changed more than one variable at a time. I just assumed an expensive payware aircraft was bug free, when it wasn't.

 

In short everything I did that fixed the original issue with radials being a little off is the same as what FLJeff337 did in his thread he posted above. My error following that came from testing the result of that with a bugged aircraft. Thanks for the lengthy reply though, from both of you. In the end I still learned a lot of good info so I'd not call this a loss in any way. Just an education.

  • Upvote 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...