Solving poor altitude capture in FS9

[robert young 2,897]

After exhaustive testing and experimentation, it appears clear that the FS9 altitude capture is even worse than it was in FS2002, in that the VS to ALT capture function is far too weak, especially for light, slow aircraft. It can be shown that the standard ALT capture overshoots badly at airspeeds less than 180 knots, so the slower the aircraft the worse it gets.I cannot find a single param in the airfile which over-rides the hard coded ALT capture function. Furthermore the aircraft cfg autopilot pitch section is completely useless and changing the value of max pitch acceleration to more than 1.0 results in a practical value of....1.0, although setting less than 1.0 does result in even weaker capture. The other two params are equally useless.Does anyone know of a method using XML which can aggressively over-ride this function so that the VS much more strongly reduces to near zero when within say 200 feet of target ALT. Currently, at a climb speed of 100 knots I find that the VS is extremely sluggish to decrease and unless you actually reduce thrust to encourage a nose drop it will miss the captured altitude every time.This also has consequences for turning, because the Alt hold is too weak to compensate for the nose falling when a turn is established and then again as the nose rises when the turn is complete.Any wisdom would be gratefully received!Rob Young

[rcbarend 37]

Hi Rob,Have to tried:[pitot_static]vertical_speed_time_constant = 99 (see aircraftSDK).Furthermore, what do you mean by "altitude capture"1. The way the aircraft follows the AP-set altitude ? or2. The way the aircraft follows a glide slope ?I don't think there's another way of influencing the Alt Hold speed, other than writing your own autopilot and directly give Elevator commands. I have a simular problem with the airspeed hold algoritm used in the default FS AP functions; definitely worse than in FS2002.Or is this "as real as it gets" :-) ??Rob Barendregt

[robert young 2,897]

Hi Rob,As coincidence would have it, I've just been discussing your new gauge with Bill Learning. I see that it optimises throttle control and VS rate. I wonder if this kind of gauge can be adapted to achieve exactly what I mentioned in my original post.I confirm I'm talking of Altitude Acquisition NOT glideslope. In fact the glideslope functions in FS9 appear to be adjustable in a way the ordinary altitude capture and VS functions are not.I have obviously played around with the Pitot Statit Vertical Speed Constant and it is obvious to me that this actually has no meaningful effect on the efficiency of the autopilot with regard to capturing altitude, except when it is set to very small values (say 0.3 or lower). Raising it more than around 3.0 actually worsens the altitude capture if anything!I'm e-mailing you with more detail on this.Kind Regards,Rob Young

[jcboliveira 1]

Doesn't the gs_integrator_boundary and gs_derivative_boundary help? I didn't "played" with the PID values for Glide slope but it seems that is capable of solving the problem.Jos

[rcbarend 37]

Jos

[Guest Douglas K]

>I cannot find a single param in the airfile which over-rides the hard coded ALT capture function. Furthermore the aircraft cfg autopilot pitch section is completely useless and changing the value of max pitch acceleration to more than 1.0 results in a practical value of....1.0, although setting less than 1.0 does result in even weaker capture. The other two params are equally useless.

[brucek 38]

I'm no FS a/c designer by any means, and understand little about the workings of the FDE. However:"This also has consequences for turning, because the Alt hold is too weak to compensate for the nose falling when a turn is established and then again as the nose rises when the turn is complete." Whenever real life prevents me from keeping current in my club's C172SP, I always get caught when I do fly by increasing altitude in a turn due to my anticipation of the "nose-drop" in the turn that FS2004 produces. This nose falling is really- at least for the C172SP- way too exagerated. I do know about the loss of the lift vector in a turn, but FS is doing something else :)Not that this helps you in your question, Rob.Bruce.

[Guest _FSAviator]

