The KAP 140 Autopilot will not work more than once per flight

[Bishop398]

@NixonRedgrave

They can say what they want about the add-on “simply being a pass through”, but I have documented evidence that it breaks the autopilot in the V35B.

It may indeed. The aircraft was created before the new GNS and as such does not use the new GNS. Using the Marketplace package to bridge the old GNS to the new GNS is not guaranteed to work properly, depending on how a given aircraft is coded. The package is provided as a convenience for those planes that do happen to work with it bridged and have yet to be updated, as third parties do not always update their airplanes when these avionics are upgraded.

If the airplane is functioning as originally designed, then I think this is not a bug. Support for the new GNS only extends to those planes designed with it in mind. While of course we’d prefer developers to use only the new GNS as well as update old planes, we can’t force them to, nor could we have removed the old GNS units from the sim and left both customers and developers with broken (and already purchased) aircraft.

It’s not ideal, but it’s the most ideal scenario that could realistically be provided.

[NixonRedgrave]

Apologies if that read as a dig. It wasn’t meant as such.

The issue really stems here from the communication, or rather the miscommunication, that is continuously passed around by members of the community about what the add-on does and when it’s needed and how it might affect aircraft systems when it is installed.

I know you all tried your best here, and it’s really easy to be critical with the benefit of hindsight.

It just hasn’t worked out smoothly and the fact that we’re still here having this conversation a year out since AAU1 was released is testament to that.

I wonder if the better approach would have been to make the Asobo GNS the add-on rather than promote the use of the bridge add-on we have now. Sure, forcing the WT GNS upon all GNS-equipped aircraft would have introduced issues, but in so doIng we wouldn’t be here with recently released/updated aircraft getting the Asobo version implemented by default.

Again, it’s all hindsight.

I would hope, that in light of all the continued confusion and frustration generated by these unfortunate mishaps, that the documentation or some other means could be reviewed and, maybe, holes found in the process by which developers are educated about how to implement the GNS moving forward.

I have no doubt that you have probably already created excellent documentation, but something isn’t working and I feel it will “always” be like this unless some solution can be found to fix the process.

[nebo]

after hours of investigation, removal of mods, etc. we finally discovered the source of the problem: the TDS GNS 750 tray app was running and needed to be updated.

thanks to everyone who helped investigate this impossible problem.

Interesting details:

• I had removed ALL mods from Community and had uninstalled all the mods from marketplace official that raised conflicts in the simstaller tool from Parallel 42. The simstaller scan was completely clean, yet the error persisted.

• I had forgotten that I had the TDS autolaunch via exe.xml on sim startup to save starting it each time manually.

• I didn’t realize that the TDS app needed an update.

It appears that there were no javascript overrides from other mods involved in this error. Instead, my guess is that the TDS tray app is using SimConnect to implement a handshake using AP events. When it misinterpreted my AP reengage as a handshake from the 750, it may have sent an unknown pattern of rapid AP events to “establish” connection to the AP in case the user is running a TDS GNS 750. No one expected this interaction, although WT did recognize it as an “old bug” they thought TDS had fixed.

The TDS system consists of 3 components: a tray app, a JS mod in Community, and the Garmin trainer software for the 750 outside the sim. The tray app needs to watch for the JS mod “turning on”, at which point it starts a Garmin 750 process in the background and sends that display to the JS mod in aircraft that support the TDS 750 for rendering in the virtual cockpit.

What was completely unexpected was that the JS mod was uninstalled and the aircraft being tested (Asobo C172 steamgauge) did not use the 750 at all. That leaves the TDS tray app which was apparently injecting simevents that hung the AP under certain circumstances.

When we removed the TDS tray app, everything worked. I then checked the TDS app for updates, and found that it was behind by several versions. (This is why my other request for managing mod updates is so important.)

Lastly, I want to reflect on the amount of pain involved in debugging these dependencies. I don’t expect devs to know every combination, but likewise users shouldn’t be expected to try every combination of system configuration to isolate the problem.

What didn’t work:

• telling me I wasn’t using the AP correctly without seeing what I was doing
• “whatabout-ism” involving every possible component of the system, even down to windows install
• lack of awareness that not everyone’s system in Windows is the same, and that’s ok, and it’s NOT automatically a cause.

What did work:

• streaming/video capture of the actual problem. there were 1000 details missed in text. we kept talking past each other. sharing the video was a real breakthrough in allowing people to see and agree on the ground state.

• debugging a chain of evidence rather than “guessing”. it’s ok to have hunches, but then follow them up and actually PROVE the relation exists.

Some of these points are on the user side (like screen recording problems) and some are on the dev side (like proving instead of guessing). Some may be on the platform (Asobo) side: if we had a tool showing us where Simconnect messages were coming from, we might have instantly discovered that the TDS tray app was reacting to the AP reengage and sending unexpected messages to the AP causing it to hang.

