The WpNAVFIX.txt file?

[vonmar 123]

Hi,When does the WpNAVFIX.txt file get accessed? Building SID/STAR?Building a flight plan in MSFS?Is it used by MSFS scenery?For example, when programming (rebuilding) a SID or STAR for the Level-D manually (using the FMC) to add a new waypoint to the SID/STAR that is not in the .txt file already. I assumed the waypoint must exist there first. But, I tried a downloaded SID and it worked in my FMC. I later discovered that a waypoint did not exist (at least I could not find it) in the .txt file. Must I first add the waypoint to this file with the LAT/LON and put it in "numerical order" with the other waypoints already in the file?Or, can SID/STARS be edited without worry about the .TXT file and other uses it may have. Once a SID is defined and saved. Loading the SID would be directly from the procedure XML file .... the xml would not go back and check the .txt file to see if all these waypoints exist. The assumption being the LAT/LON data is already in the SID so why go back and look again at the .txt file?All this can get a little confusing to a non programmer.

[downscc 1,327]

When does the WpNAVFIX.txt file get accessed? Building SID/STAR? NoBuilding a flight plan in MSFS? NoIs it used by MSFS scenery? NoThe wpNavFIX.txt file is used in by the FMC when you create a route, in conjuction with the wpNavRTE.txt file. When you are flying direct to a fix or navaid, the waypoint comes from the fix or navaid files and when you are flying a route it comes from the route file. SIDSTARS use either fixes defined within the procedure file or navaids defined in the wpNavAID.txt file. Although I create procedures for PMDG, it is the same basic data. I prefer to define all the fixes I use in my file such that I do not rely on external references.When building a flight plan in the FS9 flight planner, the add-on navdata (airac and sidstars) are not available. All fixes, navaids and routes are from the scenery .bgl files. Conversely, when using an add-on it rarely refers to the FS9 data. The advantage to this scheme is while FS9 data is only updated by adding new scenery the airac and sidstar data is updated every cycle by Navigraph, Planepath and others.Hope this helps.

[vonmar 123]

Dan,Thanks first for the great reply.A couple follow up questions just to make sure of my understanding here.Once you download a new procedure (.xml) it is ready to go and be used by the FMC. Even if the new fixes are not yet in the .txt file because it already has the LAT/LON/fix name and data embedded in the SID/STAR procedure flie itself. Is this correct?In the last procedure I downloaded from you, you included a katl_wp.htm file which listed 58 new waypoints.Is it the intent here to provide a way of adding the fix data if not already present in the .TxT or navaid files. In other words, check each one and manually update as necessary until the next navdata cycle?If while flying cross country you use the FMC to go direct to an intersection or navaid ... which may already exist in the currently loaded procedure in the FMC. It will look it up the direct to waypoint in the .txt etc. files. It will not first look to see if the fix you want to go to now is already in the loaded FMC procedure file. The last KATL procedure I downloaded from you is fron JAN 2006. Do you have a newer one in .XML format?When you build a procedure with a new FAA waypoint/navaid that does not yet exist in the .txt file. Where do you get the LAT/LON from so you can create a new procedure?When you create a new procedure do you have to key in each waypoints LAT/LON data or do you just have to give your program the sequence of waypoint names and it then generates the procedure automatically?

[Guest BigJacko]

I hope Dan won't mind me butting in with some answers to your questions, >Once you download a new procedure (.xml) it is ready to go and>be used by the FMC. Even if the new fixes are not yet in the>.txt file because it already has the LAT/LON/fix name and data>embedded in the SID/STAR procedure flie itself. Is this>correct?Depends. If the turning-point in the XML is explicitly declared in the XML as a FIX, and given a set of lat-lon coordinates, then all will be well.However, if the turning-point in the XML is mentioned only as a NAVAID reference, within a given procedure, then there WILL be a problem (a big one!) if that turning-point doesn't appear either in wpNavAID.txt or wpNavFIX.txt!And lately, this has been happening a lot with some of the new data available, post-DAFIF-decline. Some of the core Navigraph AIRACs don't seem to feature certain points that previously, freeware terminal developers were relying upon as being present in the wpNavAID or wpNavFIX files, and simply referencing using the 'NAVAID' function-call. Until they are all changed to defining these missing points as FIXes in their own procedure XMLs, these will remain bust. Alternatively, these missing points need to turn up in one or other of the Navigraph wpNavAID or wpNavFIX files (and in some cases, I'm quite concerned that some haven't, because they are well-known and have been around for some time, causing me to question the datasource Navigraph may be using, perhaps).>>In the last procedure I downloaded from you, you included a>katl_wp.htm file which listed 58 new waypoints.>>Is it the intent here to provide a way of adding the fix data>if not already present in the .TxT or navaid files. In other>words, check each one and manually update as necessary until>the next navdata cycle?Unfortunately, that has very much been the occupier of my time since October, when the DAFIF died, and the online AIRAC world went to #### in a handcart, yes! The online VA group I'm in (like many others I expect), is (to coin a phrase) "doing its nut" about these problems with all their planes, and I am one of only a couple of chaps in our group with sufficient geekery to even begin to understand this problem, and help them. I pity any poor soul working on his own!But basically, yes... manual checking against the AIRAC (wpNavAID/wpNavFIX) and the XMLs is the principle way of discovering such missing turning-points - failing that, fly 'em, and see what breaks, then fix 'em later (but that's not always so pleasant when online and being handled by live ATC! :)>>If while flying cross country you use the FMC to go direct to>an intersection or navaid ... which may already exist in the>currently loaded procedure in the FMC. It will look it up the>direct to waypoint in the .txt etc. files. It will not first>look to see if the fix you want to go to now is already in the>loaded FMC procedure file. In my experience, (mainly with the PMDG which uses the same navdata core), the FMC will NOT look any further than the wpNavAID (VORs, NDBs) and wpNavFIX (RNP5 Waypoints) files for the thing you've typed in as 'DIRECT'. Very often, it will NOT pick up the fact that the turning-point you're demanding is actually defined in the XML as a standalone FIX. Annoying, but that's tough, alas.>>The last KATL procedure I downloaded from you is fron JAN>2006. Do you have a newer one in .XML format?This one for Dan, I'm afraid! I can't answer that.>>When you build a procedure with a new FAA waypoint/navaid that>does not yet exist in the .txt file. Where do you get the>LAT/LON from so you can create a new procedure?There should be available a file with the RNP5 Waypoint definitions in them, with LatLongs for each - there is certainly the same for the UK (which is where I am), published by the CAA/NATS in the AIP and available publicly on their website. I think the same is also true for the EuroControl area - and I'm pretty sure the USA will be the same. There are usually also similar files for Navaids, too, but these can also be located on charts too, where they are often shown with a lat-long sufficient for our needs to update the relevant wpNavAID.txt or wpNAVFIX.txt filesFirst stop, I guess, for the USA, would be your local FAA website!>>When you create a new procedure do you have to key in each>waypoints LAT/LON data or do you just have to give your>program the sequence of waypoint names and it then generates>the procedure automatically?Generally, if you've defined the turning-point at the top of the file as a FIX (for use within that XML file), then thereafter, all you need to do is reference it by name using the FIX="blah", and the procedure will work out the lat-lon accordingly. Alternatively, if you've added the turning-point to wpNavAID.txt (if it is a VOR or NDB) or wpNavFIX.txt (if it is an airways RNP5 waypoint), then you'd simply reference it as NAVAID="blah" in your XML, each time you needed to use it.Hope this helps!Regards