burle1

In the real world this navaid is an NDB/DME. The NDB is tunable on 223 and the DME is located on 114.4. If you mouse over the VOR symbol in the FSX in-game map, the tag says "high altitude DME." Hope this helps. Todd

You are correct and I was wrong. My apologies for misreading the OP's post. I was going to suggest a scenery conflict, but the OP seems to have solved the problem. Todd

The current Runway 16L/34R at KSEA was not placed in service until after FSX was released. The current 16C/34C is shown as 16L/34R in FSX. My guess is that this is the root of the OP's problem. Magnetic variation should not have an effect on ILS capture in vanilla FSX, because the ILS data is coded as true heading and not magnetic heading. If the localizer is situated on the runway centerline, and on the same true heading as the runway, then the airplane should be able to follow the localizer path and stay aligned with the runway centerline, no matter what magnetic variation model is being used. Todd

Hi,The default display in FSX for Latitude and Longitude coordinates is in degrees and minutes. Does anyone remember how to change the units to degrees-minutes-seconds?There is an edit to fsx.cfg that will do this, but I have forgotten what it was.Any response will be appreciated.Thanks,Todd

Graham,It appears that HST is a TACAN and not a VOR. The TACAN is a military version of the VOR, operating in the UHF range as opposed to VHF.This particular TACAN is situated at Homestead ARB. All TACANs in the FS world have DME capabilities only.In the map view a TACAN is represented by a square, instead of the hexagon within a square which is used for a VOR/DME.Hope this helps,Todd

Martin,These problems occur because the decompiling tools have bugs and shortcomings.NewBGLAnalyze, for example, can not properly decompile some elements in ATIS/AWOS/ASOS radio frequencies. Attempts to recompile the files will result in error messages. There are similar faults in handling of certain instrument approach legs, taxiway signs, and VASI/PAPI arrangements.You will probably find it easier to do much of what you want with a program like ADE9X. Editing a BGL file directly is a high-risk endeavor, as you have discovered.Todd

