Autopilot keeps disengaging NAV mode (VOR-to-VOR navigation)
-
@Tadeus72 The manual clearly states that BlackSquare simulates radio signal propagation and does so quite accurately, just like A2A. In real world operations, pilots rarely use the autopilot in NAV mode tracking a VOR. More commonly, they fly in HDG mode, adjusting the heading according to the VOR indications whenever the signal is available for example, when flying through mountainous terrain or other areas where reception can be affected.
There are countless tutorials and training materials available online explaining how radio navigation actually works. Because of that, it’s not reasonable to compare this product with more simplified implementations where VOR guidance works perfectly all the time. If it always works flawlessly regardless of conditions, that’s actually unrealistic behavior.
Unfortunately, many other aircraft developers including the default MSFS/Asobo aircraft prioritize convenience over realism in this area. As a result, they often teach incorrect expectations and poor operating practices.
Best, Seb
-
@SebAvi Thanks, but I don't think it's about signal degradation. It also happens when the signal is strong and uninterrupted, as well as in planes that don't have custom signal degradation.
For everybody who have issue with VOR make this simple steps. In my opinion blacksquare birds working as expected, in msfs vs reality possibilities.
- Position the aircraft approximately 10–20 NM from a known VOR station and at an altitude that provides a clear line of sight to the transmitter. Best without any hills, min 5000 ft AGL.
- Enter the VOR frequency manually instead of relying on automatic tuning.
- Enable the NAV audio and listen for the station’s Morse code identifier.
- Check the CDI indication, the TO/FROM flag, and verify that the needle responds correctly when you rotate the OBS knob.
- Repeat the test in another pro dev aircraft A2A , blackbird etc preferably comparing an aircraft with analogue instruments to one equipped with a G1000 - Cows DA40/42.
- Test the same VOR after restarting the simulator with all Community folder add-ons disabled.
- If using Navdata, check that the latest AIRAC is installed.
If the VOR works with the G1000 but not with an analogue CDI, the issue is likely related to the specific aircraft or instrument implementation. If only certain VOR stations do not work, the navigation database may be the cause.
-
@HansDeVlieger said in Autopilot keeps disengaging NAV mode (VOR-to-VOR navigation):
What I will do is empty my Community folder except for the Commander 114 and do a test flight without SPAD.neXt or any other program running besides MSFS2024. Then I'll do a flight with my "normal" setup in one of the Bonanzas to see whether it occurs or not. After that, I'll report back.
This will be greatly appreciated! Unfortunately, I think this is going to be a deep simulator level issue, but I've found that unless we can really pinpoint the issue, bug reports are likely to be sidelined. I will really appreciate even one more data point!
@Black-Square OK, I did some more testing and these are my findings:
I am on MSFS2024 SU5.1 and flew 5 different scenario's on the same route: LFSL (Brive-la Gaillarde) -> MEN VOR 115.30 MHz (Mende) -> VOR CFA 114.35 MHz (Clermond-Ferrand-Auvergne) -> LFLC (Clermond-Ferrand).
Altitude 7500 ft MSL.
NAV-data: Navigraph AIRAC cycle 2607 (2608 came out during my "investigation").
PC restart between flights.-
Commander 114 - MX-170B radios, MC60 Digital Localizer and ILS 400, Narco DME UDI-4, S-TEC Programmer,
Blank (=empty) Community and Community2024 folders, except <<black-square-commander114>>
No external programs running (no SPAD.neXt, TrackIR5, MSFS AutoFPS, Navigraph Charts, Little NavMap etc.)
Observations: Autopilot NAV disengaged every couple of minutes (variable) without apparent reason during climb-out and cruise. -
Commander 114 - MX-170B radios, MC60 Digital Localizer and ILS 400, Narco DME UDI-4, S-TEC Programmer,
Selected apliccable and my usual "standard" Add-ons in Community and Community2024 folders via Addons Manager
External programs running: SPAD.neXt, TrackIR5, MSFS AutoFPS
Observations: Autopilot NAV disengaged every couple of minutes (variable) without apparent reason during climb-out and cruise. -
Bonanza TC - KX-155B radios, KI 525A HSI and KI 229 RMI, KDI 572R DME, KFC 150 Autopilot,
Selected apliccable and my usual "standard" Add-ons in Community and Community2024 folders via Addons Manager
External programs running: SPAD.neXt, TrackIR5, MSFS AutoFPS
Observations: Autopilot NAV disengaged every couple of minutes (variable) without apparent reason during climb-out and cruise.
Autopilot NAV disengaged during ILS-approach. -
Daher TBM 850 - KX-155B radios, KI 525A HSI and KI 229 RMI, KDI 572R DME, KFC 150 Autopilot,
Selected apliccable and my usual "standard" Add-ons in Community and Community2024 folders via Addons Manager
External programs running: SPAD.neXt, TrackIR5, MSFS AutoFPS
Observations: Autopilot NAV disengaged 7 times without apparent reason during cruise. -
Just Flight - Piper PA28 Turbo Arrow III- KX-170B radios, HSI, VOR1 / ILS and VOR2 indicators, KN 62A DME, standard Autopilot unit,
Selected apliccable and my usual "standard" Add-ons in Community and Community2024 folders via Addons Manager
External programs running: SPAD.neXt, TrackIR5, MSFS AutoFPS
Observations: Autopilot HDG and NAV physical switches switched off 9 times (variable interval) without apparent reason during climb-out and cruise.
A spilt second before HDG and NAV switch off the aircraft banks slightly to the right or left.
In all scenarios CAP and SOFT indicator lights on the AP panel dim or turn off/on - off/on - off/on regularly (might be intentional?).
NAV disengages at random moments in time and distances from/to different VOR stations (with ranges of 60, 100 and 150 NM), also when unobstructed line of sight.
DME seems to work fine all flight long, no interruptions or misreadings observed.My conclusion is that the disengaging of NAV is not likely to be related to any particular aircraft (I didn't test a stock MSFS2024 aircraft though), nor having anything to do with the signal degradation feature in Black Square's aircraft. Which by the way for me adds a lot to the illusion of "flying" a real aircraft. I do take this degradation into account when flying VOR-to-VOR (use of AP HDG when the VOR signal is not yet stable or transitioning between to/from legs or from VOR1 to VOR2).
So, even the TBM 850 and the Arrow III show the issue and I am quite confident that this didn't occur before SU5 or SU5.1.@SebAvi I am aware of how radio navigation actually works in the real world and I know how ASOBO actualy implemented the unrealistic signal "on-or-off" behaviour. But I also do appreciate the fact that I can rely on an Autopilot to track a VOR radial. As stated before I am not a pilot. This is my hobby, I am not flying a real airplane with real threats and challenges (I wish I could!). The life of a average flightsimmer comes with having to walk the dog, feed our cat, change our grandson's diper, make a coffee and a couple of sandwiches during that 4-hour flight etc. and then to be able to use a simplified version of the real world is a usable shortcoming. And for adding back in some realism, we have our quality developers like Black Square. Thanks Nick!
-
-
Maybe this post is important. SU6 solve this issue perhaps.
https://forums.flightsimulator.com/t/vor-range-often-incorrect/406277/85
@SebAvi That might very well be related. Let's hope so. Thanks for the heads up.
-
Doesn't seem related at all, but maybe they will fix something in the code by mistake when adding/fixing those longer range VOR stations
In general I'm not sure if Asobo is even aware (and how it was described to them). There was a longer discussion on this topic in the Aircraft section of the official forums. But the only report I have seen was a user trying to report it and the answer from the mod was that this doesn't qualify as a report in this form. Not sure if the user re-tried in another form.
-
What I don't know is if developers have a feedback channel with Asobo where they can report the issue. After all they are the ones who get the feedback from their users / customers (questioning their product, not me btw
). Maybe Nick can comment on this. -
Found the report I was writing about.
Commendable effort on the side of the user, but I think he gave up in the end
https://forums.flightsimulator.com/t/bug-multiple-planes-change-from-nav-to-rol-hdg-mode-when-tracking-vor/762974/10
BTW. It not happening for me in the F28 and Bae146 might be suggesting that it's about the standard AP units. Both planes are larger and have the AP functions spread over the cockpit, with probably some custom coding involved to make it happen - and not just a standard AP panel.- decided to withdraw the conclusion as I just realized the 114 also has a custom AP panel and it also happened with the StarshipEither way, have some examples from YT (link should point to the specific moment):
https://youtu.be/1a-g3UMooCs?t=4393
On glideslope for some time now, clear view of the runway, APR randomly moves back to ROLL (the popped breaker is not about this, it's an icing sensor and was known).
Here a similar situation:
https://youtu.be/300F3IcCAqM?t=3593The same, but with only a localizer.
Normally it happens with VORs, was just easier to remember and find those two.
-
Found the report I was writing about.
Commendable effort on the side of the user, but I think he gave up in the end
https://forums.flightsimulator.com/t/bug-multiple-planes-change-from-nav-to-rol-hdg-mode-when-tracking-vor/762974/10
BTW. It not happening for me in the F28 and Bae146 might be suggesting that it's about the standard AP units. Both planes are larger and have the AP functions spread over the cockpit, with probably some custom coding involved to make it happen - and not just a standard AP panel.- decided to withdraw the conclusion as I just realized the 114 also has a custom AP panel and it also happened with the StarshipEither way, have some examples from YT (link should point to the specific moment):
https://youtu.be/1a-g3UMooCs?t=4393
On glideslope for some time now, clear view of the runway, APR randomly moves back to ROLL (the popped breaker is not about this, it's an icing sensor and was known).
Here a similar situation:
https://youtu.be/300F3IcCAqM?t=3593The same, but with only a localizer.
Normally it happens with VORs, was just easier to remember and find those two.
-
Yep, that was my original post in the MSFS forums about this issue, and yes I've just lived with this for some months.
I am also getting this behavior in the Commander.I have a workaround I've set up in multiple planes with some Spad.Next trickery, where I can activate/deactivate monitoring for when Nav mode is lost. When that happens, it quickly turns it back on again. It works pretty well.
Ironically, it seemed that if I didn't have SPad.next running, this problem didn't happen in the first place. It makes me think that Spad simply listening or polling certain variables might be causing this, but it would take some deep debugging to troubleshoot this.
Feel free to add observations to that thread for visibility to Asobo. I'm doing a VOR tour of Alaska in the Commander (before it gets too cold/icy for this plane), so maybe I'll experiment a bit this weekend.
-
Yep, that was my original post in the MSFS forums about this issue, and yes I've just lived with this for some months.
I am also getting this behavior in the Commander.I have a workaround I've set up in multiple planes with some Spad.Next trickery, where I can activate/deactivate monitoring for when Nav mode is lost. When that happens, it quickly turns it back on again. It works pretty well.
Ironically, it seemed that if I didn't have SPad.next running, this problem didn't happen in the first place. It makes me think that Spad simply listening or polling certain variables might be causing this, but it would take some deep debugging to troubleshoot this.
Feel free to add observations to that thread for visibility to Asobo. I'm doing a VOR tour of Alaska in the Commander (before it gets too cold/icy for this plane), so maybe I'll experiment a bit this weekend.
@SteveKane Thanks for the tip I must try your SPAD.neXt trick.
BTW, in my attempt to isolate the cause, I tested several scenarios that I described in my earlier post (see above). In the first scenario SPAD.neXt was not running, so I think this is not related. -
@SteveKane Thanks for the tip I must try your SPAD.neXt trick.
BTW, in my attempt to isolate the cause, I tested several scenarios that I described in my earlier post (see above). In the first scenario SPAD.neXt was not running, so I think this is not related.@HansDeVlieger said in Autopilot keeps disengaging NAV mode (VOR-to-VOR navigation):
@SteveKane Thanks for the tip I must try your SPAD.neXt trick.
BTW, in my attempt to isolate the cause, I tested several scenarios that I described in my earlier post (see above). In the first scenario SPAD.neXt was not running, so I think this is not related.Can confirm, never had SPAD installed and I don't have it now
I'm wondering if it's really a very small subset of users experiencing it or if the rest just thinks this is intended behavior and accepts it.
-
@HansDeVlieger said in Autopilot keeps disengaging NAV mode (VOR-to-VOR navigation):
@SteveKane Thanks for the tip I must try your SPAD.neXt trick.
BTW, in my attempt to isolate the cause, I tested several scenarios that I described in my earlier post (see above). In the first scenario SPAD.neXt was not running, so I think this is not related.Can confirm, never had SPAD installed and I don't have it now
I'm wondering if it's really a very small subset of users experiencing it or if the rest just thinks this is intended behavior and accepts it.
@Tadeus72 I'll devote my final weekend flight tonight to test a flight without SPAD and see what happens. IIRC, even running SPAD early in the flight and killing it still had the disconnect behavior, so I'll start the sim afresh with no Spad running. (gonna be weird to "mouse" everything, lol).
Stay tuned!
-
Yep, that was my original post in the MSFS forums about this issue, and yes I've just lived with this for some months.
I am also getting this behavior in the Commander.I have a workaround I've set up in multiple planes with some Spad.Next trickery, where I can activate/deactivate monitoring for when Nav mode is lost. When that happens, it quickly turns it back on again. It works pretty well.
Ironically, it seemed that if I didn't have SPad.next running, this problem didn't happen in the first place. It makes me think that Spad simply listening or polling certain variables might be causing this, but it would take some deep debugging to troubleshoot this.
Feel free to add observations to that thread for visibility to Asobo. I'm doing a VOR tour of Alaska in the Commander (before it gets too cold/icy for this plane), so maybe I'll experiment a bit this weekend.
@SteveKane said in Autopilot keeps disengaging NAV mode (VOR-to-VOR navigation):
Yep, that was my original post in the MSFS forums about this issue, and yes I've just lived with this for some months.
I am also getting this behavior in the Commander.I have a workaround I've set up in multiple planes with some Spad.Next trickery, where I can activate/deactivate monitoring for when Nav mode is lost. When that happens, it quickly turns it back on again. It works pretty well.
Ironically, it seemed that if I didn't have SPad.next running, this problem didn't happen in the first place. It makes me think that Spad simply listening or polling certain variables might be causing this, but it would take some deep debugging to troubleshoot this.
Feel free to add observations to that thread for visibility to Asobo. I'm doing a VOR tour of Alaska in the Commander (before it gets too cold/icy for this plane), so maybe I'll experiment a bit this weekend.
Hi SteveKane,
I contributed to your post in MSFS forums some time ago, sadly without much response.
Maybe some of those reporting here can contribute too over at MSFS.
I found the problem in many BKSQ aircraft, and some others, but curiously not in the Commander 114. At least not until now, after several flight hours in VOR NAV.
At least I can confirm that it has nothing to do with add-ons, since I don't use any - aside from aircraft and scenery.
And it does not depend on signal strength, since it happens in all distances. -
Interesting, as I've seen this behavior in I think all BKSQ aircraft, including the Commander.
I've got a couple of scenarios I want to try tonight:
-Try using the RNAV receiver with distance = 0.
-Start with SPAD, track VOR, wait for it to disconnect once, then kill SPAD and see what happens. (I think I've tried that before, and the disconnects continued, but that was months ago.) -
@Black-Square
Thanks again for taking the time to take a look at my issue.
I'm afraid I don't know an awful lot about the magic behind the interacting between add-on airplanes and the simulator, but I understand what you're saying. I don't use FSUICP but use SPAD.neXt instead to manage my hardware. In this case I use the Honeycomb Bravo's autopilot feature.I must say this is the first time I run into this. I have a fair collection of Black Square aircraft and I don't recall I saw any disconnection issue before. I am not sure about the Dukes and Starship but I did quite a lot of hours in the TBM 850 and the Bonanzas.
What I will do is empty my Community folder except for the Commander 114 and do a test flight without SPAD.neXt or any other program running besides MSFS2024. Then I'll do a flight with my "normal" setup in one of the Bonanzas to see whether it occurs or not. After that, I'll report back.@HansDeVlieger Hans, I read your post and wondered if you have tried using ‘empty” hardware control profiles in MSFS to find the problem, not just an empty Community folder?
I had a related problem with the Honeycomb Bravo where commands pre-assigned to the default Honeycomb Bravo controller profile conflicted with a command that I was trying to assign in Axis and Ohs (similar keyboard software to Spad.next).
Once I created an empty hardware profile for the Honeycomb Bravo, my problems disappeared. After that I was able to add commands back in step by step. I only mention this as the Bravo fires commands constantly and the default Bravo profile contains commands for all of the autopilot controls and something there could potentially by causing your problem.
I could also be completely wrong but wanted to let you know my experience and how I solved it, in case it helps you too.
-
I tested as follows: used Spad, climbed to 11000 feet. It took a while, but finally got a disconnect. Turned off Spad, eventually got another. It seems at higher altitudes, there are much longer intervals between disconnects than my current flight at 6000 feet, have had six disconnects in about 12 minutes all with SPAD. I'm using SPAD to output a voice when it runs my auto-reset to NAV mode code. (In fact, as I type, it's now up to 11 instances.)
Anyone else note a correlation between cruise altitude and disconnect rates?
-
@HansDeVlieger Hans, I read your post and wondered if you have tried using ‘empty” hardware control profiles in MSFS to find the problem, not just an empty Community folder?
I had a related problem with the Honeycomb Bravo where commands pre-assigned to the default Honeycomb Bravo controller profile conflicted with a command that I was trying to assign in Axis and Ohs (similar keyboard software to Spad.next).
Once I created an empty hardware profile for the Honeycomb Bravo, my problems disappeared. After that I was able to add commands back in step by step. I only mention this as the Bravo fires commands constantly and the default Bravo profile contains commands for all of the autopilot controls and something there could potentially by causing your problem.
I could also be completely wrong but wanted to let you know my experience and how I solved it, in case it helps you too.
@toby23 Thanks for joining.
Yes, I empty any MSFS hardware profile for the Honeycomb Bravo with any new aircraft as I use SPAD.neXt (only exception: for some aircraft I use the standard axes bindings). Conflicting bindings are very often the root cause of strange behaviour of the sim, so I agree with you to look for those first.