It may help if TDS put a line in their user manual saying “the TDS app should only be run if you are using the TDS. unintended side-effects may occur if you run the app with other planes/avionics.”

Earlier I had also tried a mod fix and an unpublished fix from BKSQ in the justflight forums. neither of these had any effect on my issue and were unrelated.

The problem began back in November, total time spent debugging and triaging was probably 6-7 hours total. I fly Cessna Sundays with EasternHops, so every Sunday at least I would encounter this problem with the AP. I stopped using it and avoided the affected aircraft.

There may not be many people using TDS, but maybe this will help any that are and have a similar problem. Next time TDS will be the FIRST thing I check rather than uninstalling everything.

[Bishop398]

@NixonRedgrave

The issue really stems here from the communication, or rather the miscommunication, that is continuously passed around by members of the community about what the add-on does and when it’s needed and how it might affect aircraft systems when it is installed.

The community is not generally wrong here: the Marketplace package indeed contains no code at all. It just points the old AS430/530 HTML files (the instrument entry point, so to speak) to the new WT GNS430W/530W. It was just not clear from the initial report (and indeed somehow many folks can’t tell) that removing the package was reverting to the old GNS.

@NixonRedgrave

I wonder if the better approach would have been to make the Asobo GNS the add-on rather than promote the use of the bridge add-on we have now.

This, unfortunately, would not have technically been possible given the way the VCockpit HTML system works. Additionally, post final release, we haven’t been promoting the use of that package, and our guidance has been to not use it unless you have to.

@NixonRedgrave

I have no doubt that you have probably already created excellent documentation, but something isn’t working and I feel it will “always” be like this unless some solution can be found to fix the process.

I would love for there to be a magic bullet here that we could have influenced, but the reality is that the documentation regarding implementing the Garmins in one’s aircraft is some of the best in the sim and is easily discoverable either by Googling or from the MSFS dev docs site or by querying on the dedicated MSFS dev support forum; developers need to take some responsibility for reading it. Additionally, our lines are always open and we have offered support in our own time to those developers, many of which come with questions answerable by the docs; we don’t turn folks away.

@nebo

What didn’t work:

I understand the frustration, and as an advanced user those questions might seem belittling, but our experience has shown that user error is the most common cause, and that windows issues are not even remotely out of the question as to a cause either. It’s all just more variables to be isolated and eliminated when only one (or a very small number) user is having a given issue. These avionics are used by hundreds of thousands of people all day, so systemic and user issues are the most common cause with highly isolated bug reports.

@nebo

What did work:

Videos are indeed super helpful, we always suggest posting videos when possible. However, hours of dedicated support via streaming is really enormously generous by either a developer or a community member (@LesOReilly4451 in this case); I could only provide text support at the time (a weekend for me that I was not working).

However, I just want to be super clear here: the state of the installed system is the responsibility of the user and not of the sim developers. There is a very clear reason that all of the MSFS support guidance starts with “remove all mods”. While I have great, great sympathy for this scenario in which the TDS tray executable wasn’t even remotely obvious, the point remains that this was a third party software installed by the user. While we of course always try to help (and I think our community would agree we generally go well beyond the call to do so), users also need to take responsibility for the modification of their simulators.

Nonetheless, I am super pleased and heartwarmed that once again our awesome community was able to help find the conflicting mod; it’s a testament to everyone here and in other channels just how great and helpful the community is. Hopefully everyone comes away from this with a warm vibe.

EDIT: Also don’t want to throw anyone under the bus here: when this issue was discovered a year or two ago regarding the TDS autopilot doing things without the avionics running in an aircraft, Tiberiu from TDS was immediately responsive after we reported it in creating a new version without the bug (I think in just a day or two). Just didn’t want it to appear that we felt poorly about TDS, quite the opposite!

[NixonRedgrave]

@Bishop398

Nonetheless, I am super pleased and heartwarmed that once again our awesome community was able to help find the conflicting mod; it’s a testament to everyone here and in other channels just how great and helpful the community is. Hopefully everyone comes away from this with a warm vibe.

For sure.

It’s what keeps me coming back and participating here in spite of my occasional frustrations with this place.

You’re a good dude, Matt.

[tiberiu11]

Hello,

We would like to thank @LesOReilly4451 and @Bishop398 for their professionalism, expertise and help in addressing the issue and finding the cause of the issues that you have experience.

We are sorry to hear that you have had issues with an outdated version of the TDS GTNXi. They should not have happened and we totally understand your frustration as well as searching for the exact cause of the issue, which was a bit difficult to find.

Part of our autopilot system has to do with intercepting events/interacting with the MSFS autopilot. There were a few logic flaws in our code, where the interception code would be active even if the TDS GTNXi was not used (2d integrated or standalone mode). Because of this, you have experience the KAP140 issues; this is our fault, we are sorry for this. This has been found internally and fixed by us for at least one month.