Top half mostly in reply to Rob and bottom half mostly in reply to Douglas K, though they must both know most of it anyway.I tried to replicate the finding reported at the top of the thread and, when using identical FDE with mean incidence coded via a TBL 404 shift, I could not. Of course the particular set of FDE Rob was testing may have the problem, but I don't think it is generic, or of the form reported.We know that in FS7 REC1199 contained (up to?) 112 defined variables some of which acted as AP gain or limit parameters and could pass these variables from the flight dynamics (FD) to the flight model (FM). We know that in FS8 REC1199 was 'hijacked' and contained only variables read by the AI engine (AIE) and not by the FM. The only AP variables defined in the both the FD variable list and the FM variable list became those in the FS8 aircraft.cfg. Since the FDE I produce are not compatible with the AIE I do not write or include a REC 1199 section in my air files. FS9 also uses REC1199 solely to pass variables to the AIE. Those who write AI code may know which of the 112 variables the AIE can read.That the FD could no longer pass any REC 1199 variables to the AP modules of the FM in FS8 was known. We never discovered whether those variables were still defined in the FM variable list, but we had no reason to suppose that they were. MS delete variables from the FM from time to time and they never tell us unless we torture them.In accordance with the previous MS philosophy of migrating FD variables from the .air to the .cfg some more of the old REC 1199 variables appeared in the .cfg in FS9. If those variables migrated from the FM defined variable list to the AIE defined variable list, either when FS8 appeared, or when FS9 appeared, there is no reason to suppose that they can pass data to the FM in FS9 any more than they could in FS8, when they were still within REC 1199 of the air file.<>1) Have you checked that these VARs are not passing directly to the AIE having migrated from REC 1199? 2) In accordance with the SDK many of the variables in the aircraft.cfg in both FS8 and FS9 are parsed only by FSedit. Have you checked that FSedit does not read these to write REC 1199?Many variables are defined in the .cfg that cannot be passed to the FM because they are not defined variables in the FM. They are not for use by the FM. Of course I do not exclude the possibility that MS have just screwed up, but nothing in the SDK or our experience in FS8 would lead us to expect these variables to be present in the FS9 FM. If they screwed this up it was when they released FS8 not FS9. The evidence suggests that the AP gain variables within the FS7 FM became hard coded constants within the FS8 FM and are still (the same) constants within the FS9 FM. I do not conclude that the value of the gain constants changed between FS8 and FS9, but maybe I just lack a set of FDE that highlight such a change. We also face the problem that ever since MS decided to produce FSedit and decided that it should create new air file sections with IF EXISTS - GO TO coding in the FM some RECs and TBLs in the air file are either not parsed or only some data fields of a particular REC are parsed when the FDE load. I doubt that this is causing the problem in this case, but since I don't think the 'problem' is AP related at all I think it theoretically could. See below re the many other air file sections involved in this

[Guest Douglas K]

>>>><>1) Have you checked that these VARs are not passing directly to the AIE having migrated from REC 1199? 2) In accordance with the SDK many of the variables in the aircraft.cfg in both FS8 and FS9 are parsed only by FSedit. Have you checked that FSedit does not read these to write REC 1199?<<<

[Guest _FSAviator]

