I have posted a link to this topic on the Navigraph forum and got the following answer from Richard.

 

Quote

 

Hi Soeren,
I haven´t an AVSIM account, so I can´t see the screenshots. Anyway, I have looked into the database and had compared the PMDG files.

The answer of "scandinavian13" in the AVSIM forum is not very "competent", sorry! I will try to explain why:

First, there are indeed two LCA navaids, one VOR and one NDB:
LARNACA LCA NDB 34.820278 33.554167432.00N
LARNACA LCA VORD 34.872861 33.625581112.80H

Both are included in the PMDG navaid-file.

Ok, than we look into the airway UM978 (I pick only the important sequences):
UM978 030 RUBIK 34.903334 33.081667
UM978 031 LCA 34.872861 33.625581
UM978 032 SOBOS 34.925000 33.945000

You see in the airway file, that there is no information, if LCA is an VOR or an NDB, nor any frequency ... only the ident plus the coordinates. Now, when you compare the coordinates with the coordinates in the navaid file, you see, it should be the VOR because the NDB has slightly other LAT/LONG coordinates.

Conclusio:
The navdata files are correct, and the LCA position is equal with the position of the LCA VOR in the navaid file, so the PMDG should select the right frequency. I won´t say, this is a bug in the PMDG but as you see, there is no possibility to define which type of waypoint this is.

Here the result of your other examples:
GRAZ GRZ NDB 46.920656 15.458953290.00N
GRAZ GRZ VORD 46.955367 15.449431116.20H

UP978 004 ABIRI 46.762503 14.967572
UP978 005 GRZ 46.955367 15.449431
UP978 006 GOTAR 46.997881 16.224764
UT23 017 BIRGI 47.347778 11.923889
UT23 018 GRZ 46.955367 15.449431
UT23 019 NIDLO 46.804175 15.995600

LAVAN ISLAND LVA NDB 26.800028 53.386306310.00N
LAVAN ISLAND LVA VORD 26.812056 53.355861116.85H
G666 006 DATUT 26.561667 53.561945
G666 007 LVA 26.812056 53.355861
G666 008 LAM 27.372833 53.183972

It´s always the same schema. Additional to this: thats exactly the reason, why I must add a "NB" at the end of each NDB-Ident in the procedure-files, because I can´t differ between a VOR and an NDB, when the idents are the same (as an example: LOWG GRZ for GRZ VOR and GRZNB for GRZ NDB - 17C/SID GOLV2G is using the GRZ NDB and GRZ3X the GRZ VOR).

Possible it´s a navdata issue, but then someone must explain what I should do in this cases.
Sorry, at the moment I can´t do more for your ... I use the right navaids, as you see exactly the same position - so in my eyes, it should work ...
Cheers,
Richard

PS: I have find out a "rule": The PMDG takes every time the first navaid with this ident ... means when the first ident LCA, GRZ, LVA is an NDB (and in all three cases, it´s this order), than the PMDG stop search and takes this waypoint. So, I´m nearly sure, that the PMDG don´t compare the coordinates to find the right navaid - the PMDG looks only for the first existing ident ...

 

End Quote.

 

So where is the problem.

 

I do not know.

 

But I do know, it is not working as, it should be working.

PMDG and Navigraph should put their expertise together and find a solution on this issue.

 

Best regards

Soeren Nielsen♦

Have just submitted a ticket on this issue to PMDG.

 

Soeren Nielsen

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,

 

As a customer of yours, please understand that what I said wasn't a personal shot at you.  I clearly appreciate what you do, else I'd take my business elsewhere.  Had you taken the time to read the rest of the posts in the thread, you would have seen that I conceded that it could be an issue with how the system is calling the data.  You would have also seen that I never mentioned the ARINC format at all in any of my posts.  I didn't even know you all used the ARINC format until you just said it.

 

My initial reaction was just a gut reaction based on the fact that Soeren posted screenshots of the data files.  Those files come from Navigraph, so I'd assumed that was the issue.  It was wrong.  I'm sorry for that, but I don't think I quite deserved the kind of response that I got.

Richard!

 

Thank you very much.

 

 

Kyle!

 

With all due respect, for your knowledge in many areas, I think you should, not just be assuming, but sometimes closely read the topic, and think, before you answer.

 

 

This issue has been bothering me for 2 years now. As a professional navigator, not in the air, but at sea, you do not rely on a single navigation system (GPS, the magenta line)

but crosscheck your position by other means, which is exactly what I have done in this case, and found a possible bug in the FMC programming.

 

Finding yourself suddenly 5 nm off your planned track, without any obvious reason, is really not a acceptable situation, not in real life, nor in this

"extremely sophisticated simulation with nearly every function of its real-life systems modeled in high fidelity"

 

In the air ATC starts screaming at you, and in the US FAA Inspectors will bee knocking at the cockpit door, before you have completed your shutdown checklist.

At sea, in coastal waters, if not following the recommended routes, grounded or not, the VTS and or the Coastguard will be on your back.

 

Best regards

Soeren Nielsen

 

 

Kyle!