It is very odd that we did not have many reports of the issue since at least one and a half year ago, when there was an altitude intercept event, which we have quickly patched on our end. Had we have received other reports, we would have acted quicker. For all bugs that we receive, we quickly act on solving them.

As of writing the message, all logic flaws in the TDS GTNXi have been patched and you or any other users do not have to worry about the TDS GTNXi interfering with the MSFS autopilot when it is not used. We recommend making sure that version 1.0.3.5 or higher of the TDS GTNXi is installed.

The method that has been provided to us to interact with the MSFS autopilot as well as hot-swapping other avionics is great and we would like to thank @Bishop398 and the entire team for their hard work, dedication as well as great ideas into making this all happen. Again, we apologize for the inconveniences cause to everybody and we will strive our best in order to product a great product without any ill effects.

Best regards,
Tiberiu
TDS Sim Software

[LyonHaart001]

I had problems with this also since the SU14 update. The Trinidad TB21 autopilot stopped working and the VOR1 read backwards when the MSFS update came out. Also another plane I have that uses the buttons and linking to the KAP 140 also stopped working. And… The Asobo Cessna 172 Classic on my rig stopped working. No functionality. It was working before the updates to the GNS-530/430. I feel it is a bug by WT as they modified the code. It was working fine before.

I found that if I deleted the GNS530/430 Version 1.1.4 and the Trinidad, and redownloaded them fresh, it worked again.

If I didnt redownload the GNS530 - V1.1.4, the Autopilot in the Trinidad and the Cessna 172 work again, but the screens in the TB21GT become like postage stamps. (crazy). But the AP was working. Reinstalling GNS530-V1.1.4 brings back the screens to normal ‘and’ fixed the AP. But I havent tried turning it on and off several times. Also, the Cessna 172 is again broke with the GNS530-V1.1.4.

Doesnt make sense. I link to the Asobo screens only. In the past, WT would launch new screens and they would have bugs (everyone does, but it seemed a high amount) so I always link to Asobo, as they were always solid, well tested. But I guess the Asobo versions are now completely WT.

[Bishop398]

@LyonHaart001

but the screens in the TB21GT become like postage stamps.

Looking at your screenshots, the ones with the postage stamp size are all the Asobo units.

The easiest way to tell them apart is to look at the font. The Asobo units use a standard Arial type font, whereas the WT units use the correct custom square-ish digital looking font (the 0 with the slash through it is a clear indicator also).

[dreampage]

@CasualClick

I’ve suggested it get removed soon as I can’t really think of any current manufacturers who still haven’t upgraded their code post AAU2.

Sadly, there are still such aircraft. The Carenado Mooney M20R is one of them. I have it, and I need to have the “colored” WT 430/530 installed from the marketplace, otherwise the Mooney only has the ancient 530 in it without the advanced functionality. And I assume many Carenado planes could have the same issue (I only own this one).

[LesOReilly4451]

Is that first image taking place after doing a quick reload in Dev mode?

I would be happy to look at it but I don’t own the TB21. doing a quick reload you can get the AP to not work correctly with the WT530.

With the 208 from BKSQ there were some initialization issues with hot swapping since SU14 and the fix they posted actually resolved some other side effects as well for them in planes. FD on off or even captures of ILS needles with the TDS.

I could replicate this as well in the default 172 steam gauge but only when I used the dev mode quick reload… Then the AP would not follow a heading and was usually stuck when you turned it on in the Attitude it was in (basically the Pitch and Roll mode).

[LyonHaart001]

Hey all,

I hear there will be an update to the GNS systems soon, possibly the next big update.

I also hear that if you reload the flight ‘in-flight’ that you can break the linking of the AP with the GNS systems, so if you reload, or if the system is malfunctioning, return to the main menu and reload the flight from there. It should then work fine.

Kind regards,

Bill
LHC

[nebo]

@Bishop398

However, I just want to be super clear here: the state of the installed system is the responsibility of the user and not of the sim developers.

I agree with everything except this. I think there has to be a compromise somewhere for an effective solution. It is not my responsibility to uninstall and reinstall every permutation of files you think might be the cause any more than it is your responsibility as a dev to do the same.

Microsoft went through this same problem in the “dll hell” years. There were some combinations of software that simply could not work together without causing both programs to crash. Users and devs were endlessly frustrated.

Then Microsoft came up with a system for registering DLLs and declaring dependencies. Those problems disappeared.

I already see several streamers making very public decisions that they “will not buy or install any mods other than what is absolutely necessary” – the risk to their stream is too great. I also see this attitude across other players in the community. They refuse to try anything new because it’s too big a risk. These are potential customers that are walking away rather than agreeing to your terms.

I think there are options beyond just “giving up”. The market won’t grow beyond a certain point if the complexity of using mods is up to users or devs alone. We need platform support.