Why are .air files such a 'deliberate' mystery?

[Guest Mike_FFXSGA]

It's amazing how this thread went off completely into another direction regarding gauges. Anyway I'll input what I have either read or heard regarding the original reason for this thread.The original programmers that created the air file way back in FS' early days no longer work for or are involved with MS or FS. In the subsequent releases following the first ones, for simplicity's sake, the team kept the original air files thru each release. Remember, this was originally released as a game for home use. But as computers, programs and designs became more and more sophisticated thru the years, so did our needs and or demands of what we wanted in relation to performance.It wasn't until FS2K that people really started taking this game seriously. Designs became much more realistic or I should say, the sim as a whole became more realistic in many aspects. So all these years have past since the air file was originally created, and the sim has relied on it each release. Now with our new "needs" for better "reality", the team at MS is trying to figure out in a least costly way, how to rewrite an entire sim just because of one little air file.If you notice for those of you that have FS2K4, there are many more entries now in your aircraft's config. These are more parameters "pulled" off of the air file, whereas, now FS is reading those specific entries from the config file and no longer referencing the air file. In time, it is MS' goal to remove the air file complety and have everything read off of the (or a) config file. But here's the HUGE stumbling block they run into.Much of the air file also contains the parameters needed for the panel to display correct readings in the multitude of gauges. EVERY SINGLE gauge in your panel, no matter how complex or simple ALSO relies on the air file. So, how do you get several hundred variations defined into a simpe config? Do you end up with several config files, or one with a few hundred pages in length that the sim has to read before it will load your aircraft.We'll have to wait until several more versions of FS are released before we finally see the air file become a thing of the past. It would involve a complete rewrite of the entire program to completly remove it. Up till now, all they have done is upgrade and modify one that has been in existence for so long. If anyone actually believes that the newest sim is a completely new rewrite each 2 years, forget it. It's only upgrading the program within the hard coding itself. The sim's actual "foundation" is still the same as it was back in FS98. Each release simply edits lines of code and adds and or deletes several more to bring it up to date with the latest technology and coding. The only thing that has truly changed is the overall quality and appearence. The basics are still all the same.None of this is to be considered factual, it is merely information that I have gathered on the subject in my own search for the "answers and secrets" to the all mysterious "Black Art". Verifying all of this would be pointless. MS will only tell us what they want to and nothing more.http://sgair.net/mike/mike/mike_small.jpg

[Guest Douglas K]

