Sign in to follow this  
Guest xoio

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

Recommended Posts

As the question asks....Why do micro$oft still seem to 'refuse', or at the very least, never get round to fully divulging HOW their .air files are structured? Thus allowing plane designers complete control over the Flight Dynamics etc..Correct me if I'm wrong, but it seems like we have to continually scratch around in the dirt, using trial & error. to only come up with fragments of knowledge.... Would it REALLY be that much of a problem if Micro$oft DID release FULL details concerning the hidden depths of the .air file? It would make so much more sense..... Afterall, why promote that their flight sim can expand with addon planes etc, when they don't help in giving all the info needed to build those planes properly.....Any thoughs?? .... Does Anyone know anyone from the MS Sim development team, To get an answer to this lack of co-operation? Al :-)

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I think the bottom line is like any game produced for public consumption, that once the game/simulator whatever..has been done,the company then feels it wants a return on the product produced, maximizing their return by NOT SPENDING ANY MORE MONEY PAYING PEOPLETO EXPLAIN HOW THINGS WHERE CREATED/DEVELOPED.And when you think about it. Why should they have to explain how they developed something. We as consumers must bear in mind, that Microsoft or whoever, does not create a product with the expectations that they then will tell the world how they developed it. The idea is to make money on said product/service, with pre-prescribed methods of marketing/sales/distribution methods. NOT explain to the world how they made the product.I think we often forget the reason behind the free enterprise concept. The concept is to create a product/service, whatever. andsell it to a consumer market.Would you for instance, complain about some Drug Company not devulging how they created a given drug? Or would you complain about an Aircraft Company not providing minute details on how they developed some feature in one of their aircraft?Likewise, game producers should not be expected to devulge how they created the product they marketed. Obviously it is a great thing to see some company take the time and effort (willingness to pay people to follow up to provide information on how their product) to give details on their product but I don't think it is fair for use to comdeme them. OK, in the case of Microsoft, they have been a bunch of sneaky bandits for years, but that is their right based on the free market principle. Food for thought...

Share this post


Link to post
Share on other sites

Fair comments,However, Drug companies don't promote actively that their drug CAN be combined or added to... (for obvious reasons).If we compare MSoft to your aircraft company.... Its like them saying... "Of course you can customise our aircraft with your own cockpit instruments, however we won't tell you anything about how to install them so that they ACTUALLY WORK with our plane." etc etc....Unlike a drug company, MSoft DO promote that their product (sim) CAN be added to. But then then don't back that up by telling you HOW to do it properly..... Its that old addage... If you're going to do or offer something.... DO, or offer it properly. But as usual.... its Half baked with Msoft.How many years has flight sim been around in its various forms? 20years..? Over that time, they have obviously followed some gradual learning curve as to how they best impliment their interpretation of Flight Dynamics. You'd think given ALL that time, they could divulge something about how their FD works. Thus aiding 3rd party developers, especially when they actively encourage 3rd part development. But the very componant that is lacking in info, remains SO IMPORTANT to the success of a 3rd party plane developer. .... I think my counter comment is just as much food for thought :-)Al

Share this post


Link to post
Share on other sites

It's probably no more a mystery than aerodynamics is to the lay person. Everyone is not in the dark.There is a lot of knowledge running about by people who know aerodynamics.What we need is a really nice high level tool that allows us common simmers to set up a reasonable package.Jerry Beckwith has one and it is available to you free for the download. I use it and love it. You only need basic geometric and performance data to set up your FD's. The end result is an .air file and an aircraft.cfg file with other goodies as by-products.Take the time to learn this tool and be happy.http://www.mudpond.us/Milton

Share this post


Link to post
Share on other sites

