October 16, 201312 yr I have been observing the following during quite some time now,first with the NGX and now with the T7.And with all Airac Cycles, the latest is 1310 from Navigraph.I always enter the routes manualy in the FMC.Enroute from LPPT to OMDB over Cyprus.As seen on the above screenshot we are on UM978 heading to Larnaca LCA NDBAt LCA NDB we will continue on UR655.As seen there is also a Larnaca LCA VOR.VOR L is tuned on LCA VOR 112.80 and ADF R is tuned on LCA NDB 432.00.And here is the possible bug in the FMC. The FMC use the NDB instead of the VOR. The route should pass over the LCA VOR and not the LCA NDB.Opening the wpnavrte.txt and wpnawaid.txt files from FSX/PMDG/NavDataand looking up UM978, we can see, from the position that this airway is usingthe LCA VOR. Screenshot below.And not LCA NDB, screenshot below.And again UR655 is using the VOR and not the NDB. Other examples:Lavan Island in the Persian Gulf, LVA VOR and LVA NDB, Airway G666.Graz in Austria with GRZ VOR and GRZ NDB, Airway UT23 and UP978.There are other examples all over Europe, the Middle East and North Africa.Other parts of the world I don't know, as I have only been flying the NGX in this areaand have not done any flights outside this area with the T7 yet.So is this a bug in the FMC of the T7 and the NGX?Soeren Nielsen
October 16, 201312 yr Commercial Member So is this a bug in the FMC of the T7 and the NGX? No. It's a bug in the navdata, which is from a navdata provider. If you use Navigraph, then it's something to bring up to them. Kyle Rodgers
October 16, 201312 yr Author Sorry Kyle But I don't believe so, as the Airways is correctly using the position of the VOR. Would like to get a comment on this from PMDG. Soeren Nielsen
October 16, 201312 yr Commercial Member And here is the possible bug in the FMC. The FMC use the NDB instead of the VOR. The route should pass over the LCA VOR and not the LCA NDB. Yes. I have seen this behavior too (incorrect waypoint selection during airway entry). This bug only exists if you enter the airways only, and allow it to auto-fill the waypoint. If you select the waypoint yourself as you enter the airways, this problem does not occur. The problem is that the auto-waypoint selection is selecting the wrong waypoint. Best regards, Robin.
October 16, 201312 yr Author Robin Thanks for your reply. But I have tried both. Auto wp selection and airway - wp - airway with same result. Best regards Soeren Nielsen
October 16, 201312 yr Commercial Member Interesting. Can you post the full route here? I'll try it and see if I can persuade it to do anything different. Also - does the position in the nav data (any coordinates) agree with FSX nav beacon position? I'm thinking the difference is between the waypoints in the nav DB and the beacon location in FS. A long shot, but how else does the ND paint the tuned beacon location? The beacons do not need to be in the nav DB to be tunable. Best regards, Robin.
October 16, 201312 yr This bug only exists if you enter the airways only, and allow it to auto-fill the waypoint. If you select the waypoint yourself as you enter the airways, this problem does not occur. Robin, are you referring to selecting two routes in succession without entering the endpoint of the first route (same as the start point of the second route)? Or do you mean that the pilot must enter all waypoints on a route to avoid this error? Thanks, Mike
October 16, 201312 yr Commercial Member I'm still not convinced, really. As a database guy, one fundamental aspect of databases (which those files are essentially a rudimentary DB) is lack of ambiguity. If two waypoints share a name, then there is something wrong. Generally, waypoints that share the NDB ID have some sort of naming convention that makes them unique. You see this when you try to enter an NDB in many off the shelf GPS units, and the JS4100's FMC. When pulling the data, even though the RTE info is in conflict, it has to choose one or the other when trying to resolve the ID in the DB. Some part of me thinks that it's an issue in the naming convention within the file itself. As usual, if you feel that this is actually an error, the proper location to submit this message is support.precisionmanuals.com. The forum does not guarantee that this will be seen. A long shot, but how else does the ND paint the tuned beacon location? By looking at the lat/lon position data in the navdata files. Kyle Rodgers
October 16, 201312 yr There are plenty of VORs that share the same name as others and the only differentiating characteristic is the lat/lon. In this case it would seem that the selection criteria is picking the wrong one. Maybe the logic is only looking at the name in the airway instead of the name/lat/lon to make a full match.
October 16, 201312 yr Commercial Member There are plenty of VORs that share the same name as others and the only differentiating characteristic is the lat/lon. In this case it would seem that the selection criteria is picking the wrong one. Maybe the logic is only looking at the name in the airway instead of the name/lat/lon to make a full match. Yeah...my slow brain only picked up on the possibility of a composite key only after I posted that. Good point! Kyle Rodgers
October 16, 201312 yr No. It's a bug in the navdata, which is from a navdata provider. If you use Navigraph, then it's something to bring up to them. Hi Kyle, please can you explain, why you know, that this is a bug in the navdata? Possible, with your explaination you give me a hint how I can fix it ... Thank you, RIchard --- Richard Stefan / Navigraph FMS Data Developer Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures) Direct link: http://www.navigraph.com
October 16, 201312 yr Interesting. Can you post the full route here? I'll try it and see if I can persuade it to do anything different. Also - does the position in the nav data (any coordinates) agree with FSX nav beacon position? I'm thinking the difference is between the waypoints in the nav DB and the beacon location in FS. A long shot, but how else does the ND paint the tuned beacon location? The beacons do not need to be in the nav DB to be tunable. Best regards, Robin. Either way, the coordinates of Larnaca NDB and Larnaca VOR are different in the PMDG wpnavaid.txt file and presumably in the real world. However the wpnavrte UM978 entry does not include "VORD" as part of the identifier, so the FMC would have to check the waypoint coordinates it finds in the wpnavaid file to make sure they match the coordinates given in the wpnavrte file. Can it do that? Seems to me the underlying problem is the RW use of the same identifier, LCA, for two different navaids. Mike
October 16, 201312 yr The logic is: take the first one with this ident from the wpNavAID.txt file - in all examples is the first one the NDB ... Cheers, Richard --- Richard Stefan / Navigraph FMS Data Developer Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures) Direct link: http://www.navigraph.com
October 16, 201312 yr Generally, waypoints that share the NDB ID have some sort of naming convention that makes them unique. You see this when you try to enter an NDB in many off the shelf GPS units, and the JS4100's FMC. When pulling the data, even though the RTE info is in conflict, it has to choose one or the other when trying to resolve the ID in the DB. Some part of me thinks that it's an issue in the naming convention within the file itself. Kyle, sorry but do you really know the ARINC424 nameing conventions? Because, what you wrote isn´t correct - look at LOWG (Graz) - here you have a GRAZ VOR and a GRAZ NDB and both!!! had the same ident! Larnaca, exactly the same - when you don´t believe it, than please take a look in the official AIPs of these countries. Beside all of that: There is NO!! special naming convention for VORs and NDBs ... only when system employing the "NDB" as Waypoint concept, but that´s tailored data and not standard. Cheers, Richard --- Richard Stefan / Navigraph FMS Data Developer Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures) Direct link: http://www.navigraph.com
October 16, 201312 yr Seems to me the underlying problem is the RW use of the same identifier, LCA, for two different navaids. The issue seems to be is how they're differentiated and selected when entering airways into the CDU. If entering an airway selects the NDB instead of the VORDME where the VORDME is called out (by lat/long) in the airway file (I don't have it in front of me so I can't tell) this is a DB lookup issue. Entering by name on the legs page the CDU doesn't know it's supposed to be part of the airway and will give you a list to select from, including the lat/long so you can intelligently pick.
Create an account or sign in to comment