ILS capture fix for TBM:

Since the last MSFS update, it is known that autopilot ILS localizer approach has been broken for most situations which require early [less than 10 miles] approach distance. This has been documented in the AVSIM forums for the last couple weeks. We have been encouraged to believe that a fix of some sort is impending , and I am happy about that. For the immediate, though, my lifetime is not forever, anymore, so I spent some time today playing with the control variables assigned to ILS capture and control to my favorite MSFS aircraft- the  TBM930. 

It is irresponsible to tell 'game enthusiasts' to edit internal game files for 'improvements' attained without retaining a backup somewhere, at the risk of destroying their game installation. A specific text file has been identified on the various forums which include the file named 'ai.cfg'. TBM has one. Here is my simple change which allowed me to execute and enjoy very good localizer control down to the numbers with straight landings. My three test flights were with pilot configured G3000 FlightPlan:

KFNL>KGXY ILS RWY 35 via [WELDS]
KGXY>KFNL ILS RWY 33 via [COLLN]
KORS>KBLI ILS RWY 16 via [SECOG]

These all involve very sharp route bends greater than 90 degrees. You might try these out BEFORE making the following change.

Integrated into the MSFS program are control system subprograms which handle many axes of the planes' 3D variables using the popular PID [proportional-integral-derivative] math technique 
learned in engineering classes for the last 60 years. Many ASOBO aircraft files found in the 'official' folder include a file named 'ai.cfg'. This file (which can be edited) includes the 9  PID variable lists for that specific aircraft. For the TBM ai.cfg file, there is a list line:

headingPID = 1.0, 0.01, 1.0, 0.2, 1.0

Change the second variable from 0.01 to 0.5

That's what I did. Any problems?...change it back.

Dave
 

Edited December 3, 20205 yr by Eclex

47 minutes ago, Eclex said:

Change the second variable from 0.01 to 0.5

This actually works for variety of stock MSFS aircraft, but you might have to tinker a bit with the values. This is how the FBW A320 was "fixed". I fixed the C172 in a similar fashion.

Yes, but the 2nd number did seem to be  most compulsive. I haven.t had time to look at other craft. I get to fly stormy landings again..

 

Thanks, Dave

 

Unfortunately, the AP death spiral is still there and occurs randomly without warning. At least this "fix" undoes the poor AP tracking introduced in patch #7.

None of these changed values alter the underlying problem, which is that the heading function has been slowed down to a crawl. I know this having spent several hours  every day since the update trying to "fix" it myself, with literally hundreds of combinations of PID values. All you can do is make the ILS capture a little better and very slightly increase the speed of the first part of the heading capture. But once any aircraft gets near 30-40 degrees to the desired heading it will radically slow down the heading capture speed to less than a quarter of normal speed.

I realise Asobo think it is a valid temporary fix but it actually isn't. I realise they are sincere in this attempt, but it is plain wrong. The out-of-control spirals in some aircraft were never caused by heading mode itself, but by other factors. While a slower heading function might APPEAR to fix these issues, it is not actually fixing the underlying issue. I do wish they would quickly re-instate the previous a/p core functions which were very tunable and had nothing whatever to do with any a/p problems - those were caused by the INDIVIDUAL a/p settings or flight models of the aircraft suffering the problems.

Some people are confused between two things: 1) the basic, hard-coded a/p, and 2) The ai.cfg tweaks that can tune the individual a/p functions of each separate aircraft.

With the previous a/p before the update, every single aircraft's individual a/p could have been tuned to eliminate all problems.

Edited December 3, 20205 yr by robert young

Robert have you contacted ASOBO about all this. You are one of the Premier developers/modders/experts when it comes to flight sim models. I am not sure how you want to be called. But I really think your input along with others could be invaluable to ASOBO, and might be able to help them.

5 hours ago, robert young said:

The out-of-control spirals in some aircraft were never caused by heading mode itself, but by other factors.

I probably shouldn't have added that as an aside in this thread, but the unexpected loss of control behavior is just some dodgy coding bug that Asobo can't track down. It almost seems to me that they probably can't consistently duplicate the AP death spiral and have internally attributed this misbehavior to "pilot error". To me, this is one of the first bugs I would have addressed, but given the MSFS user base, I can see why Asobo has kicked the AP can down the road to Patch #9.

But back to the  AP heading "fix". I totally agree with you that fiddling with PIDs is just a stopgap approach to combatting the heading issue introduced by Asobo in Patch #7. That's why I put the word fix in quotes in my posts. But the main contention of the original poster in this thread is correct. The "fix" can get the AP behavior back to some semblance of usability. We can argue all day whether Asobo should just put the Patch #6 code back in the sim, but that won't help anyone using MSFS in the short term.

3 hours ago, a321 said:

Robert have you contacted ASOBO about all this. You are one of the Premier developers/modders/experts when it comes to flight sim models. I am not sure how you want to be called. But I really think your input along with others could be invaluable to ASOBO, and might be able to help them.

Maybe, but I am not a programmer and have scant coding skills. Where I could be useful is a lot of experience regarding getting the best out of what is available, but on the a/p issue I feel defeated. Nothing I have tried will compensate for the slowdown of basic heading functions. Actually I think I have identified that it is not the heading function itself but the wing levelling sim var which kicks in far too early in the heading change cycle. If someone clever can achieve access to that variable it might be possible to reverse the "fix" which is not a fix.

As for contacting Asobo there is no identifiable path and I'm not so entitled that I feel they should pay attention. What I do know is that a Zendesk report will be less than useless.

Edited December 3, 20205 yr by robert young