Milton,I agree with everything you have had to say. I was just trying to show the rational in how companies "think and act". I am a Ex-BellLabs engineer amoung otherthings. And while at the labs for 13 yearsI had deep involvment in UNIX and then later in the Linux with a small VAR. 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!The company run by the little giant that never grew up knowing what real engineering and programming was really about, has played havoc on the world scene for some twenty two years now! They have cause more heart ache and a loss of money to companies etc., that eventually get passed on the the customer, then one can shake a stick at. So yes I agree with all you have said. Problem partly is..........I am convinced that they have few if any real sharp people, either in the development areas or the documentation areas. In a pinch, their people do not produce high quality documents for their products most of the time. And as you are aware, have done their best over the years to hide and deceive information. Many compaines have complained to no end of how shaddy MS really is, butto no avail. They just keep rolling along!There one specialty and they seem to be pretty good at it has been to keep a careful eye on third party developers and when the time is right, try to take the company over or with often dis-honest or otherwise deceiving tactics try to convince the public and often very limited Information Tech people of why they should be leary of purchasing those third party products which often where created to begin with for the sole reason they did not exist, or ran poorly in the windoze ops. So yes I am with you on all you have complained about.hang in therePS. Thanks for sharing the tool mentioned in your last letter. I maycheck it out once I get some C++ compilers up and running I downloaded based on help provided by a JeanLuc and Arne Bertels.Figure I will try to design some gauges based on the Panel_SDK.......groan! YES ...........Microsoft probably only gives enough info to those that crated the tool kit to make us all quite miserable!

Share this post


Link to post
Share on other sites

Argg, I wish I could use the workbook, but I don't have Excel.

Share this post


Link to post
Share on other sites

Well, if you could swing it, it would be a great investment.Jerry's workbook is one awesome tool. I love it it because it generates all the airfile tables and parameters specific to your aircraft components. The end result is accurate takeoff, climbout, cruise and descent all on the numbers (of course only as accurate as your input :-)You learn a lot about what parameters affects which tables in the .air and .cfg files, see table data, input proper air foil numbers and you can tweak key flight characteristics using lay terms. It can be a great learning tool.Milton

Share this post


Link to post
Share on other sites

I do understand the frustrations having gone through the design learning curves. I guess that's part of the fun, the challenge, the mystery, and the gratification that comes with conquering it.Heck, if that were not there, I'm not sure I would be doing this. :-)Milton

Share this post


Link to post
Share on other sites

Milton,Question for you. I downloaded the package as you sugggested. Thenfor the heck of it included the MACH and RADAR ALTIMETER GAUGEs in my T38 Talon panel (the neat one we download at this site). Well,as usual. Now when I look at the mach number (two decimal point accuracy of his guage), verse what I see in the Speed/mach gauge that comes with the Talon T38 the International version that has threedifferent paints, and all working parts created by FSD.....,there is a definite difference by a few percent in what each gaugeindicates. I am not complaining, only making an observation. So what I think I will do is add the Mach gauge to various aircraft I have that include mach guages of one form or another and see how much theyall differ. One would think that if all used the same parameters in the gauge design refering the aircraft such as A:Airspeed mach, thenone should see the same numbers for all gauges. At any rate, thanks again for the tool reference. No need to repond out of courtesy if there is nothing to add in this particular case.chowGeorge

Share this post


Link to post
Share on other sites

