Re: [Flightgear-devel] JSBSim Piston Engine Idle
Ron, From experience: the lyco IO540 idles at 14-15 inHG, 900RPM (MT-prop with P-880-xx governor) Eric From: w...@jentronics.com To: flightgear-devel@lists.sourceforge.net Date: Sat, 8 Dec 2012 12:12:23 -0700 CC: jsbsim-de...@lists.sourceforge.net Subject: [Flightgear-devel] JSBSim Piston Engine Idle I took a quick look through the FGData Aircraft directory today and came up with a list of some 27 JSBSim piston engines that still seem to be using either the old aeromatic default values for idle manifold pressure (minmp) or suspiciously low values. As time permits this week I intend to take a deeper look at this list and adjust the minmp value as seems appropriate, if there are no objections. I know a couple of engines have different versions in other repositories (JSBSim or personal hangers) that are updated and just need to be copied into FGData. Ron Probably won't idle: Aerocar/Engines/Lycoming_O-290.xml: minmp unit=INHG 6.0 /minmp an2/Engine/ASH-62IR.xml: minmp unit=INHG 5.0 /minmp Boeing314/Engines/WrightGR-2600.xml: minmp unit=INHG 6.0 /minmp c150/Engines/eng_O-200.xml: minmp unit=INHG 6.0 /minmp c172r/Engines/engIO360C.xml: minmp unit=INHG 6.5 /minmp c182/Engines/engIO540AB1A5.xml: minmp unit=INHG 6.5 /minmp c182rg/Engines/engIO540AB1A5.xml:minmp unit=INHG 6.5 /minmp c310/Engines/engIO470D.xml: minmp unit=INHG 6.5 /minmp c310u3a/Engines/engIO470D.xml: minmp unit=INHG 6.5 /minmp dc2/Engines/R-1820-R52.xml: minmp unit=INHG 6.0 /minmp dc6/Engines/CB17.xml:minmp unit=INHG 6.0 /minmp dc6/Engines/eng_R-2800.xml: minmp unit=INHG 6.5 /minmp Dragonfly/Engines/Rotax582.xml: minmp unit=INHG 2.1 /minmp Dromader/Engine/engine_Asz-62IRM18.xml: minmp unit=INHG 5.0 /minmp fkdr1/Engines/Oberursel-UrII.xml:minmp unit=INHG 6.0 /minmp flash2a/Engines/503.xml: minmp unit=INHG 2.0 /minmp Lockheed1049/Engines/WrightCyclone-975C18CB1.xml: minmp unit=INHG 6.0 /minmp Lockheed1049h/Engines/WrightCyclone-972TC18DA3.xml: minmp unit=INHG 6.0 /minmp Lockheed1049h/Engines/WrightCyclone-975C18CB1.xml: minmp unit=INHG 6.0 /minmp Noratlas/Engines/Bristol-739.xml: minmp unit=INHG6.0 /minmp ogel/Engines/200hp-jsbsim-2.0.xml: minmp unit=INHG6.0 /minmp P-38-Lightning/Engines/Allison.xml: minmp unit=INHG6.0 /minmp p51d/Engines/Packard-V-1650-7.xml: minmp unit=INHG4.0 /minmp PBY-Catalina/Engines/PBY-6_engine-new.xml: minmp unit=INHG 6.0 /minmp Skyranger/Engines/rotax.xml:minmp unit=INHG6.0 /minmp Storch/Engines/Argus_As_10.xml: minmp unit=INHG6.0 /minmp Maybe: G-164/Engines/R-1340-AN1.xml:minmp unit=INHG 7.0 /minmp Good: A6M2/Engines/Sakae-Type12.xml: minmp unit=INHG 10.5 /minmp b29/Engines/eng_R3350.xml: minmp unit=INHG 12.0 /minmp c172p/Engines/eng_io320.xml: minmp unit=INHG 8.3 /minmp C684/Engines/6Pfi.xml: !--minmp unit=INHG 6.0 /minmp-- Cap10B/Engine/LycomingIO360B2F.xml: minmp unit=INHG 12.0 /minmp Cessna337/Engines/engine_IO360C.xml: minmp unit=INHG 15.0 /minmp ercoupe/Engines/c-75-12.xml: minmp unit=INHG 10.0 /minmp Nordstern/Engines/eng_Maybach_Mb_IVa.xml:minmp unit=INHG 9.0 /minmp SenecaII/Engines/tsio360eb.xml: minmp unit=INHG 10.0 /minmp Short_Empire/Engines/eng_PegasusXc.xml: minmp unit=INHG 10.0 /minmp Submarine_Scout/Engines/eng_RRhawk.xml: minmp unit=INHG 10.0 /minmp ZivkoEdge/Engines/io540.xml:minmp unit=INHG 10.0/minmp ZLT-NT/Engines/engIO360C.xml: minmp unit=INHG 10.0 /minmp -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
On Tuesday, December 11, 2012 00:40:16 Torsten Dreyer wrote: Hi, let me chime in here with a personal note, hoping it's not offending anybody. Hi Torsten, and thanks for your detailed message. Let me explain below why realistic radio propagation should be inside Flightgear, and aleviate some of the fears about performance (leaving aside the fact that I would leave the system disabled by default, except for those who are really interested, like flying in an area which requires realistic radio factors). Although I like having accurate and detailed computation of our real-world simulation, I'm not really a friend of the radio propagation code with the level of detail given. Please let me explain why that is the case: The radio stations used for aviation purpose certainly follow the same physical laws as any other radio station does. However, their performance have to adhere to some specific rules, mostly set up by the ICAO. Service volumes is on of these rules, a straight ILS final track is another etc. If real life's environment disturbes the performance of the radio stations, the operator has to work hard to override these environmental impacts. As we usually do not have any detailed information about how the radio station is set up (and I doubt, we will ever get those), it's close to impossible to correctly model radio probagation of a specific station. Well, it certainly is possible to take into account terrain, free-space loss, diffraction over mountain edges and other such stuff the ITM algorithms allow for. All I know is that now, sitting on the ground 88 km away from a VOR station, with hills in between, I have needle deviation. Impossible. Please consider that having realistic radio navigation according to terrain would be as far as I know a unique feature for any flightsimulator I've seen. To refuse to add such a realism enhancing feature would be quite illogic to me. Adding envirionmental factors besides terrain and terrain cover and the factors of aircraft installations will result in a wide range of uncertainty, spoiling all the detailed computation of the radio signal propagation. Terrain, terrain landcover, and frequency of station are exactly the factors involved in my calculations, the rest comes from published data and equipment specs available all over the web. If needed, I can bring on board a specialist, but I'd rather await request. If needed by a research project, any station can be tuned like in the real world, and evaluated within the simulator. As a pilot, I am usually just interested in the factor, if I am within the service volume of a radio station. If so, I'd expect a clear and correct indication, probably with the well-known system errors applied. If I am outside the service volume, the systems may show something, but I do not really care about what exactly an ILS indicator (as an example) is showing. I will make my case with just two screenshots, available from the wiki article, re: published volumes. http://wiki.flightgear.org/images/e/e0/Vor_no_itm.png no real radio http://wiki.flightgear.org/images/c/c6/Vor_itm.png realistic radio Or consider for DME equipment, which is very much more affected by terrain than VOR, due to the 10x times higher frequency: http://wiki.flightgear.org/File:Vor-no-dme.png :VOR with no DME due to propagation over edge of mountain for lower VHF freqs. http://wiki.flightgear.org/File:Vor-dme.png :VOR with DME measurement, once obstruction was cleared. From real life experience, I can say that barely two stations behave the same if you are outside their published range. Sidelobes of a localizer may appear at on site and may not at another site. False glideslopes appear here but do not show up somewhere else. It depends heavily on the local setup of the base equipment (and to some degree on aircraft installations). However, I have seen the shoreline effect of ADF stations deflection my ADF needle heavily and I have seen effects of nearby thunderstorms and lightning on the instruments. I'd love to see these effects modeled. If I remember correctly, Flightgear used to be used also in university projects, ARINC, etc. Has that changed? The ILS with it's two components is modelled rather simplistic right now. But still it's not possible to receive if obstructed by terrain, trees, buildings etc. Also, the fact that GS uses a higher, therefore more prone to terrain/clutter interference than LOC, is included. How would you feel to make an approach 10 km with a mountain turn like some airports in Swiss, and have ILS indication even while behind the mountains? That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Thanks to your patient advice and a lot of time spent tuning the system, I can say this: with 3 stations tuned in, the
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
On Tue, 11 Dec 2012 14:20:58 +0200 Adrian Musceac wrote: My suggestion is to include this feature, leave it off, and let anyone interested turn it on. I can't comment on the actual code, but from the repeated detailed descriptions of what it actually does, I think it would be a very great pity if it weren't seriously considered for inclusion. More than that, I can't see why it shouldn't be turned on by default (assuming the performance hit isn't significant) - isn't realism and accuracy what FlightGear is all about? I know that I've sometimes added what most people would think as silly details my models, things that possibly almost nobody has ever noticed... but it all helps to model reality which is the end objective after all! Cheers, AJ -- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 00:55:35 Eric van den Berg wrote: Ron, From experience: the lyco IO540 idles at 14-15 inHG, 900RPM (MT-prop with P-880-xx governor) Eric Thanks Eric, The JSBSim piston engine model is missing something, probably Mach effect through the intake valve, so models tend to idle at lower manifold pressures than real engines. The current code idles most engines around 10-11 inHg, but the oldest code used 6 inHg... Ron -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
I'm not a developer here, I just maintain one of the mirror sites. I would like to comment here a bit. Over the years I've seen several folks who contributed lots to the project leave after disputes over one thing or another. I'd hate to see this lead to something like that! I personally agree with these points, and the final one in particular: snip Please consider that having realistic radio navigation according to terrain would be as far as I know a unique feature for any flightsimulator I've seen. To refuse to add such a realism enhancing feature would be quite illogic to snip I know you are a pilot, fellow amateur radio operator and one of the leaders of the project. So please don't say that you would refuse a realism increasing option, which would not even have to be on by default, and which is not present in any other flightsim that I know of. It would be illogic, and would limit the options of using Flightgear in other environments, like research projects, university, aeronautical radio. It would also make a discouraging statement vs. contributing to Flightgear. snip My suggestion is to include this feature, leave it off, and let anyone interested turn it on. Regards: jj http://kingmont.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
I see. Looking at the code (I think) I can see you are trying calculate the pressure losses in the injector/throttle valve, airbox and inlet tubes. Using throttle position and engine speed (was expecting cylinder displacement here also). Basically your MAP at idle is to low, thus the pressure loss too high. As 99% of the pressure loss comes from the injector/throttle position, I would say for idle power setting the injector air valve should be a bit more open? I assume it is only calculated for indication and not for engine power calcs? Eric From: w...@jentronics.com To: flightgear-devel@lists.sourceforge.net Date: Tue, 11 Dec 2012 06:20:23 -0700 Subject: Re: [Flightgear-devel] JSBSim Piston Engine Idle On Tuesday 11 December 2012 00:55:35 Eric van den Berg wrote: Ron, From experience: the lyco IO540 idles at 14-15 inHG, 900RPM (MT-prop with P-880-xx governor) Eric Thanks Eric, The JSBSim piston engine model is missing something, probably Mach effect through the intake valve, so models tend to idle at lower manifold pressures than real engines. The current code idles most engines around 10-11 inHg, but the oldest code used 6 inHg... Ron -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: I see. Looking at the code (I think) I can see you are trying calculate the pressure losses in the injector/throttle valve, airbox and inlet tubes. Using throttle position and engine speed (was expecting cylinder displacement here also). The displacement is somewhat irrelevant in that it is a constant and can be ignored. The modeler provides two data points; the pressure at full throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. These are used to determine the impedance of the airbox and throttle respectively. In this scheme, the engine is also treated as an impedance which varies with ( 1 / engine speed ) giving infinite impedance at 0 RPM[1] and falling towards, but never reaching, 0 impedance as engine speed increases. We experimented with many other and more complicated intake models early on, and this is the best behaved of the lot. Basically your MAP at idle is to low, thus the pressure loss too high. As 99% of the pressure loss comes from the injector/throttle position, I would say for idle power setting the injector air valve should be a bit more open? I assume it is only calculated for indication and not for engine power calcs? Actually, the manifold pressure is used in three ways in the power calculations. First, it affects the mass flow rate. We assume an adiabatic process so the loss in pressure is accompanied by a corresponding loss of density. Second, the volumetric efficiency is reduced by the intake pressure being less than the exhaust pressure further reducing the mass flow rate. Finally, the pressure difference between intake and exhaust creates a direct power loss as work is performed to pull and maintain the manifold pressure drop. Ron [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
So it is kind of modelled like an air pump. Interesting method. BTW p0 =101325 Pa R = 287.05 Cp_air = 1004.68 gamma = 1.4 Handbook of Aviation fuel properties, third edition: net heat of combustion of AVGAS, all grades : min. 43.5 MJ/kg, 44 typical density of AVGAS: 710 at 15degC C_p_AVGAS = 2.065 kJ/kg K @20degC, approx linear to 2.710 @140degC hope this might improve accuracy (a bit), Cheers, Eric On 12/11/2012 07:35 PM, Ron Jensen wrote: On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: I see. Looking at the code (I think) I can see you are trying calculate the pressure losses in the injector/throttle valve, airbox and inlet tubes. Using throttle position and engine speed (was expecting cylinder displacement here also). The displacement is somewhat irrelevant in that it is a constant and can be ignored. The modeler provides two data points; the pressure at full throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. These are used to determine the impedance of the airbox and throttle respectively. In this scheme, the engine is also treated as an impedance which varies with ( 1 / engine speed ) giving infinite impedance at 0 RPM[1] and falling towards, but never reaching, 0 impedance as engine speed increases. We experimented with many other and more complicated intake models early on, and this is the best behaved of the lot. Basically your MAP at idle is to low, thus the pressure loss too high. As 99% of the pressure loss comes from the injector/throttle position, I would say for idle power setting the injector air valve should be a bit more open? I assume it is only calculated for indication and not for engine power calcs? Actually, the manifold pressure is used in three ways in the power calculations. First, it affects the mass flow rate. We assume an adiabatic process so the loss in pressure is accompanied by a corresponding loss of density. Second, the volumetric efficiency is reduced by the intake pressure being less than the exhaust pressure further reducing the mass flow rate. Finally, the pressure difference between intake and exhaust creates a direct power loss as work is performed to pull and maintain the manifold pressure drop. Ron [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 13:49:51 Eric van den Berg wrote: So it is kind of modelled like an air pump. Interesting method. Piston engines are basically air pumps. We currently calculate power by dividing the mass fuel flow by the user-entered bsfc multiply by correction factors for mixture and spark and subtract a little bit for good measure. The little bit ensures the engine stops spinning if it isn't producing power. The propeller code will keep it spinning under certain conditions, and needs to be fixed up to let it start the engine spinning again... If I were to start over with this model the biggest thing I would change would be replacing the power calculation with the Otto cycle[note 2] pressure calculations. We already (as mentioned) calculate the area of [1:2]+[6:1] as pumping losses.[note 3] The trick to this method is calculating the [3:4] pressure rise to get the area of [3:4:5:6] This should let us roll the egt and cylinder temp calculations into the power loop and make them more meaningful. Right now they are largely just indications, altough egt does indicate power somewhat correctly. That may be done in the future as we can then more easily add a diesel cycle. Ron [2] http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/otto.html#c5 [3] http://mae.wvu.edu/~smirnov/mae320/figs/F9-2.jpg BTW p0 =101325 Pa R = 287.05 Cp_air = 1004.68 gamma = 1.4 Handbook of Aviation fuel properties, third edition: net heat of combustion of AVGAS, all grades : min. 43.5 MJ/kg, 44 typical density of AVGAS: 710 at 15degC C_p_AVGAS = 2.065 kJ/kg K @20degC, approx linear to 2.710 @140degC hope this might improve accuracy (a bit), Cheers, Eric On 12/11/2012 07:35 PM, Ron Jensen wrote: On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: I see. Looking at the code (I think) I can see you are trying calculate the pressure losses in the injector/throttle valve, airbox and inlet tubes. Using throttle position and engine speed (was expecting cylinder displacement here also). The displacement is somewhat irrelevant in that it is a constant and can be ignored. The modeler provides two data points; the pressure at full throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. These are used to determine the impedance of the airbox and throttle respectively. In this scheme, the engine is also treated as an impedance which varies with ( 1 / engine speed ) giving infinite impedance at 0 RPM[1] and falling towards, but never reaching, 0 impedance as engine speed increases. We experimented with many other and more complicated intake models early on, and this is the best behaved of the lot. Basically your MAP at idle is to low, thus the pressure loss too high. As 99% of the pressure loss comes from the injector/throttle position, I would say for idle power setting the injector air valve should be a bit more open? I assume it is only calculated for indication and not for engine power calcs? Actually, the manifold pressure is used in three ways in the power calculations. First, it affects the mass flow rate. We assume an adiabatic process so the loss in pressure is accompanied by a corresponding loss of density. Second, the volumetric efficiency is reduced by the intake pressure being less than the exhaust pressure further reducing the mass flow rate. Finally, the pressure difference between intake and exhaust creates a direct power loss as work is performed to pull and maintain the manifold pressure drop. Ron [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Piston Engine Idle
On Tuesday 11 December 2012 13:49:51 Eric van den Berg wrote: So it is kind of modelled like an air pump. Interesting method. Piston engines are basically air pumps. We currently calculate power by dividing the mass fuel flow by the user-entered bsfc multiply by correction factors for mixture and spark and subtract a little bit for good measure. The little bit ensures the engine stops spinning if it isn't producing power. The propeller code will keep it spinning under certain conditions, and needs to be fixed up to let it start the engine spinning again... If I were to start over with this model the biggest thing I would change would be replacing the power calculation with the Otto cycle[note 2] pressure calculations. We already (as mentioned) calculate the area of [1:2]+[6:1] as pumping losses.[note 3] The trick to this method is calculating the [3:4] pressure rise to get the area of [3:4:5:6] This should let us roll the egt and cylinder temp calculations into the power loop and make them more meaningful. Right now they are largely just indications, altough egt does indicate power somewhat correctly. That may be done in the future as we can then more easily add a diesel cycle. Ron [2] http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/otto.html#c5 [3] http://mae.wvu.edu/~smirnov/mae320/figs/F9-2.jpg BTW p0 =101325 Pa R = 287.05 Cp_air = 1004.68 gamma = 1.4 Handbook of Aviation fuel properties, third edition: net heat of combustion of AVGAS, all grades : min. 43.5 MJ/kg, 44 typical density of AVGAS: 710 at 15degC C_p_AVGAS = 2.065 kJ/kg K @20degC, approx linear to 2.710 @140degC hope this might improve accuracy (a bit), Cheers, Eric On 12/11/2012 07:35 PM, Ron Jensen wrote: On Tuesday 11 December 2012 09:46:10 Eric van den Berg wrote: I see. Looking at the code (I think) I can see you are trying calculate the pressure losses in the injector/throttle valve, airbox and inlet tubes. Using throttle position and engine speed (was expecting cylinder displacement here also). The displacement is somewhat irrelevant in that it is a constant and can be ignored. The modeler provides two data points; the pressure at full throttle and maximum RPM, and the pressure at 0 throttle and idle RPM. These are used to determine the impedance of the airbox and throttle respectively. In this scheme, the engine is also treated as an impedance which varies with ( 1 / engine speed ) giving infinite impedance at 0 RPM[1] and falling towards, but never reaching, 0 impedance as engine speed increases. We experimented with many other and more complicated intake models early on, and this is the best behaved of the lot. Basically your MAP at idle is to low, thus the pressure loss too high. As 99% of the pressure loss comes from the injector/throttle position, I would say for idle power setting the injector air valve should be a bit more open? I assume it is only calculated for indication and not for engine power calcs? Actually, the manifold pressure is used in three ways in the power calculations. First, it affects the mass flow rate. We assume an adiabatic process so the loss in pressure is accompanied by a corresponding loss of density. Second, the volumetric efficiency is reduced by the intake pressure being less than the exhaust pressure further reducing the mass flow rate. Finally, the pressure difference between intake and exhaust creates a direct power loss as work is performed to pull and maintain the manifold pressure drop. Ron [1] Note: Engine speed actually used is mean pistons speed not RPM. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
My suggestion is to include this feature, leave it off, and let anyone interested turn it on. +1 There may be many reasons to reject code, but they roughly fall into two categories: 1) the idea itself which is coded is not acceptable or 2) the actual implementation is not acceptable (unstable, degrading performance,...). Adrian has invested a fair share of time to make it work, and he introduced the project early on in this list. I think fairness asks that any argument of type 1) against including the code should have been given earlier. Otherwise the message sent to possible future contributors is quite negative. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Personally I don't need such a feature, since I'm not so much interested in IFR. However, I think in many situations we do have spare CPU capacity (I usually do - with lots of shader work on, GPU speed seems the limiting factor), and I also think it should be up to the user how he wants to burn his hardware performance - VFR sightseeing people like me want detailed shaders, IFR people may want to turn terrain eye candy off but spend the framerate for radio signal propagation. So including the code as optional feature seems entirely fine to me, I don't think there's such a well-defined 'we' with the same wishlist. So I would also suggest to include it unless there are issues about stability, performance degradation if not running, which I'm not qualified to judge. * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Grass and Dirt material declaration
During the last weeks, someone added the 'Grass' landclass to the 'grass_raw' materials declaration and the 'Dirt' landclass to the 'dirt_rwy' declaration in/ Materials/regions/materials.xml. I would like to undo the changes, or discuss other solutions to fix the problems caused by them - my GIT knowledge isn't good enough to find who committed that, so please get in touch. The problems caused are as follows: * assigning 'Dirt' the dirt_rwy texture changed all rock textures in the summit regions of the Alps in the French custom scenery to dirt runway textures. I realize this isn't as it should be - potentially this could be a scenery-side issue that the summit regions are misclassified as 'Dirt' rather than 'Rock', although I think this unlikely. I've come across similar issues that some landclasses are not really separable - so by some weird effect setting Dirt also previously set Rock for me when I tried this a year ago. I have no good understanding of the underlying issue, but at least till the time this is clarified, I think the error of replacing rock by dirt runway is much worse than replacing dirt by rock. * assigning 'Grass' to 'grass_rwy' seems to suddenly reveal the fact that the green around our airport runways is two different landclasses. Since now 'Grass' gets a size of 75x75 but later AirportKeep Co get a size of 125x125 and in addition specular reflection coefficients, under the right light what formerly seemed a common green now shows pronounced differences in color and texture. For the same reason, the change spoils my RealGrass(TM) overlay texture scheme, which unfortunately inherits size and specular reflection and shows the same differences in an even worse way. I'm not quite sure why these two changes have been introduced, but maybe we can find a solution without such bad side effects? * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