Greetings Douglas,FSedit rewrites both the air file and the aircraft.cfg forcing them into compliance with MS design intentions whenever it is allowed to save any FDE. It uses many internal algorithms, some of which appear to be bugged, to recalculate and rewrite the variables in both parts of any FD loaded into it. Only a few of the recalculations depend on any changes made to variables within its GUI. Most of the changes depend on its constants. I believe the algorithms are coded to ensure that the output from FSedit will be 'compatible' with both the FM and the AIE within the specific retail product for which it is the authorised binary compiler, rather than to maximise 'realism' during first person flight simulation. This suits most users of the retail product very well. It does not suit some who post here. It is rumoured that we use unauthorised binary hacking tools to edit the binary directly. The EULA forbids this. MS have no intention of releasing an SDK which includes the chapter 'How to hack into copyright Microsoft binary files and make them incompatible with some features of our products'. The relevant information is in forums such as this, not in SDKs.Many of the variables in the aircraft.cfg are nothing to do with FS9.exe. It is an ASCII file created by FSedit.exe and which stores data varied via the FSedit GUI. Some variables in the aircraft.cfg are also used by the smaller FS9.exe. Since it is an ASCII file you can edit it with a text editor. As is normal most of those changes have no effect unless you compile them. The only compiler authorised by the EULA is FSedit.exe and the compiled binary file that FSedit.exe produces is the .air file. The reference section of the aircraft.cfg created by FSedit is not used by the FM. It is used by the AIE. That is why it is in KTAS. KTAS are useless to an FM, but are required by an AIE. The values are calculated (badly) by algorithms in FSedit using the variables supplied via the FSedit GUI, or the filename.air that was loaded into FSedit, if saved without altering its variables. A few of the variables which FSedit writes to the autopilot section of its aircraft.cfg are also used by the FM. The rest may be variables or they may be constants. FSedit may compile them to somewhere so that the AIE can use them. Somewhere may logically be REC1199 of the air file, but like you I have too little interest in AI traffic to test. I was posting to highlight the incongruity in assuming that variables in the aircraft.cfg are for direct use by FS9.exe let alone by its FM. This is all old news. <>Yes the FM can read that variable directly, but 'work' and 'can be read directly by the FM' are not the same thing. Each variable 'works' if FSedit can impose it, or compile it, for whatever purpose MS may have in mind for it. After FS7 that purpose may not relate to the FM. If you increase the value for this variable imposed upon the aircraft.cfg by FSedit the problem described at the bottom of this post is exacerbated.<>Most MSFS consumers wanted an airport simulator within their flight simulator, and another company was scooping the profits with a popular add on during the retail cycle of FS7. MS needed a quick solution so they hijacked some of the AP modules within FS7 as an AIE in FS8. From FS8 onwards AI compatibility had priority over FM realism, but only for AP users. It is a compromise, but maybe not a daft one. I am not happy that they have not restored the realistic AP that they destroyed in FS8, but they have not taken any more AP functions away in FS9.<>Because the AP must not have authority to apply full elevator deflection in either direction, whilst it can have authority to apply full aileron. MS destroyed the alpha limiter when they ripped the key AP modules and variables out of the FS8 FM. They retained the AP bank limiter within the FM. From FS8 the only way FD authors could control AP pitch rate gain was to hijack Cm_dt for that purpose. Since the time the AP takes to proceed from zero (pitching moment) to Cm_dt is an FM constant, Cm_dt can act as a rate controller of Cm_de as well as the trim authority. Once the FS7 AP had been degraded into the FS8 FM, FD authors had to write unreal FD code to cover up deficiencies in the post FS7 FM. Whilst in real life Cm_dt <= Cm_de, in FS9 they are just variables in software modules so if necessary we can code Cm_dt > Cm_de which is the most obvious solution to the problem reported at the top of this thread.<<..... If (Cm_dt) set high, I find it difficult if not impossible to trim for level flight as each application moves the trim too far (even with the repeat sliders at the halfway position), and I'm constantly adjusting the trim and fighting to maintain a specific altitude. >><< I attribute this to the pitch trim operating differently in FS9. In FS9 if I press the joystick buttons assigned to pitch trim momentarily I can achieve a fine adjustment (.1 degrees or so), much finer than was possible in FS2002. >>Oh dear, my heart sank when I reached here. Now I understand. You have tested the repeat rate coded for the same joystick switch when it represents a key press and repeat rate in two different retail products and not Cm_dt at all. MSFS allows whatever repeat rate you like for the switches on your joystick. The FM and any FDE must be tested with keyboard key presses else you just test personal joystick settings. I think you will find change per keyboard key press (zero repeat rate) is identical in both retail products. You need the elevator trim repeat sliders in a nearer minimum position than 'halfway' to obtain 'maximum virtual enjoyment' of your joystick. The default joystick switch repeat rates in FS8 and FS9 may be coded differently but that is nothing to do with Cm_dt. FD are written to work with the keyboard. It is up to each end user to assign and calibrate any switches on the joystick they purchase, so that they replicate the computer keyboard correctly. The repeat rates must match.If anyone still has this problem after calibrating their joystick to correctly match the keyboard I refer them back to the part in my previous post about 'permutating' the control authority, stability and damping. If for the moment, and probably unwisely, I aggregate the last two and call them pitch stiffness, then the real problem is often overstated pitch stiffness. Relax the stiffness and you can reduce both Cm_dt and Cm_de. In many air files excess Cm_dt is required, not as a result of missing AP variables, but due to excessive pitch stiffness. In many, but not all cases, permutation of the 4 key variables of pitch authority and stiffness can allow the real Cm_dt to be used if we work away at a solution for long enough. >>>>What bank angle an aircraft can hold without descending is a simple function of surplus thrust........ This is not a bug.<<<<<>Exactly. Cm_dt is correctly independent of Cm_de. The MSFS AP is designed to use the former which replicates the real world case Cm_ap <= Cm_de using a different variable. Consequently the FD author can control AP pitch rate gain and ALT capture within FS9 independently of hand flown capability. This is not a bug.<< I do assert that the elevator and not the elevator trim should control the autopilot.>>See above. Whether in real life or in FS8 and FS9, the AP does not necessarily have authority to apply full elevator deflection and we need to code that. Making the AP use the trim tabs to deflect the elevator is necessary so that Cm_dt can be used in lieu of Cm_ap.The real problem, which your last two comments above highlight, is nothing to do with trim or elevators. In FS8 MS deleted the all important AP_pitch_limit variable from the FM. Consequently the AP fails to regulate bank to less than max bank regardless of attitude. In FS8 and FS9 Alpha incorrectly increases without limit as the AP rolls on G and aircraft respond by descending, as they must, unless the end user applies the required increment of thrust when turning. This is a huge bug for those who like to use a realistic AP during their flight simulator experience. Third party authors have found FD fixes to cover up the other deficiencies in the FS8+ FM, but so far not that one (unless I missed it).FSAviator

