Question on VOR DME approach when runway not aligned


question from a novice: so yesterday I tried my first VOR DME approach (KBJJ Rwy 10), for reference here is the approach plate:

I have the approach loaded into the TBM autopilot, and the plane follows nicely to BSV, then outbound on radial 295 and across the airport, turn after PTATO, and then inbound on radial 115. Now my question: The runway heading itself is 98°, so if I follow the approach according to the plate I will reach the runway threshold at a 17° angle. How do you (as a real pilot) fly such an approach?

  1. Stay on course 115° until reaching the runway threshold, and then try to align once being over the runway?
  2. Stay on course almost to the runway but at some point make a right turn to intercept the runway heading and have some time to align so that I reach the runway straight on? And if so, at what distance would you leave the approach course?
  3. Or something completely different?

Also, related to this - are those approaches in real life usually flown completely by hand after the IAF, or can you continue to use the autopilot and dial in an appropriate descent rate that gets you almost all the way down?


My plane didn’t have such equipment so I’ve not studied this properly myself.

But in the sim this is how I’d do it. My expectation is that you fly the radial until you have sight of the runway (must be above the MDA) then set your course to gently intercept the runway straight on. Basically I’d think of it as rounding the sharp corner.

But I’d follow the radial until MDA.

It’s option 2: conduct the approach and stay on the radial until you have the runway and environment in sight. Once you have the runway in sight, you break off the radial and visually maneuver to line up with the runway.

In a perfect world, you want to be in your final approach configuration (gears and flap), speed, and lined up with the runway so you’re not making heading changes, and you want to make sure you’re like that and stable before 500’AGL


This is a non precision approach. You’ll fly down to minimums (listed at bottom 1840-1 = 1840 ft MSL and 1 mile visibility required) until you see the airport environment (approach lights, runway lights, REILS etc) and then align yourself with the runway. There is no vertical guidance on this approach. You determine your needed descent rate after crossing PTATO. The chart tells you the glide path is 2.92 degrees so almost a standard glide path (3 is standard). You can use a rule of thumb and divide your groundspeed by 2 to get a descent rate. Example you fly the approach at 100 knots. Divide by 2 and you get 50 (add a zero) for -500 fpm.

Anyway, assuming you break out of clouds, or see approach lights/runway before minimums, you could at that point, align yourself with the runway heading and continue to a normal landing.

In a small GA aircraft you’d pretty much fly all by hand. If it’s a twin or maybe a TAA (Technologically advanced aircraft like a Cirrus) you may opt to just engage in a NAV hold and vertical speed mode descent until minimums.


They key to understand here is that LOC DME or VOR DME or NDBs are Non precision approaches. You follow the lateral and vertical path until the minimums. You must have the runway insight to proceed with the landing. If you don’t have the RW in sight, you climb and try a precision approach like an ILS, or divert to another AF.
Remember, in non precision approaches you are the one in charge of landing, not the instruments, so simply follow the VOR , follow the chart you have(the vertical path) until you can see the runway, then align yourself to the runway.

1 Like

On a related note, I’ve seen a few airfields where the ILS is several degrees off of the actual alignment of the runways (such as Phuket in Thailand - VTSB).

I ended up simply going to manual and swinging over about a mile or two out, but then I thought “Can’t you simply adjust the course setting on NAV1?” FS2020 automatically loads the course setting when it captures the localizer, but if it is set to 290 and it actually should be 293, can’t you manually adjust it, or does the sim not let you override it? I have to try that.

The purpose of an offset ILS is to get an otherwise penetrating obstacle out of the final approach area.

Or the White House in the case of the LDA 19 into KIAD. Flying in on a ILS aligned to 19, would take you to directly over the WhiteHouse, so they have a Offset ILS (LDA) of 149 degrees to avoid that (and instead have you fly over the Pentagon instead … go figure)

The value the course is set to is irrelevant for ILS and LOC approaches. The way the signal is propagated means it will continue to give correct course deviation indications, centred around the designed inbound course. As you have seen, sometimes this isn’t runway aligned (JFK runway 22R is similar).

Whilst it’s common practice to set the inbound course when conducting an ILS, it’s not required. Although if using a HSI style display for deviation indications, it would become difficult and confusing if you didn’t.

1 Like

Aww, bugger, I thought I had a brilliant idea, LOL. Reality sucks.

Thanks guys for all the responses, that’s a great help!

You mean KDCA. The problem is that no localizers that are offset in r/w work correctly in the sim. Every ILS localizer in MSFS is currently set to the exact runway heading. That works fine for 95 percent of ILS approaches where the localizer is indeed aligned to the runway centerline, (which means that the localizer antenna will be located directly beyond the runway threshold.)

But, when a localizer is offset, the antenna will usually be positioned to the side of the runway. MSFS does have the coordinates of the localizer antennas set correctly, but because they have set the heading of the localizer beam center to be exactly the same as the runway in all cases, trying to fly such an offset approach will guide the aircraft to the side of the runway, and parallel to it.