With all due respect, for your knowledge in many areas, I think you should, not just be assuming, but sometimes closely read the topic, and think, before you answer.

 

 

+1

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

You know there are MULTIPLE waypoints with the same ident? Just enter AA for example and look at the PAGES you can select from. As for the unique part of the ident? It's the Lat/Lon of the beacon/waypoint that makes it unique.

 

There are two things the system does to help us ID the position we want by listing in order of DISTANCE, and the Lat/Lon of the waypoint in question. It is the duty of the pilot to cross-check that beacon/waypoint he is entering is the one he thinks it is. Computers make mistakes.

 

As for the mistake with incorrect beacon selection, it seems the FMS is ignoring the database, because the airway data CLEARLY states that it belongs to the VOR and not the NDB of the same name. If the FMS was doing its job correctly, it would see the two waypoints have the same POSITION, and thus select the correct beacon (and in fact no look-up is required as the position data is right there in the airways data, so no excuse).

 

If the real unit works the way the sim does, the designer wants to be fired.

 

Best regards,

Robin.

Hi Kyle,

thanks for your posting - the problem was, that I´m new here, so my postings must be approved thru a moderator first - therefore, the delay of my postings which I had made long before all other postings were written. In german it´s called "unglücklich gelaufen", which means like an english phrase "a perfect storm" ...

 

The main thing, why I had comment your posting is, that nearly all the first reactions with such issues are, that this is a navdata issue. This issue is still existing since the first release of an PMDG addon. Now, PMDG had released a new addon and NO ONE, NEVER had asked, why we add a "NB" at the end of each NDB in the procedure files ... because the result of this workaround ends in different problems: ie. when the last point of a SID ends at an NDB you can´t connect it directly via an airway, because in the airway file the NDBs are without the "NB" prefix, ... same now in the airways and the autotuning, ...

 

We (especially I) are not perfect, and we make mistakes too - but sometimes, like in this case, we haven´t any chance to fix it by yourself and it looks like, it´s really a PMDG issue :mellow:

 

Thanks again and please don´t understand my posting wrong - It wasn´t my intention to attack you ..

Cheers,

Richard

 

PS: moderate posting too - written at 7 o´clock UTC :blush:

OK, I think we've all come to the same conclusion - there's a flaw in the way the FMC logic picks the waypoint from the database. It appears it's not even restricted to the 777 but something that's persisted since the 73. I'm sure PMDG will figure out the same fix (search by name/lat/lon instead of just name) when doing the DB lookup from entering an airway and address the issue. No reason to keep beating the dead answered horse.

as someone submitted a support ticket so they are aware to even apply the fix?

as someone submitted a support ticket so they are aware to even apply the fix?

 

Have just submitted a ticket on this issue to PMDG.

 

Soeren Nielsen

 

It would appear so.

 

 

Kyle!
 
With all due respect, for your knowledge in many areas, I think you should, not just be assuming, but sometimes closely read the topic, and think, before you answer.

 

Fair enough.  I try, but there's definitely a gut reaction that kicks in because it looks like so many of the other issues that keep coming up over and over again because people aren't reading the manuals, etc.

 

 

 

thanks for your posting - the problem was, that I´m new here, so my postings must be approved thru a moderator first - therefore, the delay of my postings which I had made long before all other postings were written. In german it´s called "unglücklich gelaufen", which means like an english phrase "a perfect storm" ...

 

Gotcha - I can see how that all worked out now.  Definitely a perfect storm situation, especially when you have to write on the defensive position after I asserted my initial position.

 

 

 

We (especially I) are not perfect, and we make mistakes too - but sometimes, like in this case, we haven´t any chance to fix it by yourself and it looks like, it´s really a PMDG issue
 
Thanks again and please don´t understand my posting wrong - It wasn´t my intention to attack you ..

 

Agreed.  Clearly I'm not, as displayed here by my gut reaction posting instead of actually looking at the issue.  Honestly, looking back at what you wrote, I probably would've reacted the same way if someone accused me of being wrong.

Kyle wrong? never? 

Have received the following answer on my ticket.

 

Quote

Soeren,

I have submitted this item to the team to look into to determine if the problem is in the way the FMC is reading the data or if there is actually a format error with the Navdata files.   Any corrections that we can make if it is something we can fix would be part of the SP1 update but if it turns out to be a Navdata format issue then it would be up to the creator of the Navdata file to correct.

 

Paul Gollnick
Technical Support

PMDG Simulations, LLC

www.precisionmanuals.com

End of quote

 

Soeren Nielsen

And have replied to PMDG as follows:

 

In the case, very unlikely in my opinion and others, including Navigraph, the provider of the navdata, is a format error in the navdata,
then please contact Navigraph directly to define your requirements.
Please closely read every post in the topic.
Richard Stefan / Navigraph FMS Data Developer has participated
and is at a blank if it is a format error from their part.

Soeren Nielsen

Soeren,

Please stop acting like we're ignoring you or not going to look at this. Paul put it into the bug tracker for the FMC programmer to look at and that's exactly what he told you he did. It will be looked at - you don't need to do anything else.