I have been generally lazy and relied entirely on LNAV to get me around. When I decided recently it was time to work a little harder, I came across this puzzling problem.Flying SID BOGNA1M out of EGKK, I tuned OCK and MID VORs, only to find that both bearings and DMEs are totally wrong (see pic 1). Interestingly, the position vectors are OK! A little further, the brg/dist to SFD are OK but again completely out wrt GWC. Out of curiosity, I checked on a map if there was ANYthing at the brgs/distances indicated and found no navaid at all.Needless to say, this does not bother LNAV at all. It dutifully starts the initial turn 10nm from MID while the indicated distance is 30+Another little quirk: as I tune NDBs on the way, the freq shows on the display but no ident and no needle, even as I literally overfly the beacon.Any help greatly appreciated!Phil

Weird. For one thing on your 180 track approaching OCK28 for the turn your VOR 2 is reading DME 41. I attached an extract of the current SID chart. OCK should be behind you. The VOR 2 RMI indication is pointing too far to the left in my opinion.The 737NG series installs a copy of FSUIPC3. That is used by some elements in the nav display. As a routine thing it would not hurt to update it as follows:-------------Get the base FSUIPC version from:http://www.schiratti.com/dowson.htmland then interim update from the modules link on this page:http://forum.simflight.com/forum/142-download-links/FSUIPC now self installs initially based on your registry entry for your FS path. Check that with this free utility:FSX/FS9 Registry Repair Tool (36KB) from http://www.flight1.com/view.asp?page=library------------------Reinstall those and see what results in any that has.Did your path waypoints come from the FMC terminal procedures data base or from a flight planner. Maybe something was off in those waypoint database coordinates as clearly your aircraft position on the ND does not agree with your tuned in navaids for bearing and DME.I'd also run the registry checker alluded to in the FSUIPC update instructions. An incorrect registry entry for your FS version has been known to cause ND display errors.Last, a scenery check should be performed if this is happening only at EGKK. Is this an add-on EGKK? I'd try disabling the add-on scenery and try the flight from the default if previous checks don't fix anything. Look for additional afcad files placed perhaps by a traffic program. Generally if you use an add-on scenery or have added a separate afcad (but not both) and you have a traffic program you would disable the afcad provided by the traffic program safely by renaming the extension from .bgl to .bgh.Report back with your findings.

Hello Phil,Which AIRAC version are you using and from what source?I have checked cycle 1102 in the PMDG FSX 747 and all appears to be ok.Edit: Checked this in FS9 737 also

Edited February 12, 201115 yr by srcooke

Hello Phil,Which AIRAC version are you using and from what source?I have checked cycle 1102 in the PMDG FSX 747 and all appears to be ok.Edit: Checked this in FS9 737 also

Thank you, Ron and Stephen for your prompt replies. I'll follow your suggestions very methodically as getting rid of the problem without pinpointing the exact cause is not quite good enough for me.I use FSUIPC ver 3989t and AIRAC 1101 from Navigraph. The SID was loaded direct from the FMC. I am positive that my position was correct as I always crosscheck against the FSC moving map (where I measure brgs/distances). EGKK scenery is UK2000 but could the AFCAD really affect navaids away from airport?As you can see on the 2d pic (original post), the navaid positions on the ND (using the POS vectors) are correct; the needle and DME for SFD are OK but not for Goodwood. Likewise on the attached SID SAM3J from EGLL: both OCK and SAM vector positions are OK, needle and DME are OK for SAM but not for OCK. For this reason I am inclined to suspect the system simulation rather than the nav data itself. I went to EDDH and xchecked against 3 local VORs - everything is perfect.I will now proceed with Ron's suggestions and report back.Cheers.Phil

I pulled up the SAM chart from AIS UK and Eurocontrol. The latest data there was AUG10. I also looked at the Navdata cycle used by FSBuild for 1310. The charts do not show any references to OCK waypoints as on your plan in the ND and neither do any waypoint data that I see in the navdata. All VOR references are to SAM, MID and DET plus I-GG localizer. Am I looking at the wrong ND image?The current FSUIPC is FSUIPC 3.989w. One was quickly pulled but I'm not sure if it was the t version.I do not recall the limits of a scenery airport AFD file on navaids. I don't know what design approach is used on the UK2000 Gatwick scenery.I have to check on a few items and I'll be back later.

Hi Ron,Here is the current SAM3J chart from the EAD site. It is consistent with the AIRAC data in the FMS. Anyway, SID or not, the situation display shows I am 7.0-1.6=5.4 nm past OCK on the 255 radial. Needle and DME are wrong. They are OK wrt SAM.This does not look too good and I'm afraid I am headed towards a reinstall of FS9. Here what I have done so far:- installed update to ver3989w of FSUIPC- deactivated all 3 add-on London airports- flew manually on Cessna and Learjet, just maintaining rwy hdg: exact same indications, therefore I am posting in the wrong forum. This is not PMDG-related.- for fun I flew a VOR LOC along that weird VOR needle. At DME0, the needle did swing OK but there was absolutely nothing resembling a navaid there in the database. Next I'll try to find some other examples anywhere in the world where this occurs. So far I have only found OCK, MID and GWC. Is it a coincidence that they are almost lined up? and close to longitude 0.0W? Grasping at straws here!What I'd like to understand is why the software displays the navaid position correctly on the ND but somehow uses another algorithm to drive the needle and DME readout...Thanks for yr help but pls don't waste too much time on this... unless you enjoy the exercise as much as I do.Cheers.Phil

