xml lift formula

[Guest Ron Freimuth]

>Hi,>>This goes a little bit much over my head of course.>I tried with weight, temperature, altitude (density etc.),>vert. spd., pitch etc.>Then calculate a constant for the different flight stages and>so a number to set the throttle-axis.>But....not very reliable.>At least can you say which factors i have to consider to come>a little bit closer.>E.g. influence of weight, temp., alt. etc.>Jan A lot of what I posted I learned from the Boeing 'Flight Engineering Manual' and other texts. Others also worked some things out. MSFS pretty much corrects for the effects of temperature variations -- as long as one uses 'corrected' values as appropriate. The corrected values account for changes in Temperature; the gauge (uncorrected) values vary with absolute Temperature. Warmer air is less dense, so higher gauge RPM's are required for the same effect. Corrected RPM's don't vary with temperature. This simplifies matters. The climb approach I gave accounts for different flight weights. If weight is high one has to climb at a higher IAS to make Cdi ~ Cdo/3. However, his vertical speed will be lower due to the higher weight. ------- There are several thrust ratings I'm aware of. What I call "Relative Thrust" is [Thrust/TO_SLThrust] * 1/Delta. Where 'Delta' is 1/IAP (Inverse Atmospheric Pressure), the same IAP in the turbine tables. Delta is 1.00 at SL pressure, so Relative Thrust = 1.00 at TO rating. As the AC climbs, Delta decreases, and so does Relative Thrust. Further, one soon reduces Relative Thrust below TO rating. To maybe 90% for the climb. Due to using Delta, rather than Delta_Total (which is what the turbine sees at the Intake), Relative Thrust can be allowed to increase as the AC approaches cruise FL. Boeing says to as much as 120%. Another turbine limit is RPM. That is generally given as %N1 and %N2. 105%, 102% is typical, the values are given in the TCDS. One would see higher N's at higher than ISA temperatures, which might require the pilot to keep the RPM's below the maximum safe value. More modern turbines are automatically limited. Finally, there is EGT. That may be the first limit hit. It seems my 727 EGT ran about 50 C below the maximum at rated TO power at 15C, but at higher airport temperatures it would go higher. Note two of the above limits are related to Temperature. A derated power TO simply assumes the temperature is higher than actual, then the TO thrust is set for the rated N1 or EGT at that higher temperature. This increases turbine life, but is only appropriate for long runways and/or light TO weights. Tom appears to have figured out all these details. He has also been working on his XML gauges for a long time. ;) I think much of the detailed approach could be done in a suitable spreadsheet. So one need only enter a few significant data points, perhaps from a FM table, to generate turbine and gauge tables. However, no one has attempted such a SS. ------------------- I wrote some info in a text file some years ago, I'd suggest the approaches I give in it for a good start. At that time I didn't understand the more advanced stuff, but still was able to get reasonably accurate N1 and PPH readings. Ron

[taguilo 33]

>> Tom appears to have figured out all these details. He has>also been working on his XML gauges for a long time. ;)>Well, Ron has helped me out to understand quite a lot of aircraft data relationships and other useful info. His XML Jet Test is a gem; one can find tests for almost every technical var; sometimes it is even easier to follow his code than to understand his explanations :-)Now, for TO/CLB/CRZ Thrust managing I use Boeing tables translated straight into XML (I call them 3DTables), and parsed with macros specifically designed for that. Tom

[phjvh 0]

Hi,I use something similar, but i ask myself often when flying, why not back to the simple altitude dependend system with MS AP:TOGA0-2500 ft accelerate to 210 kts.2500-10000 250 kts.>10000 300 kts until M 0.7.M 0.7 up to efficient FL.Then M 0.8 till point of descent.Next idle and get awake again.But realism...................!!Jan"Beatus ille qui procul negotiis..."

[Guest Ron Freimuth]

>I use something similar, but i ask myself often when flying,>why not back to the simple altitude dependend system with MS>AP:>TOGA>0-2500 ft accelerate to 210 kts.>2500-10000 250 kts.>>10000 300 kts until M 0.7.>M 0.7 up to efficient FL.>Then M 0.8 till point of descent.>Next idle and get awake again.>Jan The 'no FM' approach I mentioned should give results similar to using FM tables --- assuming my approach includes the significant parameters and the FM is realistic. However, it wouldn't have the granularity flying by the tables gives. One really wants an FMS that approximates the real one. All sorts of performance data might be coded in an FMS. Or, it might be more just a lookup approach that uses digitized FM tables. I don't know the details -- I can only speculate. I wrote some XML code to try to follow a climb/descent profile. Hold FLIGHT SLOPE to maintain 250 kts IAS to 10,000 ft, then drop the flight slope slowly so the AC would accelerate to a preset 'above 10000 ft' IAS. When Mach 0.78 was hit, increase flight slope to maintain that. Manual control of the throttle sets the vertical rate. Drop power and the descent should mirror the ascent. The cruise FL would also have to be set, at that FL slope would go to zero. Though, ALT hold is really needed in the end. I had problems transitioning from IAS to Mach, then back from Mach to IAS. I think my coding needed some 'memory' or hysteresis. While manual control of the throttle set ascent, descent rate, that could be automated. One could try to hold the appropriate N1 or EPR, which would vary some with conditions. Or, it might be that using that 'Relative Thrust' parameter would work. Automatically setting it to 90% at lower climb levels, increasing to 110% near cruise FL. One could use a straight line fit to change Relative Thrust as pressure altitude increased. One might select from a set of lines, depending on current TAT and/or EGT. So Relative Thrust ran from say, 87% to 107% at higher than ISA temperatures. With a bit of luck, he might find the panel values were close to those of the real AC when the appropriate 'straight line' fits were used. Note controlling the throttle to straight lines should be simpler than trying to control it from a big set of FM data. Typically I've gotten more ideas as I implemented more XML coding to show significant parameters. I'd watch the Test Gauge as I flew and eventually note things that might be of value in automatic flight control. When I wrote XML control code, I'd slowly build it up to get closer to the results I wanted. Quite a bit of cut and try. Note good core code could be embedded in many different FMS systems. The trick would be to get the good core that was available to anyone who wanted to use it. If programmed in a DLL, it could be licensed to the payware people. Ron