Lynn,It appears that your coordinates are reversed and your waypoint has materialized near the South Pole. :( Try this:<?xml version="1.0" encoding="ISO-8859-1"?><FSDataversion="9.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="bglcomp.xsd"><Waypointlat="N40 45 43.80"lon="W085 47 01.20"waypointType="NAMED"magvar="5"waypointRegion="K5"waypointIdent="FRIDG"></Waypoint></FSData>Let me know if this works!Todd

Jim,The magnetic bearings you are receiving from SHIFT-Z are based on a circa 2005 magnetic north model. Many VOR installations use much older alignments, from the 1965-1980 period. The difference can be in the range of six degrees or more, very noticeable in the absence of wind.Todd

Did you add any scenery recently? This topic has come up in the past, and this problem is usually traced back to a FS-2002 scenery file being used in FS-2004.Try disabling any third party scenery you may have, and then adding it back, one at a time, until you find the culprit. Sometimes the offending file is literally on the other side of the planet from where you experienced the compass problem.Todd

Yes, using KIAD as an example, the old 1L and 19R ILS feathers should be relabled 1C and 19C.Just be aware there are some issues.First, AFCAD tends to get easily confused. It may try to associate your new 1L/19R ILS systems with the old 1L/19R runway.More importantly, altering runway designations will disable any instrument approaches at the airport. You will still be able to intercept and fly the ILS, but you won't receive the approach from ATC. The AI aircraft will receive visual approaches only.There is no quick and easy fix for this. You might try searching the file libraries for a utility called ILS and GPS Approach Creator. The author is Martin Gleeson.Let me know if you need more info.Todd

The Create a Flight menu lists the runway start positions.Are you sure that you updated these in AFCAD?Another possibility is that the Addon Scenery area is not active. Check the Scenery Library to make sure that the "Active" box is checked.Todd

Kane,Your solution to your problem is in your post.The ILS identifiers must be unique. Change them to whatever you want them to be.Also, if you are using the same localizer frequency for both ends, remember to uncheck the "activate back course" function.Todd

Be aware that FS Nav displays localizer back course approaches on the map, by default. There is a checkbox in the settings that can turn this feature off.What runway were you landing on? In the real world, KSNA has both an ILS and an LDA (a form of offset localizer) on Runway 19R. If you were landing on Runway 1L, you were probably receiving the back course.Todd

The Clearance Delivery frequency is for issuance of an IFR clearance.Try filing an IFR flight plan in the Flight Planner. After loading your plan, you will be given an option to contact Clearance Delivery. Upon readback of your clearance, you will be given the option to contact Tower, Ground or Traffic, depending on the airport.In FS your IFR clearance will always be delivered "as filed." In the real world, that is not always the case.Todd

George,This question comes up occasionally. It has to do with changes in magnetic north models over time.Airnav.com shows the EYW VOR has a magnetic variation of 1E, using data from 1965.The published variation for KEYW airport is 4W, using year 2000 data. The FSX flight planner and GPS also use magvar data from 2000.If you fly the J79 airway on a true course of 038, you will be flying the 037 radial from the EYW VOR (38 - 1 = 37), but your compass bearing will be 042 (38 + 4 = 42). This assumes the absence of a crosswind, of course.This situation is quite common in the USA. Many VOR navaids are defined using old data. FAA policy calls for realignment of the VOR when published and current magvar data are off by 6 degrees or more.Looks like they need to put EYW on the list.Todd

You need three items to make your refueling station work.One is the physical model. You already have that.The second is the trigger element. This defines the invisible boundaries of the fueling area. I don't know of any scenery programs that can do this. You would have to hand code the xml and then compile the .bgl with Microsoft's BGLComp.The third item is the services element, which also has to be coded in xml and then compiled. This item tells the Map View and the GPS that fuel is available at your airport.If I can be of any assistance, let me know.Todd

Others have reported similar problems.Sometimes this is triggered when AFCAD and AFCAD 2 files are mixed in the same scenery. You might want to check the offending sceneries and look for AF_* and AF2_* files mixed together.Also, a poorly written exclude or flatten file can cause the same effect. You might want to try removing these files one at a time until the problem is cured.Todd

As Reggie said, there is a problem with improper back course capture if both localizers are on the same frequency.There is another complication at KAVP. Both of the localizers are offset from the runway heading in the real world. I don't know how accurately this is modeled in FS 9, but the back course capture issue is even worse when there is an offset localizer involved, at least in my experience.Todd

You are correct. Setting the navaid frequency to zero will render the navaid out-of-service, but will not remove it from the map. There is no harm in doing this.Todd

The easiest way to accomplish this is by using AFCAD2, available in Avsim's library as well as elsewhere.You would need to create a new VOR with the new name and identifier, with all the other attributes identical to the old VOR. Then you edit the old VOR and change its radio frequency to zero.Completely removing a navaid is not a good idea even if it could be done, as any instrument approaches which reference the navaid would be rendered unusable.Todd

This topic has come up several times lately. Did you install any 3rd party scenery before you noticed the problem?You might want to disable any addon scenery and see if the problem goes away. There was a thread here a few weeks ago about a South American scenery which broke magnetic variation all over the globe. The scenery contained a corrupt exclude file. Once this file was removed, the problem disappeared.Let us know if this helps.Todd

Rick,AFCAD can add the ILS facility, but it cannot add the instrument approach procedure for ATC to assign.The approach procedure must be coded and compiled into a BGL scenery file using BGLCOMP from Microsoft, following the meager instructions in the BGLCOMP SDK.Which airport and approach in particular? If these are US Airports I might be able to help.Todd

Try looking for the addon scenery Torres Straits. If you have this scenery installed, find and delete ydni_excl.bgl .There are several posts here and elsewhere about this problem. It seems this one rogue file is disabling magnetic variation.Hope this helps,Todd

The magdec.bgl file defines the compass bearings displayed on your airplane's instruments. This includes the magnetic compass, HSI, Shift-Z information display and GPS.Each airport has a defined magnetic variation in the ap*.bgl file. As far as I can see, this element does nothing but allow the ATC to calculate the correct bearings to the airport. There are also magvar elements for each ILS, which serve the same purpose.It's worth noting that the information in magdec.bgl seems to represent a 1985 magvar model, while the ap*.bgls appear to contain 1995 information. This means that when you are shooting an ILS there will be a slight difference between the heading on your compass and the heading shown in the map view dialog.Hope this helps,Todd

Interesting observations. Here are some of my own:NewBGLAnalyze corrupts AWOS and ASOS radio frequency type parameters. "AWOS" is changed to "ASOS", while "ASOS" is changed into a null string " ". This stops the string from compiling.NewBGLAnalyze changes 4-light PAPI displays into 2-light displays. This occurs when the parameter "PAPI4" is decompiled as "PAPI2". Note that the genuine "PAPI2" parameter is decompiled properly.Sometimes BGLXML inserts a bogus "deleteAllWindsocks" parameter into the DeleteAirport element. I have only seen this happen once. The resulting string did not compile.For what it's worth, NewBGLAnalyze seems to do a better job than BGLXML, especially with Approach elements. Neither program is perfect, but the shortcomings of NewBGLAnalyze are more easily identified in the decompiled output.Todd