I think Milton's advice to: "Take the time to learn this tool and be happy" was the best reply here where the original topic on airfile mysteries is concerned. I might add that for those without Excel, a somewhat lengthier but ultimately more satisfying solution may be achieved using AirEd, Ron Freimith's ini file for AirEd, his "Comments on AC CFG", and then gaining a working knowledge of the aerodynamic definitions involved with flight dynamics. With these you can also create a very satisfactory flight model in MSFS, and be happy.I have done just that with several aircraft now, the latest is a DC-3 for FS2002 that I'm very satisfied with. Thanks to Ron I now have a FS aircraft that is very close to the real thing in performance, stability and control. It is well balanced and easy to trim, stable throughout the flight envelope (No A/P needed ever), and in cruise it needs only a gentle touch now and then to keep it going along the way I want it to. On the ground, it can be taxiied and turned with differential power only, exactly the same as the real aircraft (no tailwheel lock though, so I am spared the additional chore of unlocking it for turns and locking it again for straight taxiing and takeoff), the maximum turning radius is exactly the same as the real DC-3, and I can even "walk" the throttles on takeoff for directional control before the tail is up and the rudder becomes effective. With input from Ron in this forum about yaw stability and rudder control, and using a modified version of Tom Goodrick's roll and yaw stability derivatives (many thanks to you both!), the ball now behaves correctly in slips and skids, level flight, climbing and descending turns, both power on and power off. Coordination rolls can be practised with this aircraft, something that is not possible with the MS flight models. Among the MS defaults any kind of behavior can be expected (mostly weird and all wrong). Even the MS 747 and 777 exhibit continous adverse yaw of one ball width or more when established in a level turn at a 30 degree bank angle that requires a constant rudder input to correct.By reading the AvHistory Airfile Decode forum and visiting Jerry Beckwith's Mudpond web site this same flight model will now drop a wing at the stall break, and although it can be recovered using normal techniques with only about a 400 ft loss of altitude, if you have the ball out of the center or try to pick up the wing with the ailerons, or if you hold the controls full aft after the break it will enter a spin quite easily to the left or right. A normal spin recovery is all that is necessary to put the world back where it belongs in the windshield. Thank you Jerry Beckwith!:DThe two remaining issues are that it requires too much power to breakaway and start rolling (it needs so much horsepower to start rolling that if you used that much power on the real DC-3 you could roll right over the chocks), and the single engine flight dynamics after engine failure.Nothing can be done about the first, and the second is so much better after applying Ron and Tom G's info about roll and yaw stability derivatives that I'm leaving it alone for now.>I have bad mouthed Microsoft for years! It's owner and CEOand his cronies and many mid managment level folks especially the Sales/Marketting folks should be lined up in public places and either hung by the neck till dead or shot in firing lines, or hung and then shot at!Does anyone have an answer to this shabbiness?:DAs far as the FS gauges are concerned, I would like to see the engine gauges display different readings on multi-engined aircraft. Even with EECs, ECUs and FADEC keeping the engines matched and trimmed, the EGT, ITT, N1, N2, Ng, Nh, Nl fuel flow etc. readings between engines will vary considerably when those engines have different times and cycles on them. It would be nice to see that implemented in FS, instead of the just the same numbers repeated on different gauges.When I retire I'm going to learn gauge programming as a full-time hobby. At least it will be better than golf:D. >In time, it is MS' goal to remove the air file complety and have everything read off of the (or a) config file.EVERY SINGLE gauge in your panel, no matter how complex or simple ALSO relies on the air file. So, how do you get several hundred variations defined into a simpe config? Do you end up with several config files, or one with a few hundred pages in length that the sim has to read before it will load your aircraft.Each release simply edits lines of code and adds and or deletes several more to bring it up to date with the latest technology and coding.The only thing that has truly changed is the overall quality and appearence. The basics are still all the same.MS will only tell us what they want to and nothing more.:D

[Guest Milton]

Hear, Hear! Douglas. :-)I would also like to again thank publicly Tom Goodrick, Ron Freimuth, Herv

[Guest Douglas K]

I am embarrassed to say that I completely forgot to mention Herve Sors, a terrible oversight on my behalf, thank you for reminding me. AFSD is an absolutely indispensable tool, and I am so used to having it running in the background when I am using Flight Simulator that it seems like a part of the sim to me now. I also appreciate his website and all the great resources that are available there.And I should have also included a big thank you to you Milton, your Dash 7 and Aero Commanders have flight dynamics that are among the very best available for MSFS. When I first flew your Dash 7 in FS2002 I fully expected to be disappointed. At that time the turboprop flight models in FS (both freeware and payware) were a big letdown to me. All of them had a pitch attitude on final approach that resembled the approximate climb attitude of a normal aircraft, and they left you with a very uncomfortable feeling of FALLING out from under you and getting progressively further and further behind the power curve on final and I figured that yours would be no different. Boy was I ever suprised and pleased when your Dash 7 proved to be a STOL aircraft no less able than the real thing! The first thing I did after this discovery was the infamous Dash 7 Rocky Mountain Airways 7 degree glideslope approach to Aspen-Pitkin County (KASE) airport. I used to work with RMA's former Director of Quality Assurance when he came to Eagle in the late 1980's and had heard about this steep approach procedure from him. I was finally able to try for myself in FS2002 a approach that has humbled or killed many pilots in aircraft less capable than the Dash 7.So thank you once again Milton, for making MSFS more enjoyable for everyone with your fine aircraft, and let me echo your thanks to all who have contributed to this forum and the AvHistory Airfile Decode forum.

[Guest Ron Freimuth]

