Grand Duke VOR Navigation issues (MSFS2020)
-
Thank you for your kind words. Briefly, it seems that the indexing of the attitude indicator is biased slightly high, so the bottom of the triangle reads the correct pitch, not the top. You can correct this with the knob on the right for now, and I can give you a short snippet of code to do this every time the aircraft loads, if you like.
Regarding the rest of your observations, they do seem highly suspect (thank you for all the pictures), but I have also never seen behavior like that in any of my aircraft while testing. I'm inclined to suggest temporarily removing all the GPS addons from your community folder, and trying to fly some VOR/LOC courses in the no-GPS radio configuration. Out-of-date or incompatible GPS addons cause 99% of the issues I see with CDI/FD readings in my aircraft, though not usually when in VLOC mode. If you're still seeing these problems at another VOR station (you never know what's inaccurate in the MSFS database), then I will really have to think hard about what else to test. I'm sure we can find a solution, but I believe the symptoms you present here are not similar to anything I've seen before.
-
Thank you so much for the reply! I went ahead and completely wiped the KLN-90B, and I don’t have any other GPS units installed. I did a few test flights without it, then reinstalled it again to compare the behavior. I tried different airports and VORs this time.
My findings are a bit mixed, but overall it seems like the KLN-90B might indeed have some impact.
- Flight without KLN-90B
The flight went pretty smoothly overall, but I did notice that the autopilot in NAV/VORLOC mode tends to oscillate a bit while capturing the VOR signal, both enroute and on final. It seems a bit aggressive during the initial turn-in, overshoots slightly and then tries to correct itself again.
- Flight with KLN-90B reinstalled
Surprisingly, things were quite stable at first. I didn’t actively use the KLN-90B during the flight, but I did turn it on and set my destination. NAV/VORLOC mode behaved quite well enroute, with only minor and occasional oscillations, nothing major.
However, things broke down again on final, I saw the same behavior I described in my original post, where the FD commands took me way off course. I climbed out and tried to recapture the VOR from about 50 nmi out, but NAV mode just ended up circling.
Is there any way to completely decouple the GPS from the autopilot or avionics logic when using VORLOC?
- EDM issue
I noticed that sometimes the EDM gives me negative TOTL USD readings that slowly tick up toward zero and then go positive. I suspect this might be related to starting the aircraft on the runway with engines running and then refueling using the tablet.
- HSI course setting
One small nitpick: when flying FROM/TO a VOR, the HSI can sometimes give a slightly confusing readout when setting the course. Even when I try to align my view directly with the gauge, both ends of the arrow can be off by 1-3 degrees. That can result in noticeable deviation over longer legs. Is this something that can be fine-tuned?
Thanks for your support and again, I’m really enjoying the aircraft! Appreciate all the work that’s gone into it.
- Flight without KLN-90B
-
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.
