NDBs and DMEs in MSFS

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…?

Cheers!

Hi,
thank you very much for your input - indeed interesting request and we like to be “heros” :slight_smile:

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?

Cheers,
Richard

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.

All the best!
Peter

1 Like

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.