I, and another user here on the forums independently discovered how to fix this, and force the localizer to generate the correct course, but it requires directly editing numeric values in two compiled BGLs with a hex editor. (Or only one BGL if Navigraph beta nav data is installed), and this has to be done on a case-by-case basis because the specific BGLs involved depend on which airport and runway is affected.

Since editing complied MSFS BGLs directly is literally a hack, and technically a violation of the EULA, I can’t provide details of how this is done, and in any case, end-users should not have to be put in the position of doing something like this to make offset localizers work correctly. I have filed a detailed Zendesk report explaining why forcing offset localizers to assume the runway heading is not appropriate, and could easily lead to collisions with terrain for those localizers that offset for this particular reason (like LOWI).

This problem would likely not affect custom 3rd party airports that happen to have one or more offset ILS approaches, since a custom airport scenery overrides the default.

I haven’t tried the LDA 19 approach at KDCA. Perhaps they got this one “right”, but if so, it would be a first.

1 Like

Duhhh yes KDCA … thanks.

The LDA 19 localizer is set up correctly to the correct localizer bearing. No issues there.
It is also a Localizer only (ie Localizer DME) as opposed to Localizer/Gideslope

The problem is, MSFS FLIGHT PLANNER ignores the last few WP on the LDA, and diverts to a FP that has an extended 19 runway approach.

It’s 100% a MSFS “Fantasy” FP approach.
The way around it, is to edit the FP, and manually put back in the correct last 2 waypoints,
or manually fly the last two WPs, ignoring the MSFS FP approach.

or, generate the FP outside of MSFS, with an App like LNM, which is obviusly way better than the MSAFS internal flight planner.

And then there are all these “Fantasy Arcs” that MSFS seems to want to include in their generated FPs !!! Really, WHY ??? Where did they magically come from ??

As I suspected, both LDA 19 approaches at KDCA are completely wrong for the reason discussed in my previous post. The localizer is set to the magnetic heading of runway 19 (187 degrees), instead of the actual localizer course of 149 degrees. A 38 degree error!

Since these LDA approaches are specifically designed to keep arriving aircraft west of the prohibited areas over the White House and Capitol, flying it in the sim has the exact opposite effect . Because the localizer is forced to the runway heading, flying this approach with a centered CDI needle will bring you directly over the center of Washington DC, right through the prohibited areas. If you tried this in a real aircraft, it would probably result in being on the receiving end of a surface-to-air missile.

The screen cap below shows the C172 flying the LDA Y 19 approach in Nav mode in Foreflight, overlaid on the actual approach chart, with aircraft position injected into Foreflight by XMapsy

No, its correct … it does use the correct localizer I-ASO (near end of 15 ?), so that is correct.

What the MSFS FP planner does, is to divert OFF that 149 deg approach on the Localizer, (I-ASO) (before Mindy) and route East, then south on the 19 heading, talking you right over the Top of the 2 restricted areas. !!

It is if MSFS assumes that any Approach must be on runway heading for the last few miles !!!
Most are – LDA’s are NOT.

If you try it, make a MSFS FP from KIAD say dept 18L ? no departure procedure, and then direct to KDCA LDA 19.

Must have taken some effort to Fantasize that ARC !!!

COOL, I want that !!! Project for this weekend, while waiting for rthe next “Patch”

No, the localizer is misaligned in the core default nav data. It is not NavBlue’s doing - Asobo deliberately changed the NAXxxxxx.BGL for KDCA to set the localizer to the runway heading.

The frequency and ID are correct, but when you tune the ILS on the Nav 1 receiver, it auto sets the course to 187 degrees, instead of the correct 149 degrees.

If you install Navigraph nav data, it overrides the default. In that case, tuning the Nav 1 to I-ASO on 109.9 does set the CDI to the correct 149 degrees, but it still does not work. The reason that it does not work, is because there is a 4-byte flag in the airport APXxxxxx.bgl that forces the localizer to the runway heading no matter what the nav data says.

Zeroing out those 4 bytes in the APX with a hex editor unlinks the localizer from the runway heading and the approach then works perfectly.

If you don’t use Navigraph, then you also have to edit the NAX BGL to change the field that defines the localizer course to the correct value.

There is no question that setting every localizer in the sim world to the exact runway heading was a deliberate design choice on Asobo’s part. For the great majority of ILS approaches it is not a problem, but it is a major issue when a r/w localizer has a significant offset like the KDCA LDA approaches to runway 19.

Ahh, I am beginning to see your point… Thanks … (see PM)

Small but important point - you don’t have to have the runway in sight, or the runway AND environment in sight before descending below the MDA. It’s the runway OR the runway environment (which is often the runway approach lighting in marginal-weather cases), and in a position to make a safe landing.

MDA is an altitude, not a point on the ground. You must stay on the radial until you have the runway or runway environment in sight, and in a position to make a safe landing, or until initiating missed approach.

The 1st Addon Developer to come out with" Full AUTOLAND for GAMERS" for all the planes in the sim, will make a fortune !!!