Flight dynamics - drag couple of questions

[Guest Ron Freimuth]

Douglas,Interesting comments.I only have time right now to say the MS prop thrust is supposed to be calculated by 'low speed formulas' at low speeds. Note the '80.0' ft/sec setting in the (prop) section. That is supposed to merge 'low speed theory' with the prop tables at 80 ft/sec (47 kts). Changing that '80.0' did have some effect to TO acceleration when tested in 2000. It might also affect reverse thrust performance, though should only when air speed is above the value set. Not for low speed backup. But, who knows?'Low Speed Theory' is needed to calculate static thrust since normal theory is based on J=V/ND, and V is zero or very low before air speed over the prop picks up. I think the theory calculates thrust per unit area of the prop's swept area and HP into the shaft. However, I found I could change static and low speed thrust by editing the Ce (Efficiency) prop table at J=0. So, things don't appear to work as claimed. Typical of things the Airheads get their fingers in.Note there is a 'min blade angle at idle' setting. That is important for 'simple' CS props. I found it should normally be set to the same mimimum blade angle used in normal flight. Otherwise, the prop might go to zero degrees at idle and RPM run too high. Of course, if the prop really drops below the minimum flight blade angle stop when on the ground then one sets something near that angle. There is also a question of what 'blade angle' means. It is similar to AoA for a wing. Note zero AoA produces a lot of lift with a cambered wing. A blade with its chord line at 0 degrees would still produce positive thrust.However, the 'low speed theory' may figure zero degrees gives zero thrust. I don't think blade camber is taken into account. But, MS might have added an arbitrary offset to the angle to 'make things simple'. 'Simple' doesn't mean realistic.One can see what prop thrust is with AFSD, etc. I set the reverse throttle setting to get appropriate reverse thrust in normal turbine engines. It depends on the turbine tables and I've found 50% is necessary to generate appropriate reverse thrust.I added 'Pitch' and 'Slip' to my XML Prop Test gauge to better see how a prop operates. 'Pitch' changes in a CS prop, I displayed it in feet rather than inches. A small AC FP prop runs maybe 66" pitch.From Pitch I calculated Slip. That may be 20 deg or more at high throttle, low speed but drops to near zero at cruise. When one pulls back the throttle Slip may go negative, which indicates the prop is absorbing power.However, 'Slip' is only correct if the prop tables are set with accurate values for each Beta. Conversly, if Slip is realistic, I'd figure at least some elements of the tables are accurate.The point here is 'slip' gives an intuitive number related to prop operation. It shows one the blade AoA. Meaning one should be able to use airfoil theory to see if prop performance is appropriate."Slip" might also give a better idea of reverse operation. Ron

[Guest Douglas K]

Ron,>Changing that '80.0' did have some effect to TO acceleration when tested in 2000. It might also affect reverse thrust performance, though should only when air speed is above the value set. Not for low speed backup. But, who knows?80, AFSD reported the prop thrust as -455 with the brakes set. Setting low_speed_theory_limit to 10 resulted in so much thrust in reverse that the tail struck the runway and bounced again and again with the thrust varying from -5000 to over -7000 between bounces. So I'd say it does affect reverse thrust, and that this is one more way to increase the reverse thrust effect for aircraft with propellers. Also, that the MS assertion in the SDK that it is the speed in ft/sec at which low-speed prop theory is blended into high-speed theory must be something less than accurate, (to put it kindly) since propeller thrust with the aircraft static and at idle RPM is increased by reducing this value. But see below for more testing with the C-172, both static and moving forward. >'Low Speed Theory' is needed to calculate static thrust since normal theory is based on J=V/ND, and V is zero or very low before air speed over the prop picks up. I think the theory calculates thrust per unit area of the prop's swept area and HP into the shaft.However, I found I could change static and low speed thrust by editing the Ce (Efficiency) prop table at J=0. So, things don't appear to work as claimed. Typical of things the Airheads get their fingers in.80, the time to 60 KIAS was 12 seconds. Changing it to 10 yielded an identical time to 60 KIAS of 12 seconds. I took screenshots of both takeoff runs from top-down view, and a comparison of those showed that the aircraft reached the same location on the runway both times. I found the same results testing in FS2002, but the MS C-172 in that version took 18 seconds to reach 60 KIAS.With low_speed_theory_limit at 80, AFSD reported thrust at idle RPM as 18, and 75 at 1000 RPM. Set to 10, idle thrust was 38, and at 1000 RPM it was 161. I've been using your excellent 'Comments on aircraft.cfg' as a reference, and the comment for the low_speed_theory entry states: "Lower may reduce TO distance - but 80.0 is good". I figured if 80 were good enough for you, then it was more than OK for me. But it looks to me like it doesn't affect the takeoff distance at all in FS2002 and FS9. As I mentioned previously, it does have a big effect on very low speed thrust and the breakaway power needed to start rolling. The FS9 C-172 would start rolling at 1250 RPM with low_speed_theory_limit at 80; with it set to 10 it would roll at 1000. The FS2002 C-172 would need 1400 RPM to roll at the default value of 80, and lowering low_speed_theory_limit to 10 reduced that to 1100 RPM. Exactly what you would expect when looking at the prop thrust in AFSD before and after editing.>Note there is a 'min blade angle at idle' setting. That is important for 'simple' CS props. I found it should normally be set to the same mimimum blade angle used in normal flight. Otherwise, the prop might go to zero degrees at idle and RPM run too high. Of course, if the prop really drops below the minimum flight blade angle stop when on the ground then one sets something near that angle.There is also a question of what 'blade angle' means. It is similar to AoA for a wing. Note zero AoA produces a lot of lift with a cambered wing. A blade with its chord line at 0 degrees would still produce positive thrust.

