Skip to content
View in the app

A better way to browse. Learn more.

The AVSIM Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Possible FMC bug?

Featured Replies


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 NDB
At 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/NavData
and looking up UM978, we can see, from the position that this airway is using
the 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 area
and 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

Boeing777_Banner_Pilot.jpg

  • Replies 30
  • Views 5.5k
  • Created
  • Last Reply

Top Posters In This Topic

  • 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

  • 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

Boeing777_Banner_Pilot.jpg

  • 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.

  • 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

Boeing777_Banner_Pilot.jpg

  • 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.

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

 

                    bUmq4nJ.jpg?2

 

  • 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

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.

  • 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

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

richard_stefan.png

Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures)

Direct link: http://www.navigraph.com

 

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

 

                    bUmq4nJ.jpg?2

 

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

richard_stefan.png

Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures)

Direct link: http://www.navigraph.com

 

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

richard_stefan.png

Regular AIRAC Updates - Jeppesen worldwide coverage (includes terminal procedures)

Direct link: http://www.navigraph.com

 

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

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.