>Hear, Hear! Douglas. :-)>>I would also like to again thank publicly Tom Goodrick, Ron>Freimuth, Herv?ors, Jerry Beckwith, and a host of others who>over the years have shared their toiling hours and knowledge>to help us through this mystique. >Milton There are a few more hard core technical types. Ian Kerr knows more about many aspects of AC and turbines than I do and works with Herve' and me exchanging information. Howver, Ian still has the challenge of applying his knowledge to MSFS. ;) Eric Voisard helped Herve' and me with some details of how induced drag might be calculated by FS/CFS. And, other matters. Eric is mainly into CFS AC. If Jerry hadn't decoded the Prop Tables (and many other things) in CFS1 I don't think any of us would be very far. Then there are the misc. people who figure out unknown matters in the AIR file. I forgot his name, but a guy in Switzerland worked out almost all of the 'Mach Tables' a year ago. Only a few more significant ones had been know before then. ----------------------------------------- As far as powerplant 'gauge readings' go, the gauges only report FS variables. How they read is a matter of AC drags and powerplant and often, prop settings. Many things are set in tables, and if all the tables were included in aircraft.cfg it would be really big. And, more confusing to most. Maybe some day plug-ins for AAM.exe (or stand alone SS's, etc) will be worked out to help set prop and turbine tables. With people like Douglas now mentioning 'Stability Deriviatives' the level of sophistication is clearly growing. Heck, I only discovered the term and what it means 2-1/2 years ago. Hopefully Tom G. will update his info on MSFS and include more info on Stablity (and Control) Derivatives. Ron

[Guest vas_yan]

Monty Pythons?

[Guest Douglas K]

>As far as powerplant 'gauge readings' go, the gauges only report FS variables. How they read is a matter of AC drags and powerplant and often, prop settings.Maybe some day plug-ins for AAM.exe (or stand alone SS's, etc) will be worked out to help set prop and turbine tables.With people like Douglas now mentioning 'Stability Deriviatives' the level of sophistication is clearly growing. Heck, I only discovered the term and what it means 2-1/2 years ago.:) I think I can, I think I can.....>Monty Pythons?

[Guest Ron Freimuth]

>>As far as powerplant 'gauge readings' go, the gauges only>report FS variables. How they read is a matter of AC drags and>powerplant and often, prop settings.<>>Right. But I have a ITT gauge obtained in a turboprop aircraft>package that I downloaded long ago that reads 20 degrees lower>than the ITT gauge in the Oleksiy Frolov Dash 8. Something is wrong, they should read the FS variable (and scale) to the same readings. With no more than that truncation error if not coded 'professionally'. Possibly one is an FS98 gauge and is seeing an FSUIPC mapping from a new variable to the FS98 variable. >I assume that both gauges are coded in C or C+ or whatever, so>why the big difference? Can the truncation error that you>mention in your reply to Al account for this? No, truncation only cuts off the invisible digit(s) so one only sees the more significant ones. But, without rounding (up half the time).>The findings that Al and George were reporting concerning the>differences between Mach gauge readings reminded me of my>experience with the ITT gauges. Your answer about truncation>error seemed to explain why different gauges would display>slightly different values, and inspired in me a firm resolve>to learn gauge programming at some time in the future, with>the goal of perhaps creating gauges for multi-engined aircraft>that would better reflect their real world counterparts. Normally gauges should report the FS variables. Most powerplant values can be adjusted in the AIR file. Though, EPR is very poor. EGT isn't that good either, and ITT appears to be just a scaled EGT normally set with a different time constant. I coded JT-8D EPR and EGT in my XML test gauge. First learning how to use Excel so I could fool with the equations. I don't trust panel gauges for displaying even good FS variables(pitch, RPM, etc.). I set up my AC with test gauges. Which I know display correctly. >I have already experimented with using the Corrected A: Vars>in XML gauges to provide different readings between engines,>but found that the results differed too much with changing>conditions (pressure, temp, engine speeds, torque etc.) to be>acceptable. The panel N's are based on the Corrected values with temperature accounted for. They are identical at 15 C. The values in the AIR file tables are Corrected -- one has to remember they normally are higher than the panel readings (due to lower temperatures with altitude). > I don't know enough about creating more complex>forms of XML gauges yet, or whether the G: and L: user>definable variables could be used to create gauges that>display slightly different values. My XML test gauge readings sometimes vary from AFSD by 0.05%. ;) However, it was easier for me than Herve' to get the readings, there were appropriate XML Parameters that required only simple calculations to get what I display. In part because one could use 'atmospheres' for pressure. At SL, standard pressure is one atmosphere. I didn't need to convert from 'in Hg'. The best way to make the engine read slightly different would be to offset the throttle outputs slightly. However, that is probably difficult. One could make Eng1 N1 offset slightly from Eng2 N1 in custom gauges. You can't do that with standard gauges since they read the engine variables directly. One could add 0.007 to the FS N1 and put the result in a custom gauge.>>Maybe some day plug-ins for AAM.exe (or stand alone SS's,>etc) will be worked out to help set prop and turbine tables.<>>That would be a nice feature for AAM, I use it exclusively for>the prop tables. I like the way the data is represented and>it's much easier to make changes. I've read info on how to approximate prop tables for light AC mathematically. But, have never had the time to try to write a program or SS to see if it would help. One would still have to set a couple of constants for it, but that's much better than editing a bunch of prop table entries. Similar for turbines, I use my HP-15 sometimes to set the shape of the curves in TBL 1506. An app could have default values for the constants which might well give better tables than the default MS ones. Best would be to have a list of constants for different standard props. Ian also models turbine tables for us. However, I think he has a way to go to get just what is needed in FS AIR files. >>With people like Douglas now mentioning 'Stability>Deriviatives' the level of sophistication is clearly growing.>Heck, I only discovered the term and what it means 2-1/2 years>ago.< >>Jeez Ron, I sincerely hope that was a left handed compliment!>As in: >>"Yesterday Douglas couldn't even spell aerodynamicist, today>he are talking just like one"! Yup, a compliment. Not as: "Last year I culdn't even spel ingineer and now I are one". Ron