Hi George / Milton or anyone else....I've noticed this with differing Mach Gauges as well.I'm working on an extremely fast plane: (Mach 4+)The cockpit at the moment is a mish mash of different gauges including some from the default Concorde mega gauge.The panel has a primary MFD. On the MFD there is a little mach number below the vertically scrolling ASI. My panel also has the Concorde Mach Gauge...(ALL weather is off during the gauge test to create a control environment - pressure 29.92)As I start to accelerate, I begin to notice a discrepancy creep in between the two gauges. So much so, that when I'm flying at Mach 4.55 according to the Concorde Mach gauge. The little Mach number in the MFD is only showing Mach 4.51 It gets worse!!... I popped in the basic Mach meter from the panel that comes with the X-15 recently released... This was WAY OUT in the opposite direction!!!I.E. Concorde gauge showing M 4.55 ... X-15 showing M 4.66 !!! .. Whets going on?? Surely mach is gained from a centrally running sim variable??? (Thus all numbers should be the same?) Or do gauges like these, allow the creator to input whatever formula they like to calculate mach? If so, this is stupid!!... If not... what the heck is going on!???During the above, the IAS & Groundspeed were the same values. (So it's nothing to do with flying at different speeds by mistake.) Bare in mind also, that I had ALL three Gauges on the screen at the same time.. with all three showing the different readings simultaneouslyMost importantly WHICH GAUGE is CORRECT? Or at least the closest to being accurate?I even see this slight type of error with air pressure gauges..... One gauge could be showing 29.92, whilst another gauge, (again on the MFD) is showing 29.91 !Does anyone have an answer to this shabbiness?Al

Share this post


Link to post
Share on other sites

Hi IanThanks for the reply, however this thread is concerning Gauges that display the same thing (eg Mach) but show discrepancies in accuracy when compared against each other.The links you've given me though are sites that i already know about & have alas had no luck in answering the specific questions I'm after. But thankyou for answering.RegardsAl

Share this post


Link to post
Share on other sites

>Hi George / Milton or anyone else....>>I've noticed this with differing Mach Gauges as well.>I'm working on an extremely fast plane: (Mach 4+)>>The cockpit at the moment is a mish mash of different gauges>including some from the default Concorde mega gauge. First, as Herve' Sors indicated some time ago, the Mach Variable only goes to Mach 3.2. It is scaled to 0 - 64 K. That is stated in a gauge SDK file. Any higher reading would seem to be faked or perhaps errors in the scale factor or an overflow error.>I even see this slight type of error with air pressure>gauges..... One gauge could be showing 29.92, whilst another>gauge, (again on the MFD) is showing 29.91 !>>Al MS, and other gauges often truncate, rather than "round to nearest", so many altimeters display 29.91 when the SL pressure is more like 29.919. N1=91.99% would display as "91", not "92". I noted that this truncation error was (at least partly) fixed in FS9. AFSD displays appropriate, rounded values. My XML Test Gauge displayed variables are also appropriate. "TAS", "GS" and "Mach" variables are very accurate in MSFS. However, "IAS" can no longer be calibrated in the AIR file to get appropriate compressability effects. It reads about 5 kts high at FS320, 250 CAS.RAF

Share this post


Link to post
Share on other sites

Well Al,This stuff is also starting to get to me! I am in the process of trying to learn enough XML Gauge programming to make a XML gauge that will produce a sound whenever MACH 1.00 is exceeded. If I ever get the gauge to run correctly, then I plan on playing around with the various aircraft parameters associated directly or indirectly with speed and mach to see if I can figure out better what is happening here. Trouble I am having is I am in learn mode, so I am attempting to use XML Code produced from others along with some of the available sound gauges with the result that things are getting really screwy.I get sounds produced that never should happen with the particular XML code I am using for test gauge etc..If I ever figure this stuff out, and get an operational gauge that then can be fine tuned to sense different ways of sensing MACH (whatever it even really means in FS2K2), I will share my results with the AVSIM community. But at the rate I am going, I may go nuts before getting a basic gauge to work correctly! Some weird stuff has been happening. Perhaps due to my ignorance as how the whole XML gauge and associated sound files available work.Hang in there,George

Share this post


Link to post
Share on other sites

Hello Al,I was only replying to your first posting before the thread got on to guages, in reply to the subject line and the text, which did not seem to have been adequately answered down the thread. Unfortunatly guages are necessary to extend the behaviours that the basic sim does not provide.Ian

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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?

Share this post


Link to post
Share on other sites

>>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

Share this post


Link to post
Share on other sites

>>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

Share this post


Link to post
Share on other sites

>> 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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this