[Guest Ron Freimuth]

Douglas, You have really been into 'props'. Good Comments! Have you visited the avhistory.org Air File - FD Forum? It's been up and down recently, due to moving to a different server. When one defines prop efficiency as Pout = V*Thrust divided by Pin = 2Pi*N*Torque you get zero when V is zero. The standard prop equations don't work well. While AC velocity, V is zero when braked, the air flowing past the prop is still moving. However, I think V relative to the AC is still the basis of Po/Pi. "Blade Angle" is typically measured at 75% of the distance to the tip. I came up with the simple formula to figure 'Pitch' (the forward distance a screw moves, per revolution, with no slip). Pitch is generally measured in inches, but I changed the display in my XML Prop AC Test gauge to feet. Knowing TAS in ft/sec, one can calculate relative 'Slip'. Note 'pitch' and 'slip' are based on Blade Angle, Beta. So, the prop tables have to be correct for each Beta column to get a realistic 'Slip'. Conversely, that helps verify the prop tables are approprite. As the FS2000 aircraft.cfg files became avalaible it was seen that the mysterious '80.0' in the AIR file prop record was shown in a comment as 'low speed theory limit'. One CFS guy tried different values and logged the TO roll for some CFS AC. There was an effect. However, my prop AC appeared to be OK with the default '80.0'. And, as you also mentioned, editing the prop tables still has and effect below 80 ft/sec. Besides the efficiency table, I've changed the Cp (Power) entries a bit. Lowering an entry means less load from the prop so it spins up faster with the same shaft torque. That way, I could adjust the run-up RPM to the specified TCDS value. Dr Lowry owns a C172 and used measurements from it for calculations in his 'Performance of Light Aircraft'. He gives a way to calculate prop tables from prop measurements and his combination of Blade Element and Momentum Theory. One has to find the 'Activity Factor', which amounts to how much of the prop disk is activated by blades. Wider, or more blades increases that factor. If one has a set of general prop curves he should find there is one value that gives the best overall prop accuracy. I think the C172 prop has a value at the low end of his curves. However, Lowry also has some more direct curves for the C172 FP prop and I started with them in setting the single row of entries needed for each prop table. Then, made fine adjustments to get RPM, TAS, Percent HP, and MP quite close to the C172 POH tables. Note the engine also has to have appropriate HP vs RPM and MP to get the powrplant-prop combination to work. Further, AC drags have to be appropriate. Too many things to adjust experimentally! But, I could set and verify drags somewhat independently of the powerplant, and set the engine curves from a combination of general knowledge and published data. That leaves mainly the prop curves to tweak for the final adjusments. CFS and FS2K set excessive prop efficiency, I decided they were 'raw' data, taken on a test stand with no AC fuselage interference. Lowry's text mentioned 'Slow Down Efficiency Factor' and 92% is a good value. So, I multiplied at least the high efficiency prop table entries by 0.92 to bring them down to the more realistic values a mounted prop gives. That is well known to be around 83% to 87% at cruise. While I might experiment with the J and Beta entries corresponding to climb to set them near 70%. I got Herve' to add Prop calculations to AFSD so I wouldn't have to calculate J for each TAS involved. That made it easier to adjust the prop tables. Douglas, you would probably like to look at my XML Prop Test gauge. While some of it has tricky strobes to reduce CPU overhead, the torque, power, etc. formulas aren't too hard to follow, And, XML parameters let me set appropriate scale factors directly. I found the Engine Power Parameter is only in kW, so has to be adjusted by 746 to get HP. The XML Parameters list also shows only kW available. While most of the things displayed in my XML test gauges are correct for any AC, some are specific to prop diameter, etc. So, I've had to enter those values for the specific AC I'm testing. But, the 'gauge' is so small I can set different variations in different GAUGESsubfolder names. If put in CAB files they would probably be under 10 kB. You could modify the XML gauge to display what you want to see. And, probably get ideas for other gauges that made use of the flight paremeters calculated. It would be easy to add "BMEP", since that's just based on total displacement and shaft torque. ------- I also want to improve the CHT some day. Bypass the FS "CHT" and generate a variable that changes with more than RPM. I'd also like to make CHT vary with Mixture. One could even display the rate CHT is changing, and if it got too high add 'damage' to some logged data that accumulated the effects of shock cooling. You can't save XML calculations in files (at least not FS2K2 XML) but a C gauge could. More realistic CHT readings would be a significant improvement to the more complex AC modeled in FS. I'd post a screenshot of my Test Gauge, but something is messed up in IE and I can't UL. However, my email address is listed here so you might email me if you like. I'll see what I could send you. Ron