Hi Ron,Here is the current SAM3J chart from the EAD site. It is consistent with the AIRAC data in the FMS. Anyway, SID or not, the situation display shows I am 7.0-1.6=5.4 nm past OCK on the 255 radial. Needle and DME are wrong. They are OK wrt SAM.This does not look too good and I'm afraid I am headed towards a reinstall of FS9. Here what I have done so far:- installed update to ver3989w of FSUIPC- deactivated all 3 add-on London airports- flew manually on Cessna and Learjet, just maintaining rwy hdg: exact same indications, therefore I am posting in the wrong forum. This is not PMDG-related.- for fun I flew a VOR LOC along that weird VOR needle. At DME0, the needle did swing OK but there was absolutely nothing resembling a navaid there in the database. Next I'll try to find some other examples anywhere in the world where this occurs. So far I have only found OCK, MID and GWC. Is it a coincidence that they are almost lined up? and close to longitude 0.0W? Grasping at straws here!What I'd like to understand is why the software displays the navaid position correctly on the ND but somehow uses another algorithm to drive the needle and DME readout...Thanks for yr help but pls don't waste too much time on this... unless you enjoy the exercise as much as I do.Cheers.Phil

Well, I may be onto something here. I did a xcountry flight around London, monitoring my position on FSC and tuning away as I went. LON and BNN are both bad (and both West of 0.0). However, everything East of 0.0 was correct: LAM, BIG, DET, SFD, MAY. On my way back, I tuned the ADF: RCH, LSH, RDL, LCY all gave me correct needle indications. When I started tuning on NDBs West of 0.0 (EPM, FOS, BLK, WOD, BUR), the ADF needle either disappeared or defaulted to 090.Just need to understand why...Phil

