Are you on Steam or Microsoft Store version? Microsoft store edition
Are you using Developer Mode or made changes in it? No
Brief description of the issue: The AP APR mode stopped working. I can use NAV mode with no significant problems (it initially turns in the wrong direction, but eventually stabilizes on the correct course). But if I switch to APR mode (either before or after GS is live) then the aircraft starts turning randomly in different directions. If you let it go it would go into steeper and steeper turns until it loses control. If I take over to manual flight I can recover manually.
I did numerous attempts to see whether I am doing something wrong, but even if the approach was completely stabilized on NAV, switching the AP to APR causes it to go haywire.
I tried this both on the 172 (steam gauges, did NOT try G1000) as well as on the TBM. Same results on both.
This used to work fine (moire or less) before the GOTY edition. It seems to have broken after the latest update.
Provide Screenshot(s)/video(s) of the issue encountered:
Detail steps to reproduce the issue encountered:
For instance: approach an airport with ILS (e.g. KALB RWY 19 109.50). Tune your VOR to the correct frequency (doesn’t matter whether you are using VOR1 or VOR2 as source). Verify that the CDI needle and GS are responding as expected. Turn AP on. Set NAV mode: works. Set APR mode: all you get random turns and eventually AP loses control.
PC specs and/or peripheral set up of relevant:
Build Version # when you first started experiencing this issue: GOTY edition (with Reno air races)
I tried the KALB ILS 19 approach with the TBM, non-G1000 C172, and the Beech G36 w/G100Nxi. The TBM and the Beech both flew the approach flawlessly. The C172 had problems tracking any course with the GPS or VOR. I restarted the approach several times and the AP never locked onto anything. I tried hand-flying the approach just to get the aircraft lined up on the approach. The NAV just wouldn’t track. Activating the approach didn’t change anything. I am using a GPS mod that is probably screwing up.
sry but no problem here. As for sure, look to my pict and set VLOC indicator with CDI button for sure to indicate. No problem then with APR click on near of LOC.
I see same issue with C.208/G1000 Nxi.
running fully on Flightplan/AP (that works), but does not get into vertical glide path. hoizontal works fine.
All Altitudes set as in Flightplan.
worked with old version of G1000 for me.
Any idea?
OK. So I tested the C172 G1000 as well. And like all other variants - the APR mode loses lateral tracking. Same as with the steam gauge version: you can be perfectly stabilized on the localizer in NAV/LOC mode. When the GS comes alive, I push APR, and soon enough - lateral navigation is screwed up. Turns off course and does not recover. Maybe less violent than the other variant, but APR mode is basically as broken and useless. Using the NXi, if that makes any difference to anyone. But really, it looks like the default AP is what’s broken here, as it does not matter which aircraft I use, with addons or without - always same result.
The following is specific to the Working Title G1000 NXi, which everyone should be using since the stock G1000 doesn’t act at all as the real-life unit:
APR is supposed to be armed before you intercept the GS - that would be in most approaches before the Final Approach Fix. That’s how in part the G1000 switches the CDI from FMS (GPS) to NAV1/NAV2 (whichever has the ILS frequency tuned). Generally speaking the CDI will switch to LOC first after passing the Intermediate Approach Fix (FACF), then pick up the Glideslope just at or after the FAF. Lateral Navigation is provided by GPS to at least the FACF, then LOC takes up the remainder of the way to threshold. APR will show armed with the GS/GP indicator in White. It will blink Green when capturing GP/GS, then steady state Green once captured. The cross-check is the ILS diamond scale next to the altitude tape appearing in Solid Green.
What happens after you pass the FACF is the the FMS (GPS) switches back and enters SUSP iirc. To execute an MA, you would have to clear SUSP, manually select the first fix in the Missed Approach and activate, and FMS sends you to the MA leg and eventually the hold.
For the Working Title G3000, Missed Approaches aren’t supported, so the LNAV will revert back to the last point in the approach - usually the RWY. You can handfly after that, or sync HDG to current heading and use HDG mode to continue down runway heading. However, the technique used above in the NXi works the same way in the WT G3000 in terms of intercepting the GP/GS. You MUST be in APR BEFORE the FAF.
As I mentioned in my description of the problem, the AP loses lateral tracking as soon as I arm the APR mode. When I say “GS comes alive” I mean that the GS diamond starts descending, and the GS has not been intercepted yet. The AP at that point is indicating LOC, which means, to my understanding that it is tracking the CRS to the localizer and holding altitude, which it does - until APR is armed. The second I arm APR and quite before GS intercept, it starts turning and does not track the course any longer. It never gets a chance to intercept the GS because it cannot track laterally. That is completely broken behavior.
I get the same problem on the KP-140, on the G1000 nxi, and on the G3000 (also working title). I do have the PMS5- GTN750 installed, but it doesn’t matter whether it is in the community folder or removed. In other words - I don’t believe it has anything to do with the problem as when I remove it, the problem persists.
Ok, to be clear though, are you in APR before the FAF? Because it sounds like you’re arming it after. You should be in APR long before the GS diamond comes alive, but more importantly before the FAF position.
I’m trying to figure out your exact steps so someone can repro.
OK. Here are some images, flying procedure as you request. We’re in the clear weather preset. Going for KALB ILS RWY 19.
The first image shows the Navigraph chart with the location of the aircraft stabilized on the localizer in NAV mode (109.50) right before the IAF (EYMEY). The second image shows the cockpit at this point.
After passing EYMEY, and well before the FAF at HAUKY (third image) - armed APR on the KP-140. In this location, the GS diamond (in this case, horizontal needle) has not come alive yet. Not that it matters.
A few seconds after that the aircraft enters a left turn (always a left turn). The turn steepens, until control is lost, or I take over from the AP to recover.
I don’t think I can be any clearer than this.
Now, as for your comment about arming APR before the GS diamond comes alive - I believe it is incorrect. As long as you intercept the ILS GS from below you should be OK. Besides, the problem here is not the glide slope interception. The problem is that it loses lateral tracking and initiates a left turn right after arming APR. This should never happen under any conditions.
So. No response to this question. Look, this is real. I am not the only one having this problem. Could you offer any way to investigate this? Maybe turn on some kind of logging. Maybe some way to use developer mode to see more detail of what’s going on with the autopilot.
Having a basically non-functioning ILS AP approaches in all aircraft is really crippling to the IFR experience. This is not a small problem. Could anyone from Asobo offer some kind of useful advice that does not claim that I don’t know what I’m doing?
@CasualClick you seem to be the moderator. I don’t know whether you work for Asobo or have any special access to them, but I would really want to get this resolved. IFR is my main way of flying and has been for over a decade. This is a really big issue for me. Can you help with this?
Mods are volunteers and basically end users of the product like yourself. We have no special connection or pipeline to the Dev Team. We report up to the Community Managers who are full time Microsoft employees.
That being said, I’m mindful of what MSFS Executive Produce Martial Bossard asked the user base on yesterday’s Dev Q&A Stream: we need to be able to repro(duce) the problem to fix it - so we need more data to do it.
To that end, I tried to reproduce your problem on the TBM. I don’t fly the analog gauge version of the Skyhawk so that repro is out from my abilities/current installation.
To baseline:
I am using Working Title G3000 Mod because it’s more functional and have been so for more than a year.
I am also using MugzMod Performance Mod for the Flight Dynamics and some cockpit improvements more in line with the real aircraft.
I am also a Navigraph user like you, but I only subscribe to the Navdata portion, not the charts or anything else - I use Little Nav Map (see below) as my EFB and pseudo-chart reader.
You can tell Working Aero is installed because it has the Flight Path Marker active on the PFD among other things once airborne. It also does a lot of work to be more in line with the AIRAC Procedures and Leg Types than the stock G3000, which of course is critical for IFR. The long term implication of course is Working Title was hired by MS to improve all the FMS - so what you see in G3000 is a glimpse of what it will look like long term for the remainder of the sim’s lifecycle.
You can tell Mugz is installed because at a cold & dark, the PIC door swings open until you close it as part of the startup procedure. It has many other improvements.
Okay - off to the races. For a quick test, I launched out of Floyd Bennett Memorial (KGFL) north of KALB with an approach similar to yours - ILS 19 with CAM Transition. For consistency, I filed IFR but since ATC is nothing more than an overlay, it’s really not material to whether the approach would work or not.
This is what the flight plan looked like after completion.
As you can see by the player icon (yellow aircraft) I’m on the CAM->EYMEY leg, still in FMS, descending to the 2000’ altitude fix as prescribed by the Approach. There’s a corresponding cockpit shot. Note - I have already LOADED and ACTIVATED ILS19 via CAM Procedure before I got to CAM. The FMS is guiding based upon the Approach, not because I defined it in the Flight Plan before flying or loading it manually into the FMS at Cold & Dark. This is key.
Now, given that EYMEY is acting as the FACF, I have every intention of actively switching to APR at EYMEY cross-over or just after, in preparation of being in the right approach mode before the HAUKY FAF.
However, and this is not a surprise - this is one of the reasons why the Working Title G3000 is preferred - because this is how it works IRL - just before EYMEY, the CDI automatically switched from FMS to LOC, even before I touched APR.
However, in order to get Glideslope Captured (White GS on the Annunciator Scoreboard, I MUST switch to APR. Once armed, the FMS is simply waiting for the GS intercept (green diamond) to coincide with aircraft altitude.
Here’s the GS armed - you can see the Green Diamond coming down - and as expected, GS capture coincides just with the Outer Marker Beacon notification popping up. (2 shots in sequence).
Thanks for the detailed response. I do have the working title G3000 mod installed. I do not have the TBM improvement mod installed, but happy to install it, as it was already on my to do list. My attempt with the TBM was in my current configuration and that did get off course laterally. I’ll install the TBM improvement mod, and try again, using the same flight plan you used here and see what happens. I’ll report back here.
Just flew the ILS at KSBP in the C172 Steam Gauge… flew the approach plate starting at 4500 feet intercepting at CREPE. “Rode the rail” all the way down. Squeaked the landing too.
Just tried the ILS to Rwy 11 @ KSBP in the TBM with no WT Garmin (avionics as “stock” by Asobo) and intercepted the LOC and acquired GS without issue. No complaints from the passengers at touchdown either…
EDIT: Just flew the exact same course with the WT Garmin 3000 mod installed; v0.7.6
Same result. So, this is a mystery. I’ll give this another go with the WT Garmin 3000 mod at KSFO, which has a number of procedures for inbound flights. I may even load up the proc for approach to KALB via CAM to ILS 19 and see if I encounter the “swinging” back and forth behavior. There is an answer out there somewhere…
It’s pretty clear that this issue is hard to reproduce. It’s clearly not affecting most users, but does affect more than just one. So I am back to my question about diagnostics. Is there any way to glean information on the internal state of the AP from some logging functionality or with developer mode turned on. I think there is no hope of Asobo fixing anything if I cannot provide them some more specific information about the state of the sim at the time of the problem… Is there a way to contact them to ask about this? Users helping users can only go so far.
I am another bemused user watching and trying to find resolution. I have the Mugz TBM 930 installed. I have found the AP wouldn’t engage without the WT Garmin 3000. I then installed the WT G3000 and still same behavior.
One thing I did note the garmin reporting FPL desync’s. I loaded my FPL from Simbrief, into the sim and then launched into the cockpit. When I saw the desync’s I amended the FPL to remove the duplicate overlaps and to be fair all looked ok to me on the FPL. So maybe I’ll try loading the FPL manually and report back.