[Guest Ron Freimuth]

Here is a screen shot I took of my two 'Jet Test' windows during a B707 flight.http://forums.avsim.net/user_files/167874.gif The left window is more engineering oriented. Speeds are in ft/sec. Sorry, the black window BG may not display correctly. Half way down (in orange) one sees total Drag and several components. Fnx is 'thrust_net, excess'. It will be 0% in unaccelerated, level flight. Fnr is 'thrust_net, relative'. Explained in other messages. Note it is only 18.98% at this flight condition. However, the B707 is not in level, unaccelerated flight. Vs is -32.36 ft/sec and there is a small acceleration, Vdot, of 0.05 ft/sec^2. A few other parameters: Near the top, 'SFC' is 0.840. Set in aircraft.cfg. Spc Range is Specific Range (NAM) in nm per 1000 lb fuel. 'Ld/D' is essentially Lift/Drag. An important criteria, the B707 approaches L/D of 19 in optimum flight. 'Ldw/DltA' is Wing Loading relative to Delta_ambient. It increases as pressure altitude increases, excessive values result in less efficient flight. I don't pay much attention to most of the values displayed. Ron

[WarpD 824]

I needed to calculate lift/drag to implement VNAV functionality.The jet I'm working on has a FADEC throttle system which controls N1 levels based on pilot's positioning the throttles, but doesn't have an autothrottle, per se. It has a scheduled N1 value based on throttle position/weight/altitude.The drag calculations you offered give me fairly accurate drag in straight flight, but are off a bit whenever the aircraft banks.As for making a module available to all, the problem with that is if a commercial application is released the author(s) tend to get tired of their work being used without compensation (FSUIPC is a good example).So, while I could most likely develop such a module, I won't simply because I don't want to travel down that 'slippery slope'. I develop both commercial releases as well as have plans for a freeware panel release. So, I simply code the flight management into my gauges so no one can claim them for their own. The gauges are tailored (intentionally) for the specific aircraft and not for use on any aircraft desired.

[Guest Ron Freimuth]

>I needed to calculate lift/drag to implement VNAV>functionality.>>The jet I'm working on has a FADEC throttle system which>controls N1 levels based on pilot's positioning the throttles,>but doesn't have an autothrottle, per se. It has a scheduled>N1 value based on throttle position/weight/altitude. That means thrust vs N1 has to be accurate. Setting a scheduled N1 is how I'd suspect such a system would work. I'd think the equivalent of FM tables are in the FMS. Or, equations that approximate them. I adjust my turbine throttle tables so N1 changes appropriately with FL and Mach; then I don't have to change the throttles (much) during a climb; "Relative Thrust" tends to vary appropriately. However, the throttles may have to be adjusted for differences in Temperature. I think Tom broke the throttle to turbine link so his controller set the throttle position. That's probably what you want. One might want to create his own Throttle variable and use it to set the controller. I'm not sure that would be easy to accomplish.>The drag calculations you offered give me fairly accurate drag>in straight flight, but are off a bit whenever the aircraft>banks. The drag equations that depend on AoAe should give correct values in a bank. Since AoAe has to increase as Bank increases, calculated Cdi also increases. However, if there is any slip, then Side Forces add to the drag. Neither my test gauges nor AFSD account for the Side Forces. I think the Side Forces could be accounted for. Note when there is some Yaw, part of the Side Force has a longitudinal component. I fact, I determined some time ago that extra drag varies nearly as q*S * CY_beta * Beta^2. See Aired Info for CY_Beta. CY_Beta is the largest Side Force, Rudder Deflection adds some CY_dr, but that's normally small. The other two Side Forces are zero when Roll and Yaw rates are zero. Regardless, in a turn with only a couple of degrees of Yaw, the Side Force drag is negligible. The effect on Drag is significant at 15 deg Yaw/Slip, that increases the descent rate when one slips to a landing in a small AC. AFSD may report an excessive Cdi in such conditions since it assumes any drag not accounted for by Cdo, Cdm, Cdlg, etc. is due to induced drag. Prop AC may also have prop drag at idle throttle settings. Ron