[Guest Douglas K]

>>>>This suits most users of the retail product very well. It does not suit some who post here. It is rumoured that we use unauthorised binary hacking tools to edit the binary directly. The EULA forbids this.<<<>>>MS have no intention of releasing an SDK which includes the chapter 'How to hack into opyright Microsoft binary files and make them incompatible with some features of our products'. The relevant information is in forums such as this, not in SDKs.<<<>>Most MSFS consumers wanted an airport simulator within their flight simulator, and another company was scooping the profits with a popular add on during the retail cycle of FS7. MS needed a quick solution so they hijacked some of the AP modules within FS7 as an AIE in FS8. From FS8 onwards AI compatibility had priority over FM realism, but only for AP users. It is a compromise, but maybe not a daft one. I am not happy that they have not restored the realistic AP that they destroyed in FS8, but they have not taken any more AP functions away in FS9.<<<>>>Because the AP must not have authority to apply full elevator deflection in either direction, whilst it can have authority to apply full aileron. MS destroyed the alpha limiter when they ripped the key AP modules and variables out of the FS8 FM. They retained the AP bank limiter within the FM.<<<< Not sure I fully understand your reasoning here, I can understand the loss of the alpha limiter, and it goes without saying that full elevator authority is not necessary or desirable, but full aileron is not being used to roll the aircraft into the turn up to the maximum bank angle, more like 5 or 6 degrees initial deflection. Are there no gauge variables that could be used to limit the pitch? But I'll defer to your superior knowledge on this subject, much like the AI traffic the autopilot isn't a priority for me, more like a slight academic interest, and I really haven't devoted much time to it. Probably about 2% or less of the amount of time I've spent on stability and control derivatives. Most of that time was trying to fix problems I've caused in my quest for decent hand flying characteristics.Still, using trim only seems a backward and troublesome way to go about controlling the aircraft.>>>>From FS8 the only way FD authors could control AP pitch rate gain was to hijack Cm_dt for that purpose. Since the time the AP takes to proceed from zero (pitching moment) to Cm_dt is an FM constant, Cm_dt can act as a rate controller of Cm_de as well as the trim authority. Once the FS7 AP had been degraded into the FS8 FM, FD authors had to write unreal FD code to cover up deficiencies in the post FS7 FM.<<<< This is where we came in, and the heart of the subject matter, how to write unreal FD code to cover up deficiencies.>>>>so if necessary we can code Cm_dt > Cm_de which is the most obvious solution to the problem reported at the top of this thread.<<<>>>Oh dear, my heart sank when I reached here. Now I understand. You have tested the repeat rate coded for the same joystick switch when it represents a key press and repeat rate in two different retail products and not Cm_dt at all. MSFS allows whatever repeat rate you like for the switches on your joystick. The FM and any FDE must be tested with keyboard key presses else you just test personal joystick settings. I think you will find change per keyboard key press (zero repeat rate) is identical in both retail products. <<<

