Hi, I have a query about NDB frequencies and DME readings in MSFS.
Several planes that are commonly used in the sim (an example is the Analog King Air, or Carenado PC12), do not have the ability to tune NDB frequencies to decimal places. In the real world this is not an issue, as you just tune to the nearest whole number and because ADFs are about the most inaccurate instrument known to man they still pick it up. However, in the sim, you have to tune to the exact frequency, including the 0.5. This makes some instrument procedures completely unusable in the above planes, an example is EGTK Oxford Airport, where every single instrument procedure requires the OX NDB, which is 367.5, so effectively you cannot fly any of these in the above planes where you cannot tune to a decimal.
The DME also behaves weirdly, to use Oxford again there is only an ILS for 19, but the NDB DME for 01 uses the I-OXF DME, however in the sim this stops reading once you go “behind” the ILS, even though the ILS radiates only one way the DME radiates through 360 degrees, so you should be able to pick it up anywhere.
I know these are both issues that are probably best fixed by Microsoft/Asobo, or the aircraft developers, to allow tuning of decimal NDBs, but seeing as this hasn’t been mentioned by them I’m wondering if there is some way within the navdata to solve this in a temporary way. I know it wouldn’t be 100% accurate to the real world, and of course it would be better if the sim didn’t cause these issues, but given how slow Asobo are at fixing these sorts of minor defects, is there a way to get a version of the navdata you provide for instance that only has whole number NDBs (so to use the OX again as an example this would radiate on 367.0 rather than 367.5), and where every ILS has a backcourse DME in existence, to allow for realistic flying of procedures where the sim can’t compensate for it’s own inaccuracies?
I know the answer is probably no but asking more in hope than expectation, and I also know these issues have been raised with Asobo but they haven’t even acknowledged them in over a year let alone say a fix is anywhere on the horizon, so Navigraph, any chance of being a hero…?
Hi,
thank you very much for your input - indeed interesting request and we like to be “heros”
I don´t say immediately no, it´s worth to try yes … the NDB issue shouldn´t be a big deal, but the backcourse ILS issue. I had an idea how we can solve this MSFS issue with the data for a long time but I haven´t looked deeper into it. I assume, and also due your request, it´s worth to look deeper into this solution, which is in my head.
So, let me add this to our task-list - due the amount of work at the moment, I can´t say if you get a final answer tomorrow or the next days. Also we must test our scenarios but I promise you, that you can expect an answer if yes or no and also a detailed reason for each decision.
So please be patience, I try my best to test my idea during the next week … again, I don´t see any issue with the NDB “correction” but the backcourse ILS needs a little bit more time for testing.
Thanks again for your posting and I will inform you here in the next 7-10 days how and if, we can help you in this case. Is this an acceptable way and time-frame for you?
Richard, that is exactly why you guys are heroes and worth the money every single time!! Of course that’s fine, I appreciate it takes testing and time, my frustration is much more with Asobo/Microsoft not fixing these issues than it is with your data just being a part of it.
Take your time, do and test whatever you need, and I appreciate the in depth and very quick answer.
If I could second the back-course ILS DME issue that would be great. I’ve previously flagged this to ASOBO but it’s probably way down their priority list.
We have found a first solution for the back-course issue but this is still under testing but we discovered a few other things that result from this possible fix. No big issues but worth to clarify first to avoid confusions on the end-user side.
For the NDB frequency issue we have also found a solution and this is also working but we are discussing if we release this fix. The reason for that is the “out of sync” between the charts and the data than and normally we try to be “in-sync” between all our applications.
Overall, I guess we are on a good way … but this two workarounds have no priority on our side sorry. We have a lot of open tasks at the moment, which we must handle first … Such workarounds need a lot of time for testing to avoid possible side-effects and I guess everyone know how long it takes to close/re-start the MSFS to test only one change.
So, please be patience …
Thank you very much,
Richard
PS: this posting will be still open and I have “labeled” as “open-task” on our side, so it will not be overseen
Many thanks Richard - glad you are making progress, completely understand you need to test things and make sure they work.
I also get your hesitancy regarding the NDB fix, and in an ideal world this wouldn’t be required and the aircraft would all have the ability to tune the decimal digit (or it would somehow be sorted in the sim itself) - however I have since discovered even more aircraft (the 414, twin otter, blackbox islander/trislander) that just tune the ADF to whole numbers, so it really does impact many things, hence even if you made it just as an optional extra I’m sure it would be much appreciated (or somehow duplicating every NDB to be whole number and decimal so it didn’t matter which you tuned? I don’t want to suggest things you may have already thought of so I’ll stop there!)
Thank you very much for continuing to look at this, looking forward to hearing (hopefully in not too long!) what you decide to do