[Guest SHORT360]

Douglas,Very good comments, Thanks. >>as you noted Mr. Frolov has done this brilliantly with his Dash 8-Q300,I know also a bit the real Dash8 for having spent more than 20 hours in the cockpit twice a week some years ago. ( I am private IFR rated Pilot) Here I heard the first time that the blade in the Dash8 -100 are at -3

[Guest Douglas K]

Ron,>Have you visited the avhistory.org Air File - FD Forum? It's been up and down recently, due to moving to a different server.

[Guest Ron Freimuth]

"I agree. It would be a significant improvement in realism. Speaking of improvements, with FS9 CHT now varies with the cowl flap position. Also, some people have reported an increase in drag from open cowl flaps, but I haven

[Guest SHORT360]

Hi Ron,I would be interested in your prop xml gauge. You can sent it directly to roger.wielgus@noos.frBy the way do you think it would be possible to create an XML gauges able to play a particular sound file when the throttle is set in the beta range?Cheers,Roger

[Guest Ron Freimuth]

>Hi Ron,>>I would be interested in your prop xml gauge. >By the way do you think it would be possible to create an XML>gauges able to play a particular sound file when the throttle>is set in the beta range?>Cheers,>Roger I just emailed you. I still need to do something so one doesn't get confused by 'Prop Test' from the AC dependent settings. At least I have some comments in the source. ;) There are recent threads on setting sound files from an XML gauge and I think the interface is in the AVSIM library. Ron

[phjvh 0]

Hi,Doug Dawson's "dsd-xml-sound.gau"Over 100 sounds possible!I'm very, very!!!! pleased with it.Jan"Procul Negotiis"

[Guest SHORT360]

Great!!!Thanks. Gonna download it.Roger

[Guest SHORT360]

I downloaded it and toke a look in the files and must say that it is pure chinese for me. I do not understand the relation between a gear wind sound and the ADF2 radio setting. There must probably be an excellent reason, but I cant decode it.I really do not understand the core of that system.Thanks for the helpRoger

[ddawson 35]

Roger,Drop me an e-mail at the address noted in the readme.txt and I will give you a hand.Doug

[Guest _FSAviator]

