Grand Duke VOR Navigation issues (MSFS2020)
-
Thanks for experimenting with this. That's very interesting that you are getting different results with the KLN installed. To answer your question, they should always be completely decoupled when in VLOC mode, which is why I am so surprised by your symptoms. Usually when I see anything that looks like this, it's while trying to follow a GPS course. Are you sure you have the MSFS 2020 version of the KLN installed, and not the MSFS 2024 version? I can't imagine that would be the issue, but it's a thought.
The easiest thing for me to suggest is for you to keep flying with the KLN uninstalled and see if you ever have this issue. If not, then we can really suspect the KLN. I can then explore myself and talk to the developer of the KLN. I know that would be very inconvenient to some users, but you seem like you might take that as an opportunity to practice your radionagivation skills, as I would. I apologize if my estimation is not accurate.
Yes, the fuel totalizer will read negative if you load fuel while on the runway, since you're obviously not meant to fuel the real airplane while the engines are running. You could reset it by pulling the engine monitor circuit breaker (bottom-most row of the two circuit breaker panels on the right of the cockpit).
Unless I misunderstand your comments about the HSI, I checked the model file, and the course pointer is indexed perfectly with the compass card. The force of gravity and acceleration can affect the CDI reading, but not the course pointer. Are you sure you're not just observing a parallax effect, and if you moved the camera further down to be level with the instrument, they pointers would not align?
-
Yep, I saw that they have a separate module for MSFS 2024, and I’m definitely using the one made for MSFS 2020 :)
I’ll keep flying the Duke without the GPS for a while and report back with my findings, definitely a good excuse to practice some raw navigation anyway!
Thanks for checking the HSI model file, I'm honestly not 100% sure if what I saw was a parallax issue or something else, so I’ll take a closer look from a better viewing angle next time.
Speaking of CDI behavior, I noticed that the CDI tends to wobble a bit too much when flying enroute, especially at distances around 60–90 nmi from the VOR. The aircraft is quite stable, and the autopilot is holding course perfectly, but the CDI needle still twitches back and forth, even though there’s no actual course correction happening.
I’ve seen some wild ADF/NDB needle behavior, which makes sense given how those systems work, but with high-power enroute VORs, and especially on the CDI, I’d normally expect things to stay a bit more stable. I’d be really interested to hear your thoughts on the current implementation.Really appreciate the your response!
-
Fair question! I’m basing it on real-world flight experience, though with a slightly different type of HSI (Bendix KI525).
I completely understand that some needle movement occur in real-world conditions, due to number of factors. Yet in this case, with the aircraft flying steady and the autopilot holding course, the CDI felt a bit more twitchy than I’d normally expect at close range.
I brought it up more out of curiosity than criticism, just trying to understand whether this is considered expected behavior or maybe something worth a closer look. I really appreciate your thoughts on it!
-
@Black-Square What’s the best way to bind electronic trim toggles on the yoke to some buttons or keyboard keys? I couldn’t find any specific options for them in the MSFS settings unfortunately. Would appreciate any pointers if I’m missing something
-
Fair enough, thanks for chiming in. I agree that some CDI movement is normal when signal quality drops off, especially with marginal VHF reception.
That said, what I’m seeing isn’t just the occasional fluctuation you'd expect near the edge of range or in rough conditions. It’s happening in smooth air, autopilot locked on, within 35 nmi of a high-power VOR. No terrain, no weather, no heading changes, just the CDI needle drifting back and forth for no apparent reason. Check out my video: I’m flying two enroute VORs at roughly equal distances and well outside the cone of confusion. In the first example the CDI is oscillating noticeably, in the second it’s rock solid.
It’s not a dealbreaker by any means, but it does raise an eyebrow. Could be a sim quirk or maybe some intentional randomization built into the logic, hence the question. Either way, figured it was worth pointing out.
Appreciate the exchange as always.
-
Thanks for the video. That illustrates perfectly what you're seeing, and also why a screenshot or video can be so helpful. All powers of VOR transmitters are considered to have a service volume that begins at 1,000ft above the station. For high and low powered stations, this lowest altitude service volume is considered to have an effective radius of only 40nm. For terminal stations, it's only 25nm. In the lowest portions of the service volume, the signal's propagation is usually depicted as being hemispherical, meaning that it falls off quickly at the extremities. What you're seeing here is just being on the very edge of the service volume at low altitude.
That being said, you are not the first person to complain that my signal degradation code is a little aggressive. While I have my intuition from flying my airplane too, I often find myself programming based on charts and equations, and then seasoning to taste with my own experience, rather than the other way around. This means that the signal degradation might be accurate to the service volumes that we're taught in ground school, but that real world performance may greatly exceed those worst-case numbers we're presented in the textbook. I have been meaning to revisit those algorithms now that the whole system has been working well out in the wild, so your commentary will be one more reason to do so soon.
-
Hi guys, I'm the author of the KLN-90B and I'm reading this topic with great interest.
Unlike most other GPS units, the KLN-90B does not touch the autopilot in any way. I only write GPS simulation variables that can then be used by a custom autopilot or the default autopilot of the sim. I assume the only thing that could go wrong here is if I write a variable I should not be touching when it is in VLOC mode. However, in your screenshot of the approach you turned the KLN off. In this case, the KLN does not perform any calculations at all and it will not touch any simulation variables either. So with the KLN off, I'm absolutely certain, that the KLN cannot interfere with the autopilot.
You should see the same behavior with the KLN installed and without. Only if you install another GPS unit, you should see a different behavior, as those usually come with their own custom autopilot. -
@Black-Square Thanks so much for the detailed reply, really appreciate you taking the time to explain it all. I’m glad we’re on the same page here. That all makes a lot of sense, especially the part about service volumes and how things drop off near the edge at low altitude.
Honestly, it’s great to hear how you approach the logic, ground school theory first, then fine-tuned with real-world experience. That mindset definitely shows in how well the Duke flies.
And yeah, if you ever revisit that part of the signal logic, happy to help test or throw more edge cases your way ;) Loving the aircraft and really appreciate the back-and-forth!
p.s. I’m still trying to figure out how to bind electric trim, does MSFS support that directly?
-
hi @falcon71, thanks so much for jumping into the conversation and also for your fantastic KLN-90B implementation! I use it on almost every flight and it’s truly a delight to work with, the level of detail and thought put into it really shows.
As for the issue I mentioned earlier, I’ve been flying the past few days with the GPS turned on but sticking strictly to VOR navigation, trying to reproduce it, and so far I haven’t been able to. Not sure what to say here, I’ll keep flying this beautiful aircraft and let you guys know if I notice anything else, are there any logs that I can share here when I reproduce the issue again?
Appreciate all the work you’ve put into this!
-
@John-S Thanks for the kind words, I'm glad to hear that you are having fun.
Logs are a bit difficult, since I cannot write to the file system with JS avionics. Best would be if you could find a reproducible case. Like a sequence of actions and a specific approach that always results in the problems you see. If I can then reproduce the issue on my machine, I can use the debugging tools to see what is going and then it is usually easy to find and fix the issue. The most difficult part is usually to reproduce the issue. A video also helps a lot to see what steps you are taking.