I just looked at a 2008 scenery that was released as freeware by UK2000. The AF2 file there does have OCK in it with the correct coordinates. That confirms your findings since it is not add-on scenery related, not PMDG/FSUIPC/NAVDATA related,etc.There have been other add-ons that have changed the base APxxxx files which contain several stock airport data each for the worse. At least one other changed the magnetic declarations file (can't recall the name) but I think that would affect several VORs in the vicinity and any but it seems so. Check out another UK airport in the vicinity and then in another area remote by a few hundred miles.Especially if you ever had FSX and FS9 installed run that registry checker to insure their paths are correct. The wrong files for the wrong sim may be pulled in for some of that data including the magnetic deviation file.I don't know off hand which Axxxx.bgl file set contains FS9 navaids but maybe one of those got changed. The on-airport ones are the APxxxx.bgl file. The data in those files is what drives the navaid instruments. The data in the APxxxx.bgl files also affects the default FS9 GPS display.On flightsim.com and perhaps avsim.com there is a file you can download that relates these file names (each is an area tile) to locations. Once you do that you can see if those files for that areas have been modified and then extract them from your CD. I am not sure if these files are included but it is possible you can reinstall the FS9.1 patch only by renaming the folder the patch created called BACKUP so the patch will run again.On AVSIM this Excel spreadsheet file fs9cddir.zip lists the location of original files on the FS9 install CDs. It is more likely an ABxxxx or APxxxx needs to be reinstalled. Use this once you find the tile area. I could not find it but there ia also an image map of the world relating to the tile locations and their names.I would repost on the FS9 forums here and on flightsim.com regarding your change in VOR references asking where they are stored for the area in England you are getting erroneous values. Ask where the magnetic declaration file is especially if it seems east-west pointer direction to the VOR is off. But FIRST check the paths to FS9 in the registry.Sorry I can't be of more help.

I just looked at a 2008 scenery that was released as freeware by UK2000. The AF2 file there does have OCK in it with the correct coordinates. That confirms your findings since it is not add-on scenery related, not PMDG/FSUIPC/NAVDATA related,etc.There have been other add-ons that have changed the base APxxxx files which contain several stock airport data each for the worse. At least one other changed the magnetic declarations file (can't recall the name) but I think that would affect several VORs in the vicinity and any but it seems so. Check out another UK airport in the vicinity and then in another area remote by a few hundred miles.Especially if you ever had FSX and FS9 installed run that registry checker to insure their paths are correct. The wrong files for the wrong sim may be pulled in for some of that data including the magnetic deviation file.I don't know off hand which Axxxx.bgl file set contains FS9 navaids but maybe one of those got changed. The on-airport ones are the APxxxx.bgl file. The data in those files is what drives the navaid instruments. The data in the APxxxx.bgl files also affects the default FS9 GPS display.On flightsim.com and perhaps avsim.com there is a file you can download that relates these file names (each is an area tile) to locations. Once you do that you can see if those files for that areas have been modified and then extract them from your CD. I am not sure if these files are included but it is possible you can reinstall the FS9.1 patch only by renaming the folder the patch created called BACKUP so the patch will run again.On AVSIM this Excel spreadsheet file fs9cddir.zip lists the location of original files on the FS9 install CDs. It is more likely an ABxxxx or APxxxx needs to be reinstalled. Use this once you find the tile area. I could not find it but there ia also an image map of the world relating to the tile locations and their names.I would repost on the FS9 forums here and on flightsim.com regarding your change in VOR references asking where they are stored for the area in England you are getting erroneous values. Ask where the magnetic declaration file is especially if it seems east-west pointer direction to the VOR is off. But FIRST check the paths to FS9 in the registry.Sorry I can't be of more help.

Thanks for pointing me in the right direction (pun intended).It took me much too long to realise that FMC and the ND display the AIRAC data while the needles and DME readout are driven by the FS nav data, an entirely different source.So, I finally did what I shd have done in the first instance: display the FS map (attached). Sure enough, the positions for the faulty stations are all mirror images of their correct posions wrt to meridian 0; i.e. correct longitude values with the wrong sign.This shd be easy to trace.Will report when the culprit is charged.Phil

Are you running the US version of Windows? Set it up so that the language is U.S. as some numerical values in FS data might be misinterpreted. I don't recall if FS has a language choice but it should match Win. That might explain some reversals.Also while it should not affect navaids in your realism settings set your compass heading to magnetic. As I stated there have been some instances of some scenery add-ons updating the FS file with the world magnetic deviation data. Since navaids are oriented to use magnetic deviation that might be a problem if that occurred. That file substitution would affect FS globally and not part of an add-on scenery folder.Here's a thread where some responses relate to both FS9 and FSX and shows the location of magdec.bgl in the Scenery\Base\Scenery folder. Check the properties of that file for dates and version just to see if that was changed from the other original global .bgls in that folder.http://www.flightsim.com/vbfs/showthread.php?219314-Magnetic-Declination-and-runway-changes-on-FS2004Finally the magnetic deviation r/w was 1.7 W in 2010. FS9 data is thought to be about 1993.If the magdec.bgl was changed that might have a significant effect. There are revised independent magdec.bgl updates available but this might throw VORs off.Here is an image of the OCK VOR properties from the freeware UK2K scenery for FS9.

Are you running the US version of Windows? Set it up so that the language is U.S. as some numerical values in FS data might be misinterpreted. I don't recall if FS has a language choice but it should match Win. That might explain some reversals.Also while it should not affect navaids in your realism settings set your compass heading to magnetic. As I stated there have been some instances of some scenery add-ons updating the FS file with the world magnetic deviation data. Since navaids are oriented to use magnetic deviation that might be a problem if that occurred. That file substitution would affect FS globally and not part of an add-on scenery folder.Here's a thread where some responses relate to both FS9 and FSX and shows the location of magdec.bgl in the Scenery\Base\Scenery folder. Check the properties of that file for dates and version just to see if that was changed from the other original global .bgls in that folder.http://www.flightsim.com/vbfs/showthread.php?219314-Magnetic-Declination-and-runway-changes-on-FS2004Finally the magnetic deviation r/w was 1.7 W in 2010. FS9 data is thought to be about 1993.If the magdec.bgl was changed that might have a significant effect. There are revised independent magdec.bgl updates available but this might throw VORs off.Here is an image of the OCK VOR properties from the freeware UK2K scenery for FS9.

Ron,1. I have not found a language setting in FS9, maybe it is an option during install.2. I have found out that all the stock VOR/NDB data for EURW are in the single file NV9EURW0.bgl, not in individual APxxx files. Last change to that file was the day I installed NL2000 scenery but it was likely already corrupt before that.3. I have regenerated my navaids with the utility from http://hsors.pagesperso-orange.fr/index.html. This is a great site for reference. I'll now update my magvars from that same source and carefully put back specific bgls that had been modified for a few addon sceneries. (The utility generates an automatic backup)4. The map you mentioned locating the bgl files is at http://forum.simflight.com/topic/60973-location-in-the-world-of-specific-bgl-files. My APxxx for the UK were still the original ones but this is probably irrelevant due to 2. above.5. Since regenerating the stock data put everything back in order, I can safely assume the problem was not caused by some rogue AFCAD.I hope some of the above will be of interest to you.Thanks again,Phil

I was referring to the Windows area setting. In some locations commas are used in place of dots for decimal separation. That should not be causing errors in already compiled .bgls but if any .csv or comma delimited database text formats are used that could be a problem.The AP files sometimes are replaced to accommodate runway renumbering and also to move or change an ILS code, something that really can't be done correctly with AFCAD. It has to do also with approach data. ADE9X shows both the 'normal' afcad type view but also shows the separate approach layer which can offer some modification beyond AFCAD's capabilities. In the AFCAD help file it explains limitations on NAVAID changes. That's why in FS9 some files that should not really be changed are.Thanks for the reference of the navaid location files.

I think the problem I'm having is quite alike to this onehttp://forum.avsim.net/topic/328776-fs2004-navdata-or-something-else/