[Guest IanK]

>>Hear, Hear! Douglas. :-)>>>>I would also like to again thank publicly Tom Goodrick, Ron>>Freimuth, Herv?ors, Jerry Beckwith, and a host of others>who>>over the years have shared their toiling hours and knowledge>>to help us through this mystique. >>>Milton>> There are a few more hard core technical types. Ian Kerr>knows more about many aspects of AC and turbines than I do and>works with Herve' and me exchanging information.Thanks for the mention Ron. I am trying to put knowledge of turboprops into the public domain, so if anyone have relevant experience to share please get in touch. I think I have most of it now.> Eric Voisard helped Herve' and me with some details of how>induced drag might be calculated by FS/CFS. And, other>matters. Eric is mainly into CFS AC.>> If Jerry hadn't decoded the Prop Tables (and many other>things) in CFS1 I don't think any of us would be very far. >> Then there are the misc. people who figure out unknown>matters in the AIR file. I forgot his name, but a guy in>Switzerland worked out almost all of the 'Mach Tables' a year>ago. Only a few more significant ones had been know before>then.>>> With people like Douglas now mentioning 'Stability>Deriviatives' the level of sophistication is clearly growing. >Heck, I only discovered the term and what it means 2-1/2 years>ago. I can now compute subsonic SDs from geometric panel areas which correspond to published data.> RonThe guy was Yves Guillaume and he gave us these corrected records:410: Lift - Elevator vs. Mach 411: Lift - Pitch Rate vs. Mach 412: Lift - AoA Rate vs. Mach 413: Lift - H.Stab vs. Mach 420: Pitch Mom - Elevator vs. Mach 421: Pitch Mom - Pitch Rate vs. Mach 422: Pitch Mom - AoA Rate vs. Mach 423: Pitch Mom - H.Stab vs. Mach 430: Zero Lift Drag vs. Mach 433: Pitch Mom at Zero Body AoA vs. Mach 440: Sideforce - Sideslip vs. Mach 441: Sideforce - Rudder vs. Mach 442: Sideforce - Roll Rate vs. Mach 443: Sideforce - Yaw Rate vs. Mach 450: Roll Mom - Dihedral vs. Mach 451: Roll Mom - Dihedral vs. Body AoA (factor) 452: Roll Mom - Rudder vs. Mach 453: Roll Mom - Ailerons vs. Mach 454: Roll Mom - Yaw Rate vs. Mach 455: Roll Mom - Roll Rate vs. Mach 456: Roll Mom - Roll Rate vs. Body AoA (factor) 459: Yaw Mom - Sideslip vs. Mach 460: Yaw Mom - Sideslip vs. Body AoA (factor) 461: Yaw Mom - Rudder vs. Mach 462: Yaw Mom - Ailerons vs. Mach 463: Yaw Mom - Yaw Rate vs. Mach 464: Yaw Mom - Yaw Rate vs. Body AoA (factor) 465: Yaw Mom - Roll Rate vs. Mach 473: Pitch Mom Aircraft vs. Body AoA (rad) Ian