[Guest _FSAviator]

<>I figured you must know most of it. >>><><>I could have phrased it better, but there are two ways of looking at it, most of the variables, or most of the changes. Some of the variables in aircraft.cfg may only be used by FS9. Some are used by FS9, but are also used by FSedit to rewrite co-dependent air file variables. Some are probably only ever used by FSEdit to rewrite air file variables. Some may be used only by the AIE, but if not used by the FM may be annotated 'not used' in an FD editor or third party aircraft.cfg. Changing the value of one variable in the aircraft.cfg might change the value of many more co-dependent dynamic variables in the air file, but only if recompiled. I have not tested in detail as I rarely use Fsedit.<Nothing. I just consider fake scalars to be separate from the real world dynamics variables that they can scale. You are right though they do indeed externally scale individual air file variables, and not the product of the equation they appear in, contrary to the implication of the assigned name of the scalar.Where X is named as though it were the scalar of R in the equation below it is only the scalar of A.A * B - c - d - e - f = RIt cannot scale R the result as many suppose. It is therefore possible for use of the scalars to tip a function from positive to negative, under unpredictable circumstances and with unpredictable results.<>Both you and Rob seem to agree about this, yet I cannot replicate the finding. As I said in my first post, maybe I just lack true hybrid FDE that can demonstrate the change in the AP. <>There are plenty of FS8 FD available for download which do not have this problem encoded. The AP, like every other gauge is driven by the FD. The real problem in FS8 was the removal of the AP pitch (alpha) limiter. In FS8 unlike FS7 end users had to manage alpha via manual power inputs when flying with IAS hold off, and when flying with IAS hold on became responsible for ensuring that the IAS was appropriate to the aircraft configuration, weight and phase of flight. Unfortunately many FS8 releases, with no related errors in the FD, failed to provide the end user with handling notes sufficient to ensure that they could manage power, configuration and IAS appropriately.It wasn't just 'Land Me' that 'disappeared' in FS8, it was also 'fly me without regard to weight, configuration, and IAS' that was hijacked for use within the AIE because of course the AIE needed to hijack both attributes. In theory an FM and an AIE could share the relevant code modules, but Microsoft decided that their AIE would take TAS not IAS as its 'speed' variable and so that possibility seems to have been lost. It would seem trivial to fix given that IAS to TAS conversion is just another code module in the same program. I expected a proper AP to reappear in FS9, but it didn't. What I cannot confirm is that the AP in FS9 is worse than the AP in FS8.<>I find it identical to FS8 when using equally good FD. Again the alpha limiter is missing allowing alpha degradations of the stability. I take the view that including the degradations if they render the AP inoperable post FS7 is an error if the aircraft is normally flown using AP.Of course any FD that are not true hybrids will behave differently in the two retail products. They do not have the same FM. The FM deletions in FS9 cause many FS8 FD to fly at different pitch in FS9. Your last two comments, (but not Rob's problem), are all about controlling pitch in level flight. The alpha related FD degradations within the air file apply to the AP, but cannot be scaled - see above. The FD must be truly FS9 compliant. Mean incidence must now be coded as an alpha shift. This might require alpha degradations to be rewritten in some cases. Perhaps this has not happened leading to the conclusion that the problem is in the AP.>>>>Because the AP must not have authority to apply full elevator deflection in either direction<<<< <><>The AP bank limit variable is still in the FM. The AP pitch limit has been hijacked. FD authors only have to fake the data to cover up the loss of the pitch limit. No roll data has to be faked. In the aircraft above bank approaches the encoded AP limit before max aileron. From FS8 there is no equivalent alpha protection via a pitch limit to protect against max elevator. FD authors have to make up for that FM deficiency.<>Gauges read pitch, they cannot write it. They could respond to it, but not usefully, in AP commanded flight, after the AP invokes ALT capture, because this appears to be a hard coded FM table of scripted behaviours. I expect this ALT capture table is shared by the FM and AIE. That table is never invoked with ALT capture OFF. APs with no ALT capture mode might be adapted to have a 'fake' ALT capture mode. This does not solve the missing AP variables problem completely but would allow the FS author to code Cm_dt to achieve other things. <>It is a necessary FD solution to an FM deficiency.<>You can scale Cm_dt in an FM equation, but potentially it has the form;Cm_dt * variables - degradations = ResultAgain, exactly in accordance with what you posted above, you cannot scale the degradations, nor even determine whether the result is positive or negative by using a scalar. If you have been trying to modify the result of dynamics equations with a scalar of just one variable in the equation it may explain why you do not like the results.I refer you back to my original post. All the degradations are optional, but if you include any, the use of scalars is unpredictable and probably unwise. Once you embark on writing high fidelity FD which include degradation for alpha, Mach and Q you should probably avoid external scalars of primary variables. If you are sure you know the exact form of the equation in the FM, and you know it is of the form A * B / (C * D), with no subtraction or addition then external scaling of the primary variable A becomes predictable.I imagine, but have not tested, that the optional degradations are not read by the FM at some position of the general realism slider and that under those circumstances the scalars work predictably all the time. <>No.Think old biplane with fixed tabs that you bend (increment Cm_dt) with your thumb and finger having lost the official tab bending tool long ago. A slight bend of the fixed tab deflects the elevator slightly in flight. Cm_dt < Cm_de. Trim (tab) authority less than elevator authority. In a flight sim we just have the impossible solution Cm_dt > Cm_de if we decide to code it, which is why elevator trim seems to work too much like a second (available) elevator.As far as I can tell post FS7 the AP has constant gain and its pitch authority is the trim authority not the elevator authority. Time from zero to Cm_dt = constant. Pitch moment applied after t seconds is proportional to Cm_dt until = Cm_dt. It is difficult to test, but I have not seen any confirmation in other threads, or forums, that the time constant has changed.<>The trim required depends mostly on IAS (at constant altitude), which you do not mention. What the IAS decays to depends on available thrust. I don't want to open up a whole new can of worms, and will not progress it further, but remember that for prop planes one of the enhancers/degraders of Cm_de is slipstream effect. This may or may not impact Cm_dt and AP ability to pitch the aircraft, (in MSFS), but does affect human ability. This has been variably bugged across retail versions and so prop planes may appear to be 'variable', and jets not, due solely to varying slipstream bugs, or slipstream effect slider bugs. <>The AP should sense and sustain rate 1, but post FS7 it is broken because the variables have been hijacked. The real AP and the FS7 AP would fail to deliver rate 1 at high TAS, but would sustain altitude. The broken post FS7 AP, lacking a pitch limiter, and a rate sensor, will not roll off G and the aircraft descends. The lack of variable AP_pitch gain, which Rob bemoans in post 1, can be fixed with bogus Cm_dt. However unlimited trim cannot hold an aeroplane in level flight, while it pulls more G than the propulsion system can sustain. Failing to sustain altitude in turns is wholly due to lack of thrust to sustain the AP commanded G. It demands too many G due to the lack of pitch limiter. A third party AP can sense pitch, but it cannot command ailerons without altering the heading commanded. FSUIPC can read offset 0BB6 but I don't think it can write to that offset. If not I do not see how it can command aileron movements without commanding a HDG change either. If you can program in C you might like to check. I cannot.There are of course a variety of old fashioned APs available for download that do not feature HDG or CRS capture and where you are responsible for appropriate use of the turn knob.Trim change v flap is not an area I am going to extend this thread into. The last part of your post and this one explains in full why it takes no longer for the AP, but longer for the human user to counter the trim change in FS9. I believe this supports the conclusion that the AP code has not changed, but the keyboard repeat rate has.<>You are right. I relied on the FS9 graphic, which suggests multiple options. If this thread is about aircraft with unswept wings (low speed AP capture) I would expect there to be a satisfactory value for stiffness and authority which was compatible with the default max setting for all aircraft, but I am sure there is some exception.It is excess pitch stiffness or inadequate trim authority that frustrates AP ALT capture post FS7. See permutation issue in earlier posts. <><><>OK I got that this time. When you said in your reply to Rob,<< I find I don't need to set Cm_dt pitch moment trim as low in FS9 as I did with FS2002. >>I thought you were saying that Cm_dt had changed between these two products. I now see that we agree that Cm_dt has not changed at all. I accept your test of the keyboard interval repeat rates and note that they have changed whilst the single press increment of Cm_dt has not. I agree this may have (almost certainly has) changed the repeat rate of default max, mid and min Joystick button trim calibration via MSFS screens in proportion. Thus we can see that MSFS overrides the Windows keyboard repeat rate, whther or not changed by the user. I expected all versions to re-impose the default windows keyboard repeat rate while in use, but was wrong. Let me try to summarise and tie this all up.Enhanced AP ALT capture requires high Cm_dt in relation to pitch stiffness. Permutation of the variables may allow realistic Cm_dt to be coded.Cm_dt is a moment. It is the longitudinal trim authority. It is not a rate. For a given aircraft the pitching effects, (e.g. due to flap), are invariant across versions. Consequently Cm_dt required, (authority needed to counter those unchanged effects), is invariant across versions. The AP and the human user have identical trim authority (Cm_dt) to one another and in every version. The AP does not use the keyboard or joystick repeat rate. It proceeds from zero pitching moment to Cm_dt in a time constant. Hence large Cm_dt = large rate of change of trim for the AP. Conversely with slower key and joystick button repeat rates in successive versions humans now have more precise control over trim increments, but conversely these smaller increments of trim per second mean they must hold the button down for longer to achieve the same trim change. Humans enjoy this extra precision in the cruise, but hate it when the flaps go down. The deletion of the AP_max_pitch variable from the FM post FS7 causes lateral weaving during CRS/LOC capture and uncommanded descent from level turns because the AP fails to reduce G, by rolling off bank, as alpha increases. There is no known work around. Handling notes should indicate the appropriate power setting, configuration and IAS for successful (45 degree) LOC capture. At that point I think we should be in complete agreement about how to solve the problem of AP ALT capture and why it may work even less well for the human user in FS9 than in FS8, how Cm_dt works, and what has or has not changed between FS7, FS8 and FS9. FSAviator

[Guest Douglas K]

FS Aviator,This topic has been very educational for me, and as always it's been a pleasure to correspond with you.I'm hoping that everyone involved will find solutions to the problems we discussed.Best RegardsDouglas