Posted in text format as I could not get the server to swallow the included URLs when posted as HTML and as the last post in sequence since I deal with issues from several posts within.Firstly apologies to Roger for not reading the second part of the original question carefully enough. I am glad that others were able to solve that problem. This thread has drifted into other matters a couple of which caught my attention and motivated me to post again.In several recent threads posters have talked about 'problems' with CHT.Firstly I concur that the CHT variable responds correctly to cowl flap position. There is no problem.<>There does not appear to be sufficient evidence that a little extra friction between a cylinder and a piston separated by a film of oil is a significant source of heat in a furnace. Ignoring the friction heat change looks sensible. <>It already does. The problem is not in the CHT code. The bug is in the mixture code. The mixture algorithm does not recognise an over rich mixture as such. I cannot see any evidence that MS understand this issue or intend to address it. Resolving it requires an FSUIPC based solution. In short I cannot see anything wrong with CHT that needs to be fixed in either FS8 or FS9.>The discussion of 'extraneous drag' particularly caught my attention.Ron said,<>Yes, I do that whenever relevant. Douglas said,<>Like much else it has to be added by third party developers. I am probably the only flight dynamics author who bothers. Big piston engines are not easy to replicate in MSFS. The mainstream payware producers studiously ignore them. If you have not flown any of my FDE produced to work in conjunction with Tom Gibson's flight dynamics extension gauges it is all too likely that you have never experienced cowl flap drag in MSFS. << Drag from open cowl flaps could be significant on the old radial engine cowlings, and on the multi-engine aircraft it could be a big problem if an engine failed. Be nice to see that modeled in MSFS.>>In a powerful twin engined propliner such as the Convair CV-340 fully open cowl flaps add about as much drag as the final stage of flap. In a DC-6 twice as much, in a P-47 half as much. In a modern twin with flat six engines again about a 'stage of flap'. The cowl flaps would not be fully open for climb, but it is not really possible to create realistic flight dynamics for aircraft with complex air cooled engines without cowl flap drag since it controls available climb rate, current operational ceiling and therefore time to height. In large aircraft it determines the ability to step climb which in turn determines the cruising TAS. Fortunately more than two dozen complex piston propliners, a military freighter and a tanker, all with appropriate cowl flap drag are available from the home of the propliners;http://www.calclassic.com/They are probably the most complex piston engined aircraft simulation files available for use in any desktop flight simulator. The learning curve can certainly be steep, but they all have step by step on screen handling notes. Don't expect them to fly like the real thing if you don't make the right inputs at the right time. The Convair twins are a good starting point on the learning curve.Use of the provided panels is mandatory as the flight dynamics are spread between the aircraft.cfg, the air file and the gauges. Use of the handling notes is mandatory if you hope to replicate the flight envelope of these complex aircraft. Some offer substantial simulation of the flight engineer function as well. Not all have updated flight dynamics for use in FS9, but no one has lost the use of FS8 just because FS9 exists. FS9 has no obvious advantages for simulation of medium level IFR and several disadvantages. The alternative AI FDE files, low poly multi LOD MDLs and a California statewide recreation of the airports as they were in 1959 are available as separate freeware downloads from the same site. Non pilots may struggle with many of the concepts involved in operating a large, complex, piston engined aircraft. End user support for these files is provided via Tom Gibson's forum at;http://www.simufly.com/cgi-local/YaBB/YaBB...d=Classic_PropsThere is an active user base in Tom's forum, including at least one current propliner captain. Please search the database there for earlier answers. No support questions here please.Elsewhere in this thread on the same subject;<>The singular 'spoiler' variable has incremental use. We can code the angular increment for each event. For example in the DC-7, one increment for each of four sets of cowl flaps and a bigger increment for the main gear when it is lowered (without the nosewheel) as two air brakes. The only limitation is that the drag is applied along the datum line. Multiple 'spoilers' would not solve that, but see below for the solution. We have as many 'spoiler' increments as we need. All we have to do is code the max co-efficient of drag to match the sum of the possible increments. In most piston engined aircraft few of these potential drag events have a significant pitching moment or disrupt lift.In many cases there is no need to use spoiler code at all. If we need to manipulate lift, drag and pitching moment there are potentially flaps.n solutions available. This takes some care but in principle Flap.n can be coded as the flaps. Flap.n+1 can be coded to deliver a dive brake. Flap.n+2 can be coded to deliver each of four cowl flaps. They are associated with specific angles of deflection. The matching drag, lift and pitch scalar are then coded to match the specific requirement of that event.Complaining that MS don't do anything to make our lives easier is simply not true. However in many cases the best solution to real time variation of these variables is to use FSUIPC because this can manipulate off datum line inputs. Whilst we cannot manipulate drag directly using FSUIPC we can manipulate thrust and its analogues. So we can manipulate the energy state in any way we like. If we need to replicate asymmetric drag from leaving just one set of cowl flaps open on a DC-6 we would need to use FSUIPC to reduce the thrust on that engine by the value of the excess drag. Frankly I don't think it matters whether Microsoft bother to provide the tools for better FDE creation so long as someone else provides them instead. In fact we are probably better off dealing with a fellow flight sim enthusiast rather than a mega corporation. The tools have been available for a long time and in some cases so have the FDE. The real problem is that we have not attracted those members of our community who can program in C into FDE creation. FSUIPC has never been exploited to anywhere near its full potential by FDE authors. I would love to see what a gauge guru with extensive experience of writing code in C could do in a (partial) flight model outside MSFS, using FSUIPC to overwrite the output of the MS flight model. Bypass operations for MSFS are the future of realistic FDE authoring. MS are never going to fix the MSFS flight model, or its associated flight dynamics files so that transonic drag, two speed supercharging, etc., can be replicated with any significant accuracy. It will take someone who can program in C to write the bypass module to a specification provided by an FDE author. Air files are still relevant, but since FS5 we have not been limited by their capability. We must be careful not to become obsessed with air files to the extent that is still necessary within CFS. The significance of air files diminishes with every new version of MSFS. The solutions increasingly lie outside the air file and opportunities to create better FDE are being missed. FSAviator