[Guest Ron Freimuth]

>> There are a few more hard core technical types. Ian Kerr>>knows more about many aspects of AC and turbines than I do>and works with Herve' and me exchanging information.>>Thanks for the mention Ron. I am trying to put knowledge of>turboprops into the public domain, so if anyone have relevant>experience to share please get in touch. I think I have most>of it now. It's dangerous to mention specific people, since many others have helped work out the AIR file also. Going back to 'FS95'; before I was into this.>I can now compute subsonic SDs from geometric panel areas>which correspond to published data. I can put AC dimentions in Smetana's DOS programs and get the same results. ;) But, it takes more detail than required for dimensions in aircraft.cfg. However, there are details of just how to set Dihederal Effect in the AIR file. Since Vertical wing offset also has an effect. Ian, perhaps you should try to come up with the SD's for the C310. Cm_alpha is only 0.27 at alpha=0, but increases to several times that at landing AoA. I approximated the curve in the DF C310 (TBL 473). It didn't feel good with Cm_alpha a straight line of low slope, but was OK after I made it curve. RF>> ...... I forgot his name, but a guy in>>Switzerland worked out almost all of the 'Mach Tables' a>year ago. Only a few more significant ones had been know before>The guy was Yves Guillaume ..Right. I think I'm about the only person who ajusts many of the Mach tables now that they are understood.> .. and he gave us these corrected>records:>Ian Not quite all, these two were known before I got far into AIR files:>430: Zero Lift Drag vs. Mach >433: Pitch Mom at Zero Body AoA vs. Mach (Mach Nose Dip) And, this is not Mach Related, and was also know some time:>473: Pitch Mom Aircraft vs. Body AoA (rad) I've set TBL 433, Pitch Moment vs Mach, in the Concorde so it accounts for the rearward shift in CoL as Mach Increases. It only took '40' or so to give a pitching moment that represents moving the CoL aft (or CG forward) several feet. Which is pretty well balanced by the trim fuel moving the CG aft from 52% to 58% MAC. I calculated the MAC to be about 50 ft, so 6% of that is -3 ft. However, for a delta wing the full root chord may be used. That is more like 90 ft.The shift in fuel mostly balances the effect of my TBL 433. For those curous about how I calculated this, I'll give some formulas. S*q is reference from all SD's. For the Concorde, S is about 3900 ft^2 and q is about 600 lb/ft^2 at cruise. Reference for pitching moments is S*q*MAC. '40' comes to 0.020 when scaled by 2048 to its real value. S*q*MAC*0.02 would then be the actual pitching moment when TBL 473 is at '40'. That comes to 2,340,000 ft-lb. All I need to compare it with is Weight * delta_CG (ft). Where delta_CG is about -4 ft. At 300,000 lb, that gives 1,200,000 ft-lb shift in CG. Looks like I set Cmo(Mach) kind of high, I used somewhat different values before. Regardless, the effect on trim is much smaller than other things. ;) Ron

[Guest Douglas K]

>Possibly one is an FS98 gauge and is seeing an FSUIPC mapping from a new variable to the FS98 variable.Something is wrong, they should read the FS variable (and scale) to the same readings. With no more than that truncation error if not coded 'professionally'.805-------------------------Np=46%FF=432-------------------------FF=262I found that the ITT starts out with a 20 degree split at flight idle power, the Dash8 gauge reading 20 degrees higher than the turboprop gauge, then as power is increased the turboprop gauge catches up and displays a reading 10 degrees higher than the Dash8 gauge as the T/O torque setting is reached, and that the Frolov ITT increases by 70 degrees between idle and T/O power, while the unamed turboprop eng gauge manages to increase by 100. So the rate (and possibly scale?) factors are different between the gauges, something I thought was only adjustable in the airfile. Also, the torque readings are considerably different between the two gauges at flight idle, but are exactly the same at high power settings. I also found that the turboprop gauge Np is reading very low, it displays 46% at F.I (should be about 67% for 805 rpm), and only 68% at T/O power (should be at or near 100% for about 1200 rpm). Fuel flow is considerably different between the two gauges, the unamed turboprop gauge reads 170 PPH lower at flight idle, and a whopping 463 PPH low at T/O power. AFSD disagrees with both of these fuel flow gauges, reporting 575 PPH at F.I, and 1511 PPH at T/O power! A check with the default King Air 350 revealed that its fuel flow rate agreed closely with AFSD. How is this possible? Some months ago I reworked the Dash8 flight dynamics for a PSS Dash8 visual model/Frolov Dash8 panel merge I did. But beyond checking the power settings and airspeeds at three different altitudes (8000 ft, 16000, and 24000 ft), against the data in the performance charts and making some minor adjustments I never really went into the engine parameters, being too lazy to use AFSD to get a good look at them and possibly having to overhaul everything. Instead I concentrated on the flight characteristics and when I was satisfied with those I called it a day. Stupidly I used the panel fuel flow gauges to crosscheck the fuel flow against the charts, and I never ran a check on range or fuel remaining after a timed flight.So today I decided to check the fuel consumption using the time honored and tested method of starting with a known amount of fuel, then flying for one hour at maximum cruise and "dipping the tanks" to determine the amount of fuel used. During this flight, the dash8 gauges read 844 PPH, the turboprop gauges 494 PPH, AFSD reported a very accurate 1090 PPH against what I measured as 1095 PPH per engine (my measurements are probably in error by 5 PPH) that was burned during the 1 hour flight. The book figure is 856 PPH per engine at maximum cruise power settings, OAT 7 degrees C and A/C weight at 43000 lbs, very close to what the panel gauges were reading, but too low by nearly 500 PPH for the actual amount of fuel burned by both engines. Best to not plan any long overwater flights!Note: None of the above is meant in any way to be a criticism of Mr. Frolov's Dash8 A/C, I think it is absolutely brilliant and it is one of my all-time favorites. I am only using it as an example of the differences that can exist between FS gauges and the potential for increasing realism in FS by creating custom gauges. Strange to find such large variations between these gauges and contrast it against the precision from AFSD, aren't they reading the same FS variables? This is what fueled my desire to learn to create gauges in C, they seem to have calibration possibilities, and might be created to display different readings between engines. I've found that the XML gauges that I can create will only read the FS variables. And then I read what you wrote below: >The best way to make the engine read slightly different would be to offset the throttle outputs slightly. However, that is probably difficult. One could make Eng1 N1 offset slightly from Eng2 N1 in custom gauges. You can't do that with standard gauges since they read the engine variables directly. One could add 0.007 to the FS N1 and put the result in a custom gauge.Yup, a compliment. Not as: "Last year I culdn't even spel ingineer and now I are one".

[Guest Ron Freimuth]