[Guest SHORT360]

Hi PC aviator,You wrote"I would love to see what a gauge guru with extensiveexperience of writing code in C could do in a (partial)flight model outside MSFS, using FSUIPC to overwrite theoutput of the MS flight model."You aare absolutely right. Oleksyi Frolov's Dash8 is a plane programmed from scratch. The entire core in in a gauge called "maingauge" which does everything.That's why that plane is the best plane ever made for any desktop flight simulation. But being a prop freak with real world flying experience, I will download the Convair and test it. RegardsRoger

[Guest Ron Freimuth]

<>>There does not appear to be sufficient evidence that a littleextra friction between a cylinder and a piston separated by afilm of oil is a significant source of heat in a furnace.Ignoring the friction heat change looks sensible. Ring friction is the major source of mechanical losses in piston engines. Total friction losses are roughly equal to thermal losses. Theoretically, the thermal loss goes out the exhaust pipe. However, there is a considrable heat transfer to the cylinder head and wall. I'd figure direct heating depends on fuel flow, BMEP, etc. While ring friction accounts for a good part of 'friction HP'. One can easily estimate the heat equivalent of 'friction HP'. It tends to vary with RPM^3. Rather than try to work out the physics directly, I'd just generate a CHT variable that varied as a*BMEP + b*RPM + c*RPM^2 +... Then, find a combination of constants that appeared reasonable. In fact, I have curves from AVWEB that show Turbine IT, CHT, EGT, fuel flow, etc. for a SEL turbochared AC. <>>It already does. The problem is not in the CHT code. The bugis in the mixture code. The mixture algorithm does notrecognise an over rich mixture as such. I cannot see anyevidence that MS understand this issue or intend to addressit. Resolving it requires an FSUIPC based solution. I got the Mixture curve quite good just before FS9 came out. Its main use is to set SFC and HP vs Mixture. Then, MS messed it up with FS9, which ignors that table and sets its own, rather poor variation. CHT does not vary with Mixture in MSFS. I'm not sure how to add the variation, but have curves from real engines that show the form. On the rich side, one could consider the heat of vaporization of unburned fuel. That's why 'rich' is used at high power settings, excess fuel cools the mixture. When set quite lean, there is simply less fuel to burn, and excess air helps keep the combustion temperature down. However, I don't think EGT peaks exactly where the above model would predict. Further, CHT starts dropping before EGT peaks. The curves are similar, but not identical. Also, CHT is filtered by thermal mass, while EGT changes almost immediately. Further CHT is reduced by more cooling air flow, so it depends on EAS, cowl dynamics, and cowl flap setting. The effect of cooling air flow is already modeled, and there is a parameter in the AIR file to adjust the cowling restriction. Also, a CHT Time Constant. But, to use those effects I'd have to start with the FS CHT, then change it to account for the correct variation. --------------------RF<>>The singular 'spoiler' variable has incremental use. We cancode the angular increment for each event. For example in theDC-7, one increment for each of four sets of cowl flaps and abigger increment for the main gear when it is lowered(without the nosewheel) as two air brakes. The onlylimitation is that the drag is applied along the datum line. One can set Cd, CL, and Cm with only one 'spoiler' avaiable. But don't have one 'spoiler' to modify CL, another to modify Cd, etc. I know one can add up different drags and apply them to the single spoiler. Though, non parasitic may have to be corrected by 1/q or something else. The combination of Cd plus Cm offsets the drag vector vertically. I assume the spoiler drag without any Cm is set on the vertical location of the wing. Similar to the flaps. The vertical CG and vertical CoL are adjustable in FS. However, they should be appropriate for the airframe, not distorted to move the 'spoiler'. FSUIPC is not the best way to interface these things. It can't interface with XML, requires registration (even if free, an added complication), and often has bugs. Further, there is a limit as to how rapidly one can access remapped FSUIPC variables. Many commerical gauge programmers access the FS variables directly. That also is problematical since they tend to change between FS versions.Ron