Douglas, I read your second message about differences in gauge readings. I don't have many more ideas. ;( You might rename FSUIPC.DLL to *.DL$ before running FS and see if the gauges read any differently. That would suggest FSUIPC is mapping some old variables to what you see. It seems the FSUIPC.ini file can be set to map or not to map, but that confused me -- I'm not sure it did what I thought it should. Occassionally a gauge will read the wrong FS value. Or, calculate a conversion incorrectly. I bet there is some macro many use that converts to F (or C). Howver, when temp went below freezing the reading went over 100! An error in the macro. I saw this more than once but couldn't get a panel and gauge programmer to fix it for one freeware AC. I found there are two EGT Parameters (probably token variables also). I couldn't figure out how to scale one for a Jet EGT reading. But, eventually found the other one (I think "General Engine ... " directly gave what I wanted. Turboprop parameters can be tricky. It seems there is only 'Percent Torque'. If it reads in ft-lb it is probably calibrated for the Rated Turboprop Torque setting in aircraft.cfg. That's how Herve' set AFSD to display turboprop torque in ft-lbs. "Percent * value_in_aircraft.cfg". I don't know if there is a C macro or function to display digtal readings to a given number of digits. Whatever, it truncates the displayed value, giving an average error 1/2 the invisible digits low. I requested that a couple of older digital test gauges be fixed for this. Normally a compiler rounds displayed digital values with correct round off. I don't know if some (not all) of the fixed display fields had to have 1/2 LSD added, or if the authors used some other way to display the values correctly. Regardless, not every value displayed got fixed. ;) As I've mentioned, I don't see that error in FS9 panel readings. MS fixed a lot of stuff that's not so obvious -- too bad they broke many other things (or, new WX, etc. has it's own set of new problems). --------->As a young man I failed to demonstrate any real talent for >differential equations and calculus, ... Half the U.W. engineering class failed the third semester of Calc and Analytic Geometery. It was mainly Differential Equations. ;) I don't remember anything from that semester, fortunately the D.E.'s used in Elec Eng are presented as needed. Most fit in a few classes that weren't taught much in the Math class anyway. It is useful to know what "derivative" etc. means in this FD stuff. Many time delays (CHT, EGT, VS, etc) are set to solve a D.E. where 'The rate depends on the amount remaining'. In the case of CHT that would mean it changes fastest when the distance left to the final CHT is the greatest (ignoring the effect AC speed has on cooling). I figured many parameters in the AIR file that affect how fast a reading changes were based on the reciprocol of the "Time Constant"; what I call the 'Rate' in the CHT, etc. records. In one TC, the value changes 67% of the amount to the final value. Now looking at real data for CHT, it looked like the TC was about 60 seconds. So, I set the 'CHT Rate' parameter in AIR files to 1/60. Which is 0.017. The CHT gauge appears to change at a reasonable rate. BTW, MS defaults are too fast for Oil and Water (Radiator) temperatures. Clearly, the Oil heats up more slowly than the CHT. So, I set the "Oil Temp Rate" to something around 0.005. Which corresponds to a TC of 200 seconds, over three minutes. Be careful, in aircraft.cfg many things MS calls 'Time Constant' are actually the reciprocol. I guess they don't understand what a TC is. ;) At times gauge readings have been fudged to try to fix problems in the AIR file. Howver this is usually not appropriate, it's much better to have the correct flight and powerplant settings. AFSD is very likely to be correct. I give Herve' plenty of static if I find something I don't think is correct. ;) So, if AFSD or some other good test gauge doesn't agree with your gauges, you are on your own to to find or create a gauge that is correct. Ron

[Guest Ron Freimuth]

Douglas,REDUNDANT. Most deleted.Ron

[Guest Douglas K]

>You might rename FSUIPC.DLL to *.DL$ before running FS and see if the gauges read any differently. That would suggest FSUIPC is mapping some old variables to what you see. It seems the FSUIPC.ini file can be set to map or not to map, but that confused me -- I'm not sure it did what I thought it should.AFSD is very likely to be correct. I give Herve' plenty of static if I find something I don't think is correct.So, if AFSD or some other good test gauge doesn't agree with your gauges, you are on your own to to find or create a gauge that is correct.:)